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

by Camille Fournier

Great managers notice when your normal energy level changes, and will hopefully care enough to ask you about it.

Developing a sense of ownership and authority for your own experiences at work, and not relying on your manager to set the entire tone for your relationship, is an important step in owning your career and workplace happiness.

you become more senior, remember that your manager expects you to bring solutions, not problems.

If one universal talent separates successful leaders from the pack, it’s communication skills. 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.

The engineering lead will spend less time writing code, but they still engage in small technical deliverables, such as bug fixes and small features, without blocking or slowing down the progress of their team. More than writing code, they hold responsibility for identifying bottlenecks in the process and roadblocks to success for their team and clearing these roadblocks.

The engineering lead is an independent manager. They are comfortable managing team members with different skill sets from their own. They communicate expectations clearly to all team members, and solicit and deliver individual feedback frequently (not just in the scope of review periods).

They clearly communicate the timeline, scope, and risks to their pillar partners, and lead the delivery of major initiatives on clear timelines. Additionally, they identify areas of strategic technical debt, do the cost/benefit analysis for resolving this debt, and communicate suggested timelines for prioritizing this to the management team.

Furthermore, if you truly wish to command the respect of an engineering team, they must see you as technically credible. 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.

It’s far easier to identify technical debt and prioritize dealing with it when you’ve slogged through the code yourself.

as the manager of a single team, you’ll be called upon to help guide what is possible and impossible to do in your systems.

Strong engineering managers can identify the shortest path through the systems to implement new features. As you learned in your time as a tech lead, a critical part of complex project management is understanding the pieces of the system well enough to determine the best path to implementation. The more you understand the code in the system, the easier determining this path will be.

While the product manager is responsible for the product roadmap, and the tech lead is responsible for the technical details, you are usually accountable for the team’s progress through each of these elements. The nature of leadership is that, while you may only have the authority to guide decisions rather than dictate them, you’ll still be judged by how well those decisions turn out.

Don’t rely exclusively on consensus or voting. Consensus can appear morally authoritative, but that assumes that everyone involved in the voting process is impartial, has an equal stake in the various outcomes, and has equal knowledge of the context. These conditions are rarely met on teams where each person has different levels of expertise and different roles.

creating functional teams is building teams that work well and happily together.

you’ll be the person to give the team options as to what can realistically be implemented, or how much more time getting everything in will require.

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.

As the manager, you’re responsible for handling uncertainty and limiting how much of that uncertainty you expose to your team. Don’t be a telephone between the engineers and the rest of the company, parroting messages back and forth and distracting people who are busy with the important tasks you’ve already committed to do. But you’re not a black hole, either. Try to get a teamwide process in place for talking about new features and customer complaints, and limit estimations that occur outside of this process.

The engineering director typically leads engineers across multiple product areas, or multiple technology functions. Both tech leads and individual contributors report into them. The engineering director is not generally expected to write code on a day-to-day basis. However, the engineering director is responsible for their organization’s overall technical competence, guiding and growing that competence in the whole team as necessary via training and hiring.

They should have a strong technical background and spend some of their time researching new technologies and staying abreast of trends in the tech industry. They will be expected to help debug and triage critical systems, and should understand the systems they oversee well enough to perform code reviews and help research problems as needed. They should contribute to architecture and design efforts primarily by serving as the technically savvy voice that asks business and product questions of the engineers on their teams, ensuring that the code we are writing matches the product and business needs and can scale appropriately as those needs grow.

The director is a very strong communicator who can both simplify technical concepts to explain them to nontechnical partners and explain business direction to the technology team in a way that inspires and guides them.

“Yes, and”

“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.

“Help Me Say Yes”

For most engineers, the answer to these questions can be discerned by the speed and frequency with which they push code. If the work they need to do is clear, they know what code to write. If the tools, tickets, automation, and process are available and easy to use, they are able to get the code written. And if they’re not distracted by excessive meetings or drowning in support and incident management, they’ll get a chance to write code every day. These health signals — 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.

You have to be the advocate and push for technical process improvements that can lead to increased engineer productivity, even if you’re not implementing them all yourself.

As a manager, be careful about focusing on your teams to the exclusion of the wider group. Even when you have been hired to fix a team, remember that the company has gotten this far because of some fundamental strengths. Before you try to change everything to fit your vision, take the time to understand the company’s strengths and culture, and think about how you’re going to create a team that works well with this culture, not against it. The trick is not to focus on what’s broken, but to identify existing strengths and cultivate them.

Larry Wall’s idea that “laziness, impatience, and hubris” are virtues of engineers, as he articulated in Programming Perl

Some suggested prompts to provide the person you are holding the skip-level 1-1 with include: What do you like best/worst about the project you are working on? Who on your team has been doing really well recently? Do you have any feedback about your manager — what’s going well, what isn’t? What changes do you think we could make to the product? Are there any opportunities you think we might be missing? How do you think the organization is doing overall? Anything we could be doing better/more/less? Are there any areas of the business strategy you don’t understand? What’s keeping you from doing your best work right now? How happy (or not) are you working at the company? What could we do to make working at the company more fun?

Estimates are often useful even if they aren’t perfectly accurate because they help escalate complexity to the rest of the team. Not every project necessarily has requirements that change frequently, and it’s possible to do up-front work to drastically reduce the unknowns that make software estimation difficult.

Ironically, while luck plays a role in both failure and success, we often attribute failure to bad luck and success to our own actions.

Culture is how things get done, without people having to think about it. Frederick Laloux, Reinventing Organizations: A Guide to Creating Organizations Inspired by the Next Stage of Human Consciousness

Split management and technical tracks. It’s pretty obvious in this day and age that you need separate tracks for management and individual contribution. You do not want people to feel that the only path to advancement is by managing people, because not everyone is suited to that role.

Consider making people management skills a mid-career requirement. Encourage everyone to have some sort of management or mentorship experience before they are eligible to be promoted above the level of the track split. For most companies, the tracks should split when people start to exhibit leadership, whether that leadership involves managing humans or designing software.