Finding a Balance Between Staying Hands-On and Letting Things Go

Lee Van Steerthem

Site Reliability Engineering Lead at Aaqua



Every manager has lived through this dilemma: should I remain close to my team -- whether to feel their pain or show by example -- or transition into my new role, distancing myself from the team.

I always believed that being as close to a team as possible is critical. In the past, I had managers who were so far from the frontlines that we felt rather detached from them. Whenever we would try to explain something to them, we could tell they were struggling to grasp it. That experience only strengthened my belief that as a manager, one needs to know what the team is doing and be capable of contributing by occasionally working with them. A manager should be an integral part of the team, not a distant figure that merely oversees the work.

Actions taken

There are many different scenarios a new manager can find themselves in when trying to strike a balance between staying hands-on and having the team pick up the work by themselves. When I want to encourage my team to take the initiative while still being there as a mentor, I will double down on pair programming. They would own the tick et, and I would be a rubber duck, a soundboard that they can ask questions. If they asked me how I would do it, I would give them some pointers. The idea is that they could take ownership and lead the process from beginning to end while expanding on their expertise.

There is another typical engineering situation that illustrates how one can balance delegation with staying hands-on. During an incident, people are assigned two main roles: an incident commander who instructs everyone else what to do without doing the work itself and subject-matter experts who do the actual fixing. Although I am the one to have the most knowledge, I would encourage someone else to take on the role of the incident commander. The incident commander would be the central facilitator, who would organize the team for the biggest impact.

I am always aware of the need to stay close, so I don’t feel detached from my team. When I see my team struggling, I would ask if they need another pair of eyes, if they need me to be a rubber duck or if I could help in any other way. I would say: “What are you stuck with? How will you be able to move forward with this?”. If you are detached, you will not be able to understand what they are doing, let alone help them with it. Knowing the workflow in and out is crucial. If a ticket stays too long in progress, there might be something that is troubling them.

However, balancing means taking the reverse action too. I had to learn to stop getting into the urge to fix things for the team. The first step will be to establish if it is a one-off thing or something recurring. Constantly fixing something for them would make me a bottleneck in addition to preventing their growth. Again, this is very much connected with the overall problem of delegation and knowing how much time I should be spending teaching the team and how much time I should be doing the work myself. If everyone could do all the work, it would help the team, but it would help me too. If I am the only person that can do something, we have a problem. I should also try to document processes to make them sustainable and enable the team to be more proactive.

I value autonomy a great deal and would heavily invest in making the team autonomous. The team that is autonomous is more proactive and is willing to explore various solutions before asking for permission. By doing so, they would be able to come up with much more creative solutions than I ever would. Encouraging them to be more autonomous also helps level the team up and have them feel empowered.

Lessons learned

  • Find time to reflect on what went well or what you learned at the end of every week. That helps knowing where to draw the line between delegation and staying hands-on Be aware of the things that only you can do. For example, there is only one person on the team that is tasked to do interviews, communicate with other people, enable them, and manage people who are doing IC work. If you start doing IC work, who will take care of people? No one. People are not anyone’s responsibility but their manager’s. It helped me realize that if I don’t put in the time, no one else will. People can fill their time with different types of work, more or less meaningful. No one will step into your shoes because it is your job to ensure that the team is happy and unblocked.
  • Currently, I am witnessing many people leaving my previous team. I always felt a strong connection with them, and they knew I was there to help them. Finding out that so many were leaving the team made me curious. I learned that they felt abandoned by their manager, which proved that connecting with people and understanding what is going on is a formula for success. I believe that my approach of being a people and technical manager at the same time is something most people appreciate tremendously.
  • I wholeheartedly recommend the book Herding Tigers: Be the Leader That Creative People Need by Todd Henry, which most compellingly explains why one needs to stop working and become a mentor without falling into a rescuer trap.

Be notified about next articles from Lee Van Steerthem

Lee Van Steerthem

Site Reliability Engineering Lead at Aaqua

CommunicationEngineering ManagementMentorship ProgramsTechnical ExpertiseCareer GrowthSkill DevelopmentLeadership RolesEngineering ManagerAgile, Scrum & KanbanTeam & Project Management

Connect and Learn with the Best Eng Leaders

We will send you a weekly newsletter with new mentors, circles, peer groups, content, webinars,bounties and free events.


HomeCircles1-on-1 MentorshipBounties

© 2024 Plato. All rights reserved

LoginSign up