Upcoming Webinar: Becoming a Manager of Engineering Managers Register Now

Camille Fournier on Scaling, Structure, and Growing as an Engineering Manager

Perspectives in Engineering

Camille Fournier on Scaling, Structure, and Growing as an Engineering Manager

GitPrime elevates engineering leadership with objective data. In this interview series, engineering leaders talk about how to build high performing teams.

Today it’s understood that all startups go through a metamorphosis as they become larger companies. They go from one stage to the next, shedding strategies, products, people—and requiring an entirely new set of skills with each shift.

The same goes for individuals growing in their careers. Going from an engineer to a manager, and then a manager to manager of managers, each require a fundamentally different set of skills. Having gone through the journey from tech lead to CTO, Camille Fournier, Managing Director at Two Sigma and author of The Manager’s Path, has spent a great deal of time mentoring, writing, and giving talks to help others through that learning curve.

Fournier recently sat down with us to discuss some of the lessons she’s learned in rapidly changing roles and environments. Here, she describes the difference between a manager and a manager of managers and explains why and how to introduce structure to a previously unstructured organization, while also shedding light on her approach to communication, time management, and team building.

The expectations of managers will change as the company grows

“When you’re at a company that is small and growing, the expectations of managers are much more about shipping and hiring,” Fournier says. “There’s less emphasis on things like developing career paths and having effective one-on-ones. I think a lot of startups tend to build relatively tight-knit teams without necessarily having to work all that hard at it.”

Coordination and retention will become increasingly important

A growing team will hit an inflection point where what’s expected of managers will shift, requiring a different set of skills. Fournier often sees it when the company grows to 30-40 people. It’s often a subtle transition: managers will find themselves spending more and more time getting everyone on the same page. At this point, it’s a big enough team where people don’t all know each other very well, and they certainly don’t know what everyone else is working on.

“All of a sudden, some of the other aspects of management start to become important,” she says. “You’re not just hiring. You also need to retain people, and retaining people tends to mean talking to them about how they’re feeling, how they’re getting along with their colleagues, are they learning stuff, what do they want to do with their careers. People aspects of management quickly come into play.”

The amount of overhead that goes into managing the coordination of people cannot be overstated.”

Develop collaborative partnerships with other teams

Fournier emphasizes that managers will need to develop strong peer relationships to stay connected with everything that’s going on in their growing organization. Equally important, she says, is developing relationships with higher-level directors or executives. These relationships will allow you to be more efficient in communicating and getting work done, while also building trust for your team.

“As the company gets big, a lot of the job of management is making sure that the various directors or executives you’re working with actually understand what’s going on — what your team is doing, and what’s going well and what isn’t going well — so that they feel like their interests are being represented,” Fournier says. “And that starts to consume a lot more of the manager’s time.”

Essentially, managers in scaling organizations can anticipate their jobs to change as the company goes through different stages of growth. Handling these transitions well will affect the trajectory of their careers.

Introduce structure intentionally or shadow hierarchies will arise

Humans, Fournier says, are naturally sensitive to power dynamics, influence, and hierarchy — at least to some extent. But if structure is not introduced, then the voices that carry farthest will dictate how that structure emerges. Maybe those people are everyone’s buddy, or they are the loudest and most vocal, or they’re exhausting when they don’t get their way.

Fournier holds that introducing structure is preferable to allowing those implicit traits to shake out your team’s organization. It’s best to lead the change and create clarity around a deliberately introduced organizational structure — otherwise, you lose control of the output.

Structure is inevitable: if you don’t explicitly introduce it, it implicitly shows up.”

“That works okay when it’s really, really small team, and everyone trusts each other a lot and just about everything you have to do is really obvious,” she says. “But when it stops being so obvious what needs to be done, the things that you need to accomplish are going to require lots of people working together collaboratively.”

Utilize structure as a decision-acceleration process

When the team is a small, tight-knit group and decision-making is easy, structure isn’t as necessary yet. It’s when projects start requiring lots of people working together and consensus building becomes extremely expensive that structure becomes a means to continue moving quickly.

Fournier explains: “Consensus gathering is important, but it’s a very slow process. It tends to be faster if you can say, ‘Hey, we have a structure, and the person who’s in the product management role makes these kinds of decisions, and the person who’s in the tech lead role makes these kinds of decisions.’”

“Structure is really just a decision-acceleration process,” Fournier says. Having structure allows certain decisions to be made swiftly, thereby reserving communication and consensus-building for decisions that benefit from everyone’s input.

“Meetings are valuable,” she says. “They’re just really high bandwidth. You don’t want to have too many of them because they take a lot of time. But their value comes from having however many people’s undivided attention in a room together. You want to make the most of that.”

Be explicit about what it means to work at each level

As you implement some level of hierarchy into a previously unstructured group, communicating the changes constructively and transparently will assist in smoothing out the transition for everyone involved. It’s also helpful to know going into it that the framework you start with will likely need some ironing out.

Choose your structure wisely

“First and foremost, be as thoughtful as you can about what the structure is going to look like — the structure for the levels and pay ranges for those levels,” Fournier says. “It’s usually a bumpy road, at least at first. Any time I’ve added structure to a formally unstructured group, it tends to end up working, but it usually takes a bit of uncomfortableness to get there.”

An effective rollout asks leaders to give serious thought to what their real goals are with the structure they’re aiming to implement. They need to become really clear with those goals an the reasons for the specific structure they’ve chosen. (If you decide to do an engineering ladder, here’s the Rent the Runway ladder to get started.)

Try not to build structure around assumptions

An easy pitfall for leaders when designing a new structure is making decisions based on where they think other people want to be. An effective structure works well for the organization, more so than the current possibilities of the people within it.

“I have definitely been caught blindsided by assuming Person X is going to take on a new leadership position,” Fournier admits. “A couple things happen: First of all, Person X says no, they’re not interested in being a lead. And second, Person Y says, ‘Actually, I really would love to do that job, and nobody even asked me. How do I get on the list to be considered for things like this?’”

Not surprisingly, it’s easy to go to the other extreme and ask everyone to volunteer for new positions within that structure. That has problems too; sometimes, the volunteers aren’t necessarily the right people for the roles.

“Sometimes you have to say, ‘You volunteered but you’re not really suitable for this role,’ or, ‘You didn’t volunteer, but I really think you’d be great at this; can we talk about it?’” Fournier says.

Adding structure generally means adding a degree of hierarchy. People require some care when they’re being located and assigned within that new framework. But the more thoughtfully that structure is filled out, the more specific leaders can be about the reasons behind the structure. And with more clarity and communication, the easier the change will be.

Becoming a manager of managers means spending less time in the details

Fournier agrees that the transition to managing managers can be as difficult as was the transition from engineer to manager. Having been a manager of managers for almost 10 years, Fournier clearly understands the differences between the roles and what it takes to progress from one to the other.

“When you’re managing ICs, you’re much closer to the details of what’s going on in a given area,” she says. “Often people who are managing ICs are still doing technical work themselves to some extent. Maybe you’re not writing a ton of code, but you’re really heavily involved in design review, or you’re still doing on call a lot.”

“When you’re managing managers, you might talk about high-level technical decisions, why you’re making certain kinds of decisions, or where you are with a technical design,” Fournier says. “But you very rarely go into that level of detail. And the conversations are much more about the health of the team as a whole.”

Managers of managers keep a pulse on the health of the engineering organization

Making the transition to managing managers can be incredibly challenging partly because it’s still important to develop strong relationships and stay connected with the people and projects in the organization — but you’re now a level removed.

To stay connected with the projects going on in the organization, and to the organization’s health, Fournier frequently runs skip-level 1:1s. Her organization is about 100 people now, and she tries to hold a sit-down with everyone at least twice a year.

“Those meetings can definitely help you stay in touch,” she advises. “And then, you can decide how you want to pay attention to other aspects of your team, like ongoing progress. It is useful to keep a finger on the pulse of things.”

Figuring out how you can add value without getting into a team’s decisions and overriding them is really important—and it’s something a lot of managers struggle with.”

When she was managing managers for a smaller team, she would still occasionally pop into code reviews to get a read on how people were collaborating and their communication styles. Today she still wants to know how teams are working, and hear about when there are outages and incidents to understand what happened and why.

Effective managers of managers don’t solve their teams’ problems for them

The manager’s managers’ job is no longer to solve problems themselves, it’s to guide and coach their direct reports so they can solve problems with their teams.

It’s very tempting to get in a situation where a manager comes to you with a problem, and you tell them to do X. But it’s not really your job to tell them what to do. It’s your job to ask them what they think they should do, talk them through the alternatives, and then let them pick one.”

“It’s very tempting to get in a situation where a manager comes to you with a problem, and you tell them to do X,” Fournier says. “But it’s not really your job to tell them what to do. It’s your job to ask them what they think they should do, talk them through the alternatives, and then let them pick one—maybe with some nudging from you—and then follow up and see how it goes.”

It’s very rare that a manager of managers should be overriding technical decisions, she says. It happens once in a blue moon, but it’s a bad sign if they find themselves doing it with any regularity.

“It’s a very undermining thing for a senior manager to veto someone’s technical decision,” Fournier says, “so you want to be really careful about that. It has to be something that I have a better risk analysis on than the people making the decision, and I’m willing to take the heat for it.”

In essence, managing managers comes down to learning how to listen carefully and see things through a level of abstraction. These leaders are no longer working regularly with the technical details, so they get the opportunity to build up their instincts about when to ask the right questions and where to gather information. They’re keeping track of the important things without getting overwhelmed by the details of the team.