Let Me Speak To Your Manager Starter Pack

It's been almost five years since I switched to engineering management. I am by no means an expert engineering manager and I'm always looking to improve. However, most managers will define their manager principles in the first couple of years of their management career. I think of this post as the "Nakazawa Management Starter Pack", and I'm curious how it evolves over the years.¹

In a hurry? Skip straight ahead to the Priorities.

Why did I switch to management?

This question is one of my all-time favorite questions when I interview other managers for a position. Many people tell stories about how they found out that they were really good at helping others grow their careers.²

Here is my answer upon reflection: I tend to stumble into opportunities because of my curiosity and naivety. I had some managers who were not enjoyable to work with. I believed that I could both manage myself better and do a better job managing others. The primary way I learned that I'd love to be an engineering manager, though, came from my time working on Jest. I was the only engineer dedicated to the project, and we didn't have any headcount to put a whole team together that could execute on the vision I put together.

My only option was to make the project exciting and look for passionate people to contribute as a side-project or maybe even on their own time.³ While I made engineering contributions to Jest, I am most proud about helping many others contribute to Jest, help them grow their careers, and build an active, self-sustained community of contributors.

First time Management Challenges

I knew about management concepts and thought I knew what management might be like yet I had no idea about the extreme information overload I was about to experience. It took me at least six months until I got comfortable and more than a year to deal with this much information effectively. There were several other first-time challenges:

Broken Team Dynamics: The first team I managed had broken dynamics. It was far from a high-performing team, and while we improved substantially, we never got team cohesion quite right, and we ended up with project silos within the group.
Managing Underperformers: I got thrown into a situation where I had to deal with multiple underperformers right away. While I managed to navigate it ok, this early experience made me more reluctant about managing poor performance later on. It made me work harder to support people, but I may have gone too easy on some folks instead of holding them accountable for repeatedly making similar mistakes.
Hiring: I somehow had assumed hiring the best talent onto a team wasn't that hard. It never looked like it took much effort when somebody new showed up on a team. Oh boy, I was so wrong⁴. Hiring is so much harder than I expected. The primary takeaway for me was the lead time it takes from identifying talent to hire, and fully ramping someone up on a team can easily take anything between 3-9 months. Before, I only knew about a small slice of that process. Once I got more involved with recruiting, interviewing, onboarding, and ramping-up senior engineers, I had to learn how to be more strategic about long-term investments rather than thinking about papering over short-term gaps.
Team Makeup: One of my mentors early on gave me the advice to "Build the most senior team you can." It was undoubtedly well-intentioned but led me down a path of hiring only very senior folks and focus on the career growth of individuals with little consideration for how the team might develop as a whole. I have since learned that two things are always true:
- A team will always have gaps.
- A healthy distribution of seniority of a team is as important as the evolution of that seniority as individuals progress through steps in their careers (growth, promotions, …).

Failures

The first time I became a manager, I took it extremely seriously. I still do as I feel a great sense of responsibility towards my manager and reports, but I tried to do everything as correctly as possible back then. I didn't have all the positive manager behaviors internalized and mostly emulated what I assumed were good management behaviors from observing others. It was only years later that I realized just how many mistakes I made on the first team I managed. I did many things right, but I also hired the wrong people for the wrong reasons and set the wrong goals for a project that needed different outcomes, and I was terrible at building trust with one of my managers and some of my reports.

Failures on their own don't lead to growth. It's what you do after a failure happens. Plenty of people will not even recognize or self-reflect when they failed and lose out on all the upside of skill improvement. My failures shaped me as a manager. Priorities help me avoid making the same mistake twice. They enable me to build high-performing teams in which individuals take ownership of their careers. Ultimately, all that leads to better outcomes for the business, organization, and individuals.

Priorities

In the previous post about DevX Principles, we introduced the concept of a principle stack. For this post, I choose to list priorities without ranking. They are all roughly of equal importance. An effective engineering manager will know when to make trade-offs to adjust their approach for a tricky situation or a specific person with individual needs.

We'll cover the following priorities:

Build for Optimism
Trust
Embrace Change
Transparency
Care
Accountability & Recognition
Scope through Delegation
Cohesion
Vulnerability
Selflessness

Build for Optimism

So far, I got to build two teams as a manager. The first team was seeded with people who weren't precisely optimists. Even after they left the team, I noticed that the culture defined in the early days persisted for the duration of the team's existence. I made it my mission to seed new teams with optimists, focused on that with the second team, and noticed an incomparably better team culture the second time around. With it came an increased sense of belonging, more mutual respect, and a can-do attitude.

Trust

The amount of trust in a manager has a high correlation with how happy people are in their jobs. When people are working in a high-trust environment, it means they feel safe to take risks. It also usually comes with a level of autonomy that allows people to be self-directed. I strive to build a high-trust environment with people reporting to me, not just with me but also among each other. From experience working with various managers, there are four different positions people can be in based on trust and the amount of direction they receive from their manager:

Being above the horizontal line is generally a good place to be. If there is high trust between a manager and a report, the manager's amount of direction is often based on the person's experience and whether they need guidance. The amount of direction can generally be adjusted when there is high trust.

The danger zone is below the horizontal line. If you are an experienced engineer joining a new team, you may start with low trust and low direction. It's risky, but things will generally be fine if you can quickly move into high trust territory. Now, if you end up in a spot where you have low trust in your manager and your manager gives you a lot of direction, you may get into trouble. These situations tend to occur when a manager perceives a report as not performing well and doesn't have a consistent track record of prior good performance. Once I was in a situation where there was low trust, my manager insisted on giving me a high amount of direction while having insufficient domain knowledge. I eventually chose to leave that team. In most cases, the right course of action is to aim at building trust quickly.

One person who used to report to me taught me the value of trust and creating win-win situations not just by being incredibly patient with me but also by sharing a wonderful small game.⁵ Here are the three primary takeaways:

Trust keeps relationships going.
Incentives must be non-zero-sum, and situations must have win-win situations for every participant.
A large amount of miscommunication will lead to trust breaking down.

Embrace Change

This priority purely exists as an important reminder: Change requires hard work and is usually out of my comfort zone. I like stability – I mean, most people don't like the rug being pulled out from under them all the time. Yet, change tends to happen, and it's necessary to keep in mind how it affects people. Different people will react differently, have various concerns, and take different amounts of time to process change. Managers should handle transitions by informing people individually in 1:1 chats and looking at the positive outcomes a change may enable. A messaging plan helps deliver the news.

For example, let's say there is an organizational change like a manager change or a re-org that will impact a team. I – or the relevant management team – will prepare a messaging plan to communicate the changes. It usually contains information about the transition, various written announcements to be shared with different groups, a timeline detailing the roll-out plan, and a list of anticipated questions and talking points. While it's easiest to announce a significant change to everyone simultaneously, the most gentle approach usually takes days of communication – in 1:1s – because the amount of time increases with the change's complexity and how many people are involved. The pay-off, though, is that it's easier to get everyone on the same page, and you'll get a head-start on the new setup after successfully executing the messaging plan.

Transparency

I attempt to build accurate mental models of everything around me as well as mental models that other people may have. It helps me make better decisions and allows me to relate better to people around me. For that, I demand as much transparency as possible from my manager. Similarly, I strive to pass on as much information as possible to people reporting to me.⁶ Transparency makes it easier to rationalize decisions, understand the perspective of leadership, and ultimately puts the burden on the directly responsible individuals to make decisions with the full context. In a way, more transparency automatically leads to delegation.

Transparency also allows separating the facts (behind a decision) from my own opinion on various matters. As a manager of engineers, I'm aware that only a few important decisions are up to me. Decisions are either made layers above me or delegated to people reporting to me. When I disagree with a decision that wasn't up to me, it can be useful to share my perspective and why my view may differ from that of the decision-makers. While it may not affect any outcomes, candidness builds trust.⁷

Care

I genuinely care about people and their experiences. They choose to work with me, and it is my responsibility to help them make the most of it. I focus on understanding people's strengths (and helping them understand their strengths), how their work relates to business impact, career growth, and whatever it takes to make everyone feel included.

I don't see my responsibility ending when people stop reporting to me either by switching teams or leaving the company. I care about people being satisfied with their career and progress, and sometimes that means not actively working with me. I'm happy to be there for people at every step of their careers and sometimes even their personal life.⁸

Care may be among the best things I offer to people working with me. Most of the time, the best thing about someone is simultaneously the worst thing. I tend to care so much that when somebody isn't doing well, I can't stop thinking about it, even when I'm not working. I want everyone to succeed and try to find a path to success.⁹

Accountability & Recognition

People must be held accountable for their progress towards goals and the impact they are having. Accountability often comes with a slightly negative connotation, like being held responsible for failure. In reality, accountability is a spectrum from misses to achievements. People want to be recognized for the things they are doing well, but that's only meaningful when there is a general understanding that everyone will be held accountable for misses.

The usual process I apply is to define expectations for each individual at the beginning of a cycle. I write and share one Expectation & Growth document for each person reporting to me. While I'm there for people to help them navigate their careers, they have to own their path themselves, and as part of that, each person has to agree to expectations and growth areas. Ideally, this is a collaborative process. Based on experience and self-awareness, I will ask some people reporting to me to write their own expectations document. After we agree on the document's contents, it serves as a blueprint to track progress – and allows holding people accountable for both success and failure.

A large part of Recognition has to do with "managing up" to one's manager. Whenever there is something great or critical about somebody, I share that with my manager. I serve as an advocate for the people around me. I am responsible for making my manager understand all parts of the team's health and functioning, including how awesome people are.¹⁰

Scope through Delegation

I prioritize making myself obsolete. Of course, that never actually happens, and the intent is to delegate as many things as possible over time to create scope for other people and help them with their growth. That doesn't mean blindly dumping all of my work on others¹¹ but is entirely about waiting for the right opportunities and moments and being sensitive around when people are ready to take on more responsibility.

Delegation has a noticeable effect that it also frees up my time to take on responsibilities and work that is challenging and pushes me out of my comfort zone, leading to growth.

Cohesion

I learned the importance of cohesion from managing a team where it was missing altogether. We were working on three distinct projects with little collaboration and overlap. Pretty quickly, people would start asking questions about why they were on the same team – and that's even worse when people outside the team start noticing and asking hard questions, too! While we had a sound vision and mission for the team, and on some level, it made sense for us to work on all those projects, the concrete manifestation of our actual work was based on individual projects instead of shared goals and focus.

It's important to split people across different pillars or focus areas when a team grows in size. It is equally important to create opportunities for everyone to collaborate. In high-performing teams, people depend on each other. Two main ingredients helped me achieve cohesion later on:

Mentorship structures: Identify or create genuine situations in which people need to help each other out. Pair up new hires with a social buddy and a technical buddy. Pair up experienced people with each other to help them fill gaps.
Shared goals and sense of belonging: If everyone is aligned on why they are here and what they are working towards, the team will be better off as there is an incentive to collaborate and help each other.

Growth documents mentioned previously are fantastic instruments to strengthen cohesion on the team. While there might be shared goals, there may be little collaboration. Growth documents can serve as a way to nudge people in specific directions. Let's say two people work on different pillars, one of them is more experienced and wants to improve their mentorship skills, and the other is less experienced and needs to learn more about project management. In this hypothetical scenario, I may define concrete expectations about how I expect them to improve in those respective areas and suggest working with each other. Almost always, this has second-order benefits when suddenly one person understands something about the work another part of the team is doing and will suggest improvements that people haven't thought about before.

Vulnerability

In high-performing environments, many people will suffer from imposter syndrome. I aim to be an anchor and source of stability in volatile times, but I also know when to display my vulnerabilities. Whether in team meetings or 1:1s, showing vulnerability with personal stories or anecdotes and talking openly about mistakes and failures makes people feel more included and gives them opportunities to open up. Just make sure not to make it too awkward.

Selflessness

I want to support people to do remarkable work. I don't need to be in the limelight. I want to be the light for others. I believe if I do everything to help others, good things will happen to me, too.

Management is hard because you need to show your reports that you are bringing value to them. Some of my past managers made me feel like everything was about them. Great managers show a genuine interest in their reports' careers – and then follow through by being actually good for their careers.

Being good for somebody's career doesn't mean just handing out bonuses and promotions for no good reason; it means helping people learn their strengths, giving them perspective on challenging situations, finding mentors for them, and coaching them through tough times. It means helping them understand what they want to get out of their career long-term, not just in their current role or company, and then finding a way to enable them to reach those goals. I strive to do this every day.¹²