In July, we hosted the first annual Code Climate Summit, a one-day
conference for leaders of engineering organizations who want to better
themselves, their processes, and their teams.

Today we’re sharing The Role of being Technical in Technical Leadership, by
Camille Fournier, Managing Director at Two
Sigma.

 

Transcript of talk

Camille Fournier: Hi everyone, I am excited to be here at this Code Climate
Summit. We were customers of Code Climate when I was at Rent the Runway, so
I’m a huge fan of the product and I was very honored to be invited to come
speak.

This is a talk about engineering management, which I think is pretty important
for building effective engineering teams and building good products. We’re
going to talk about what actually what it means to put the engineer in
engineering management.

Before I begin, of course, I must give a pitch to Two Sigma, so I am as of
about four months ago, the head of platform engineering at Two Sigma. Two Sigma
is a financial company here in New York. Our engineers and modelers harness
data at tremendous skill, use machine learning, distributed computing, and
other technologies to build powerful predictive models. If you are interested
in that world, twosigma.com/careers, check it out.

Okay. So. Let’s get this really started. “You either die an engineer or live
long enough to see yourself become the business person.” This something my
friend Cliff Moon at some point said or tweeted, probably both, and I like this
quote not just because it’s kind of funny, but also because I think it really
summarizes the struggle that many people have when they think about engineering
management. “Am I still an engineer, or have I suddenly become a
business person?”

I personally have struggled with this, so this is how I have a lot of empathy
with this. I started out my career as a hands-on engineer, I guess as most
people do. I was hands-on for a really long time, building lots of different
kinds of systems, mostly distributed systems.

I actually just got photographed for something called Faces of Open Source,
it’s facesofopensource.com, which is taking pictures of various people in the
open source community. It was a cool experience and this is the photo that came
out of that.

So, I’ve spent a long time as a hands-on engineer. At some point in my career I
was like, “Oh, I want to do more, I want more power, I want more authority.”
Lots of bad reasons, but I decided that I wanted to go into management, so I
joined a startup as a director of engineering, and I was still actually writing
a lot of code for the first year or so I was there.

As the startup grew – and that startup was, of course, Rent the Runway – as
that startup grew and was successful, and I was fortunate to be growing and be
successful along with it, I hit that dreaded cliff of no more coding, where I
really had to stop coding.

We tell managers that this will happen. Sometimes we tell them a little too
early in my opinion. I actually think it’s okay for you to write some code when
you have a small team, but there is certainly a point where if you are writing
code as a manager, you’re probably avoiding doing more important work, like
talking to people, and planning things, and other kinds of things that make
teams successful.

It’s still hard. It’s really hard if you’ve been a programmer for a long time,
if you’ve been a hands-on person for a long time, hitting that cliff of no
coding is really painful. I remember, it probably took me like a year of angst
before I finally got over it.

We say a lot of things about management, we call it a career change and now
that you’re a manager, you’re no longer an engineer anymore. I have probably
said this myself, and while I think it’s kind of true, I also really love the
language that we use when we say this, because it’s also kind of a negative way
to frame things.

I wrote a book and you all have copies of it, which is cool. I’m very flattered
that they decided to give my book as a giveaway here. This book is about being
an engineering manager. It’s about the various stages of engineering
management.

Part of the reason that I wrote this book was that I felt that there was not a
lot out there that really walked the path of being all the way from a mentor
and early career leader, but definitely still a hands-on engineer, all the way
through to being something like a CTO or a VP of engineering or a senior
executive.

I also wrote this book because I have a thesis that is, among other things,
while the people side of management is really important, managers also need to
be technical. I think that there is a reason that we tend to promote technical
people into management roles. It’s not just because we want to punish them.

Engineering management is the intersection of engineering and management.

It’s that, engineering management is the intersection of engineering and
management. It is not just managing a bunch of people who happen to be
engineers. It is important that you, to be a really successful engineering
manager, understand the way that people do their work. You are able to guide
their technical decisions.

This doesn’t mean you’re making decisions for them. In fact, most of the time,
I don’t really make all that many decisions. I try to ask good questions and
guide my teams, but I’m not actually making decisions for them. The hands-on
people who are doing the work are making the decisions, but I still need to
understand the context in which they are operating. That context includes what
it is like to be an engineer.

This talk is going to cover three traits that I believe are overlapping traits
that you tend to find in great senior engineers, and the way that these traits
translate into what makes good engineering managers. I’m going to talk about
debugging, I’m going to talk about empathy, and I’m going to talk about
judgment.

DEBUGGING

Let’s start with debugging. I love debugging. I don’t know about all of you,
I’m sure some of you do and some of you don’t. It’s definitely not the thing
that every single engineer loves to do, but it’s something we all have to do
because

I’m sure you’ve probably forgot a semi-colon the first time you wrote hello
world.

We’re always debugging all the time. Things are always breaking and you’re
always having to debug, and as you become more and more of a senior engineer,
you experience more, new, interesting ways that things can fail. You start to
sense the vast possibility of causes behind failures.

Part of the reason that I went into management is actually the same reason that
I love debugging. I wanted to understand why things were happening. I started
asking why a lot. Why is this happening? Why are we doing this? Why do we do
this process this way? Why didn’t we fix this? Why didn’t we make this choice?
Why, why, why, why?

Asking why too much, it turns out, is a not uncommon way that people end up
becoming managers, because they want to know. They want to know not just about
what is causing systems to behave in a certain way, but they also want to know
what’s causing us to make decisions this way in the first place.

At the end of the day, this skill set overlap is what a lot of people call
“systems thinking”. It’s not my favorite term, but I like the concept. People
that are good at seeing the interactions of different kinds of systems that you
may not have perfect information into. When you’re talking about looking at the
interactions of people, you can’t read people’s minds. You can only go by what
they tell you.

You don’t always have perfect insight even into the software systems you’re
developing. People who are good at seeing in systems, are good at debugging,
and they tend to become good managers for the same reason, because, guess what,
as a distributed systems engineer, the system is slow, it’s probably the
hardest problem you’ll ever have to debug, and as a manager, the team is slow.

“The team is slow” is the hardest problem you’ll ever debug.

It’s probably the hardest thing you’ll ever need to debug, especially if you
happen to be working at a startup for a CEO, especially if the CEO is not
technical. But e*ven if the CEO is technical, frankly, they always want to
know, “Why aren’t we getting it done faster. Why aren’t we moving faster. Why
isn’t this release done? Why haven’t we finished this?”

To figure this out, you have to look across a bunch of different elements. You
have to look at the people, sometimes as humans, we move slowly because people
are unmotivated for whatever reason. They’re burned out, they’re tired. They
don’t get along. The team hasn’t actually gelled all that well. You’ve got
somebody that’s very disruptive. They just can’t agree on the way to do
something.

Sometimes, of course, the challenge is a process problem. You’ve got this
product management team that thinks that they’re mini demi-gods over here,
throwing work over the wall to the engineering team and saying, “Behold my
brilliance, go implement it.” And most engineering teams don’t really like
that, it can be very demotivating, although some of them do. You’ve got to
understand what process, what’s the process contributing to the team’s
slowness.

And of course, sometimes it’s the systems. Sometimes you really are dealing
with really hairy, nasty technical problems that are going to take a long time
to figure out. They’re going to take a long time to solve.

You as an engineering manager, have moved beyond the world where you’re
thinking about the interactions of software systems all the time, but you’re
still looking at system interactions. You’re looking at the interactions of the
systems of the humans and the processes that the humans are using and the
technology that they’re having to deal with to get their job done every day.

EMPATHY

The second characteristic is empathy. We talk about empathy a lot. It was
already spoken of quite a bit in the last talk. I think it’s a very popular
thing to talk about in technical circles these days, which is probably pretty
good, because for a long time we had this very robotic approach to technology.
Programmers want to go and close the door and be in silence and just thinking
about computers. We do realize that to really build effective products, we need
to care about our customers and to build effective teams, we need to care about
our teammates, and as a manager, we want people who appreciate people. But,
there’s a little more to it than that.

There was a study done recently that showed that the number one contributor to
workplace happiness that they measured, was actually whether or not they
believed their boss was highly competent. Highly competent could mean a few
different things. Highly competent could mean the boss could do your job, but
highly competent could also mean a domain expert in the field.

It’s very clear though, that people really do want highly competent bosses, and
frankly I feel the same way. I get to work for this guy, his name is Alfred
Spector, he is the CTO at Two Sigma. He was a professor of computer science for
a long time, actually started a company, then became a lead scientist at IBM.
He ran Google Research for a very long time before coming to Two Sigma. He’s a
very interesting person. He has a really incredible technical computer science
background, he’s a good manager, which is amazing, and he’s entrepreneurial.
All of those things are awesome, and I’m really excited to get to work for
someone like that. I want to work for someone that I believe is highly
competent and has shown a track record of doing great things.

That doesn’t mean that I expect him to sit down next to me and pair program.
That actually doesn’t mean that you as a manager are going to be spending all
of your time actually in the weeds of the technology, coding with your team.

So what does it really mean to say that we want someone who possesses technical
empathy? What does this empathy element mean for managers beyond just, you can
see how people are feeling?

I think it really means that you want someone who appreciates the work, someone
who appreciates the details of the work and why work is good or bad. Your
manager is often the person who evaluates you, who is evaluating your work and
saying who’s doing well and who’s not doing well, maybe even who’s going to get
promoted. You want that person to actually be able to tell the difference
between somebody who does high quality work and someone who doesn’t.

You also just want that feeling of the expert appreciation. It means more when
you respect someone’s opinion that they have a high opinion of you. We want
someone who really appreciates why our work is hard, why our work is done well,
maybe even, sometimes is able to give us suggestions about how to do it better.
But certainly, we at least want that appreciation.

It’s also good as a manager, to be able to appreciate what your teams are going
to be excited about. Different people are excited about different things, but
engineering teams tend to get excited about slightly different kinds of
problems than marketing teams or sales teams. Engineering is a special
discipline with its own rules, with its own challenges and we want managers who
can appreciate and identify interesting problems and direct us towards those
interesting problems and make us feel like they understand what the wider tech
world is excited about and can actually help us get to do some of those
exciting things. Even more importantly of course, we want managers who
appreciate what frustrates engineers. It’s not obvious to a non-engineer, what
parts of the job are stressful. It just isn’t. It’s very hard to understand how
stressful it is to get distracted or pulled away from your code every 15
minutes because somebody keeps coming over to talk to you over your shoulder.

That can be a hard thing for people to understand. It’s much easier with a
technical manager, at least someone who appreciates what the work is like, to
be able to predict those frustrations and therefore cut them off before they
start happening.

TECHNICAL JUDGMENT

Last but not least, there’s the matter of technical judgment, which is of
course, very important in senior engineers. I said before that technical
management is often the art of guiding technical decision making. It’s not
making the decisions yourself, but even when you have a very strong tech lead
or architect or whatever and a great product manager, what you will often find
as an engineering manager is that you are the person sitting in the middle of
those two and trying to balance those differing viewpoints.

You need to make sure that you are actually taking into account the full
context of both the technical and the business side in order to help the team
prioritize their work. Because ultimately, the technical decisions that are
made will impact the effectiveness of the team, and the effectiveness of the
team as a manager is definitely your job.

A lot of the people in their first go round of engineering management try to
apply just the process to things. They say, “Oh, I know the process that will
solve it.” It can be anything from we’re going to do OKRs, we’re going to have
engineers vote on whatever project they want to work on, we’re going to do
agile, scrum, kanban, whatever style project management you want to do.

I actually think process is useful and different processes work well for
different teams, but there’s a lot of nuance. You have to understand what
process is going to work for your team. Moreover, you’ve got to remember that
process does not make decisions for you. The best thing process does is provide
the context, again, all of the information at your fingertips with the right
people in the room, to help you make decisions.

One quote I use in my book is that a good political idea is one that works well
in half-baked form, which I believe is from some kind of economics blog. I
believe the same is true for a process. Good processes are going to work well
in half-baked form. As an engineering manager, you’ve got to understand how to
get something that works well for your team, but it’s not going to be the
magical decider of all your difficult technical decisions.

Good senior engineers and good engineering managers have a good eye for detail.
They can be detail oriented when they need to be, because ultimately, building
good software systems is all about the details. It’s all about understanding
the details of the problem you’re solving and accounting for those details.

The same is true for making good decisions. Good decision making is all about
having the taste and understanding the nuance that makes two decisions that
seem about equivalent actually different, and one the right way to go, and one
the wrong way to go.

I talked about prioritizing. I’m going to reaffirm that point. You’re at the
end of the process, you’re trying to get something shipped. Prioritizing,
prioritizing, prioritizing, is the name of the game and good engineering
managers are good at being in that end stage and looking at the list of
technical features and looking at the list of product features and asking both
sides what’s really important here.

“What technical features can we absolutely not ship without. It would be bad
for us to ship without having any kind of alerting on this, because this is
actually pretty mission critical. But you know what? Actually, this is just an
MVP and it’s going out to five people, so maybe we can just ship it without
that feature.”

On the product side of course, it’s like, “Hey, product team, I know you love
all these features, but which of these do you love the most, because guess
what, this beautiful widget that you want the engineering team to build, we’ve
talked it over and this is going to be a three week project to get right. Does
this really have to be in the critical path of delivery?”

Being able to balance those two concerns and advocate for each side is one of
the important characteristics of good engineering management.

Last point here, you have to understand the problems that the team is solving
well enough to be able to communicate them with various people.

Manager telephone. Manager telephone happens when your manager goes and sits in
a meeting, takes a bunch of notes, comes back to the team, asks the questions
they have written down on their sheet that were the questions that were asked
in the meeting, writes down your responses, goes back to the other team, reads
those responses out and so forth. Zero value add. You want managers who can
understand at least well enough to focus and reframe the questions that are
being asked from people who aren’t familiar with the work of the team and who
are good at actually getting the right information out of the engineering team,
and making sense of it.

Nobody wants managers who are going to play telephone. That’s simply a zero
value add activity. We want people who are going to appreciate the work that’s
going on well enough to actually focus the discussions around it.

Debugging, empathy and judgment. These are pretty important. I think these are
important skills to build whether you decide to become a manager or whether you
simply want to be a really great hands-on engineer. What else?.

There is a little bit of a risk to this whole “rah rah managers should be
technical” and that risk is that you get managers who were once pretty good at
being technical, but who have gone hands-off for a long time and lost their
touch a little bit. They still think of themselves as really amazing, as one of
the people, as it were, but they don’t really remember what it’s like, and
frankly, they haven’t even kept up, so they don’t really know what it’s like to
write code in JavaScript. They’ve only ever written code in C++, and frankly,
that’s just a different world, right? Writing code for the browser’s super
different. They have not kept up. They don’t really appreciate what the actual
work looks and feels like.

Stay humble.

If you decide to go on this path, it’s very important that you stay humble with
your knowledge and your understanding. You can glue this in a bunch of
different ways. Some people advocate for going back and forth between big
companies and small companies where you can be a manager and then you can be
hands-on and that’s an awesome path to take.

Some ways you could do it – frankly, I sometimes write a little bit of code. I
work on a lot of open source projects, but realistically, you can keep reading
code, you can keep helping debugging. You’re going to get a little hands-off,
though.

My advice if you decide to follow this path is to, if nothing else, keep
learning, particularly about advances in the way software engineers do their
work. That’s things like, “What does it mean to build all your software based
on cloud services.”

That’s very different than building everything in house. What does it mean to
do a continuous deployment process? What are the major advances in the way
people actually do work and deliver software? That’s a really important thing
for you to keep in touch with as an engineering manager if you’re managing
software engineering.

Okay, so these traits, one more time. Debugging, seeing those symptoms,
technical empathy, that technical appreciation, and finally judgment,
prioritizing and understanding the problems at hand.

I still consider myself an engineer, even though I don’t write code all that
often. I personally hope to die an engineer someday, but whichever of those two
paths I end up following, I know that it’s going to require constant learning,
constant reading.

You can be like this guy. He used to work for Code Climate and he is the
quintessential renaissance man who manages to both be the business jerk and be
an engineer, all in one. So read more. You can start with my book, because you
all have a copy of it, and thank you all very much. I’m happy to take
questions.

Audience 1: Thank you for the talk, it’s great. Disclaimer, I’m not an
engineer, I’m a product manager. My question to you as the technology industry
veteran that you are today, you see these four engineers that either goes into
principal engineers or technical fellow or going to director of engineering, do
you see the same trend with product management? Do you have any advice for
managers of product manager?

Camille Fournier: Not as much, mostly because the product teams tend to be
so small that even as a manager of product managers, you’re not usually
managing a lot of people. There’s just a huge difference between … frankly, I
think you can be an “individual contributor style” engineer and still manage
three or four people, particularly if they’re very senior and they don’t
require a lot of mentorship or management.

I think that often product management, because there are just not that many
people to be managed, it’s not as much of a fork. I do think that what you see
happen with product management is that product managers who become more senior
or experienced, tend to be like general managers – perhaps of business lines -
and that is a bigger, more complex management job.

I could imagine that for product managers there is a little bit of a split
between, I’m going to go be a general manager for a pretty big company and run
a large business line and actually have a lot of management accountability or
I’m going to stay very focused on just product direction and strategy.

Audience 2: Great talk, thank you so much. In your experience, what is a
good management to engineer in ratio, so how many engineers per engineering
manager do you think is a right mix. I know it’s different for every company
and every field and all that, but just in general.

Camille Fournier: Okay. I do think it’s very hard to effectively be a
one-on-one manager for more than eight to ten people. If you’ve got a team of
more than ten people directly reporting to you, and frankly for many people
it’s less than that, you are probably not serving very well, some of those
people.

I know personally that if I have more than about six direct reports, at some
point, people are getting less of me than they otherwise might. That helps sort
of think about the ratios. I do still believe that you can effectively be
managing a small team and acting as an individual contributor. You’re not going
to be 100% as effective as you would be if you had no team. You can tweak
ratios that way, but I certainly don’t think that it’s a good ratio to have one
manager per 20 employees. It’s probably not a good ratio to have one manager
per two employees either. It’s going to be somewhere in that.

I would say probably one to six, one to eight is okay, especially if the line
managers are still expected to stay fairly technical even if they’re not
writing a lot of code there, they’re really thinking about a lot of technical
issues.

Audience 3: Hi. You said that team effectiveness is a manager’s primary
responsibility or one of them. What are the KPI’s that you use to determine
your team’s effectiveness?

Camille Fournier: Okay. A few KPIs that I would see, obviously, retention.
Are people quitting? That’s a big one. How are we doing on the deliveries that
we’ve committed to? If we’ve committed to deliver certain software or hit
certain goals, how effective are we at hitting those goals and are those goals
stretch goals? Do we think they’re not the level we would like them to be?

I think overall morale of a team is just generally important, so even if people
aren’t quitting, you can still find yourself in a situation where people aren’t
quitting, but they’re just not that excited about work. They’re not that
engaged and enthusiastic. A lot of team effectiveness, the output is what work
gets done, but the side pieces of it are really a lot about morale and
retention and engagement from the team.

Audience 4: You talked about show an appreciation for team members. Have
you ever been in a situation where you show appreciation of a team member and
it’s fostered envy from other members or there’s been resentment as a result?

Camille Fournier: Yeah, absolutely. I think was accused of playing
favorites at some point in my career, so I’ve tried to be very aware of that. I
think appreciation is one of those core management things that you want to try
to do a lot for everyone. It actually is not a bad thing to tell people they’re
doing a good job fairly regularly and try to tell everyone on the team.

The way you recognize people, particularly if you do public recognition, you’re
definitely shaping your culture when you do that. If you always publicly
recognize individuals, and you never publicly recognize teams, your company is
going to start to develop a culture of “individual accomplishments are the most
important thing and it’s better for me to get the win myself than to bring the
whole team along.”

You have to be very careful with thinking about how you recognize those things.
Honestly, I think a lot of this appreciation is just in that one on one. Do I
feel like my boss really understands the work I’m doing well enough to be like,
“Wow, that was a hard thing. That was a really cool set up you did to get that
migration to go so smoothly. I’m very impressed with the technical work that
you did. I’m impressed you thought through this process in that way.”

I think a lot of appreciation is very effective just in a one-on-one context,
not even worrying about big team appreciation.

Audience 5: You mentioned we all want to work on hard problems, fun problems,
and maybe direct our team towards those. Often we don’t necessarily have the
decision making in where the product goes, where a business wants to go, so
what are your strategies for maybe managing upward or convincing them of going
towards maybe a more difficult problem but more impactful?

Camille Fournier: I think it depends, so a lot of the times … hard problems is a
little bit of a, I don’t think I phrased that as well as I should have.
Engineers want to feel like they are having impact, so some engineers are very
much driven by solving the hardest problem. I think the best thing you can do
in that case is help identify where there are really hard problems and make
sure you’re keeping those engineers as close to those as possible.

A lot of the times what you do though as an engineering manager is you also
help people find some of the more purely technical problems to solve, and those
are not necessarily hard in the theoretical computer science hard way, but
they’re often hard in the, “Oh we really need to clean up this particular piece
of technical data or this particular system” and you as a manager, are actually
explaining the value of spending that technical focus to the rest of the
business and saying look, “This is what this is going to enable. This is how
this is going to speed us up, or not slow us down in the future.”

And that, I think it’s a matter of really being specific about what the goal in
that clean up work is and trying to find measurable things that you can do once
you have done that. Some of it’s also just about setting very hard guidelines
with “we always spend a certain amount of time on this kind of thing because
this is important and this is the way we run our engineering teams.” It’s a
combination of those things.

Audience 6: As you become more removed from the day to day delivery of code, do
you have any tips for ensuring code quality from your team members?

Camille Fournier: That’s hard. Well, perhaps you can use, a lovely product
like Code Climate, a word from our sponsors [laughs]. I do think that letting
go actually can be really hard. Some of it is setting standards and being as
clear as you can about the standards that you want the software to maintain.
That can be anything from someone like me, I’m very passionate about testing, I
think testing is really important and so I try to set basic standards like,
“Look, we should be very cautious about ever accepting pull requests or
whatever that don’t have tests with them. Why isn’t this code tested? Why
aren’t we writing tests for this stuff?” I think you can do things like that.

I think also some of it though is about, you hopefully have senior engineers on
your team that you’ve trained, that they understand what good code looks like.
You want them to be teaching everyone on the team what good code looks like.
That is really one of those areas where it’s not really your job as a manager,
although you probably still care, but you do want to make sure that senior
engineers feel like they have the ability to chime in and say, “Hey, we want to
improve the standards in this code. We want to improve the standards in this
software, and here’s what we’re going to do to help with that.”

Audience 7: When you first transitioned from coding full time to management, did
you experience imposter syndrome and how did you deal with that?

Camille Fournier: I wouldn’t say that it was imposter syndrome exactly. I
will say that part of becoming a, especially a senior manager, is developing a
certain level of presence and being able to, the body language and the way that
you present yourself, and the way that you talk, and the questions that you
ask, and the things that you do, are actually important. That’s actually a
pretty hard lesson to learn, and so I wouldn’t say that it was exactly imposter
syndrome, but there was certainly a level of “why am I not getting the respect
that I should get because of my title or whatever” and I think some of that was
just, “Oh yeah, I have to learn how to be in a room with my peers and be
productive and not undermine people and not be disruptive in certain ways, or
make my points in a way that people will hear them and they won’t react
negatively. I would say for me, that was the harder lesson than imposter
syndrome. I don’t feel like I had too much of that, that’s never been my
problem.

Audience 8: Hi. Thanks for speaking with us. Quick question on dealing with
promotions, especially as your team size starts to grow. You naturally have to
promote people within hopefully, but oftentimes you might find a couple of
candidates within your team that when one is a more natural leader, but they
both have the same aspirations, how do you generally deal with that? How do you
smooth that out?

Camille Fournier: Yeah. I think the best thing that you can do … I think you’re
lucky if you know the aspirations. I’ve certainly had people where we did a
round of making tech leads, for example, and someone got very upset because
they weren’t chosen and it was a shock to everyone involved because nobody had
any idea that this person was even interested. And so that was a little bit of
a mistake on our part of not actually spending the time to understand what
people wanted, to understand people’s aspirations. Part of what you need to do
is make sure you understand the aspirations.

Once you understand them, I think then if you think that you’ve got a person
who has, frankly, better skills right now, maybe because they just have a
natural skill set, that’s okay, but you want to give the other person coaching
and try to identify specific opportunities for them to develop some of those
skills and to learn some of those things.

Even though they’re not necessarily being promoted to manager, maybe they can
be running certain projects. Maybe you can work with the new manager and say,
“This person really does want to be in a management role and so we need to be
looking for opportunities for them to step up and take some leadership and push
themselves out of their comfort zone, maybe give presentations to the team”,
whatever those gaps that you think that they might have, giving them a chance
to actually practice the job and fill those gaps is a good way to prepare them
for when the next opportunity arises. Now they really have the skills and the
confidence to do it.

All right, I guess that’s it. Thank you.

Camille Fournier is a Managing Director and Head of Platform Engineering at
Two Sigma. She is the former Chief Technology Officer of Rent The Runway and a
former Vice President of Technology at Goldman Sachs.

Fournier earned an undergraduate degree from Carnegie Mellon University and a
Master’s degree in Computer Science from the University of Wisconsin–Madison.
She is a maintainer of the Apache ZooKeeper open source project, writes the Ask
The CTO column for O’Reilly Media, and is a regular public speaker and advocate
for greater diversity within technology and leadership. Her book, The
Manager’s Path
, was published by O’Reilly in early 2017.

Read more at the source