One of the most common next step in a software engineer’s career is the role of Engineering Manager. Although the role may describe different responsibilities in different companies I am implying here, the responsibility of managing 3-10 software engineers in a team and being responsible for their output and growth. However, a newly minted engineering manager almost never has background in people management and has received very little training in doing his/her job well. If you are one such person this post is for you. In this post, I will share all the readings that I found useful in building my own perspective on how to be a good engineering manager.

My perspectives on people management

It is useful to apply multiple mental models to the role of engineering manager.

• First and foremost, an engineering manager is a first class software engineer. S/he brings his/her experience, insights, and skills to the table when solving hard engineering problems the team needs to solve. I believe that the day one stops doing engineering, s/he starts to get poorer as an engineering manager. This means that one must continue to refine engineering skills even as an engineering manager.
• A manager’s output is defined by the output of his/her team. The individual’s output that matters. Thus the engineering manager must optimize processes, technology, and everything else to increase the team’s output.
• A manager must balance team’s short term output with its long term output. These aren’t necessarily the same. For example, short term output of the team can be increased by making sure that the members that know a certain part of the code base work on tasks related to that part. However, there are long term benefits of having team members learn different parts of the code base and that need should be balanced with the need to have high short term output.
• An engineering manager is also a mentor for junior software engineers. Junior software engineers often have programming skills and computer science skills. However, they often do not have software engineering skills. In my experience those skills of buy vs build decision making, choosing the right library, building the right abstractions, etc tend to be learned on the job. The manager needs to enable an environment to allow junior engineers to do those tasks and receive feedback so that they can grow.
• An engineering manager acts an umbrella that prevents shit from the top from reaching his/her team. More explicitly, s/he takes away all the unnecessary noise and carefully shares distilled relevant information from outside the team allowing the team to focus on things that matter.
• Finally, an engineering manager is responsible for the career growth of his/her team. S/he is their cheer leader, coach, and therapist. S/he works with each team member to help clarify their career goals and helps them to work towards achieving them.

Recommended Readings

So without further delay let’s get to the readings I recommend for a new engineering manager. I will also share my thoughts on each of the readings so that you can make your on decision of whether to spend time on it.

High Output Management - Andy Grove

Andy grove was the former CEO of Intel for a very long time. This short but slightly dense book is a great start to build good mental models about a manager’s role, a manager’s work, different kinds of meetings purposes of each of them, etc. It’s a short read and yet does a great job of laying the foundations for a new manager. Some of his ideas are not necessarily popular today but they are definitely thought provoking. For example, he says in the book:

A meeting is nothing less than the medium through which managerial work is performed.

Thus they are important, which goes against the current fashion of calling all meetings evil, but is definitely interesting to think about.

Five Dysfunctions of a Team - Patrick Lencioni

This book is written in the form of a fable to describe a pyramid of dysfunctions that often exist in poor teams. I loved this book personally, because the story made the book so easy to read and grasp the concepts. I also loved the book because it explicitly acknowledged that we are humans and when we come to work we don’t only bring the objective side of our selves to work, but we also bring along all our emotions and biases and issues in personal lives. Given that we often make decisions using System 1 (see Thinking, Fast and Slow later for details), which isn’t necessarily logical the book provides a way for teams to bring their illogical selves to the table, acknowledge those parts of them and then move forward in the discussions with that knowledge that a certain decision is based more on intuition than logic.

Note that the book only gets to the point of describing the pyramid. It doesn’t show how to evaluate what dysfunctions exist in your team and how to go about fixing them. However, if you find the model convincing then you can find additional resources that will help you with the next steps. For example, here is a free assessment you could do for your team.

Radical Candour - Kim Scott

I found bits and pieces of this book quite useful. The key takeaway for me from this book was about being honest when having conversations with a team member who is under performing. When brought up in a culture of politeness we tend to avoid highlighting people’s mistakes. However this is ruinous for your team members who need the feedback to correct their mistakes. The best way to think about constructive feedback is that it’s the best gift you can give to your team members without which they will not be able to grow in their careers. Of course, giving such feedback is hard and one needs to figure out how to do this effectively. Tools for those exist, for example the COIN model, but this book focuses more on helping you the manager build the realization that the honesty with your team members is extremely important for their growth and for the team as a whole.

Another useful idea in the book is about different people looking for different career trajectories. We often hear about superstars who want to quickly learn the skill get very good at it and then move to the next step in the ladder. We often subconsciously believe that this should be the trajectory for all software engineers. However, if this was indeed the case you the manager would have a hard time retaining domain knowledge in the team as everyone moves through the team quickly. The reality is that there a lot of people who are perfectly happy getting very good at a skill and using it to solve problems. Their satisfaction comes from solving problems rather than learning new skills. Such people tend to stay in the team for a long time and become the source of domain knowledge. Kim Scott refers to such people as rockstars, as they form the rock or the foundation of the team. In any successful team one needs both rockstars and superstars and it is your role as the manager to identify which are which and nurture them accordingly.

Finally, I came across a nice tool in the book that has allowed me to have career conversations with my team and define learning goals for them based on those conversations. I’ve seen a lot of excitement in my team as they can see a clear direction in which they are growing.

Thinking, Fast and Slow - Daniel Kahneman

I’ve read only parts of this book but even so, I’ve found it quite useful. The key idea the book shares is that we form thoughts in two different ways. First, called System 1, is fast, automatic, and unconscious. We use System 1 to make most decisions in our day. The second one called System 2 is slow and deliberate and is used for more effortful tasks. The most interesting insight from the book is that even though System 1 is fast, it uses short circuits in our brains to make decisions and so is susceptible to biases. The book shares a variety of such biases, which I’ve personally found very useful to know about so that I can try to catch myself falling for them. It also provides a shared language that you can use within your team so that team members can help catch other members’ biases.

Google’s Research on Effective Teams

Google spent a fair amount of time trying to figure out what made some teams more effective/successful than others. Interestingly the composition of team or the skills present in the team did not matter as much as two factors:

1. Whether everyone in the team got a chance to speak: Successful teams tend to have each member talk roughly equal amounts of time.
2. Whether everyone in the team have high social sensitivity: Everyone in successful teams were able to tell based on non-verbal cues how other team member was feeling.

More detailed information on research results and how you could go about using these insights in your teams is available at re:Work.