Welcome to the new world of engineering management! You’ve entered a brave new world that will be significantly different than your life as an individual contributor. Here are some tips I’ve learned over time.
You have one goal: maximize your team’s productive work.
That’s it. Do that and you will succeed. Do anything else and you fail. Life is simple.
Let’s break that down into a few key ideas.
Maximize Your Team Member’s Potential
First, let’s assess the type of engineers you may have on your team.
- Solid = Can solve well defined problems.
- Bad = Can’t solve well defined problems.
- Junior = Bad engineers but have the excuse of being very early in their career or being put into a new situation.
- Leaders = Can determine the problems that need to be solved and help others get the necessary work done.
How should you manage the different types of engineers?
Engineering Leaders. If you are a new manager, you are likely the only Leader in your team. If you are lucky enough to have team members that are Leaders, your life will be easy. Just keep giving them tough problems and stay out of their way.
Solid Engineers. These engineers will hopefully make up most of your team. They can tackle well defined problems, so to maximize their current utility, work on giving them the minimum definition they need and then get out of their way. To maximize their long term success, you want to try and turn Solid Engineers into Leaders. One way to do this is to keep giving them tougher problems with less definition and let them grow into Leaders.
Bad Engineers. Hopefully you don’t inherit any Bad Engineers. If you do, you need to quickly assess whether it is worth the management effort to get them to Solid Engineers, or get them off your team (either by firing or a transfer to another team).
Junior Engineers. As a new manager, you are likely to have several Junior Engineers. I’ve found that everyone is happiest if both the Junior Engineer and yourself acknowledge that Junior Engineers do not produce useful work today. Instead, both the Junior Engineer and yourself should focus your efforts on turning them into a Solid Engineer as soon as possible. As a manager, you can accelerate their growth by (1) giving them training tasks, i.e. tasks that may not be the most relevant to your team’s productivity today, but help them grow as an individual and (2) giving them extra 1 on 1 attention. While this extra effort will consume significant time now, you can have a Solid Engineer within a few months. Plus, this extra effort is nothing compared to the effort you would later need to spend to move someone from a Bad Engineer to Solid Engineer.
Maximize Your Team Output
Now that we have covered the basics of maximizing individual team member’s performance, let’s move on to some tips for maximizing your whole team’s output.
First, you need to plan that your personal coding output will basically be zero. You may occasionally do some coding, but you need to remember that you are judged on your team’s output now, not just your own. So any coding project you do needs to be weighed against the opportunity cost of you spending that same amount of time improving your team members. I’ve found that this likely means you will only end up coding (1) early prototypes, (2) refactorings, or (3) nice to have projects. Instead, you need to switch to thinking about your team’s output.
As a new manager, your life can easily be consumed by meetings. You will now be in charge of 1:1s and team meetings, and also get invited to lots of cross team meetings. My biggest regret as an early manager is saying yes to every meeting. I personally am fine with delegating work, but my weakness was that I still wanted to know everything that was going on. Before you know it, you will spend all day running from meeting to meeting. This is bad for three reasons: (1) you don’t have time to think, (2) you can’t adapt to emergencies and (3) your team members will become too shy to schedule 1:1s with you since they assume you are doing something important.
So fight the good fight and minimize the number of meetings. I advocate the following meeting philosophy:
- All meetings should have a predefined agenda, even 1:1s.
- Have the minimum number of people in the meeting (ie prefer 1:1s or small groups)
- Minimize the number of meetings that are just status updates. Most of these can likely be replaced by email, Slack, or a document.
- Group meetings into blocks. I’ve had success with the following type of meeting schedule:
- Monday AM: Sprint starts / big team meetings.
- Monday PM: 1:1s.
- Tuesday: No recurring meetings.
- Wednesday: Cross team meetings.
- Thursday: No recurring meetings.
- Friday AM: Sprint check ins / sprint end meetings.
- Friday PM: 1:1s.
A well written document is one of your two new best friends. The power of a well written document is that it (1) forces you to clarify your thoughts, (2) provides a clear documentation trail and (3) prevents you from repeating yourself. There is nothing worse than having a meeting with a lot of people that leads to some very important decisions, but then no one can seem to remember what those decisions are. Write, write, and write some more.
Do Productive Work
At this point your team should be doing lots of work. But how do you guarantee that this work is productive? Let me introduce you to your second new best friend: Objectives and Key Results.
The main principles of OKRs are:
- Objectives should be clearly defined aspirational goals
- Key results are specific quantitative measures
- Each objective should be supported by 3-5 key results
- Ideally key results can be measured on a 0-100% scale
- To make key results push the boundaries of your team, it is recommended that
- A key result is considered achieved if >=70% is achieved
- Key results are not tied to pay
Many companies use a mix of yearly and quarterly OKRs. I personally find the quarter OKRs most useful as a management tool. The yearly OKRs are more useful for upper management to set clear company wide goals, but I’ve found that setting yearly team goals are not very useful unless they directly tie into a company OKR. Instead, I would focus on writing solid quarterly team OKRs.
For OKRs to truly work, you need to get buy in from the whole team. In order to get buy in, you should:
- Do the necessary prep work to deeply understand the company priorities and OKRs.
- Involve your team members in developing the team OKRs.
- Set up a central dashboard to track your progress on OKRs.
- Make that dashboard a central part of your meetings. Kick off team meetings by looking at the dashboard and calling out progress.
- Have a retrospective at the end of the recording period to understand why your team succeeded or failed to achieve OKRs.
- Rinse and repeat. Your first several quarters of OKRs likely won’t go well. But please don’t give up until you have tried for at least 4 quarters in a row.
Good luck, hope these tips help!