Interface With Your Database in Go Tests

Go’s interface provides a way to abstract away things like your database for
testing.

The Role of being Technical in Technical Leadership

November 15, 2017

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.

[…]

The Ruby Rails Aggregator