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

by Camille Fournier

frequency of code releases, frequency of code check-ins, and infrequency of incidents — are the key indicators of a team that knows what to do, has the tools to do it, and has the time to do it every day.

engineers who don’t write tests often have a harder time breaking down their work, and learning how to do test-driven development (even if they don’t actually practice that on a daily basis) can help them get better at this skill.

Overfocusing on building systems that are defect-free, or pushing for error prevention by slowing down the development process, is often almost as bad as moving too fast and releasing unstable code.

Leaders who favor an us-versus-them style tend to be empire builders, seeking out opportunities to grow their teams and their mandates without concern for what is best for the overall organization.

the purpose-driven team tends to be very resilient to the loss of individuals and leadership. Because they’re loyal to the mission of the larger organization, they can see a path forward even through loss.

Leaders who are strong team players understand that the people who report to them are not their first team. Instead, their first team is their peers across the company.

By collaborating across teams and across business functions, your teams will come to understand the bigger picture and appreciate their mission as part of that picture.

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.

The open-door policy is nice in theory, but it takes an extremely brave engineer to willingly take the risk of going to her boss (or especially her boss’s boss, etc.) to tell him about problems.

As you manage managers, you’ll ultimately evaluate them on the performance of their teams.

Predicting problems is part of your job, so being blindsided by a team that falls apart, has major attrition, or fails to ship a major project on time reflects poorly on you as the higher-level manager.

What is a skip-level meeting? Put briefly, it is a meeting with people who report to people who report to you. There are a few different ways that people hold these meetings, but their purpose is to help you get perspective on the health and focus of your teams.

Skip-level meetings are a chance to hear the other side of the story, to get a reality check from the people on the ground.

Whether you have experienced managers or first-timers reporting to you, there is one universal goal for these relationships: they should make your life easier. Your managers should allow you to spend more time on the bigger picture, and less time on the details of any one team.

When people start quitting because their manager hasn’t given them a career path or isn’t inspiring them, it’s ultimately your responsibility.

Hiring for managers is a multipart exercise, and those parts are actually very similar to those of a good engineering interview process. First, make sure that the person has the skills you need. Second, make sure that she’s a culture match for your organization.

Culture fit is so important in managers because they shape their teams to their culture, and they hire new people based on their cultural ideas.

High Output Management,1 Andy Grove talks about cultural values as one of the ways that people make decisions inside of highly complex, uncertain, or ambiguous circumstances where they value the group interest above their own.

one of the critical elements to hiring in new managers: the reference check. Do thorough reference checks for anyone you’re planning to bring on board, even if you’ve worked with that person before.

Good meetings have a heavy discussion element, where opinions and ideas are drawn out of the team.

Dedicate 20% of your team’s schedule to “sustaining engineering.” This means allowing time for refactoring, fixing outstanding bugs, improving engineering processes, doing minor cleanup, and providing ongoing support.

Managers who don’t stay technical enough sometimes find themselves in the bad habit of acting as a go-between for senior management and their teams. Instead of filtering requests, they relay them to the team and then relay the team’s response back up to management.

making decisions is one of the most draining and stressful parts of the job.

A good leader shapes technology discussions to inject the strategic objectives and take into consideration the nontechnical implications of a technical decision. It’s not about being the lead engineer, chasing the latest language or framework, or having the shiniest technology. It’s about building a team with the tools and attributes to build the best possible product for our customers. James Turnbull

The CTO thinks about the long term, and helps to plan the future of the business and the elements that make that possible.

The CTO takes that strategic thinking and helps to make it real and operational by breaking down the problem and directing people to execute against it.

“Wanting to be a CTO (or VP of Engineering) is like wanting to be married. Remember that it’s not just the title, it’s also the company and the people that matter.” Titles are definitely not everything.

Being forthright with people will help them trust you more and make them more likely to tolerate the unhappy news well.

Patrick Lencioni’s The Five Dysfunctions of a Team

absence of trust is a fundamental dysfunction.

How do you know if you’re creating a culture of fear? It can come from placing a high value on being correct and following the rules, and having a strong affinity for hierarchy-based leadership.

Get curious. When you disagree with something, stop to ask why. Not every disagreement is an undermining of your authority. When you take the time to seek out more information about something with which you disagree, you’ll often find that you were reacting to something you didn’t really understand.

Building a culture of trust takes time, but the results are well worth it.

True North represents the core principles that a person in a functional role must keep in mind as he does his job.

For a technical leader, True North means making sure that you’ve done your job getting things ready to go into production. It means you have honored your agreed-upon policies for review, operational oversight, and testing. It means that you won’t put something into production that you don’t believe is ready for your users to experience. It means you’re creating software and systems you’re proud of.

True North leaders rely on the wisdom they’ve developed over time to make fast decisions when they don’t have time to delve into all the details. If you want to become this type of leader, you must spend enough time early in your career to hone these instincts in order to be comfortable making fast judgment calls. That means staying technical; following through with projects, languages, or frameworks long enough to learn more than their basics; and also pushing yourself to keep learning new things even when your day-to-day doesn’t involve writing code.

Arbinger Institute, Leadership and Self-Deception: Getting Out of the Box

Brené Brown, Daring Greatly: How the Courage to Be Vulnerable Transforms the Way We Live, Love, Parent, and Lead

Peter F. Drucker, The Effecti...

Marshall Goldsmith and Mark Reiter, What Got You Here Won’t Get You There: How Successful People...

Andrew S. Grove, High Output...

L. David Marquet, Turn the Ship Around! A True Story of Turning F...

One of the greatest writings about organizational politics is a piece called “The Tyranny of Structurelessness” by Jo Freeman. While the article is about early feminist/anarchist collectives, Freeman’s insights apply equally well to startup culture.

It’s no surprise that we usually end up refactoring spaghetti code when we want to make it scalable, because refactoring usually involves identifying and explicitly drawing out structure in order to make the code base easier to read and work in.

Culture is how things get done, without people having to think about it. Frederick Laloux,

Culture is the generally unspoken shared rules of a community.

the ladder existed to make sure we were being fair with things like compensation, and it was something they could use to discuss their level with their manager and learn how to grow.

John Allspaw’s blog post “On Being a Senior Engineer”

What is the lowest level at which people can sit forever, never getting promoted but also not underperforming? This is your breakpoint level. For many companies, it’s somewhere around senior engineer. Someone who’s made it this far is a solid team member, but he may stay at this level indefinitely by his own choice.

I think that the promotion to senior engineer is a big deal, as well as the promotion to staff engineer and, if you have such a role, principal engineer. On the management track, a promotion to director is worth celebrating, as is a promotion to VP.