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

by Camille Fournier

Sometimes people pleaser managers work well in agile frameworks because the team itself takes ownership of work planning. Create better processes for getting work scheduled that don’t rely entirely on the manager’s discretion.

It’s one thing for her to be a bit busier, especially as she gets the hang of the new responsibilities, but it’s another thing to see her coming in early, staying late, and writing emails all weekend. It’s amazing to me how many people never quite learn how to let go of tasks and so are just constantly working longer and longer hours. Make it clear that you expect the new manager to hand off some of her old work, and help her identify opportunities to do so.

once you’ve realize she’s wrong for it is a critical error. I am hugely in favor of making engineers who wish to go into management take baby steps of mentoring and managing very small teams, but this is not always possible and doesn’t always shake out problems that come with scale.

We talk a lot about culture fit for all hiring, but managers create subcultures, and a manager who creates an incompatible subculture can be a problem if you want your teams to work together well.

If you’re building a dynamic, product-centric engineering team, you need managers who understand how to work with teams who ship software frequently, who are comfortable with modern development process best practices, and who can inspire creative product-centric engineers. These skills are so much more important than industry-specific knowledge.

you should ensure that all of your managers respect and nurture the type of culture that you think is best for the team.

While they may not need as much training as new managers, experienced managers often need help expanding their network both within the company and externally, so look for programs that can help them meet new peers.

Any manager you hire should role-play a few 1-1s as part of the interview process. One of the best ways to do this is by asking the people who would report to the new manager to interview her by asking her to help with problems they have right now, or have had in the recent past.

Depending on the seniority, you might have a candidate come in and give a presentation to a group of people. The point of this is not specifically to judge the contents of the presentation, but to see how she is at commanding a room, answering questions posed by a group, structuring her thoughts, and getting up in front of an audience. These are skills that a senior manager should possess, and if she lacks those skills, take that into consideration when you’re deciding whether to hire her. I’d caution you not to overvalue this step, however.

You might also have her mediate a technical debate between engineers who disagree on the solution to a problem. A good technical manager will know what kinds of questions to ask that tease out the core issues and guide the group to a solid consensus.

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. I find this insight very powerful. His observation is that most new hires act in self-interest until they get to know their colleagues, and then they move into group interest.

Sit down with her and treat her as if she were your mentor, the person to teach you the ropes for this job.

Sit in their meetings. Are they boring to you? Is the team bored? Who is speaking most of the time? Are there regular meetings with the whole team where the vast majority of the time is spent listening to the manager or product lead talk?

The point of Schrödinger’s experiment was to show that the act of observing changes the outcome, or rather, causes an outcome to happen. Likewise, you can’t go into a team and not change the behavior of that team by being around them, sitting in their meetings, and watching their standups. Your presence changes the team’s behavior and may hide the problem you’re trying to find, in the same way that a log statement can cause a concurrency issue to be magically erased, at least for some time.

Therefore, you must always be aggressive about sharing estimates and updates to estimates, even when people don’t ask, especially if you believe that the project is critical or likely to take longer than a few weeks.

When an engineer comes to you with an engineering project that she wants to do, think about framing the project by answering these questions: How big is that project? How important is it? Can you articulate the value of that project to anyone who asks? What would successful completion of the project mean for the team?

You need to know enough about the work to sniff out misguided efforts and evaluate proposed investments.

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. This is not a value-add role.

Read the code. Occasionally taking the time to read some of the code in your systems can help remind you what it looks like. Sometimes, it also shows you places where things have gotten ugly and need attention. Looking over code reviews and pull requests can give you insight into changes that are happening. 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. Attend postmortems. When outages happen, make it a priority to attend the post-outage debriefs. These meetings are often full of details about the process of writing and deploying software that you miss when you aren’t coding every day. Standards that you thought were obvious have been neglected or ignored. Communication between teams is lacking, and tooling is hurting more than it is helping. In times of failure you can most clearly see where problems have built up, and you learn where your attention is needed. Keep up with industry trends in software development processes. One major weak spot for managers is losing touch with the tools and processes for actually developing, testing, deploying, and monitoring code. These are the places where new ideas can make your teams significantly more effective. Not every trend is worth pursuing, but make time to learn about how other teams delive...

Without looking at your existing documentation, write down your view of the job description for the engineering managers who report to you. What are they responsible for? How do you evaluate them? What areas are most important for success, in your opinion? Now, look at the job description your company uses. Are there differences in what you wrote compared to that description, or do they match well? Given that description, what things are you potentially overlooking in evaluating them? Finally, do a quick mental review of their current performance. What areas need coaching and development? Make time to cover this in your next 1-1.

If you manage an area that is outside of your technical comfort zone, how often do you check in on that area to make sure things are going well? Have you taken some time to learn from the manager of that area a little bit about what it takes to succeed in that role? What new things have you learned in the past three months that help you understand that team better?

Your first job is to be a leader. The company looks to you for guidance on what to do, where to go, how to act, how to think, and what to value. You help set the tone for interactions.

You can play politics in a productive way, in order to move the organization and the business forward. You work well with your peers outside of engineering and seek out their perspectives in addressing issues with a wide scope.

Information gathering or information sharing Sitting in meetings, reading and writing emails, talking to people one on one, gathering perspectives. The strong senior leader is capable of synthesizing large quantities of information quickly, identifying critical elements of that information, and sharing the information with the appropriate third parties in a way they will be able to understand. Nudging Reminding people of their commitments by asking questions instead of giving orders. It’s hard for a leader of a large team to forcefully guide that team in any direction, so instead rely on nudging members of the team to keep the overall organization on track. Decision making Taking conflicting perspectives and incomplete information and setting a direction, knowing that the consequences of a poor decision will impact both you and possibly the whole team. If making decisions were easy, there would be much less need for managers and leaders. However, as anyone who has spent a lot of time managing can tell you, making decisions is one of the most draining and stressful parts of the job. Role modeling Showing people what the values of the company are. Showing up for your commitments. Setting the best example for the team even when you don’t feel like it.

Business executive, technology strategy, organization, and execution: CTO or Head of Engineering (VP/SVP) R&D, technology strategy, external face of technology: CTO, Chief Scientist, Chief Architect, sometimes Chief Product Officer, usually for a company that is selling a software-based product Organization, execution, business executive: VP of Engineering, General Manager Infrastructure manager, organization, and execution: CTO/CIO, possibly VP of Technical Operations Technology strategy, business executive, and execution: Head of Product (or Chief Product Officer), sometimes CTO R&D, business executive: CTO or Chief Scientist, cofounder Organization and execution: VP of Engineering, sometimes Chief of Staff

While some CTOs will do this, if there’s both a CTO and a VP of Engineering, the VP is usually the one pushing the execution of ideas, while the CTO focuses on larger strategy and the position of technology within the company.

The VP of Engineering also needs to have some stake in organizational strategy, and often she owns this strategy entirely. She’ll be heavily involved in helping teams set goals to achieve business deliverables, and that means she’ll need to be closely aligned with the product team. She must ensure that the roadmap is realistic and that the business goals are translated into achievable goals for the technology organization.

The people I know who excel in this role are capable engineers who care deeply about their teams and prefer to stay out of the spotlight in favor of creating high-performing organizations. They’re interested in the complexities of getting people to work together effectively. They want their teams to be happy, but they know that it’s important to tie that happiness to a sense of accomplishment. They represent the health of the team to the other senior leaders, and cultivate a healthy, collaborative culture. They are very comfortable identifying gaps in processes and managing highly complex, detailed work without getting overwhelmed.

Let’s start by talking about what a CTO is not. CTO is not an engineering role. CTO is not the top of the technical ladder, and it is not the natural progression engineers should strive to achieve over the course of their careers. It’s not a role most people who love coding, architecture, and deep technical design would enjoy doing. It follows that the CTO is not necessarily the best engineer in the company.

the CTO should be the strategic technical executive the company needs in its current stage of evolution. What do I mean by “strategic”? The CTO thinks about the long term, and helps to plan the future of the business and the elements that make that possible. What do I mean by “executive”? 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.

First and foremost, a CTO must care about and understand the business, and be able to shape business strategy through the lens of technology. He is an executive first, a technologist second. If the CTO doesn’t have a seat at the executive table and doesn’t understand the business challenges the company faces, there’s no way he can guide the technology to solve those challenges. The CTO may identify areas where technology can be used to create new or bigger lines of business for the company that align with the overall company strategies.

If he is focused on recruiting, retention, process, and people management, that’s because it’s the most important thing for the technology team to focus on at the time.

The CTO must protect the technology team from becoming a pure execution arm for ideas without tending to its own needs and its own ideas.

If you’re a leader with no power over business strategy and no ability to allocate people to important tasks, you’re at best at the mercy of your influence with other executives and managers, and at worst a figurehead.

My advice for aspiring CTOs is to remember that it’s a business strategy job first and foremost. It’s also a management job. If you don’t care about the business your company is running — if you’re not willing to take ultimate responsibility for having a large team of people effectively attacking that business — then CTO is not the job for you.

How about management? Do you enjoy managing people? Do you enjoy making engineering processes more efficient? Do you like to have a broad view of the work being done by a team and a hand in prioritizing that work? Are you fascinated by organizational structure? Are you good at partnering with product managers? Are you willing to exchange depth of focus into technology details for focus on the effectiveness of the overall team? Would you rather sit in a roadmap-planning meeting than an architecture review? You’re probably more interested in following the VP of Engineering path.

This question may be asked of managers at every level, but most often originates from senior management. Expect to get this question from your boss. When you feel the need to ask it of your own teams, ask yourself why they don’t understand what the priorities are and what they should be cutting to address them.

Do you know what the top priority is? Do your teams know what it is? Do the developers on those teams know what it is? Sometimes the answer to this question is simply a matter of communication.

The more senior the management and leadership position you take in a company, the more the job becomes making sure that the organization moves in the direction it needs to move in, and that includes changing direction when needed.

never underestimate how many times and how many ways something needs to be said before it sinks in. Communication in a large organization is hard. In my experience, most people need to hear something at least three times before it really sinks in.

It’s not about actually deciding the product’s direction, but about enabling the larger roadmap to play out successfully. The hardest part, in many ways, was getting started. The second-hardest part was getting comfortable making a guess about the future with highly imperfect information. Going through this exercise was the difference between my ability to lead in a reactive fashion, looking at the known environment and making plans to accommodate it, and my ability to lead in a forward-thinking fashion.

The worst way to communicate bad news is via impersonal mediums like email and chat, especially mediums with commenting abilities. Your team deserves to hear the message coming from your mouth directly, and without you to guide the message, you can expect some misunderstandings and bubbling animosity. That being said, the second-worst way to deliver this message, especially to a large group that you know won’t be happy, is with them all in a room at once. You may think that trying to communicate bad news to everyone at once is the best way to keep it from spreading before everyone has heard it, but the result is still impersonal.

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.

As the senior leader, you’ll often suck all of the oxygen out of a room. Your mere presence will change the tone and structure of meetings you attend. If you aren’t careful, you’ll end up pontificating and change the direction of a project because you had a great brainstorm in a one-off meeting you decided to drop into. It sucks! I know! It’s frustrating that you can no longer be one of the team whose ideas are there to be evaluated and potentially rejected — but you are no longer that person.

but as you choose which behaviors to model in front of the team, they will learn those behaviors and copy them. If you yell, they learn that yelling is OK. If you openly make mistakes and apologize, they learn that it’s OK to make mistakes. If you always ask the same set of questions about a project, people start to ask those questions themselves.

sets the baseline of what excellence looks like in this function. I call it “True North.” True North represents the core principles that a person in a functional role must keep in mind as he does his job. For a product leader, True North includes thinking of the users and their needs first and foremost, measuring and experimenting as much as possible, and pushing back on projects that don’t address the stated goals of a team.