When you write code, you understand the tools, the tech debt, the challenges in your stack, and the roadblocks that might slow your team down. More importantly, it creates a level of empathy that makes you a more effective leader. You’re not just delegating work; you’re involved in the same struggles and triumphs as your team.
Take Stripe, for example. At Stripe, managers are encouraged to write code alongside their teams. This hands-on approach ensures managers stay technically sharp and aware of the team’s real-world challenges.
Google is another example where some engineering managers are encouraged to remain hands-on, particularly in technical leadership roles. By continuing to code, they stay connected to the technical work while guiding their teams.
At GitHub, engineering managers are often still contributors to the codebase. The idea is to keep them connected to the product and the technical challenges the team faces, while also giving them the context needed to lead effectively.
Similarly, Basecamp has historically advocated for managers to stay engaged with technical work, fostering a culture where managers lead by example and work directly on the product.
Imagine a situation where an engineer sees a problem with a core service. In many companies, they might need approval from layers of management before making changes. But in a culture where managers are also writing code, that engineer is empowered to propose and implement solutions without unnecessary red tape.
Writing code as an engineering manager isn’t about being the best coder on your team. It’s about staying connected, making smarter decisions, and fostering collaboration. Whether you’re solving bugs or pushing features alongside your team, you’re building trust and creating a culture where everyone, including individual contributors, feels empowered to take ownership.
When managers are coding, it sets the tone for a culture where engineers are empowered to make decisions. Engineers can propose projects, drive change, and help steer the company’s technical direction. The best decisions are often made by those closest to the work, not those furthest from it.
