How Buffer.com Develops Engineering Leadership Skills From Day 1 With Katie Womersley

Episode 11

There is an inherent difference between leaders and managers that is often overlooked. While most think that leaders are “born,” Katie Womersley, VP of Engineering at Buffer, disagrees. Leaders and managers both require skills that can be taught, and developing those employees from within the company can be the most timely and economically efficient way to do so. We also discuss the perception of status, authority, and vulnerability with the workplace.

 

Show Notes

• What is Buffer?
• Leaders vs. Managers
• Setting expectations for leadership growth
• Questions that threaten authority status
• Perception management and vulnerability
• Levels of the career framework
• Katie’s journey into management
• Transitioning others into management and bumps along the way
• The “dark side” of management…is it real?
• Developing leaders from within the organization
• Katie’s favorite resources on leadership & management

Links

• Buffer.com’s Engineering Career Framework
• Sponsor: www.GitPrime.com
• https://buffer.com/
• https://www.linkedin.com/in/kathleenwomersley/

Transcript

Announcer: Welcome to the Programming Leadership podcast, where we help great coders become skilled leaders and build happy, high-performing software teams.

 

Marcus: Welcome to the Programming Leadership podcast. I’m Marcus Blankenship, and I am so excited to have my guest with me today, Katie Womersley. Katie is an executive at Buffer, a fully distributed team. We met a few weeks back when I led a panel discussion for GitPrime on remote and distributed teams. Katie, thank you for being my guest today.

 

Katie: Marcus, thank you so much for having me. Really, I loved the panel, and I’m so excited to get to chat with you more. This is a lot of fun.

 

Marcus: Well let’s start. Tell us a little bit about you and maybe your journey to Buffer. And what is Buffer anyway, besides it’s just a great company name, but what is it and what do you do there?

 

Katie: Thank you. Yeah, Buffer is a great company name. I am VP of Engineering over there. We are a fully distributed team. We have people all around the world. We’re currently 90 folks in the company overall, 35 in engineering. And we champion transparency and remote work in how we work. That’s what we’re known for. What we do is social media marketing. So for folks doing their marketing on social media, online-first consumer brands, most typically. We make it really easy to schedule all of your posts, engage with your audience, get deeper insights and analytics into how your efforts in social media have been doing. We create a whole suite of products that help make this a really easy and fun experience for people that are doing their marketing, advertising, engagement on social media networks.

 

Marcus: Wonderful, wonderful. So you are a SaaS product company, it sounds like. People subscribe-

 

Katie: That is correct. They subscribe.

 

Marcus: I’m curious, what particular sector… what do you focus on? Who’s your ideal customer?

 

Katie: Our ideal customer is something we call an online-first consumer brand. It’s companies that may have an offline presence, but they are web-first. Think about brands like Warby Parker, Everlane, AirBuds, Glossier, companies that might not have started out with a retail presence or much of an offline presence and expanded to that. They started out being online only with word of mouth advertising, advertising through Instagram, advertising through having people try out the products and build hype around that.

 

The reason for this is online marketing is key to these brands’ existence because they are essentially an online-only or online-first presence, and marketing through social media is really how they are reaching their customers and how they’re staying engaged. They’re not typically using traditional channels like billboards or magazine ads. Glossier’s a great example of having built up their customer base and become a really large, really successful company almost entirely through Instagram.

 

So Buffer is there to provide the tools for these companies, and it’s a massively growing market segment. We’re there to provide the tools for these companies to reach this audience and to engage without needing to have huge armies of people kind of manually doing all this engagement work, all this promotion work sort of on phones, in apps all the time.

 

Marcus: Wonderful. Well, I am really excited about what we’re going to talk about today because it is near and dear to my heart, and we’re going to talk about how companies, and particularly how your company, develops managers and leaders. When I proposed this topic, and you resonated it back to me, this was something that was exciting to you, one of the first things you told me was, “Well, there’s a difference,” and we should talk about that difference. Can we start there? How do you view the difference between managers and leaders?

 

Katie: Well, Marcus, I would say that, ideally, in an organization everybody is a leader. Leadership is something that you embody in the way you take ownership of your work, the way you go about your tasks, the way you engage with your peers, with people in the organization beyond your team. Showing leadership is something that I want to see everybody do in every interaction.

 

Management is a very specific type of job. It’s not about being a leader at all. It’s about having a very specific set of duties where you are responsible for making sure that people’s role expectations are clear. You’re responsible for providing performance feedback, for providing coaching. You’re responsible for sponsoring employees on project opportunities, making sure that they get promotions when they’re deserving of that work. Management is a very… it’s a nuts and bolts, very specific job that needs to be done in an organization to make sure that people are aligned with the organization’s overall goals in their work and that they are growing and getting recognized for the great work that they do. Or if there are people that need some corrections, that those are being done in, you know, a kind and in an effective manner. Management is a very specific, narrow role. It’s a type of leadership. One type. If there’s everybody in your organization, only a very, very small proportion of your leaders are going to be actual managers.

 

Marcus: Where do you think that leadership comes from? I hear a lot of people who just say, “Well, they’re a natural leader.”

 

Katie: No, I actually don’t agree with that, that there are natural leaders. I think that’s something that we get this idea, perhaps in school, that some people are more assertive, and these people sort of have natural leadership. There’s actually a lot of research that the best leaders, once promoted into typical leadership positions in very hierarchical organizations, like the military, the people who were actually more successful were not the ones that stood out as being loud, sharing their opinions, taking initiative in the previous position. They were actually the best followers, so this idea that leadership is something that you either have or don’t have, I really question that.

 

I think it’s a skill set like anything else. I think anybody can develop the skill set of leadership. Perhaps it might be that some people naturally gravitate to being more outspoken of their ideas, and as a society, there are certain traits that we think look “leader-y”, like outspokenness, assertiveness, a manner of speaking, a sort of way of confidence. We think these things look like leadership, but I really don’t agree that there’s any such thing as intrinsic leadership; you’re born with it or you just don’t have it. I think it’s a skill set like any other. I don’t think anybody these days would say, “You’re either born with design skills or not.” No, you learn to be a designer, or you learn to be an engineer.

 

Marcus: I agree. I didn’t come into this world knowing how to code or ride a bike or drive a car.

 

Katie: No.

 

Marcus: Most things I didn’t come in knowing how to do, so I had to learn them. For some reason, I do hear that idea that leaders are born is sort of sticking around in people’s minds, and sometimes I think it bleeds through when they use the phrase, “Well, they’re not cut out for it,” is one I hear, as though we’re sort of “cut out” in a particular shape.

 

Katie: Right.

 

Marcus: Versus not being “cut out” for something, so I really agree with you. Now, that also means, though, that if leadership and leader skills are learn-able, how can companies promote the idea that everyone is going to be a leader and that we can actually equip people to learn those skills?

 

Katie: Well the first thing I think you need to do is be very specific about the actual skills and behaviors you want to see from folks. Sort of, a word like “leadership” means something different to everybody, so saying, “Everyone can be a leader. We should all embrace leadership,” is not very helpful because people will just stare and you and think that sounds nice, but how?

 

One thing I do at Buffer is, I have a career framework for engineers. It starts right at Engineer 1, the sort of junior, entry-level engineering position, and there is an entire pillar called “Leadership.” It’ll have, for each level of engineering, what I expect from leadership skills at that position, so I have very clear leadership expectations for a junior engineer. That expectation is: you are able to give feedback privately to your manager when you notice something that doesn’t make sense to you. You actually say that. It’s a very concrete action. It’s not something that you’re cut out with, like speaking.

 

Everyone can surface to a manager, and that’s, sort of, the junior engineer level there because we’re not asking you to speak up in front of a group. We’re not asking you to surface problems that’ll challenge the organization six months down the line. We’re just saying, “Raise to your manager when you notice something that doesn’t make sense to you.” And managers will prod. They’ll say, “Look, I haven’t noticed you doing this. It’s an expectation we have under leadership that you point out to me when something doesn’t make sense. You know, we know that there are things in our organization that don’t make sense. I’d like to see you do that. Like, next week, please can you come to our one-to-one with one thing that you thought ‘Hmm. I’m not sure that makes a lot of sense to me.”

 

Being really, really, specific with what it is you want to see is the first thing because then people have a skill to actually build because leadership is not a skill. Leadership is an entire collection of behaviors and abilities that we put in this box, and the first thing you need to do for your organization is unpack that box and actually label each thing. For all the things you think of as “leadership,” what is the exact skill? What is the exact ability or behavior that you want to see from people? And that does differ from organization to organization, depending on your values.

 

Marcus: Let me pause and thank today’s sponsor GitPrime. GitPrime’s platform allows you unprecedented visibility into your development team. For too many years, I’ve had to guess at the status of projects without any real data to make decisions from. Oh, I have tried everything: story points, Velocity, burn down charts, burn up charts. You name it, I’ve tried it. Worse yet, I’ve made the mistake of promising my boss when something would be done only to be disappointed.

 

When I dug into things with my team, I was always surprised between what the charts show and what’s actually happening. Now, it’s not like anyone’s messing up, but things are happening that I have no visibility of, which meant I couldn’t even discuss it with my team. GitPrime changed all that. With GitPrime, you can leverage Git-level analytics. That’s where the real work is happening. It provides deep insights to help you have better conversations with your engineers and your whole team. See things better, build things faster. Learn more and sign up for a demo at GitPrime.com.

 

So one of the things I think you mentioned, if you didn’t mention it here, and maybe you did, was the idea of transparency. This is one of your company values. Do you feel like that… I love that example you gave of a leadership skill, very concrete, that a junior engineer could start to practice with. Does that support the idea of transparency?

 

Katie: Absolutely because it’s difficult to encourage people to do behaviors we associate with leadership, speaking up when things don’t make sense, for example, when they’re not seeing what’s going on. You need to be transparent with what’s actually happening in the organization in order for people to start building that question-asking skill, that “Hey, I don’t understand this” skill. They need to know what this is that’s happening.

 

At the, sort of, more advanced levels, when you’re asking people to anticipate challenges that are going to face the organization six months down the line, so for a senior engineer that’s a behavior I’m expecting, right? But now how can a person possibly anticipate challenges if I’m very secretive with what’s going on in the organization? If they don’t have that context of what’s happening today, how can they extrapolate to the impact of what we’re doing today six months down the line? People can’t be leaders, they can’ practice these behaviors if they’ don’t have the information about what’s happening right here, right now.

 

Marcus: I love that. When you said the word “transparency” originally, my mental model was immediately top-down transparency. People at the top will tell the people at the bottom what is happening in a more transparent way, and that might be because most organizations struggle with that. But I also love that what you said was what you expect from your junior engineers in the area of leadership is bottom-up transparency. That when something, we can build a habit, that when something doesn’t make sense, and I also like that you said, “And there’s a lot, there is stuff that doesn’t make sense. Let’s not pretend, right?” We want to get people talking about it rather than pretending that everything makes sense.

 

Katie: Absolutely, and it’s really fascinating how, in a lot of cases where you see Harvard Business Review case studies of things that have gone really horribly wrong in organizations. Like Enron, what happened? How did this organization implode? The people at each level in the organization, the people doing the work knew what was going wrong. People typically are very aware of the massive problems facing your organization, and often it’s executives that are the last to know what’s going on.

 

We focus a lot on, as executives, sharing context, sharing vision, get everyone in line on strategy, but we don’t focus on making it truly safe, and also clarifying the expectation, that we want everybody else in the organization to share, “How are things looking from your perspective? Because you are actually in the code. You are talking to the customer. You are out there making the sales. What are people saying about our product? What are the sort of problems that you’re dealing with everyday that we really probably shouldn’t have anymore at this stage?” Those are things that executives don’t know and often the last to know, and they’re often things that’ll end up crippling a company down the line.

 

Marcus: Yeah, I actually… just this morning, I was reading Amy Edmondson’s book The Fearless Organization which is about psychological safety. Highly recommended, but it uses a lot those same ideas, and one of the thing it states is that executives are always wondering, “What don’t I know?” Because while they’re doing a lot of talking, and they may want to do a lot of listening, it’s sometimes really hard to get real truth, real information about what’s happening. I just love that that is one of the things you expect from junior people because having been someone who held the title, frankly, of Junior Engineer, I didn’t know they still handed those titles out, but I had that title, and I remember really feeling the title pressure that it was not going to be a good idea for me to ask those kinds of questions and bring up where I was confused.

 

Katie: Right, exactly. I think there’s an idea there that everybody who’s been here longer knows more, and everybody who’s more senior than me knows more and has seen more, and we miss out on the fresh eyes of people new to the organization and the sort of curiosity and perspective, the beginner’s mind of people early on in their careers. I’ve found that, as managers, the nuts and bolts, you manage people, not leaders. We’re all leaders. As managers, a lot of people these days are afraid of the words “I expect.” I’ve found I say “I expect” a lot because it actually builds psychological safety.

 

It’s not some junior engineer going out on a limb, being very unbelievably, riskily bold, saying, “Hey, I’m confused.” We say, “I expect you to share with me regularly stuff that’s confusing. It’s there for sure. I expect this from you.” So they don’t have to then go out on a limb and be like, “Oh, I don’t know if this okay, but I had a question, is it all right for me to ask?” They’ll know they’re expected to ask. It’s safe.

 

Having those expectations and clearly saying that they are expectations, putting them in a career framework somewhere, using the words “I expect” makes it safe for people to just do their job. Then they’re actually leading. They’re doing these behaviors, but we think of leadership as you really push the boundaries, go outside your lane, and you’re very brave and it’s very risky. If you expand the boundaries of the job, if you expand those expectations and say, “Hey, we expect you to do all those things as part of your job,” you remove the fear of people needing to bust out of their lane and be very, very bold. They’re then able to say, “Oh, okay. This is expected of me,” and rise to the expectation because it’s just been clearly, humbly stated.

 

Marcus: I really like that, and now I’m curious about something. I noticed that when I was a junior person in an organization, even if no one said to me, “We want you to ask these questions,” that having the novice mind and recognizing that I was new, somehow made it easier to ask questions. Sort of, I could scratch my head and say, “Maybe I don’t understand, in parentheses, because I just got here, but what does this mean or why are we doing this?” Do you find that it can be harder the longer people are with an organization or the higher you go in title and responsibility to ask the dumb questions?

 

Katie: You know, I really do think so. I think there’s two things going on there. There’s a sense that the higher you go in an organization, the more you should know, so people become embarrassed about asking questions because they start to think, “Everyone else is looking at me for answers. At this point, I should be the expert.” There’s almost the fear then comes of thinking, “Everyone’s going to look at me, and maybe I shouldn’t be a senior engineer if I need to ask such an obvious question.”

 

The second thing is just tenure, not necessarily seniority, but if you’ve been in an organization longer, you’re more likely to have had a hand in creating whatever it is, the thing that doesn’t make sense. As humans, we get defensive about our mistakes and we want to maintain consistency with our past selves. That’s not effective, but it’s very natural, it’s very human. As we’ve been with a place for longer and longer, we start to see the messes, our personal mess, and can almost be a little bit defensive about how things are because we’ve been trying really hard, and we’ve been here really long. There’s almost that kind of very human tendency to double down on things that we know really don’t make sense because we did them.

 

Marcus: Yeah, now as the VP of Engineering, that’s the top of the engineering organization, is what I’m guessing, and do you ever struggle with wondering if you should know things and if it’s okay to admit that you don’t?

 

Katie: Well, yes, I do. In my private moments, and I not to let that get the better of me, to be honest. That’s usually a sign, in myself, when I notice, “Oh, I feel like I should know this,” or “This feels like a question I’m a bit embarrassed about.” I take that as a sign of, “Interesting, there’s a slight status threat I’m perceiving here. I am, at some level, worried about a challenge to my authority.” That’s the point when I know what I need to do is double down on the actual kind of leadership I want to role model in my organization and really go in and ask those questions and say “I don’t know,” and work through what it is that I’m worried about. Why is it that I’m suddenly worried about status or authority? Those are things that I think leaders don’t usually like to admit they think about.

 

I think we all us humans think about that, from time to time. I think it’s just really important to admit that to yourself and be very honest. Yeah, it’s scary to not have the answers, and then just go for it. Be like, “Okay, I don’t know what we should do about this,” or “This code review process isn’t making a lot of sense to me right now. Is this the best to do things? Maybe it is, I just feel unsure,” and admit that.

 

Katie: In doing that, you role model to other leaders in the organization and people that have the sort of manager job description, that’s the behavior you want to see. When it gets hard personally, I like to think about “Well, what would I want to see in an engineering manager?” And then go, “Okay, think about it as role modeling vulnerability.” Then that makes it a little easier because then I can think of myself as teaching, even if what I actually right then is know the answers and be the best. We all know that’s not true. We all know that voice needs to shut up and go home.

 

Marcus: I think that there… boy, there’s a lot… thank you so much, first of all for letting me spring that question on you. It wasn’t planned-

 

Katie: Spring away.

 

Marcus: I recognize that it might be a bit difficult. I think that that’s where so often there’s this tendency for me to engage in perception management and really being concerned with how other people perceive me. I’ve seen leaders change the subject, begin yelling, walk out of a room, get really busy, quote, unquote. Often times, they will not those things that you just said. They will not simply say, “I don’t know what the right answer is. I don’t know why this isn’t working.” Because when you admit you don’t know, I feel like you open up new possibilities that everybody could start contributing. Maybe together we can know versus having to be, and especially as engineers, I think we have a tendency to love the facts and to love to know things and to feel like we’re in command and control.

 

Brilliant, brilliant. Well, let’s move back to your career framework because I’d love, if you wouldn’t mind, one of the questions I get a lot of is “How many levels do most of these career frameworks have?” I’ve talked to people who say three, and I’ve talked to other people who say 57, so I bet the sweet spot might be between three and 57 or maybe I’m completely wrong. Can you give us a sense of how many steps you use in your career framework?

 

Katie: Right now, for makers, individual contributors that aren’t managing people, we have six steps that are in active use. We have Engineers 1, 2, 3. That’s junior engineer to our normal, professional level, like you’re a great engineer. Then we have, you’re actually taking on technical leadership responsibilities. Again, leadership is something everyone does, but there’s a specific set of accountabilities that you have for the outcomes of your whole team. That it was makes a senior engineer role, and for those folks we have two levels. We have Senior Engineer 1 and Senior Engineer 2.

 

Then we have a further step in responsibility and accountability. At this point, you’re taking on technical leadership accountability for decisions that’ll impact groups of teams, perhaps all of product engineering, all of engineering overall. This level we call Staff Engineer. We do have a concept of Principal Engineer in our organization as well, but that’s not one that currently have anyone at that level.

 

If it helps to think about it in terms of manager parity, which can clarify how advanced are these levels, engineering managers map to Senior Engineer 2s. Staff Engineer is equivalent to a manager who is a director. A Principal Engineer would be equivalent to a senior director level. Then we have a CTO and a VP role, where I’m a people-management track person and then we have a CTO who is an architecture-code, technical-decisions leader.

 

Marcus: Thank you so much. It sounds like, if I were to go back to being a Junior Engineer, and I worked at Buffer, at some point, I might be given an opportunity to go left or right. There’d be a fork in the road?

 

Katie: Yes.

 

Marcus: Where we say, “Do you want to join the managerial track or do you want to stay on the technical track?” Am I getting that correctly?

 

Katie: That’s absolutely correct. Yeah, so you would go through Engineer 1, 2, 3. Senior Engineer 1. After you’re a decent Senior Engineer, it would be a case of, “Do you want to become an engineering manager if there’s an organizational need?” Of course, we need people that need a manager. Or do you want to become a Senior Engineer 2, a Staff Engineer, a Principal Engineer, and carry on with that track.

 

Marcus: Do you have folks who move back and forth between the tracks?

 

Katie: We have had that. We have had somebody go from Staff Engineer to an engineering manager, so actually proceed on the technical track and then change to the management track later on in his career. Having been an engineer for 30 years and, having seen everything under the sun, wanted a different challenge, and is an absolutely amazing engineering manager. We’ve also seen folks go back and forth. I’ve seen a Senior Engineer go to engineering management, go back to the engineering track, and is now a Staff Engineer. You know, realized, “This just isn’t for me,” and that’s fine.

 

We emphasize that, at Buffer, people management is a different role. It’s not a promotion over and above engineering or out of individual contributed work. It’s a different type of job. If you realize this job isn’t for you, that is completely fine. You can switch back, and a lot of our most successful managers are people that do switch back between the tracks. A lot of really successful engineers have had a brief stint as an engineering manager, which maybe they hated, but it gave them an appreciation for the needs of product, the needs of the business, how to coach others in their career. That made them better Senior Engineers. We encourage that kind of switching back and forth.

 

The last thing we want to do is trap people in people management when they really don’t like it and they’re going to end up bad managers because if your person manager actually hates their job, they’re not going to show up really engaged for their one-to-ones and their team planning meetings and the rest.

 

Marcus: Absolutely, and I’ve worked at those companies that said, “Well, if we move you into management and we have to move you back out, you’ll never…” You get this sort of branded, like the Scarlet Letter, “You’ll never get another chance.” It’s a career limiting move. It’s very frustrating. I would love to hear, maybe I can ask you about your own journey into management. Where did you start and how did you end up as VP of Engineering at Buffer? Maybe just a quick overview.

 

Katie: Well, the very quick soundbite would be hard work and well-placed organizational chaos at the time. To be entirely honest, I think that’s the case for many of us that end up in leadership roles. I joined Buffer as an engineer at a time when we were just coming out of self-management. We had no managers at all. We had tried out something that sounds a little like holacracy. It was a bit different. I had joined this company that didn’t believe in managers at all, and I joined as an engineer.

 

In my first six months at Buffer, I worked on every single team the company has. I changed teams about every five to six weeks. I started off writing a ton of code, trying to fix all the bugs. We had a bunch of quality problems. Writing lots and lots of features, working tremendously hard and realizing that, on these times I was joining, there were really fantastic engineers and the problem wasn’t that we had engineers that couldn’t solve their problems and needed more and more coders. We had problems like people feeling frustrated because their feedback wasn’t being heard or an unstable product road map that kept changing. Lots of half-boiled features that would get abandoned and something else would get done. We would have a lack of clarity on how people can get promoted, so they weren’t sure which efforts were going to be rewarded, and I found myself working with the engineers on my team and working with the product managers and trying to align these basic things into teams that made a little more sense.

 

I eventually went the then-CTO and said, “I just want you to know, you hired me as a developer to write a bunch of code. I’m not really doing that terribly much, so I just want to tell you this because I know it’s my job. I’m technically not doing my job, but what I am doing is this other thing, and it’s really working. The different teams I’m going around to, they’re a lot more successful after we sort out these kind of basic organizational issues.” And the CTO was like, “Interesting,” I couldn’t quite tell what he thought, and then we chatted again. He said, “You know, this is something called Engineering Management.” A lot of companies, they have this as an actual role. We then decided that I would become Buffer’s first Engineering Manager, and I was the first person to then be an Engineering Manager. Then I took on that role, and we weren’t quite sure what it was. I was then in a position of, you know, Googling a bunch, reading books, and reaching out to other people: “Do you have these things called Engineering Managers and what exactly do they do?” My first task as an Engineering Manager was to create the first career framework that we have. I did that. I put that in place. I created that. I did a lot of one-to-ones with engineers.

 

I kind of did that job, and then after doing that for about a year, our CTO moved on from the company, and there weren’t immediate to kind of replace that leadership vacuum, so myself, another person that was then an Engineering Manager, and a couple Staff Engineers, we all got together in a sort of coalition, and we led engineering somewhat by committee just trying to figure out: “How do we do things that make sense in this transition until such time as we get some kind of leader from the outside world.” We sort of expected that someone would come in and, sort of, save the day. We were just going to do stuff that made sense up until that point and then just make sure that the future VP doesn’t think, “Geez, that’s a terrible decision.” You just, sort of, do reasonable things, get some advice.

 

We did this for about six months, and then the CEO, our founder, Joel, had said to myself and one of the Staff Engineers at the time, “I think this has gone really well. You two have showed a lot of leadership. I’m going to make you both directors with different kind of focuses, and we’re just going to keep doing this because this is actually working quite well, but there is no leader coming. This person you think might come fix it, that’s not going to happen. We’re not going to do that,” which I found very alarming. I was excited to get the title, and I thought that was great, but I was very fearful inside because I kind of banked on I just sort of needed to keep things together for a little bit and then someone else that knew what they were doing. You know, the grownups would arrive.

 

Marcus: Right.

 

Katie: I mean that still hasn’t happened. We kind of did that. I think Dan and I just sort of stepped up. We’re like, “Okay, directors.” Did that role for, sort of, another year, and towards the end of last year, realized we actually have sort of a well-organized engineering team right now. We’ve managed to grow. We’ve managed to hire. We’re at 35 people engineering. A bunch of other Engineering Managers that are all working well. Product is good, growing. Retention is good. It’s like we think we’ve done a good job, and we sat down with the CEO and sort of officially moved to VP Engineering, CTO titles, and it was just based on, well, when you have a team and it is succeeding and these are all the things that have happening, we think we’ve done the job. Our CEO agreed.

 

It was a case at every point there of just doing what I thought the company needed done, not really trying to carve out for myself a path. I think if I had sat down and thought, “I’m going to join this company, and in three and a half years, I want to be their VP Engineering. What am I going to do? How am I going to get rid of the current CTO?” I don’t think that would have worked at all. It was just a case of “What’s happening with this team right now? What does this team need?” And at each point just providing that. It was like what the team needed was initially an Engineering Manager. Then they needed some kind of director-level. The team grew, and needed another Engineering Manager. Eventually, we needed a VP.

 

At each point just working really hard, staying humble, asking my teammates, “What should we do? What are the problems?” Trying to listen a lot, and just trying to the work to solve those problems. When I got stuck, asking for advice. I’d say the most useful thing I’ve done is just going outside of my company, getting coaches, looking to other leaders and saying, “Hey, I have this problem. How do you solve it?” Sometimes I’d hear, “No, everyone has that problem. That is a normal problem to have.” Sometimes I would hear how to solve it. Either way, it was useful.

 

Marcus: That is a wonderful story. I’m curious, as you went through the process, and maybe even as you reflect back on having now brought lots of other Engineering Managers into their new position at Buffer, do you see some pretty common bumps along that path that are difficult for engineers who step into that management role?

 

Katie: The biggest bump is: Should I still keep coding and, if I don’t, how am I going to still relate to engineers? What is my value if I’m no longer producing work, and how do I know that I’m productive? A lot of people that are driven to grow and progress along the path and then want to become managers to make the team more effective, they value productivity in a very fundamental way, and it’s very difficult to let go of your own output as a person and rely on the output of others. That’s a big bump I initially see.

 

Another big bump is not wanting to be authoritarian and then finding it very, very difficult to be clear. It’s that kind of wanting people to read your mind, very indirect communication, trying to get your direct reports to guess where you’re trying to go with something, and they’re just getting really confused because you don’t want to be that manager who says, “This is a terrible job. You should have done it this way. Bad job.” You sort of ask them, “Do you think this code is good?” And then it’s like, “I guess,” and you’re like, “Okay, well, do you think…” and it’s just sort of like Socratic methoding in this very awkward way. That’s another big bump I see where it takes a while to build up that radical candor skill where you sit down to be like, “Hey, this code is not your best code. Here’s what I see happening. What do you think?” It’s not a big deal. It’s not a whole emotional showdown. It’s just candid exchange.

 

Marcus: I love that. I’ve heard that many times. “Do you think this is good?” And-

 

Katie: “Well.”

 

Marcus: “I don’t know. Should I?”

 

Katie: Yeah, it’s like, “Are you going to praise me? Are you going to fire me?”

 

Marcus: Right, exactly. I know that when I became a manager, and I talk to lots of other folks who go through this transition, and they say the transition is like an identity crisis because they’ve been coding since they were in high school, or many years or something, and they’ve identified as this maker. I think the other thing that I heard from some people, and I’m curious if you’ve seen this as well, is if you’ve never had a good manager, someone who you really connected with, you might have the impression that no one does and that becoming a manager is fundamentally becoming like going to the Dark Side almost.

 

Katie: Yeah, it’s like people are very worried about that. I do see that. Also, so overwhelmed with all the negative patterns that they’ve seen that their mind is just so taken up with everything not to do, everything they don’t want to be, that they’re very paralyzed with, “Well, what can I do?” Because they’ve just never seen a manager that they thought was a good person and did a good job. They can almost be kind of paralyzed by it.

 

Marcus: Yeah, a few years back I realized that, I think there’s a lot of bad manager prototypes in the media. You have Dilbert’s pointy-hair boss, and you have the Office Space… I mean, we laugh at them, but I was trying to think, are there any great manager prototypes that we see? I just don’t see very many, so that’s one of the reasons I appreciate you coming on the show as someone who’s a great manager and leader. Even though-

 

Katie: Thank you.

 

Marcus: I think that it’s important to not only help people understand that the growing pains are real, and that they’re common, and they’re not alone. I just love the way you began our episode that it is a skill, it can be learned, and I’d even like to go a little farther and just applaud you because I think organizations should be, and I think in particular engineering groups, should be teaching these things, rather than trying to hire from organizations that do teach them well. I think we need to be producing leaders and managers in our own organizations.

 

Katie: I completely agree with that, Marcus. I think for the ecosystem it’s important that we educate leaders and managers within our organizations, but purely from a self-interested perspective. If you’re listening to this and you’re thinking, “No, no. That’s too risky. I’m just going to hire somebody who’s a great leader,” and you don’t have the ability as an organization to grow them, you’re always capping out at the level you’re hiring into. You’re always limiting yourself. You always need to over-hire for what you need because there’s just no room for you to go with this person if you’re not developing the skill set. And you’ll get lucky. Some people will just develop themselves. That will happen, but you’re going really miss out because most won’t. Most people will do the job you hired them for, and then when you need the next level job done, you’ll have to hire for that. It’s very difficult if you’re constantly hiring people over your existing team. You start getting morale challenges and retention challenges, and those are expensive problems.

 

Marcus: I was actually just going to bring up that I think a lot of engineers leave when their boss swaps out because they had this relationship, they trusted them, and now there’s a new boss. They also take that as an opportunity to say, “Is this the right place, or is this the time for me to go find someone else to work for at a new place?” I think that every time you swap out a manager, you do run that risk that the people that work for them… we’re not just cogs, right? We build real, strong, trust relationships with the people we work for, and I think those are probably the most important relationships we have at work in a lot of ways.

 

Katie: Right, I agree.

 

Marcus: Well, thank you so much for being on the show. Let’s end with this. Do you have some favorite books or resources, things that are your go-to about leadership and management that maybe we could include in the show notes?

 

Katie: Absolutely. Right now, a really great place to start is Camille Fournier’s The Manager’s Path. I’m sure you recommend that in many of your shows. It’s very actionable, and it’s got it broken down in each level, and it’s specific to engineering organizations, which I really like. Going back to the old classic High Output Management. That’s a great place to start. Andy Grove does, indeed, know what he’s talking about. A book I really think everybody should read is Radical Candor by Kim Scott or just watching the TED Talk. I think if you’re going to do one thing for your management style and for growing managers, find a way to put into words the things you know are holding your teammates back, and then help others to do the same. Create an environment of candor on your teams.

 

Then, Marcus, there’s another book coming out that I’m very excited about. Laura Hogan, who I believe you’ve had on the show quite a few times, she has a new book Resilient Management. I’ve read an advance copy of that, and it’s really fantastic, so quick one for that. I’ve pre-ordered that for all my managers. Having seen a PDF, it’s going to be a great resource.

 

Marcus: Wonderful. Katie, thank you so much for being on the show with us today.

 

Katie: Thank you so much for having me, Marcus. This was an absolute pleasure.

Announcer: Thank you for listening to Programming Leadership. You can keep up with the latest on the podcast at www.programmingleadership.com and on iTunes, Spotify, Google Play, or wherever fine podcasts are distributed. Thanks again for listening, and we’ll see you next time.