Every software engineer, at some point, faces an important decision about their future career path.
Should they continue as an individual contributor, deepening their technical expertise and taking on more hands-on responsibilities? Or should they transition into management?—a role traditionally seen as stepping away from hands-on work to focus on people, strategy and leadership.
On the contrary, Engineering Managers are no strangers to hands-on technical responsibilities. Many of them were once solid, if not the best, software engineers. In the first few years of transitioning into management, they often still find time and opportunities to code and stay technically involved. But as time passes, other managerial duties start to take priority, and they may find their technical skills becoming rusty. Over time, some of them even start to advocate for “managers don't need to be hands-on” and become more rigid in what they prefer to do.
However this doesn’t fit the bill in recent years. As teams become leaner and focus on maximizing efficiency and throughput, Engineering Managers are expected to roll up their sleeves by diving into the details and fully contribute to the team’s success.
Why should EM be hands-on?
Take a VP of Sales at a startup. In an entrepreneurial company, this person would not only run the sales funnel and coach the sales team but also have a “sales quota” of their own. In other words, they would need to get their hands dirty by going out and meeting clients to land new accounts to help grow the business.
Similarly, as an Engineering Manager, you need to have your own form of “sales quota”—a set of key hands-on contributions that comes directly from you. These goals aren't just about managing the team from far away but also about actively contributing to the work and ensuring your direct involvement in what your team is doing.
You need to be hands-on to:
Be available: Your presence for your team is crucial. Even if you don’t have all the answers, jumping on a quick call to pair with an engineer can help. Even just being there to listen as a “rubber duck” shows support and will keep you informed on the team's work.
Call the shots when in crisis: During a crisis, your team will look to you for quick, informed decisions. If you're familiar with the details, you can confidently step in and lead through tough situations, like addressing sudden performance issues or unblocking your team in a crucial product launch. Being hands-on ensures you can guide the team effectively when it counts.
Be aware of your team’s day-to-day hurdles: It's essential to be aware of your team’s blockers and challenges, whether technical debt, unclear requirements, or process inefficiencies. By staying close to their daily work, you can clear these obstacles, helping the team progress without unnecessary friction.
Work up a low-performing team: When the team’s performance drops, your hands-on involvement allows you to diagnose deeper problems, like gaps in skill sets or misaligned priorities. Working closely with the team helps you develop targeted solutions, whether it's through mentorship, process adjustments, or technical guidance, to elevate their performance.
Set technical direction and act as a bridge: Without being hands-on, you can barely act as a bridge between senior leadership and your team, translating non-technical business context to technical details that’s relevant to your team and vice versa. There will be times where you need to advocate for technical initiatives that otherwise get de-prioritized if not well explained to the non-technical stakeholders.
Maintain your credibility: When your team sees that you understand the technical aspects of their work, they are more likely to trust your decisions and look up to you as a leader. Being in touch with the challenges they face allows you to offer meaningful support and guidance, ensuring that your input is valued. Without this credibility, your influence could diminish, and your team may become less confident in your ability to lead them through complex situations.
How can EM be hands-on?
Being hands-on is more often seen as coding. While it may not be feasible to code full-time, picking up small tasks or contributing to a side project allows you to stay familiar with the technologies your team uses. It also keeps your technical skills sharp without taking on the full workload of an individual contributor. But is coding the only way to stay hands-on?—Not really.
During my second managerial stint, I had the opportunity to lead a newly formed mobile team, as well as a platform team responsible for managing our DevOps infrastructure and building tools for our product teams. Coming from a back-end background, it was both exciting and intimidating, as I had no prior hands-on experience with these technologies and was unfamiliar with the challenges the teams would face. Over the course of a year or two, I gradually learnt my way up by pairing with engineers, debugging issues, and getting acquainted with the technologies. I vividly remember referring to a DevOps manual to fix a load balancer configuration myself in AWS, bringing our backend system back online, and on another occasion, working with a mobile engineer to debug the performance of a third-party SDK, eventually refactoring the entire integration in three weeks’ time.
Do I consider myself an expert in these technologies after a couple of years leading these teams? Not quite, nor was that my goal. What I gained was the ability to lead teams working with diverse tech stacks and the value being a hands-on manager brings.
Besides coding, you can stay hands-on through:
Code Reviews: Participating in code reviews allows you to stay up to date with the team’s technical approach, best practices, and code quality. It's also a great way to provide feedback, share insights, and mentor your engineers, without fully diving into coding.
Contribute to Architectural Decisions: Being involved in high-level architectural discussions helps ensure that you understand the long-term technical direction of your projects. By contributing to key decisions, you stay engaged in the technical roadmap, while guiding your team through complex design challenges.
Pick up a Technical Discovery Task: From time to time, take ownership of a technical research or discovery task. This might involve investigating a new tool, testing a new feature, or exploring solutions for a specific problem. This hands-on approach sharpens your problem-solving skills and lets you contribute individual value to the team.
Monitor Your Technical Systems: Keep an eye on the performance of your team’s systems through monitoring tools. Regularly reviewing system metrics and logs helps you understand the current health of the infrastructure and stay aware of potential issues before they escalate.
Play the Role of On-Duty (On-call): Occasionally taking on on-call duties allows you to directly experience the operational side of your team's work. Handling incidents, diagnosing problems, and supporting your team during outages helps you stay close to the real-time challenges your engineers face.
Pairing: Pairing with an engineer on complex problems gives you an opportunity to work together on solutions. It’s a great way to stay hands-on while coaching and guiding your team through tough technical challenges.
Caveats
Then there’s the other end of the spectrum. Being overly hands-on and working almost like another individual contributor in the team. You have to be aware of the following caveats so that you don’t overdo it.
Don’t be in the critical line: While it’s important to stay hands-on, you should avoid putting yourself in a position where you’re responsible for delivering critical tasks. If you're too embedded in the team’s day-to-day work and the success of key tasks depends on you, it can create bottlenecks. As a manager, your role is to ensure the team functions smoothly and autonomously, not to hold up the flow by being overly involved in execution.
Don’t become a single point of failure: At any point, if you step away, your team should continue operating smoothly. If you're too hands-on or the sole person handling a key area, it creates dependency and undermines your team’s autonomy. Your goal should be to foster a team that can work independently, making sure knowledge and ownership are distributed evenly. If you can step away and the team still delivers effectively, you’ve done your job right.
Don’t be carried away: Being too hands-on means you’re likely spending more time focusing on immediate tasks, leaving you less room to plan for the future and think strategically. Engineering Managers need to balance the tactical (day-to-day problem solving) with the strategic (long-term planning, vision-setting, and team development). If you’re too focused on the present, you risk losing sight of larger, future challenges. The key is to find a balance between guiding the team on current technical challenges and stepping back to work on broader goals.
If you do things yourself, you’re not letting your team learn: When you take on technical tasks that could be handled by your team, you inadvertently deprive them of learning opportunities. Your job as a manager is to enable and coach your engineers, not solve problems for them. If you step in too often, they won’t develop the skills or confidence to tackle challenges on their own. Focus on supporting and mentoring, allowing the team to grow and take ownership of their work, while you provide guidance when needed.
You should look to hit that sweet spot where you're hands-on enough to stay on top of your team’s work but not overstepping on your team's efforts or that detracts you from doing actual leadership.
Now, It’s Your Turn
Here are some questions to help you assess your level of hands-on involvement as an engineering manager:
How often do you code or contribute directly to the team's technical tasks?
Less hands-on: Rarely codes or contributes to technical tasks.
Too much hands-on: Regularly codes or takes on critical tasks meant for the team.
Sweet spot: Occasionally contributes without taking on key deliverables.
How do you stay up-to-date with your team’s technical work?
Less hands-on: Relies only on updates from others and isn't directly involved.
Too much hands-on: Participates heavily in the team’s day-to-day technical decisions.
Sweet spot: Engages through code reviews, pairing, or architectural discussions.
Are you a critical point of dependency in the team’s deliverables?
Less hands-on: No direct involvement in solving urgent issues or unblocking the team.
Too much hands-on: Team’s progress often depends on your technical contributions.
Sweet spot: Available for critical decisions and support without being a bottleneck.
How do you balance tactical work with strategic planning?
Less hands-on: Mostly focused on long-term strategy without involvement in technical challenges.
Too much hands-on: Spends too much time on immediate tasks, neglecting future planning.
Sweet spot: Engages in both technical problem-solving and strategic leadership.
How often do you guide the team versus solving technical problems yourself?
Less hands-on: Rarely engages in problem-solving or guiding the team on technical issues.
Too much hands-on: Regularly solves problems for the team rather than coaching them.
Sweet spot: Coaches and supports the team in solving problems, stepping in only when needed.
Your team is facing a critical outage, what’s your course of action?
Less hands-on: Stays out of the immediate issue, relying entirely on the team to manage the resolution without providing real-time guidance.
Too much hands-on: Takes complete control of resolving the outage, stepping in to handle the issue personally and potentially sidelining the team.
Sweet spot: Stay in close touch with your team but give the autonomy and focus time for your team to resolve the issue. Keep yourself available for quick consultation and bring in necessary resources and support from other teams, if needed.
How do you balance being hands-on while managing your responsibilities? I’d love to hear your thoughts and experience.