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

by Camille Fournier

Another core element of agile software development is the emphasis on learning from the past. When estimates are wrong, what are we learning about unknown complexity? What are we learning about what is worth estimating, when?

Be smart about what you’re willing to give on. If you give only on matters of technical quality, you’ll just slow down the team after the project is launched, so be sure to look at product features in addition to technical nice-to-haves.

You may have very little ability to push back on the changes to strategy coming from above, and even when you’ve promised your team that certain projects will happen, you sometimes have to pull back on that promise because of unexpected changes.

If the project is important, get it scheduled now — or as close to now as possible.

Understand how important various engineering projects really are.

My advice is to do your best to gather data to support yourself, and talk about what will be possible when the work is done.

This is an area where you can and should push back.

By knowing enough about the progress of your teams, the projects, and bottlenecks, you can filter out technically infeasible ideas and map new initiatives onto ongoing projects.

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.

Go to a whiteboard or share a screen and have him pair with you on a small change.

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?

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 know how to plan for the months and years ahead so that your organization is best suited to handle those potential futures and capture opportunities as they come along.

Reminding people of their commitments by asking questions instead of giving orders.

best possible decisions and help them implement them in a sustainable and efficient way. I care about technology — it’s a factor in every decision we make as a team — but technology alone doesn’t make a productive and happy team. 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.

Often a great VP of Engineering is described as having a good “ground game.” This person is capable of dropping into the details and making things happen at a low level.

She should have a strong business and product instinct and a track record of getting teams to deliver big projects, including the ability to negotiate deliverables.

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.

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.

Some CTOs have no direct reports, while others manage the entire engineering organization.

After looking at all these different examples, the best definition I can give you is that the CTO is the technical leader at the company’s current stage of evolution.

To expand, the CTO should be the strategic technical executive the company needs in its c...

It’s incredibly difficult to maintain influence and effectiveness as an executive with no reporting power.

You can’t give up the responsibility of management without giving up the power that comes with it.

My advice for aspiring CTOs is to remember that it’s a business strategy job first and foremost. It’s also a management job.

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.

I’ll leave you with some advice my own VP of Engineering once gave me: “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.

they often expect that change to happen immediately, without consideration for the reality of the current state of affairs.

You didn’t explicitly go through the list of things in flight and kill or postpone work in order to make room for this priority.

Saying something is top priority is one thing, but making the actual tradeoffs on the schedule to get people moving on it is completely different.

Finally, never underestimate how many times and how many ways something needs to be said before it sinks in.

hear something at least three times before it really sinks in. You’re going to tell your own senior management and leadership team. You’ll hold an all hands meeting. You may need to send some email detailing the changes as well. A little bit of communication planning can go a long way in such situations.

When I talk about senior leadership, I emphasize strategy as a critical element. Most people don’t even really know where to begin when it comes to setting strategy at the senior level. I know I didn’t.

All of this thinking forced me to consider the structure of the business, the needs of the customer — both internal and external — and possible future evolutions. By doing this research and speculation, I was able to design a technology strategy that supported these factors into the future.

Really, she rejected two things. The first was an underdeveloped strategic plan that was almost entirely about system and architectural details and offered very few forward-thinking ideas beyond the next 6 to 12 months.

It’s not just a reactive document that tries to account for current problems, but it anticipates and enables future growth.

After I clarified this architecture for myself, leading became in many ways much easier. I could show the engineering team a vision of where we would go as a technology platform, not just what the product roadmap looked like.

As someone in senior leadership, you have to learn how to maturely handle decisions you don’t agree with, but that doesn’t mean you have to go it alone.

Do think about how you would like to be told. One piece of news that you may have to deliver someday is the news of your leaving.

Senior leaders, more than any other group in a company, must actively practice first-team focus (introduced in Chapter 6). They are dedicated first and foremost to the business and its success, and secondly to the success of their departments as a way of contributing to the overall business success.

So what does it feel like to work well with cross-functional peers? To start with, you let them own their areas, and they let you own yours.

When there’s a happy hour, you go for a drink and then leave the team to socialize.

Socializing heavily with your team outside of working hours is a thing of the past.

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.

Transparency that may have been harmless or even possibly helpful at lower levels of management can become incredibly damaging to the stability of your team at this level.

Apologize. When you screw up, apologize. Practice apologizing honestly and briefly.

You’re showing the team that apologizing doesn’t make you weaker — it makes the whole team stronger.

So work on softening your rough edges, practice caring about your team as humans, and get curious. Building a culture of trust takes time,

That doesn’t mean I made all of those decisions, but I guided the standards by which such decisions would be evaluated.

Do you have a professional coach, either provided by work or paid for yourself? This is a good investment even if your job doesn’t pay for it. A coach can give you guidance and direct feedback,