Hands-on Engineering Manager

Leaders' Stories: Ananth Ramachandran on Being Effective Engineering Leader

In recent years, the IT industry has become challenging with layoffs, budget cuts, focus on devs’ productivity optimizations, or flattening tech organizations. These all don’t only affect individual contributors but also engineering leaders. I covered some of these changes in the article "Do Companies Need Fewer Engineering Managers or Better Engineering Managers?".

One of the most common expectations of engineering leaders today is to be hands-on while still managing people. Engineering Managers, Directors, and even higher positions must not only assign tasks, discuss priorities, and set engineers' schedules but also get their hands dirty. 

This time, I invited Ananth Ramachandran, the Engineering Manager at Vinted, author of Engineering Manager Guide and the book The Complete Engineering Manager, to share his experience and advice on how to be a hands-on Engineering Manager.

Here’s Ananth story:

---

Many engineers wonder if stepping into management means giving up coding forever.

However, Engineering Managers aren’t strangers to hands-on technical responsibilities. Many were once top software engineers. They often still find time to code and stay technically involved in the first few years. However, as time passes, other managerial duties take priority, and they may find their technical skills becoming rusty.

Yet in recent years, teams have become leaner, so Engineering Managers are expected to roll up their sleeves and fully contribute to the team’s success.

Why should EM be hands-on?

Think of a VP of Sales who still carries a quota. Similarly, as an Engineering Manager, you need your own “sales quota”—a set of key hands-on contributions. These goals aren't just about managing the team from afar but also actively contributing.

You need to be hands-on to:

1. Be available: Even if you don’t have all the answers, jumping on a quick call to pair with an engineer can help. Being present (even as a “rubber duck”) shows support and keeps you informed.

2. Call the shots in a crisis: During a major incident, your team will look to you for quick, informed decisions. Knowing the details allows you to step in and lead through challenging situations confidently.

3. Be aware of day-to-day hurdles: Staying close to your team’s blockers and challenges—technical debt, unclear requirements, or process inefficiencies—helps you clear obstacles.

4. Work up a low-performing team: Hands-on involvement lets you diagnose deeper problems, like gaps in skill sets or misaligned priorities. Then, you can provide mentorship, process adjustments, or technical guidance.

5. Set technical direction and act as a bridge: Without being hands-on, you can barely translate non-technical business context into relevant technical details for your team (and vice versa). You also need to advocate for technical initiatives that might otherwise be de-prioritized.

6. Maintain credibility: When your team sees you understand their work, they’re more likely to trust your decisions and look up to you as a leader.

How can EM be hands-on?

Being hands-on is often seen as coding.

You don’t have to code full-time, but you can stay hands-on in other ways:

• Code Reviews: Participate to stay up-to-date on the team’s approach and code quality. It’s also a natural way to mentor your engineers without fully coding.

• Contribute to Architectural Decisions: By joining architectural discussions, you stay engaged and guide your team through design challenges.

• Pick up a Technical Discovery Task: Investigate a new tool, test a new feature, or explore solutions for a specific problem. This sharpens your problem-solving skills and creates individual value.

• Monitor Your Technical Systems & On-Call: Keep an eye on performance through monitoring tools. Occasionally, stepping in for on-call duties lets you experience real-time challenges.

• Pairing: Work with an engineer on complex problems. It’s a great way to stay hands-on while coaching and guiding your team.

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 learned 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.

Caveats

Avoid going too far with hands-on involvement:

1. Don’t be in the critical line: Avoid tasks where success depends on your daily coding. Your role is to ensure the team functions smoothly and autonomously.

2. Don’t become a single point of failure: If you step away, the team should still operate smoothly.

3. Don’t be carried away: Spending too much time on immediate tasks can shift your focus away from future planning and strategic vision. Strike a balance between technical problem-solving and broader goals.

4. Don’t block team learning: When you solve technical problems yourself, you deprive your team of growth. Coach and enable your engineers instead.

5. Aim for a sweet spot: hands-on enough to stay on top of your team’s work but not overstepping or neglecting real 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?

  • Too little hands-on: Rarely codes or contributes to technical tasks.

  • Too much: 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?

  • Too little hands-on: Relies only on updates from others and isn't directly involved.

  • Too much: 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?

  • Too little hands-on: No direct involvement in solving urgent issues or unblocking the team.

  • Too much: 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?

  • Too little hands-on: Mostly focused on long-term strategy without involvement in technical challenges.

  • Too much: 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?

  • Too little hands-on: Rarely engages in problem-solving or guiding the team on technical issues.

  • Too much: 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?

  • Too little hands-on: Stays out of the immediate issue, relying entirely on the team to manage the resolution without providing real-time guidance.

  • Too much: 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.

---

Mirek:

I’m grateful to Ananth for his thoughts on being a hands-on engineering leader. I try to embody this approach in my day-to-day work, where, as an engineering director and Polish site leader, I still find time to code hand-in-hand with software engineers.

Similarly to Ananth, few times I took leadership over the team where I wasn’t experienced with their tech stack. As a mobile engineering manager, I started leading the frontend team. As head of the frontend tech stack, I took over the backend platform. What helped me the most with getting up to speed were these simple steps:

• Install new IDE

• Clone the project, run it, debug it, review the code

• Take some coding tasks or build simple solutions in the frameworks your team was using (this is how I learned React, Spring, or cloud platforms like AWS).

Just give it a try, one step at a time.

Share Your Story

I also invite you to share your story on Practical Engineering Management. Even though there are endless theories and “good practices,” nothing beats real-life experience in the challenging environment of software engineering management.

If you want to share your story with thousands of engineering leaders worldwide, drop me a note here on Substack or via mirek@practicalengineering.management. I’m more than happy to help you write the final piece so we can spread it with our leaders’ community.