In this interview, we talk to Camille Fournier. She is the author of The Manager's Path: A Guide for Tech Leaders Navigating Growth and Change -  a book our technical team's been devouring lately about growing as a leader in the realm of product and technology. Camille is also a managing director at Two Sigma, where she heads Platform Engineering, and the former CTO of Rent the Runway, the fashion rocketship startup, where she published their much benchmarked engineering ladder, a set of behaviors and competencies that has helped many companies structure their technical career progressions. We'll talk about her amazing career, about leadership in tech and about performance management in tech teams. I am sure you'll enjoy this interview!

On her story

Kiko: Can you tell us a bit about yourself? How did you get started in tech?

CF: I have been into tech-y stuff for my whole life. I decided to go to college for Computer Science and attended Carnegie Mellon University’s School of Computer Science, so my decision to go into tech was made quite early in my life.

On product team organizational structures

Kiko: There are a lot of companies in Brazil organizing themselves "the Spotify way": in agile, multidisciplinary teams, where there's no actual "manager". Someone drives initiatives (usually a PO or tech lead) but has little to no responsibility in terms of people management (performance reviews, raises, time off, promotions, etc.) On the other hand, there's Mark Zuckerberg telling us to innovate on products, but not on organizational structure. In your experience, what's the optimal structure?

CF: In general I think that you probably want to have some sort of management structure once your company grows past its first, say, 10ish people, and especially once you have anyone in the company who is perhaps earlier in their career and needs more mentorship and guidance. I like to leave room for flexibility when it comes to project team assignments.

One thing I definitely share with Spotify is the desire to have initiatives where people group together to solve real business problems and they aren’t just together because they all report to the same manager. I don’t think that you absolutely have to have people management as the determination for who works on what projects. However, people management is an important factor in scaling a company. Most people want to know they have a manager they can rely on for feedback and coaching.

Kiko: In these org structures, who absorbs people management responsibilities? A chapter lead?

CF:In my experience, multidisciplinary teams can still report into functional managers. So you may have a virtual team made up of people from different areas, and those people have managers in their various functions (like tech, marketing, etc.), but work together as a group towards a similar business objective.

This sometimes require managers to be able to juggle the details of a few projects, because it’s hard to manage people effectively if you don’t know what their day to day job is like.

One structure that works well here for tech is to have a tech lead/manager for the engineering part of a multidisciplinary team, reporting up into a more senior engineering manager who may oversee engineers in a few of those teams.

On the hate-hate relationship between middle management and developers

Kiko: Google has famously tried doing away with managers completely (its then CTO at one point had more than 200 direct reports), and found out after much pain that managers - good managers - are necessary and very useful to running a great engineering organization. What's your take on the need for managers (those who help us with compensation, performance, time off, promotions, etc.) in tech/product teams?

CF: I think managers provide an incredibly valuable role in tech/product teams, and it goes beyond the need for someone to make sure the people are being cared for. This is of course essential and something that you obviously miss without managers. Most people want to have someone to talk to regularly about their career, to get feedback from, to help them understand the larger org, and to help attend to the team dynamics, which is hard to get without managers. More than that, good managers are great at understanding what the team should be focusing on, helping to maintain technical standards on the team, and making sure that their team fits in well with the wider company. They grow new leaders and hire great people, and put in the work to make sure the whole team is able to be productive. When I look at teams with absent or weak managers, the thing that is most often lacking is clarity of focus from an engineering perspective.

Kiko: What makes a great manager in a tech/product team?

CF: This always depends in some ways on the team and its needs. I have a set of great managers reporting to me, and each has their different strengths. They are all good communicators, which is a pretty essential management quality. They all care about the products they are building, and understand the people they are building those products for. Some are stronger operationally, and very good at disciplining their teams to build resilient, operable systems. Some are strong at building relationships not only within their teams but across the organization. Some are creative big thinkers who inspire the engineers around them to think about the future. Most are somewhat to very detail-oriented, and have a firm grasp on what is happening throughout their team and where the risks are.

I would say that the best managers are very good at prioritizing work for their teams, identifying what is important and seeing the common patterns for both success and failure in their teams. Particularly if you are in a team with a product-focus, you need to be good at prioritizing work, and making your team highly productive. Productivity in engineering often comes down to a combination of breaking down the work into small pieces, releasing changes regularly, attending to the technical quality enough that it doesn’t become a major burden or slowdown, and prioritizing aggressively.

Kiko: We see a lot of top engineering minds eschewing people management roles. And we also see that the best engineers - technically speaking - tend to have a much better legitimacy with their direct reports when in leadership roles. How have you solved this paradox in your companies?

CF: I’m not sure I can claim to have solved it, honestly. For the most part I have not seen a shortage of people who want to become managers. Many engineers get to a certain point of seniority and find that they are frustrated at the challenge of leading via influence, which often leads them to conclude that they should become managers. If anything, I think it’s hard to make a great career path for people who want to continue to grow their careers but not manage people directly, especially for those who want to be promoted quickly. It is almost always a slower career progression as an individual contributor with the exception of a very small number of individuals who are both very talented and very lucky. For those who want to manage, I try to remain firm that I don’t want them to manage until they’ve been an IC for a reasonably long time (my personal rule of thumb is around 5 years). Part of this is to ensure that the people you put into management have achieved significant technical fluency before they become managers, so they have the best chance of retaining that technical strength even when they aren’t building systems themselves.

On competencies and performance management

Kiko: One of the things you're famous about is for publishing Rent the Runway's engineering ladder, a set of competencies - shall I call them that? - that allows a developer and her manager to figure out what does a career progression look like in terms of skills and contributions to the team, and where the engineer is in relation to that career. We've started using it at Qulture.Rocks, and developers love the clarity it brings to performance discussions. One of the tensions we felt is, on one side, keeping it as simple as possible, and on the other side, breaking down levels and competencies ad nauseam so we can get more "precise" readings. Just as an illustration, we broke down the first level in two to account for interns and apprentices (not to say that it feels perfect now - it doesn't). How did you guys balance those competing needs?

CF: These things are always evolving, which I think is fine. I always caution people that there is really not checklist that guarantees you promotion, and trying to create such a thing is probably not a good idea. At the same time, you want to be as clear as possible with people the major areas that are important for success at each level. The first ladder I used was too vague, and that caused a lot of confusion and made the ladder not very valuable. Part of the reason the second ladder has both a grid/spreadsheet version and a long-form text version is to help add color around the descriptions at each level. What I find is that people get really hung up on the technical qualifications of the ladder, but above some middle level, it’s really the execution, communication, leadership aspects that make a much bigger difference, and those are very hard to turn into checklists. So I encourage leaders to both get comfortable with some ambiguity, but always question whether you have done the best you can in representing what is really important at each level, and be willing to make small changes as your company evolves.

Kiko: Competency assessments in performance reviews are quite popular with the HR crowd: a manager reviews her directs across many competencies on a scale that can go, for example, from "1 - below expectations" to "5 - above expectations". How exactly did you guys use the ladder? Was it like that?

CF: Not really. Some of my team did this in performance reviews, where they would use the various categories and rate people depending on how they were doing. But there was never anything formally set out.

Kiko: In many companies we work with there's often tension between tech/product teams and HR. Tech people seem not to like anything that comes from HR and shun most firm-wide initiatives. HR, on the other hand, wants to unify core processes like performance management and hiring. How did/do you deal with this conflict?

I can’t say I’ve had this conflict too much. I would advise leaders who are trying to manage this to make sure that HR is explaining their decisions directly to the team. Sometimes when you push for that clarity, you get more understanding and better outcomes.

Kiko: Was the ladder used for bonus/compensation/promotion decisions? If yes, how did you differentiate between a "great" level 4 and an "average" level 4, if anyway?

CF: Promotions, absolutely, the point of the ladder was to evaluate what level a person was performing at. When we did promotion committees, we used the ladder to ask ourselves the question, across each category, is the person up for promotion performing at the new level? That helped ground the promotion conversations in something concrete. Levels also had some relationship to compensation, as each level had a range of salaries and a formula that applied for bonuses, so a newly-promoted level 4 would probably be paid less than someone who had been at that level for a while.