I've seen many senior engineers struggle to make the leap to management, and it's not hard to see why. The skills that made you a great engineer won't automatically translate to being a great manager. Your output changes fundamentally, from code and technical decisions to the performance and growth of your team.
As a senior engineer, you're used to rapid, concrete feedback - code compiles or it doesn't, tests pass or they fail. But as a manager, your feedback is slow, indirect, and often ambiguous. It's hard to know whether the team's performance is due to your management, the team composition, the product, or the market. This inversion of the feedback loop can be disorienting, but it's essential to adapt to it.
For example, I recall a situation where I had to make a trade-off between using Apache Kafka for message queuing or Amazon SQS. Both had their pros and cons, and the decision would impact the team's performance. As a manager, I had to weigh the trade-offs, considering factors such as scalability, reliability, and cost. In the end, we chose Apache Kafka, which required significant investment in setup and maintenance, but provided the necessary throughput for our application. This experience taught me that as a manager, I need to be able to make informed decisions, even when the feedback is slow and indirect.
One common mistake managers make is to stop coding entirely, which can lead to a loss of technical credibility. But you don't need to be a coder to be a credible manager. The key is to understand what your team is building, the technical challenges they face, and the trade-offs in the decisions they're making. You don't need to write the code; you need to understand it. I've seen managers who use tools like GitHub or Jira to stay informed about the team's progress, without necessarily writing code themselves. This allows them to provide guidance and support, while still maintaining their technical credibility.
Effective managers ask questions rather than give answers. When an engineer comes to you with a problem, your instinct might be to solve it, but that's not your job. Your job is to help the engineer develop the skills to solve it themselves. This requires patience, the ability to resist the pull toward solving, and trust that the engineer will get there. For instance, I use the Five Whys method to help engineers get to the root of a problem. By asking a series of questions, we can drill down to the underlying cause, and the engineer can develop a solution. The payoff is engineers who grow in problem-solving capability rather than engineers who bring every problem to you.
I've also found that setting clear goals and expectations is crucial for engineer growth. Using tools like OKRs, we can define objectives and key results that align with the team's goals. This provides a clear direction for the engineers, and allows them to focus on the tasks that will have the greatest impact. As a manager, it's my job to ensure that the goals are achievable, yet challenging, and that the engineers have the necessary resources to succeed. By doing so, I can create an environment where engineers can thrive, and the team can produce high-quality results.
Hiring is the highest-use activity for an engineering manager. The quality of your hiring decisions has a long-term impact on your team's performance. A manager who builds a team of high performers can be mediocre at everything else and still produce great results. Conversely, a manager who builds a team of underperformers cannot compensate with their own effort. Treating hiring as a top priority, building a rigorous interview process, and making deliberate trade-offs in candidate evaluation are the practices that compound over time. I've seen teams where the hiring process is thorough, with multiple rounds of interviews, and a clear evaluation criteria. This approach may take longer, but it ensures that the right candidates are selected, and the team's performance improves over time.