The Manager's Path: A Guide for Tech Leaders Navigating Growth and Change

by Camille Fournier

You’ll probably go through periods of career uncertainty in your life. Many people feel very uncertain in their first two to five years out of school, as they settle into independent adulthood. I felt so unsettled that I went to grad school for a couple of years, in what turned out to be a quest to find security in the familiar academic setting and an escape from a job I didn’t know how to navigate well. I hit uncertainty again after climbing the technical ladder only to feel somewhat powerless at a big company. And then I hit it again after climbing the management ladder only to encounter the challenges of executive leadership. I expect I’ll experience it every 5 to 10 years until I retire, given my track record.

Especially as you become more senior, remember that your manager expects you to bring solutions, not problems. Try not to make every 1-1 about how you need something, how something is wrong, or how you want something more.

So if your company is setting up mentoring programs outside of new hires and interns, try to make sure that there is some guidance and structure to the program before you push people into it.

Brilliant, introverted developers may not ever want to formally manage, but encouraging them to mentor 1-1 helps them develop stronger external perspectives, not to mention their own networks.

My job as tech lead was to continue to write code, but with the added responsibilities of representing the group to management, vetting our plans for feature delivery, and dealing with a lot of the details of the project management process. I could be the tech lead, despite not being the most senior person, because I was willing and able to take on the responsibilities of the role, while the rest of my team were more interested in staying purely focused on the software they were writing.

The tech lead is learning how to be a strong technical project manager, and as such, they are scaling themselves by delegating work effectively without micromanaging. They focus on the whole team’s productivity and strive to increase the impact of the team’s work product. They are empowered to make independent decisions for the team and are learning how to handle difficult management and leadership situations. They are also learning how to partner effectively with product, analytics, and other areas of the business.

don’t even like hiring project managers because they often act as a crutch for engineers to use instead of learning to think through their future work and ask real questions about what they’re doing and why, and their presence means that you have more waterfall-style projects instead of an agile process.

Good managers are looking out for talented people who could be given bigger leadership roles, but sometimes this leads them to push people away from coding before they’re ready. This practice can have a very negative impact on your career, because at more senior levels people who are considered “not technical enough” can find it hard to be promoted into management positions with more responsibility. It’s much easier to stay in a focused individual contributor role and learn what you need to learn there than it is to try to learn all of those skills while also learning management skills.

You do set the standards for culture on your team, which is good and bad. It’s good when they take after your best aspects, and it’s bad when you realize that your team is also mirroring your faults.

It is common for people to try out management at some point, realize they don’t enjoy it, and go back to the technical track. Nothing about this choice has to be permanent, but go in with your eyes wide open. Each role has benefits and drawbacks, and it’s up to you to feel out what you enjoy the most.

Successful leaders write well, they read carefully, and they can get up in front of a group and speak. They pay attention in meetings and are constantly testing the limits of their knowledge and the knowledge of the team. Now is a great time to practice your writing and speaking skills.

Speak in team meetings, speak at meetups, and get practice standing up in front of an audience.

if you can’t communicate and listen to what other people are saying, your career growth from this point on will suffer.

The hardest thing about micromanagement is that there are times when you need to do it. Junior engineers often thrive under detailed oversight because they want that specific direction. Some projects go off the rails, and you occasionally need to override decisions made by your reports that could have big negative repercussions. However, if micromanagement is your habit, if it’s your default approach toward leading your team, you’ll end up like poor Jane, accidentally undermining the very people you need to be growing and rewarding.

You don’t have to do this in public, but every week there should be at least one thing you can recognize about someone on your team. Even better, look for something to recognize weekly for everyone who reports to you.

Don’t let people skip over the good stuff in order to obsess over the areas for improvement, as many will want to do. Those strengths are what you’ll use to determine when people should be promoted, and it is important to write them down and reflect on them.

Without technical credibility you face an uphill battle, and even though you may be able to get into a position of leadership in one company, your options will be limited. Don’t underestimate the value of your technical skills as you work to become a successful engineering manager.

Why bother writing any code if all you’re doing is small stuff? The answer is that you need to stay enough in the code to see where the bottlenecks and process problems are. You might be able to see this by observing metrics, but it’s far easier to feel these problems when you’re actively engaged in writing code yourself.

Another error that the shield sometimes makes is denying that any drama exists in the outside world. If layoffs happen in another part of the company and the team finds out from someone else, rather than shielding your team from drama, you’ve created a situation where they feel like something bad is happening and no one wants to admit it.

Acknowledging that there is value in the world beyond sheer intelligence or productivity would challenge her place in the world and tends to be a scary proposition for her. So she bullies with her intellect, cutting down dissenting voices in a harsh way, ignoring those she believes are not her equal, and letting her frustration with anything she sees as stupid seep out openly.

The best way to avoid brilliant jerk syndrome is to simply not hire one. Once they’re hired, getting rid of brilliant jerks takes a level of management confidence that I think is uncommon. Fortunately, these folks will often get rid of themselves, because even though you may not have the guts to fire them, it’s unlikely that you’ll be stupid enough to promote them. Right? Let’s hope so.

There are 52 weeks in a year, or about 13 per quarter. However, realistically your team will lose a lot of that time. Vacations, meetings, review season, production outages, onboarding new employees — all of these things take away from focus. Don’t expect to get more than 10 weeks’ worth of focused effort on the main projects per team member per quarter. It’s likely that Q1 (immediately after the winter holidays) will be the most productive and Q4 (the quarter that includes winter and the end-of-year holidays) will be the least productive.

The popular doubling rule of software estimation is, “Whenever asked for an estimate, take your guess and double it.” This rule is appropriate and good to use when you’re asked for an off-the-cuff guess. However, when you’re talking about projects that you think will take longer than a couple of weeks, go ahead and double the estimate, but make it clear that you’ll need some planning time before you’re sure about the timescale. Sometimes the longer tasks will take far more than twice your estimate, and it’s worth spending some time planning more carefully before you commit your team to a big, unknown project.

Part of the reason that I stress your role in this estimation and planning process is that it’s distracting and stressful for engineers to have a manager who’s constantly asking them for random project estimates. As the manager, you’re responsible for handling uncertainty and limiting how much of that uncertainty you expose to your team.

Almost everyone who goes from a heavily hands-on technical role into management has a transition period where they question frequently whether they’ve made a mistake. Furthermore, many worry that they’re losing all of their valuable skills in the process. Ask yourself whether you’ve internalized the idea that management is not a job. The tech industry is filled with people who despise management, thinking it’s not as important a job as writing code.

Writing code is full of quick wins, especially for the experienced developer. You make tests pass, you see new features come to life, you get something to compile, you fix a problem. Management has fewer obvious quick wins, especially for new managers. It’s natural to feel some longing for simpler times,

However, I have found the ideas in David Allen’s book Getting Things Done1 to be useful to think about, and I recommend reading it even if you don’t adopt the whole process.

I feel bad when I suck at being an engineer, but sucking at being a manager would be a choice I inflicted on other people. That’s not fair. So at the end of another day when I feel like I didn’t write enough code and I have no way to quantify what I’ve achieved, I tell myself I was being as good a manager as I know how to be. And that has to be enough for today.

Saying no to your boss rarely looks like a simple “no” when you’re a manager. Instead, it looks like the “yes, and” technique of improvisational comedy. “Yes, we can do that project, and all we will need to do is delay the start of this other project that is currently on the roadmap.” Responding with positivity while still articulating the boundaries of reality will get you into the major leagues of senior leadership.

It can be hard for new managers to create a shared team identity. Many of them default to an identity built around the specifics of their job function or technology. They unite the team by emphasizing how this identity is special as compared to other teams. When they go too far, this identity is used to make the team feel superior to the rest of the company, and the team is more interested in its superiority than the company’s goals.

Laziness and impatience. We focus so we can go home, and we encourage going home because it forces us to constantly focus. This is how great teams scale.

Pick an unknown area, and ask an engineer to explain it to you. Spend a couple of hours with one of the engineers who is working on something you don’t understand, and ask him to teach you about that area. Go to a whiteboard or share a screen and have him pair with you on a small change.

In my experience, most people need to hear something at least three times before it really sinks in.

Don’t be afraid to repeat yourself. If you’ve brought up an important issue that seems to have been forgotten, bring it up again if it’s really important. You may have to do this a few times before you get any traction. Three times is often the magic number.

A very common clash occurs between people who are extremely analytically driven and those who are more creatively or intuitively focused. Another is between the people who prefer to embrace agility and change (and, yes, sometimes disorder) and those who push for more long-term planning, deadlines, and budgets. You have to figure out how to understand and trust everyone’s styles across the spectrum.

At this level especially, you must decide whether you want to fall in line or quit. The middle ground, openly disagreeing with your peers, does nothing but make the situation worse for everyone.

When there’s a happy hour, you go for a drink and then leave the team to socialize. Closing down the bar with your whole organization will tend to have bad consequences for everyone, so I strongly advise that you avoid doing that with any regularity. Socializing heavily with your team outside of working hours is a thing of the past.

For many people who are attracted to startup culture, the ideas of “structure” and “process” are seen as pointless at best and harmful at worst. I have seen surveys of startup teams in which the idea of introducing structure evoked such reactions as “slow” and “innovation-crushing.” These respondents believed structure is the reason large companies move slowly, foster bureaucracy, and are generally boring places for bright people to work.

the unstructured organization either displays characteristics that ultimately make it less self-directed than the members might wish to believe, or is run by hidden hierarchies and power dynamics. In many cases both things are true to some extent.