Chris Evans, Co-founder and Chief Product Officer of Incident.io joins us to talk about all things incident-related. Chris, previously the Director for Platform and Reliability at Monzo is a regular conference speaker and author of a number of articles about incident management and observability.

In this episode, we cover the origins of Incident.io, discuss healthy incident management and Chris advises us on the right metrics to be tracking.

Listen to the Humans+Tech podcast on your favourite podcast provider.

Scroll down to read the full transcript of our chat with Chris

Chris' quick fire answers

Chris recommends The Field Guide to Understanding Human Error by Sidney Dekker.

His top tip for keeping up with the industry is to listen to Kelsey Hightower. You can listen to our episode with Kelsey, here.

Chris is inspired by Frank Slootman, of Snowflake computing, formerly CEO of ServiceNow.

We asked Chris to share a nightmare incident story with us. He responded with this one!

In this episode we cover

1. The origins of Incident.io, including Monzo's open source tool, Response [00:01:50]
2. Building incident management tools as a way of expanding an incident management rota [00:02:38]
3. Why existing incident management tools haven't managed to solve the problem of painless incident management [00:08:07]
4. Chris' dream of building a tech company from the ground up [00:09:56]
5. What it was like to move from Monzo to Incident.io [00:12:47]
6. What does good incident management look like? [00:18:20]
7. At what point should a company be setting up on call rotas? [00:20:52]
8. Metrics and incidents - how to do it well [00:24:06]
9. How to make incident management a better dev experience [00:27:20]
10. On why we should all be speaking at conferences [00:39:48]

Find out more, and follow Chris

You can follow Chris on Twitter @evnsio and at https://incident.io/

Full transcript

Amy Phillips:0:01

Welcome to the Humans+Tech podcast. I'm Amy Phillips, and this is Aaron Randall.

Aaron Randall:0:06

Hi.

Amy Phillips:0:07

Today, we're very excited to be talking to the one and only Chris Evans. So I first met Chris when he was working as a Technical Product Manager, and leading the Platform team at MOO. He then went on to be the Director for Platform Reliability at Monzo, before becoming co-founder and Chief Product Officer at Incident.io. Chris is also a regular conference speaker, and author of a number of articles about Incident Management and observability. So Chris, welcome to the show.

Chris Evans:0:33

Thank you for having me, I need to pick you up on one thing straight away, which is you said the one and only Chris Evans, and there are literally two very famous Chris Evans's in the world. So you failed straightaway, Amy.

Amy Phillips:0:46

Clearly you are the more better known

Chris Evans:0:49

Of course, of course.

Amy Phillips:0:52

So great to have you here. Now, one of the things that as you know, we like to do with all of our Humans+Tech guests is draw a doodle of them. So we're going to show you yours, and we'd love to get your thoughts on on your doodle.

Chris Evans:1:05

I'm actually really nervous. I'll take it. I like it.

Amy Phillips:1:13

You sound surprised?

Chris Evans:1:14

Well, can I can I be honest about the thing that I think is like was stressing me out, which is that I sort of don't think I have any particularly distinguishing features. Like, you know, if you wear like certain shape glasses, or you've got something that sort of like, yeah, that's the person I think I'm actually quite bland looking. So I'll take it and I like I really appreciate the little flame. Thank you very much.

Aaron Randall:1:38

Yeah, we do struggle with this. Everyone looks like a sausage. So we've struggled to make it's not you it's everyone. My drawings are very bad.

Chris Evans:1:49

Thank you very much.

Aaron Randall:1:50

Hey, you're welcome. So I want to dive straight in and talk a bit more about the idea for Incident.io. So I know this idea came from an internal project you built whilst working at Monzo. And that the project was called Response, an open source tool you built, how did Incident.io come about? And for those who haven't heard about it, what does Incident.io do?

Chris Evans:2:09

Yeah, good question, I guess, I guess, actually, I think I should probably like be very honest and credit, the very, very early inception of like, this kind of tooling to when Amy and I were at MOO, I think it was Ron, who built the very, very first version here, which was like, this super simple tool that used to create a channel for us when we had an incident. And it was like, suddenly, like we had a space to collaborate in and it was like a slash command and was this magical thing. But yes, I guess like fast forwarding to a little bit to Monzo. I, I picked up along with like running platform, the responsibility over the on call team. And as part of that I was sort of trying to trying to make on call an appealing thing for people to join. And part of the reason they weren't joining was because incidents were like quite painful, or quite chaotic, it was a bank, it was very stressful, you know, you could have like MasterCard, not working and people couldn't make card payments. So I wrote the very first version of the tooling there, to basically just try and try and get some folks to join the on call rotation and help out a little bit. And it went sort of from strength to strength within Monzo. So what started as something that sort of created a channel and then pinged out a notification to say, hey, an incident's happening, then sort of got more complex, and it started doing some more interesting things for us, like, you know, pinging data privacy folks when we were mentioning the word 'data breach', and sort of slowly sort of adding these various different like, automations on top of, on top of the incident response. So, you know, nothing like crazy, like go and turn the server off or turn it on again, but just like processey type things. And that was sort of then adopted across the whole of Monzo. And so Monzo went from a place where incidents sort of were things that happened in technology, and they happened, you know, once a once a month, maybe or once a week, you know, at worst. By the time I left Monzo, we were having something in the region of like 10 to 20 incidents a day. And that sounds incredibly scary. And I should sort of like point out that Monzo is not an unsafe place to put your money or doing anything wrong. What they've done is like lowered the bar for incidents. So they've made it that incidents were basically anything that was sort of, you know, not in the normal course of business. So, you know, it could be like a customer operations person posted something in a channel that they shouldn't have done that sort of way to delete a message and clean it up or, you know, we rolled out a thing and had to roll it back. It was basically anything that needed to be like picked up that was reactive with some degree of urgency. And so this was sort of like the aha moment for us. And so Pete, Stephen and myself as the founding team of Incident.io, started working on like an evenings and weekends project to turn what I'd written internally at Monzo into a product that we thought could be, you know, saleable elsewhere and, you know, it was like the pandemic was going on and it will was like, cool, this is something fun to do. And then it sort of snowballed from there. And you know, what was then an evenings and weekends project sort of became more and more, more and more of a sort of time consuming thing. We started selling to customers. And so there was sort of like regular late night or early morning calls to sort of sell this product, start making some traction. And then, yeah, the rest is sort of history we've been growing ever since. And yeah, product's been getting better and better. It's really exciting.

Aaron Randall:5:26

Amazing. And what was that? what point did it dawn on you that this project was actually a company building opportunity? And also a follow up question, I'd love to hear more about how that snowball sort of began to grow. I guess, from the evening and weekend project, to something customers are paying for.

Chris Evans:5:40

Yeah, maybe it's a bit of an unfair reflection to say that it was an aha moment, because I don't think I don't think it wasn't, it wasn't sort of like, you know, we were in the lift one day, and suddenly, it was like, you know what, this is a thing. But I think it was more like, I think the three of us have all kind of, you know, we've all worked in technology, our whole careers. And for me, certainly I know, it's very similar for Pete and Stephen, like I have dreamt of running a technology company, or, you know, building something from the ground up. Like, it's sort of like the dream situation for me to be able to, not just not just about like working for myself, but to sort of just take something from, from nothing to something, you know, we had pretty mild aspirations. In those early days, we were sort of thinking of bootstrapping a thing. And like just being like, well, this could be a good lifestyle business never have to work again. But yeah, so it was more of a sort of a slow, like, hey, this is actually a thing. And it's sort of, you know, came to that. And then I think when it came to like, the snowballing thing, it was basically, we launched the website, when the product was in like, you know, incredible infancy. So it did sort of basic things that Response did, that was Monzo's open source tool. It was a complete rewrite different languages, but sort of did a similar thing of creating some channels, letting some folks know, and a very, very basic web interface. But yeah, we put the website up, and then had like, immediately a bunch of sort of, like, posted on social media, and, like, immediately had a bunch of inbound. And it was like that, that was kind of an aha moment, which is like, okay, cool, we've put a thing out, sort of, like focused on the branding side of things, we bought a domain that was kind of cool. And there was just a lot of like traction from from our network. Basically, if people were like, cool, we have a thing similar our company that does this, or, you know, we have a manual process written down on paper, and this looks great. Like it would help solve that. And so then it became a case of like, starting to figure out how to sell, you know, SaaS software, you know, B2B and like, figure all that side of things out, and it kind of just picked up from there. And yeah, got first customers sort of paying, you know, a few 100 pounds here and there. And it was like, yeah, this is great. This is sort of something's gonna work.

Amy Phillips:7:42

Amazing. What were the sort of things that people, I suppose, like, what what were the problems that you were talking about on social media that people were jumping in and sort of saying, oh, we need that like, because I'm always surprised, like, you know, incident management has been around for a long time. But it's a long way away from being a solved problem. So what were the sort of things you saw that people were saying, like, these are the problems we're having? Come help us.

Chris Evans:8:07

Yeah, that's, I think that's really interesting area, because Incident Management has been around for a long time, most like my whole career, things like systems like PagerDuty have existed, Opsgenie, you know, various different software has existed to sort of help respond to things going wrong. But I think what, what our customers were seeing that was very different. And where we were sort of going was that these software platforms were places you had to go to do things with incident response. So you know, I got paged at 2am, for example, and I wanted to go get someone else I'd have to go and jump back into PagerDuty to go and like, make someone else's phone make a noise. But where I was coordinating, my response was not on PagerDuty, I was in Slack, like most, you know, technology companies. And so you'd be sort of like, the hub of everything going on incident is all founded on good communication and the communications happening in Slack. And you then have to go to PagerDuty to do a thing or Jira to log that, you know, an incident was happening, and then you'd have a doc somewhere else off to the side, which was, you know, where you were tracking action items, or who was doing what. And so that was the thing that really, really resonated and sort of like, I think the message that we sort of landed on was that, you know, we'll meet you where you are. And we, you know, incidents are already really, really stressful. You don't want to be having like more cognitive load on you, you want to be basically doing as effortless, you know, effortless experience doing as little as possible. And so, yeah, it was sort of like, hey, you're already on Slack, we will come in, we will augment that process for you, take a bunch of things off of your plate. If you need to use PagerDuty, you can do that through Slack as well. And you can get hold of the right people and you know, keep context on what's going on. And the only time you should leave that channel is if you're actually going to wherever it is that something's going wrong. So to fix a system or you know, jumping to a terminal sort of thing.

Aaron Randall:9:56

I want to ask you a bit about that point you made about you've always dreamt about building a tech company from the ground up, tell us a bit more about where the kind of the motivation for that came from and how long that has been an aspiration of yours.

Chris Evans:10:09

Yeah, I think in like it probably like university was where I first started thinking about it. And that was mainly motivated by a desire not to have to go and interview places. If I'm very honest, it was just like, hey, I started thing, and no one can interview me. It's my my sort of show.

Amy Phillips:10:27

And here you are now, it's not worked out at all.

Chris Evans:10:29

No. Dammit. So yeah, I think, like, fast forward a little bit like, for me, it was, it was, I think I'm just like, very interested. I mean, I love building clearly. Right. So that's like the first thing. And so that has sort of been something I've been able to do most of my career one way or another with like technology. And I think doing that at a company is like the ultimate form of that. And I think like when I look at my career, when I sort of moved from place to place, it has always been, because I felt like I wasn't, I'd sort of like plateaued on like a learning sort of scale, if you like so had an incredible time at MOO working with Amy, I'd say it's like one of my career highlights, you know, and what I did, there was what we did, there was like, do a massive, massive move of all of MOO's infrastructure from an on premise data center into AWS. And then at the end of that journey, I sort of felt like it plateaued a little bit. And we were back into sort of steady state as a company of like, well, now we're here, how do we optimize and make things better, and, you know, interesting challenges, but I just wanted wanted to be pushed a bit harder. And so for me, the next step was Monzo, which was then the, you know, do do a similar thing to MOO, but on a bigger scale, and in a company that's growing at some astronomical rate. And then I think if you sort of extrapolate all of these kind of, sort of situation, you then get to like building a company where it is just so hard. And the challenge, like I didn't go into it sort of thinking it would be easy. But I knew going into it that I would learn a lot about everything. And so it's really interesting now, like when, when we interview candidates, and we do introductions, and it's like, you know, I'll be like, I'm Chris, I'm working at Incident.io, like, CPO is my title here. But like, really what I do is, and then I just list basically every function of the company. Yes, I'm like doing GTM. I'm doing sales, I'm doing marketing, I'm doing like, all of these things. And it's both like, equal parts terrifying. But also, like, just incredible as is as a learning experience. Like I genuinely, genuinely don't think that there is a sort of more exciting and more sort of fully, like multidisciplinary kind of challenge you can pick up and try to build a company.

Aaron Randall:12:47

I want to ask a lot of questions about that. And we've actually got some a theme on that a little bit later. But before we move on to that, you know, this, this journey has transitioned from Monzo to starting Incident.io and doing your own thing. And obviously, with Incident.io, you went down a VC route, making that transition out of Monzo. What did it mean to you to have the Monzo founders, you know, Tom and Jonas, invest in your new business?

Chris Evans:13:10

Oh, a huge amount, absolutely huge amount. Like I think I think those folks supporting us was just was just massive, and they were so good through the whole process. So like, we started, as I said, we started building this company while we were at Monzo. And that was not something we did behind closed, closed doors, like Monzo has this, you know, very much lived value of like, defaulting to transparency. And so like, early days, we'd spoken to Jonas and been like, Hey, I think by letter of like, our contracts, we're not supposed to, you know, if we start doing work on something during like, Monzo while we're working at Monzo, there's like a risk that you can, you can take that off us kind of thing or prevent us from from doing that. And Jonas was like, Absolutely not like it might be in there. But like, practically speaking, you have my word this is this is fine for you to do was really encouraging. And so, yeah, they were just great through that whole process. They were great when it came to like raising our round when we had to sort of get things from Monzo, you know, to say that this is definitely our IP and stuff like that. And then to have the Tom and Jonas basically backing you to like heavy hitters, when it comes to, you know, this kind of thing. They've they've built an incredible business out of Monzo. And it's just sort of yeah, very buoying to sort of be have those folks sort of feeling like they're willing to put their money where their mouth is, and sort of actually, you know, give you give you that confidence.

Amy Phillips:14:36

It's awesome. It's amazing. So I know it's still you're still very early days, so it feels a little unfair to ask you this but still, we can ask you again in a few years but like what have been your challenges so far? Like what are the highs and lows in Incident.io's history so far?

Chris Evans:14:54

Oh, wow. That's I mean, that's that's like it's like every day there are highs and lows and trying to pick which of these sort of things are

Amy Phillips:15:05

Limit to a week if you want.

Chris Evans:15:07

I mean, like the highs, I would say, I think something that's like really, really been great for me is like selling the product now. And this is sort of like, I guess the context of where this comes from is. So back in the back in the early days, when we used to jump on sales calls and to jump on and like, someone would be like, I want to, I want to see your product. And you'd be like, cool, well, let's do, let's do a demo. And we'll do this, I remember being literally terrified of these like, to the point where like, for like 15 minutes before jumping on the call with them, I'd be like pacing up and down outside my office and sort of like cold sweats and that kind of thing. And then you jump on to the demo. And I'd be like stressing, because I'm trying to like drive, like showing them the product was talking but also listening to them. And then they'd have objections. And I'd be like, I don't know what I'm gonna say here or what to do. And so that that was like, genuinely a massive, massive struggle. And I think where it's now turned around, it's like, literally one of my favorite things to do is to jump on a call with a customer. And I can, you know, give the product pitch basically, in my sleep, I can drive the product and like I'm so in like, basically, at the core of it all, I love the domain, I'm passionate about the domain, I've felt the problems. And so I sort of feel like I got the cheat codes to selling to folks. In so much as like, I just sort of, you know, I can authentically speak about it, basically. And so that's been, I would say, like a personal high of the company, like more general highs for the company, some of the folks that we've managed to get as customers. So we have like some incredible customers and some, you know, well recognized brands and things like that, and increasingly getting bigger companies coming to us who, you know, it sort of astonishes me that they are interested. And then it sort of doubly astonishes me that they see the product, they use it and then we get incredibly, incredibly good feedback from them, and they are buying it. So that's been amazing. Lows, what's what's a good low? I think I think lows for us are maybe some of the people that didn't work out. And I think this is like part of the harsh reality of startups is that they are, they are very different to normal companies. And so and you know, you hire someone, and you're, you know, at the time, you're like, well, our growth trajectory is like, you know, sort of this sort of, not too steep, steeper line, I realize I'm doing this on video, and people can't see this. And then and then you know, things change in your traction picks up more, which is a great problem to have. And then you realize that suddenly you're on a much, much steeper slope. And so some people who you hire, maybe don't, don't end up working out. And that's, that's really hard, because these are people you're in such a small team, and it feels, you know, very close, and you go for dinner together, and you're hustling on deals together. And yeah, so some people have not have not made it. And I think that's that's a really tough thing for us, but a sort of necessary part of keeping a high performance culture. And the great news is that folks who haven't haven't haven't sort of made it all the way through, they have left really amicably and it's sort of, you know, a mutual thing, which is, which is really, sort of, you know, the sort of small silver lining, I guess on a bad situation.

Amy Phillips:18:20

Yeah, for sure. So you mentioned about being passionate about the domain. And I, I've got so many questions for you. Chris and I have spent quite a lot of time, a lot of nights I'd say we've spent on incident calls. But tell us a bit about Incident Management, like what what does good Incident Management actually look like?

Chris Evans:18:46

I think is highly context dependent, which is like the ultimate like way to cop out and hedge before you answer a question I appreciate. But I think it's, it's dependent on like, so many different factors. But I think at the core of it, like, if you look at what an incident is an incident is something bad has gone wrong, and there is some degree of urgency to get something fixed. And I think what makes incidents different to normal work is that urgency puts pressure on people. And I think that, you know, when incidents are certainly treated as the more severe things, what also happens is, you end up sort of bringing together a bunch of people who don't normally work together. So you know, in its simplest form, if you're a customer, if you're a company that does anything with customers, then you're almost certainly going to be putting together customer support folks and people who are dealing with whatever it is that's, you know, that's broken, and those two teams don't normally meet under normal circumstances. And so you've got like, this is the sort of like the core of it, which is, you know, something's gone wrong. Lots of problems. People trying to form a team very, very quickly. And so I think that's quite a unique sort of space to be in essentially. And so I think good Incident Management looks like having like systems in place that allow you to form that team really quickly to, you know, set up some sort of like default rules of engagement and rails for how you'll coordinate that incident. And then essentially taking, you know, a bunch of things off your plate that you know, that have to get done every time and sort of trying to focus on like reducing cognitive burden, so that you can focus on whatever it is that's going wrong at the time, basically, but like, I think at the core of all of this is just like, very, very streamlined communication. That's really what what these things come down to, because it's so hard to prepare anything for an incident, like you have people who have like playbooks for this and that, but they, they sort of, are never going to survive contact with reality fully. And so it's all about, you know, you know, being prepared to be unprepared. Basically.

Aaron Randall:20:52

You run an early earlier stage business, you know, a growing startup but early stage, and there are lots of those around as well. when's the right time for a business, like a tech company or a tech team to think about creating kind of this official on call response policy and the firefighter rota, and all these kind of things that go around incidents?

Chris Evans:21:15

Yeah, I think on call is an interesting one as a sort of like side part of incident management. So I think on call, it's, it's one of those things, I think, when your business is dependent on you being available, that is, you know, and dependent, meaning you cannot tolerate it being offline, that is your trigger for putting in an on call practice. So, you know, if you're doing a social media like site for cats, for example, probably in the early days, when you've got 10 users, it doesn't matter if it breaks at 2am, and you wake up at 8am and then and then fix it. I think as soon as customers are reliant upon something being sort of working, that's your trigger for having on call, that's your, you know, someone will always be available to support this thing. Sort of incident management, I said, I said, I'd sort of put it off slightly to the side. And so much as there's a lot you can do in the early days without overcomplicating things. And so, for example, I would not say that our software is a great fit if you are one team, and you are under 10 people like there is very little that can't be achieved with a bit of string and sellotape and, you know, a Slack channel where you communicate, I think as soon as you get to the point where, you know, either incidents are happening frequently, you've got multiple different teams, you don't spend much time together. That's the sort of trigger for like, cool, well, that it's helpful to have a process there and there's, there's obviously like a huge number of benefits off to the side, we have of starting to have a more official incident management sort of procedure or way of dealing with things. In so much as once you, you know, if you're having things going wrong, or you're being distracted by reactive work often enough, that is, you know, it's good to be able to track that work and incidents or if you know, if your policy is that we will declare incidents for every sort of time that that happens, suddenly you get this visibility into your organization. And so this is something like actually, we live and breathe Incident.io. So we touch wood do not have incidents of like high severity, we have, like I could probably count on, you know, a few fingers, how many times we've actually been offline or unavailable as an application. And when that's happened, we've been fortunate enough that we can sort of rollback or restart something and everything comes back. But what we do have is many, many times when little things go wrong, or we have like little errors in the app, and we treat every single one of those as incidents. So if a customer is like, hey, I tried to do this thing, and it didn't work, they we will treat that as a as an incident. We now have incredible insight as to like how much time are we spending, not doing proactive kind of strategic work? And who's who's the person jumping into all of those incidents? And, you know, what's the impact like on those incidents, are they bad things? Are they small things? And suddenly you get this sort of like insight that you didn't previously have into your organization.

Amy Phillips:24:06

What's the like for companies that aren't currently doing that, like, what's the correct way to start looking for those patterns? So that, you know, it doesn't feel like blamey that like this person did ten incidents, and this other person just did one or, you know, this person broke this server three times last week. How do you actually gather that insight from incidents in a healthy way?

Chris Evans:24:28

Yeah, I think like this, this is like a topic that I am incredibly passionate about is the sort of KPIing, and over metricing incidents. So I think, like, my advice would be to essentially steer clear of any top line number around incidents, there's a really common one that gets thrown around a lot which we have sort of begrudgingly added to our app, primarily because like customers were like, I need this thing. And that's MTTR which is mean time to recovery. And the sort of the theory behind this is is that you go, oh, well, for every incident, I will measure the time from when we sort of deemed it to be the start to deemed it to be over. And then we'll just average that across everything. And we want that to, you know, trend down, or at least not trend up. And like, there's various sort of papers been written about the actual, like, how this is just not an effective thing. And it's very misleading. And at the core of it, it's just like, it's kind of ridiculous. When you think about it, it's like, people are people are not going to take any longer than than they sort of need to in incidents. And no one's choosing when an incident happens. And incidents, almost certainly by their very nature are sort of things that no one no one can predict. And so it sort of just is basically meaningless. And so that, I'd say the same is true of anyone who's trying to sort of go well, Amy had 10 incidents that she reported, I'd be like, That's great. You are, you are all over it. And like I've written blog posts, for incidents.io, which are like why more incidents is a great thing for an organization and you should encourage that. And so yeah, I guess my like overarching advice around like numbers and using incidents for insights is, if you really must use a number, because it's the kind of the way that you can sort of your your entry point, I guess, into looking at something, by all means, but you need to go that level deeper, which is like even if you are addicted to MTTR, when that trends upwards, the first step is not like throw your toys out the pram and table flip, it's like cool this as a starting point for an investigation. And it might be that that investigation leads you down to cool, everything's absolutely fine. We've actually just, you know, changed something with our infrastructure. And that's like, you know, you just got to mean like, it's just like, basically meaningless to treat numbers around this stuff.

Aaron Randall:26:48

One of the things that I've experienced and observed, I guess, firsthand with the tech teams I've worked in is around incidents, is, particularly for newer members of the team that are less experienced with the stack and with the technology you're working with, how stressful responding to incidents is, and how stressful it is joining the firefighter rota for the first time or responding to incidents and being the person on call for the first time. How have you thought about that when you're building incident.io and like, and try to support making it a better dev experience in that regard?

Chris Evans:27:20

Yeah, and there's a few different angles here. So I think the first one is, is that by dealing with incidents like transparently out in the open and lowering the severity, like folks who are looking to ramp up, have an incredible like, back catalogue of, you know, this is how these people deal with incidents. And so the things that we encourage and that I sort of picked up from someone who I used to, I used to work, called Suhail [Patel] at Monzo. So he used to run, he used to do incidents, and he sort of go off on an incident by himself. And it's sort of it was fine, because it was like a low severity thing. And it was just, ended up using these, like incident channels, like debug trails. And so he would just be like talking out loud in a channel. So he's like, Oh, I've seen this thing that's really curious, I'm kind of a bit surprised by that. Here's like, the output of my terminal or this window, I'm gonna go look at this now. And he did this whole thing. And so I, I do that a lot. So I'm on call at Incident.io, when things go wrong, I will create an incident channel and I will just leave my debug trail. And that has like, a number of different benefits, like the first of which, like, if you need to call on anyone else to come and join, you've got this like cool you can catch up in the channel, all the context is there. But as I said, for an onboarding tool, it's incredible for folks to be able to, like browse those things, and you can walk through old incidents, and, you know, go go to debriefs, that's like a fantastic way to learn. But I think then another angle, which is really, really useful, which is when when folks are ready to sort of like, take that first step into being the person who was paged, or first responding to incident is to just do it in [work] hours and do it for low severity things. And you can basically go cool well, either you take it yourself, or you can reverse shadow. So we pull in someone else. And so we have ways of doing that. With incident.io, you can configure the product to basically run these lightweight automations, which would be like cool if an incident is declared, and it's minor, automatically pull in Lawrence, and he will be there to sort of help shadow you through this process. And so that, I think is another really, really good way to level folks up. And then the sort of, I guess, future direction for us is like, we would love to build something that is like a better version of PagerDuty. PagerDuty makes it pretty difficult for folks to shadow people. Like I have spent countless hours at previous companies trying to get like schedules to work and escalation policies to like have two people all at a given time.

Aaron Randall:29:39

I've battled all this stuff. Yeah.

Chris Evans:29:41

It's just so frustrating. It feels like such a basic thing that you want to do as a sort of engineering leader is set this sort of like healthy onboarding, rotation up and you have to sort of hack it and so in the future we will be we will be very much focused on that. I think the general point here is like, we are, the three of us who founded this company, we've all been sort of engineering leaders in one shape or another and have seen these sort of pain points time and time again, and sort of building tools for humans is very much like front and center of what we're trying to achieve.

Aaron Randall:30:11

I love that. I love that, that idea as well of, as you described, like going through this like process of like, posting your terminal screenshots and like talking to yourself, it sounds like an absolute treasure trove of information for other people like to come to come in and see the trail of information you've left for them that something

Chris Evans:30:29

is fascinating. It can be it can be really enlightening, and it's like, genuinely such a good way to learn. Because you'll see people who post things you would like, oh, my gosh, I didn't know you could get that data from that system like that. And it's like, that's, that's honestly, that's one of the biggest, like superpowers I think of incidents is like this concept of tacit knowledge, which is like that knowledge that people just know, and it's sort of tribal knowledge among organizations. And it's really dangerous because people leave and they take that with them and people can't make good decisions if they don't have all of the information. So yeah, the more that you can bring out to the fore the better and, and in fact, this reminds me like my, my, literally, my favorite favorite feature of our product is this really, really like small thing that we built in like an evening, because we still had a little bit of capacity left at the end of a week, which is, at the end of your incident, we will prompt with a little button which says, "How did this incident go? Leave some feedback" and we see customers use this again and again and again, you'll have folks who will be like, Oh, I literally didn't know how Amy found that dashboard, I didn't know that existed. But it was like super useful for finding the way here and it sort of snowballs. And people will just leave all of this feedback. And it's just like you can just see like, like this torrent of tacit knowledge like pouring down. And it's just yeah, a fascinating thing to be able to see basically.

Amy Phillips:31:44

Incredible. So we've, we've talked a little bit around this stuff, but super keen to hear, Chris kind of how you've ended up in this place. Right? So you've gone through lots of changes in your career, starting out as a software engineer, you've been technical product manager, technical director, now co-founder, Chief Product Officer. So what are kind of some of the biggest learnings that you've you've got from this journey and sort of transitioning through these roles?

Chris Evans:32:12

Wow, man, that's that's a big question. What have I, what have I learned?

Amy Phillips:32:19

What about some of these big transitions, right? So like, I'm particularly interested, I suppose, like, how did you move from software engineering into product management? Because that feels like I think it's a popular route but I don't think it's a common route. Like, you know, I think people like the look of it but I don't think that many people actually make that transition. Like, how did you go about doing that? And what were kind of some of the surprises when you did make that move?

Chris Evans:32:44

Yeah, that that is a good question. And one I have a good answer for, which was that, so I spent like seven years as a software engineer at a small company that was developing these like infrared sensors. And I was originally writing like embedded code for them and then later writing like applications the web apps that supported them and won't go into like loads of the details there. But basically, the end of my time there, I ended up ended up like flying like various places around the world to go and like sell our product. And we were selling products to supermarkets, primarily, it was like, counting people in queues and through doors and stuff. And I think for me, I realized that at that point, like, my impact could be greater not as an individual contributor, but as someone who could kind of go and be a bridge between non technical folks and the engineers who were writing software. And, yeah, I think I just sort of, I think carved out a little bit of a niche there in some organizations, which was that, essentially, that translation from, you know, people doing the work on the ground through to, you know, whether it's managers or customers or anyone outside? That's, I think it's quite rare to find that done in a good way. And I think there's a lot a lot of sort of, like benefit of having that that communication streamlined both ways. And so that was what led me into technical product management, which was just, you know, how can I, how can I help in the way that I think I'm sort of most impactful and as it happens, the first jump into technical product management was an absolute, like it was absolute carnage for me and it was like, working at Marks & Spencers in like an enormous, enormous IT organization with my entire team out in India. And whilst they were great, like just all the communication barriers and the like, you know, timezone overlaps and all those sorts of things. It was it was kind of dreadful, and I felt pretty ineffective there. And then it was then when I sort of made the move to MOO that I think it was right, it really clicked for me, which was like big organization-wide projects to do this whole data center move. Basically, I remember just like the the team that we're in sort of felt like felt a little bit like the rock stars of the company because that we've been told like,

Amy Phillips:34:58

Incredible team as well. We should probably give them a shout out because they're probably all listening, I expect?!

Chris Evans:35:03

Well, yeah, this is the thing. So I remember joining and just being like, astonished at the level of talent that that MOO had been able to hire. So we had some, like, just incredible, like platform engineers. And, yeah, and then combined with that, like Meri Williams, who I think, has been on this podcast before, the CTO, and so she was able to basically, I mean, she basically was like, this is the most important thing for me. And really, really repeatedly backed that up and gave, like, all the resources that we needed, whether that was time or money, or additional people or additional weight across, you know, exec team or other teams. And so yeah, I think basically, to summarize, MOO is where I really clicked and was like, yes, this is, this is definitely for me, I really enjoy this whole, you know, one foot in like technical camp, and able to sort of help or at least, you know, help make decisions or, you know, influence those sorts of things. And then the other side of like, helping to, you know, make sure that everyone understood what was going on, and that we were doing things on the right timelines, etc, etc. And then sort of, I think, I think that the, as I said earlier, like the sort of extrapolation of all of this is then being someone who then, you know, I now have like a foot in foot in the engineering camp or foot in marketing camp and a foot in various different camps around the company that I'm in now. And then my sort of stakeholders, for want of a better phrase, are investors and the many, many customers and like the other co founders that I work with. And so, yeah, I think I just found out that those, those are the things that I really enjoy, and I think I'm good at, or at least I haven't managed to, like crash and burn this company yet. So, so far so good.

Aaron Randall:36:42

You mentioned earlier in this discussion about building a company, you used the phrase, it was so hard to build a company, and also around the co founder role, that it's like a truly multidisciplinary role. You mentioned doing GTM plus product plus tech plus everything. How did you find that transition from being an employee Monzo to like running and co founding a business at Incident.io?

Chris Evans:37:07

Yeah. I mean, I remember talking to Jonas, the CTO at Monzo before, before I left and him just sort of like a friendly warning. He was like, this will be like nothing, nothing you've ever done before. I can't remember the exact words, but it was just like, you know, go in eyes open. And I was like, yeah, I got this, this is fine. But I think I think the transition, I think the transition was actually eased by the fact that I had Pete and Stephen around. So we often talk about how, I mean, firstly, just massively grateful we are to be a founding team of three people, and three people who get on incredibly well. And it's been now you know, year and a half and whatever. And we haven't had any, any significant fallouts, which is very nice. But we often talk about like having out of phase like sine waves of you know, when one person's down, it's almost guaranteed that you're not going to have both, you know, the other two not be up or at least, you know, out of phase in some way. And so that, it's been like, incredibly hard starting this company, and so much to do, but we are a tight knit group, and very, very supportive. And so it sort of doesn't, doesn't feel like I've sort of had to face, you know, build a sales org and be like, I have no idea how to do that. It's like, cool, well, let's all go and figure this out. And we'll come back, and we'll regroup and we'll work together on, you know, a master sales deck. And we'll, we'll figure out how we do this and that and like, what does marketing look like? And, yeah, so I think it's sort of, it's just hard. And I think it takes a certain type of sort of run through walls mentality to do it well, which is, you know, you've got to, you've got to be the kind of person that sees, sees a big problem as an opportunity rather than something to kind of like, you know, run away from, and it's hard like that's not an easy thing to do. But I think you sort of just, I don't know, I think the thing that I've developed later in my career actually is just this kind of like attitude of saying yes to things, even if I don't believe it. And like, this is how I got into like, speaking at conferences, and it's like, someone asks you and says, you know, will you do that? Or will you talk at this meetup? And I just sort of was like, Yes. And then I stressed for about three months, progressively, in fact I think it was someone, Amy and I used to work with at MOO, a guy, Mike Harris, who used to describe, I think he described giving conference talks as like reverse hangovers, where you get more and more and more sort of ill feeling towards the event, and then it happens. And then it's like, it's all good again, kind of thing.

Amy Phillips:39:35

Yeah, like the pit of despair. Like, three days before, when you realize you really got to write that talk. And you have deep regrets. And then on the day, it's brilliant. Yeah, afterwards, it's even better and then you sign up for the next one.

Chris Evans:39:48

Exactly. Exactly, but in the build up to the talk, you'll be like, never again, why did I do this? I think the thing the thing that, I can't remember who said it, I can't remember I heard it. I think what I love about conference talking is like I'm a massive introvert and I go to a conference, I really struggle to go and like, just strike up conversation with people around the conference. But if you talk at a conference, people want to just come and talk to you. And it's just like, that's brilliant. I love that. Because I genuinely enjoy talking to people. I just like, it's that like, awkward intro thing, which I think generally British people are just dreadful at. And me especially so.

Amy Phillips:40:27

One thing that's always struck me, Chris, is you have remained very technical. And you've always been quite hands on and even, sort of like when we worked together at MOO, and you were sort of like, I know, you were a technical product manager, but like, you were very much experimenting with things. And "I saw this thing. I've tried this thing out", like, how, how have you managed to stay so in touch with technology as you've gone through all these different roles?

Chris Evans:40:52

Yeah, I mean, I think it's probably a stretch to say I'm really in touch with technology. Like I sort of, I think in the back of my mind, my my, I think for a long time, in the back of my mind, ever since I stopped sort of writing code as a full time full time gig has been that sort of fear of waking up one day and being in a meeting that in a technology company and someone says something, or there's a conversation going on, and you've just been like, I literally have no idea what's going on. And I remember I remember this, like M&S And like, I don't want to sort of talk ill of previous employer. But there were, there were people there who just didn't get get the modern world, they just sort of like in IT orgs. And it's sort of like just seeing out a career. And that has always been in the back of your mind is like, I just don't want to be that person. And as I said earlier, like this sort of niche that I feel like I've carved out as this sort of conduit, I guess, for want of a better phrase between technology, people engineering, people focus on the like, the sharp edge of doing this work, and people outside of that. And I think something else that sort of like is like a barometer for how I'm doing is can I go to a sort of meeting with someone and not have to bring an engineer along to sort of like translate or, you know, be support or anything else like that. So I think I think those things have always factored in my mind. And then like, as to how practically I have sort of, I think stayed in touch with like, technology is like, at my heart. I'm like a massive nerd. And so I see things and like, for me, it is like the solution is just write some software. And so I haven't stopped writing software in sort of some capacity at all, in my mind, whether it's like hacking a Raspberry Pi around to like control the lights in my house or, you know, writing some like open source software over a weekend. I think just being curious and keeping your hand in is sort of the the way that that's that stayed about but yeah, I don't know, I feel like I feel like I've sort of seen the future of where I might draw the line or where my sort of knowledge is. And I think it's crypto in that it's sort of like, I see things and I'm like, I don't understand any of those words. I also have precisely no desire to go and figure it out, either. I'm just like, I'm like, is this what is this what my like, grandparents thought of email and they were just like, it's never gonna catch on, don't worry about it kind of thing.

Aaron Randall:43:09

Definitely that and I feel the same as you as well. Unfortunately, we are running out of time. Before we let you go, as with all of our Humans+Tech guests, we have four quick fire questions we like to ask everyone. So I'm going to send these your way very quickly. And yeah, let's get your rapid responses. So the first question is, what's your top book recommendation?

Chris Evans:43:34

I'm gonna, it's gonna be really, really Oh, no, it's not lame. "The Field Guide to Understanding Human Error" by Sidney Dekker, absolute belter.

Aaron Randall:43:42

Never heard of it. Amy you're nodding your head.

Amy Phillips:43:44

I've never heard of it either. I've never read it. I've never heard of it and nobody has ever recommended it before. So

Chris Evans:43:49

I was about to say Harry Potter

Aaron Randall:43:53

So if you recommend a book Amy doesn't heard of, she's my sort of litmus test for if it's worth reading or not. She's read everything, so this is you've broken the broken that rule. Okay, great. Question number two. What, or who is your number one tip for keeping up with the industry?

Chris Evans:44:08

Former guest on this show, Kelsey Hightower. Absolutely love the guy.

Aaron Randall:44:13

Legend. He's, he's incredible. Yeah. Great. I mean, related question number three, who inspires you in tech?

Chris Evans:44:21

Can I cheat and say, Kelsey Hightower?

Aaron Randall:44:24

Who else inspires you in tech?

Chris Evans:44:28

Who else inspires me in tech? Frank Slootman. I think his name is the former CEO of ServiceNow. And now working at Snowflake, I think he is a a very interesting guy, written a bunch of books, worth checking out and he's been on a bunch of podcasts too.

Aaron Randall:44:46

Amazing. Great. And the final question of the four quick fires. What's the most ridiculous thing about you?

Chris Evans:44:54

Oh, gosh, what's ridiculous about me, ah, I don't know, can I cheat and ask for what other people have said ridiculous about them? Or Amy, what's ridiculous about me?

Amy Phillips:45:08

We can give you an alternative question actually, which will be themed. Tell us about your favorite incident, nightmare story?

Chris Evans:45:17

Oh, I can I can do that. Yeah, so I had my fair share of incidents over over my time. I think the, the very, very worst one that I had is one that I wrote a public post mortem for at Monzo, which was where we were scaling up our database, which is an incredibly routine operation that we had planned for, and we had run through in like, pre prod environments, and done a lot of work for and when we went to production, it all went to shit. And we broke a lot of things for a lot of people and took an entire bank offline. And we, yes, it turned out to be a single, like, boolean flag that was true and should have been false. And so lots of, lots of pain ensued. And, yeah, we wrote in detail about it, so I won't go too far into it right now. But I'm sort of getting the cold sweats just thinking it.

Aaron Randall:46:12

I'm getting sweaty palms and I wasn't even there. Wow. I mean, a great thing to live through well done for getting on the other side. Yeah. Amazing. And finally, where can people find out more about you?

Chris Evans:46:26

I guess either, for me, me personally, follow me on Twitter. I have a ridiculous handle that you can't pronounce. But it's like evnsio or Incident.io. That's a good place to find more.

Aaron Randall:46:40

Amazing. Great, Chris, thank you so much for taking the time to talk to us today. Learnt a bunch and loved, loved hearing your stories. It's been a lot fun. Thank you.

Chris Evans:46:48

Thanks very much.

Aaron Randall:46:51

We'll be sharing all the links in the show notes plus the all important doodle over on Humansplus.tech. I'm Aaron Randall. This is Amy Phillips and you've been listening to the Humans+Tech podcast.

We're joined by the incredible Sarah Wells. Sarah's most recently worked as Technical Director for Engineering Enablement at the Financial Times, where she spent the last 11 years leading tech teams as well as defining the tech strategy and product roadmap inside the FT. Sarah's also a frequent conference speaker presenting on topics ranging from microservices to engineering productivity.

In this episode we discuss Sarah's experience of working at the Financial Times, learn the secrets behind successful Engineering Enablement, and learn how to create a Golden Path. Sarah also shares how the FT increased diversity in tech plus shares some great new book recommendations.

Listen on your favourite podcast provider.

Scroll down to read the full transcript of our chat with Sarah

Sarah's quick fire answers

Sarah frequently recommends Accelerate, Team Topologies, and The Manager's Path, all firm favourites of Human+Tech guests. She wanted to recommend us something new, so Sarah's top book recommendations are Inside the Nudge Unit by David Halpern and The Checklist Manifesto by Atul Gawande.

Twitter is Sarah's favourite way to keep up with the industry.

She's inspired by Tanya Reilly for her amazing storytelling abilities and for her blogpost and talk on glue work.

Sarah is a keen home cook. She's recently been cooking from the Every Grain of Rice cookbook.  

In this episode we cover

1. Highlights from Sarah's time at the Financial Times [00:1:33]
2. The power of a sponsor, and how to set up successful sponsorship relationships [00:05:13]  
3. Asking for what you want [00:10:12]
4. Sarah's experience of moving into directorship [00:13:49]
5. How technology contributes to the success of the Financial Times [00:17:44]
6. Chart Builder - a tool to allow journalists to turn spreadsheets into FT charts [00:19:08]  
7. The Golden Path; how to create a paved road that engineers want to follow [00:23:31]
8. Biz Ops service registry and how it came about [00:29:31]
9. How a bot helps with DNS approvals [00:35:42]
10. On when to set up an Engineering Enablement team [00:37:33]
11. Achieving greater diversity - how the FT teams became 35% women and non-binary [00:41:00]
12. Sarah's upcoming book on enabling microservice success [00:47:59]

Find out more, and follow Sarah

You can follow Sarah on Twitter @sarahjwells

Full transcript

Aaron Randall  0:01
Welcome to the Humans+Tech Podcast. I'm Aaron Randall and this is Amy Phillips.

Amy Phillips  0:05
Hi.

Aaron Randall  0:06
And today we are so excited to be talking to the incredible Sarah Wells, Sarah's most recently been technical director for engineering enablement at the Financial Times, where she spent the last 11 years leading tech teams as well as defining the tech strategy and product roadmap inside the FT. Sarah's also a frequent conference speaker presenting on topics ranging from microservices to engineering productivity, Sarah, welcome to the show.

Sarah Wells  0:29
Hi, there, it's a pleasure to be here.

Aaron Randall  0:32
Awesome. So great to have you. And one of the things that we'd like to do for all of our Humans+Tech guests is to draw a doodle of them. And I'd like to show you yours and kind of get your thoughts and feedback now.

Sarah Wells  0:43
Okay, go ahead. I have been I've been looking at the other ones and wondering what this is gonna look like, Oh, boy.

Aaron Randall  0:48
Probably very similar.

Amy Phillips  0:52
Looking here for your, your critique.

Sarah Wells  0:57
I think I look like Meri Williams, I think there's a thing about like, dark hair and glasses where you just always end up looking very similar. It's the most distinctive thing.

Aaron Randall  1:13
That's probably, yeah, they're all pretty, pretty generic all pretty much the same. But yeah, no, I see that. I see that as well actually nice. Well, moving on to the important stuff in so you know, as I mentioned in that intro, you have worked at the Financial Times for a long time, 11 years, and that's a really long time to work in one place. What were some of your highlights?

Sarah Wells  1:33
Ah, well, it is it was a long time it what's interesting about that is I did several different jobs there, which I think is what kept me there for so long. So I probably did, did about four different jobs, all for about three years. Some of my highlights Well, I mean, I joined as a senior developer, and when I, when I joined the Financial Times, I'd been working in IT for about 15 years, I've pretty much been a senior developer the whole time. So I, I was a career changer. So when I started in IT I very quickly started running a team, because I was really experienced in terms of that kind of side of work, I think. And so I've been, if you look at my career, it's like this very sort of steady line of I do this job, I run a tech lead. So the FT was the first place where I had the opportunity, and people encouraged me to step up. So it's a real big change from being a senior developer to being a technical director. And at every point, people would say to me, you know, you can, if you're interested in doing this next thing, you definitely could do it. And then the other thing is that there'd be a problem that I wanted to solve. And the best way to do it was to, was to step into a role that allowed me to, to have more kind of ownership of it. So so the highlight probably is a complete different, like career path, because I'd never really thought before I joined the FT that I could see myself being a technical director. Beyond that, actually, there's, if you want, basically, when you leave a company, and the FT is a, because it's a newspaper, one of the really nice things that sometimes happens to you when you leave, particularly if you've been there for a long time is that they create a front page for you. Which is like and I was really super lucky because they even printed it on FT paper. So I've got this, like page of the FT that that, that people, you know, told stories and mentioned things that I'd done. And a lot of them is like pointing out silly things. But you do kind of go Oh, yeah. So one thing would be the FT's internal tech conference called Engine Room. And that's been going I think, for seven years now. And I helped set it up in the first place helped run the first one, I've run two or three of them. It's very established part of the engineering culture there. It's changed from year to year. But I particularly enjoyed it in 2020, and 2021. Because we basically had to go online and really made a like made the most of that. You know I felt like we managed to gain from the ability from moving away from having to book the conference suite to being able to do it online. There would be lots of people talking, there would be loads of chat in the sidebar in any you know, in meet, it would be be great, but it's something that some that's helped provide an opportunity for people to share what they know and to try out being on a panel, try out speaking. It helps set the culture of the department and it's something that I always think is a really powerful, powerful thing. So I think that's something I'd consider to be part of the legacy for me at the FT is that I mean there's tons of other things I could talk about, it's like, you know, I feel like I can look back at what I was doing when I was at the FT and see, see an impact, which is just really exciting.

Aaron Randall  5:12
I love that. You mentioned there as well, at the beginning about having people in the FT encourage you to step up. Is it fair to say, you had advocates or incredible managers that are really supportive and helping you to sort of develop and grow.

Sarah Wells  5:26
Yes, yes. Yeah. I mean, yes. But also beyond that, as well, because I think there's something really powerful about someone senior who's not actually day to day responsible for for you as a manager, saying, oh, you know, you could, you could do this. So, so one kind of, I think a real sort of impact for me was when Cait O'Riordan, who was the CIO, approached me actually at the Christmas party and said, I want to mentor you, we're gonna have a mentoring discussion in January. Okay, we actually had only had one at the time. But she basically, it was really succinct. She just said, I want you to know that if you want to be a CTO, that's, that's something you could do if if you want to, and that there are different types of CTOs. So if you were CTO, you wouldn't have to look like our current CTO. And at the time, I was a principal engineer. So it's two steps from there, tech director, CTO. So, actually to have someone say, not just you could do the next job up, but actually to say you could do the job two above that. I couldn't believe the impact it had on me. Because it wasn't something that I even remotely had thought about. And, actually, there was quite a nice culture, I think, at the FT of people, sponsoring people. And I, probably about five years ago, I got sent on a, an internal program called Talent Acceleration program. But basically, they identified women who were about to step into leadership positions across the FT, it wasn't a tech specific thing. And we got sent on some training about things like building your brand, how to be resilient. And one of them was about sponsorship and mentoring. They talked about that. And it's that kind of really important difference between the two. Because you know, people always talk about mentoring. And Lara Hogan says, you know, that people are over, women particularly, are over mentored, and under sponsored, it's really easy to say I'm going to mentor you. But actually, the thing that matters is, does someone go into a room and say Sarah could do that? And particularly do they say Sarah could do that when every other person who's ever done it looks different from me. And that definitely happened to me, at the FT. And actually, after I had been done this training course, I realized that I did have a sponsor, quite accidentally, and you don't go and ask for a sponsor, you kind of attract a sponsor, and the sponsor sponsors you because they can see that you can do something, they can see that you're going to deliver something that they need that you know that they are betting on your ability to do something. When that sponsor left the FT, I consciously thought who is my sponsor? Now? I think that's, that's something I think it's really important is to understand, who is the person who is in a position to give you opportunities? And and do they understand what you can do and what you want to do? Because because I think we all kind of would love that our managers or our leaders would recognize our innate brilliance and give us some opportunity. But I know that like if someone says to me, Oh, I'd like to get someone to to speak at this conference have you got anyone, I'm far more likely to have the name come to mind of someone who said to me, I'd really like to speak, could you help me out with that? So I think it's really important to think about making sure that the people who can give you opportunities, understand what you're interested in.

Amy Phillips  9:11
How did you go about doing that? Because that feels like I mean, it's so like, it sounds so obvious, but like, yeah, you kind of mentioned like, you don't really go and seek a sponsor, you attract a sponsor. So how did you go about sort of setting up the new sponsor and making sure they knew what you wanted to do?

Sarah Wells  9:24
Well it was actually so the person who had been sponsoring me was the CTO at the time. When he left I thought, there was a director of engineering, he wasn't my actual manager. My manager was the head of software development, but I was a principal engineer and I, I basically, I had a good relationship with him - his name is Rob Shilston, he's fantastic. He was really influential person for me in my career. Rob and I had a great relationship anyway, but we didn't have kind of managerial relationship, but I actually asked him if we could meet monthly, because I was like, I'm a Principal Engineer. I should understand what the director of engineering needs from me. So then I had that regular thing anyway. And so so when I was thinking, Well, Rob is clearly the person who's who can now sponsor me, we already had that. So I think it's I think the thing that was surprising to me about that was, its the first time I'd actively asked for something like that. And you, you sort of, I think, and I think particularly probably, as a woman, you're a little less likely to say, Can I have this thing. But around that time, I realized that quite often you can ask for things, and it can work out. So for example, I wasn't an architect. There was an architect's forum at the FT at the time. And lots of things got discussed there that I was really interested in. And at some point, I just went to the director of architecture and said, Can I start coming to the forum? And he just said, Oh, yeah. And it's just like, Oh, my God, it's been annoying me for ages that I'm not involved in those decisions. And all I had to do was say, can I come? And maybe he'd have said, No, and then I'd have had some explanation of why and that would have would have helped. So I do think it's worth asking for things that probably aren't a massive commitment for someone. And if you're chatting to people anyway, that's good. Yeah, definitely.

Aaron Randall  11:20
How has that influenced how you think about sponsoring others?

Sarah Wells  11:26
I, I think I'm really conscious that I try to encourage people to think about who sponsors them. And to be clear about what it is that they're looking for. Definitely, and I'm actually more interested, really in sponsorship than mentoring. Partly because the kind of role that I had at the FT I had the opportunity to, to have, you know, to put people into places where they would learn something new or get or get some new experience. And I think, I mean, I do mentor people as well, I'm not I'm never convinced that how good I am as a mentor. And I think there's a lot of overlap between mentoring, coaching, etc. What I know I can do is kind of sponsor people and talk to them about what they're what they're interested in, in doing. Although I think if you spoke to a lot of people who I've mentored or sponsored, they'd say, Sarah's answer to everything is you should start talking. I know it's not the answer for everybody, because it's, you know, like, it's one of those things, that it can be one of the things people are most scared about standing up and talking in public. But if you are someone who can, who can find a way to communicate, if it's not talking, you know writing is exactly the same. It's like there's so much to gain from being able to put your thoughts in order and communicate them. And I don't think that I realized when I was more junior how, how much of a skill it is that's useful in, in work as well as kind of outside but also how it helps you build a network. It helps you get to know lots of people who can answer a question for you and save you so much time. Like when the FT would be trying to do something new. It's amazing if you can go and find someone who's already done it and say, Well, how did you introduce this into your company? Any tips on how we can not get this wrong?

Amy Phillips  13:22
Yeah, it's so important, isn't it? Wow, I have so many follow up questions. So how about maybe? So I'm kind of curious, actually, I suppose. So, you know, you did move through a lot of roles at the FT and I'm really curious about how did you find that like how what was it actually like to sort of, to end up being a director, like compared to having previously been an engineer?

Sarah Wells  13:49
I, I didn't feel, they always felt like, it always felt like the move was sensible. So So I was a senior engineer, and then the architect on the project, I got promoted to principal engineer, then the architect left the company. And I was having a conversation about who was going to replace him to lead the project. And and I just remember thinking, Well, I don't know if it should be me, but I really don't want it to be someone else that's going to come in and we're six weeks away from launch. I don't want someone to come in and go, Oh, we should change our our approach right now. That would be really, really bad. And I kind of found a useful thing, which was that I just said, I'd like to be considered. I think I wouldn't have gone I should have this job. But I was able to sort of say I'd like to be interviewed for it. And then once I'm in the processes, you kind of get excited about everything and a bit competitive. The move to technical director, I was pretty lucky I think which was, I'm kind of assuming a lot of stuff here, I've never actually asked but the CTO at the time. There was a director of operations who had just written a proposal for how we would handle out of hours, support for all the new systems we'd recently built. And we'd kind of moved to a far more. So it was all microservices, it was much more you build it, you run it, we were trying to work out how do we have developers doing some level of support for these systems, because they're too complicated. There's too many different parts, compared to our old stack. That was literally everything was running in Tomcat, with Apache in front of it. I had so many bits of feedback on the proposal, because we'd been doing this for a couple of a couple of years in my team, that I ended up writing a counter proposal because I had that thing where you put comments in a Google Doc and actually the comments are now pages down below. So I just wrote a counter proposal. And I didn't know that the director of operations was was going to leave. But I think I kind of, I kind of like

Amy Phillips  16:01
because of the comments?

Aaron Randall  16:02
Yeah, because of the comments

Sarah Wells  16:03
no, no, no, what I think happened is the CTO thought, well, we've got someone internal, who's actually really deeply interested in some of this, some of these areas, and it felt like I'd kind of said, Oh, no, but I think this, this and this, and so you know, I really wanted to apply and, and see if I could do it. And as a tech director role, it was it was really perfect, because it was a small group, it there weren't that many, it wasn't a massive change in the number of people that I would be managing, or anything like that, although I did take over the role and then go, Oh, I'm kind of responsible for business continuity. Well, that's interesting. But I don't even know what that is. And then engineering enablement, which was the last thing I did, it was, again, it was one of these things where you're looking at how the group is structured, and you have opinions about oh, well, you know, if we could move some teams around it, we'd have some we'd have a definite everyone in this group is focused on engineers as customers. So it's really interesting when you can see, yeah, it's seeing that there's a problem. And if you can just do this and get into the place you can, you can deal with it. I did actually, one of my colleagues at the FT, I was talking to her about another role, because at one point, I got feedback that maybe I needed to move into a tech director role that got me more exposure to business stakeholders. So I was talking to someone about one of those roles. And she said, "You turned up to ask me about it. And you just started with what's wrong? What needs fixing?" And you never asked me what was good about it. I was like, Yeah, I think I'm a problem solver. I'm interested in, I'm interested in what's what we needed to fix.

Aaron Randall  17:44
I'm fascinated by the fact that the FT was founded, like, all the way back in 1888. And like your organization's been around for such a long time. And what role today does tech played in organizations that has existed long before websites and apps were even a thing?

Sarah Wells  18:03
Oh, well, I mean, this is a very kind of tech, I'm going to give you the tech answer. If you were to talk to editorial. I mean, if you spoke to the business, generally, editorial are the core of the FT. That's what, that's what the FT does, like we tell, do the news. But over the time that I was at the FT, you know, you're starting to realize that technology is really important in being able to tell in being able to tell news stories, and I kind of hope that we managed to move people from the idea that technology is just a cost center, to the idea that technology actually can provide value and be be something that allows you to, you know, to make the business more successful. And that was things like having, having teams that technology teams sat in the newsroom working with editorial, building, building tools. An early example was a thing called Chart Doctor. That meant that if you had a if you had a spreadsheet as a journalist, you could create an a good FT chart to put in your story. And you didn't have to go and find the team that created charts and get them to make it for you. You can make it yourself. If you look at the look at all the stuff around the Coronavirus that the Financial Times published, their data, their charts is just the visualization is just absolutely excellent. That's enabled by very, very tech literate journalists and technologists working closely alongside them. But there's it's obviously what it's obviously wider than that. But I think that there's a there's a recognition that you solve. You basically make the business work by using technology by having a strong product strategy as well,

Aaron Randall  20:01
and how to how do journalists get involved in in kind of influencing what you do build, how do they get? How does their voice get represented in the product strategy?

Sarah Wells  20:09
Ah, so this is not my this is really not my area, because I've consistently worked a kind of a few removes from the business, you know, it's building the content platform and APIs, and then doing engineering enablement, where effectively, I'm sort of supporting all of the all of the teams. But in general, there are, there are boards related to particular parts of our product strategy, like our mission, mission control, I think they've been called. And they involve people from editorial and other commercial areas as well, along with tech leadership, so that they are working together to talk about the product roadmap to make decisions about what the priorities are, with the idea being that if that group all agree, then you know, you don't have that thing where marketing would like you to build this thing. And editorial would like you to build something else, and you're stuck in the middle. If that discussion happens with everyone in the room first, then hopefully, you're able to say, but we all agreed that the first thing we were going to do was this, this thing? I think certainly, it felt to me, like we worked a lot more closely with people from other parts of the business by the time I left than when I when I first joined.

Aaron Randall  21:25
Hmm, it's really interesting. I just love the fact that there, there are industries where I've worked at so many different tech companies, where developers are kind of the superstars, you know, the special team that does all of this amazing work. And actually, it's so kind of refreshing to, like, hear about the FT and think about other organizations were actually, as you said, like the editorial team are cool. Like they're the superstars. Not not the developers in this organization, which is kind of an interesting dynamic.

Sarah Wells  21:50
It is it is it is very different from from tech, it's very interesting. So one of one of the things that I was involved with was the, the response to the pandemic, because it started off as a business continuity issue, which was in February 2020, thinking, we're probably all gonna be working from home in a month's time, what can we do to make sure we can succeed with that? And then after that, it was how do we, you know, are we coming back? What are we going to do? What's really interesting is that the tech team, the tech department feel quite differently about quite a lot of these things from other parts of the business. And it's a challenge, because, because, because actually, for people in the tech team at the Financial Times, if we left the FT, it's not necessarily the case that we're going to work in another newspaper organization. Whereas, you know, if you work as a journalist at the FT, the place you're going to go to next is likely to be a newspaper or some other journalism thing as anything else. So you're competing against different against different markets. So whereas you know, in journalism, you might, the FT might win out because we're not making people come back to the office five days a week and and say the telegraph is, with tech, you're also competing against all the companies that have decided that they're perfectly happy being remote only. So I think it's really interesting. Because you are competing against companies where developers are the rockstar, where product or product is king and products not It's not going to be the, you know, the, the rockstar in an organization that isn't a tech focused organization, I think.

Aaron Randall  23:30
really interesting.

Amy Phillips  23:31
And maybe that gives us a nice sort of transition into actually engineering enablement. Because one thing, and I know you've kind of mentioned is the importance of the golden path. And this idea of like building a path that people actually want to follow. And, not like, they have to follow it, but actually, they choose to. And I guess, like, it sounds like, certainly an interesting one, I guess, kind of interested in the balance of the must be some golden path that it's you want to follow because you're at the FT, but also some golden path you want to follow because you're a developer and actually, this is what the the cool, the cool tech is. So how does the first maybe like, what is the golden path that like, how do you actually go and set that up?

Sarah Wells  24:14
Well, so during the time that I was at the FT, we went from, everything's written in Java, it's runs, in Tomcat. It's got Apache in front of it, to a kind of explosion of things that you could use in one database, whatever to bring pretty much an explosion of you can use lots of different things. So we started three big projects around the same time they were all microservice based. They introduced a lot of different technology. And that's great because you, you, you end up being quite autonomous when you're doing that and you're not held up so you can make progress. But you're a couple of years in and you've all basically solved the same problems. So you've got eight different solutions for a particular thing. and actually people start to get get to a point where I'd really want to be focused on the business stuff. I don't want to be like maintaining our own version of the build pipelines, or, you know, I want to just be able to do infrastructure as code and not kind of invent it from scratch every time. So there's, there's always going to be some level of things where you think well, could you? How much of it could you could you take away and provide to people, so. So we used AWS, among other things at the FT, got a team there that are building tooling around that. You want to build things that people most care about having. So you want to build something that's well documented self service, automated, you know, you have these principles behind what you're building, to, to test that, that what you're building is useful. Because I think that if you've got autonomous teams, for a lot of, in a lot of cases, they could choose not to use whatever you build, you don't want to be, you don't want to be in the position where everyone is forced to use your stuff that they don't like you want to build something that is better than having to build it from scratch. So the idea of the golden path is that you, you basically say, okay, we need to do there are certain things you need to do to deploy code into a live environment. How much of those things can we provide you with a really simple way to do it so that you don't take too much time on it. And the idea is that sometimes you might say it's paved road, you can choose not to follow the golden path. But it should be easier to walk on the road than it is to hack your way through the undergrowth. And if you do decide you're going to hack your way through the undergrowth, then I think the thing that you are, basically that you have to do is meet all of the requirements that the golden path does. So you can build your own version of this, but you better have logging and it had better be patched regularly. And you're the ones that are going to wake up at two in the morning, if it breaks, and it's being used for a critical system. So it sort of feels like if you're doing engineering enablement, within a within a company, you should be able to build something that people like, because you're right next to your customers, and you only have to solve the needs of the people in your organization. And you should be able to to be better than them having to build everything from scratch. So engineering enablement is about that. And I think when you have a very complicated distributed systems architecture, you know, when you have 1000s of different moving parts and services, and so microservices, serverless, all of these things. It's worth investing in some people that just provide a sort of stable, a stable sort of, under underlay for that.

Amy Phillips  28:07
How do you go about like, so I guess, if you're like, kind of setting up teams like this, like, where do you begin? Because, I mean, I get like, after some time, you probably have a great tool or project that people want to use, but like what does the sort of early stage look like?

Sarah Wells  28:22
So I think the way you begin when you're setting up the teams, for me, it was finding people who wanted to solve this kind of problem. And who had a natural instinct to go and talk to their customers. I mean, effectively, you are you have, you're building a kind of a product, and you're kind of, you're still you should still care about research and feedback and everything like that. You probably, like so, so what we would do is we talk to people about what they were finding was painful so we'd survey or we'd interview or we'd look at what people said in Slack about something. So you know, if you see lots of complaints about a particular bit of technology, then you could probably have that as a target you do look at or certainly I always thought we should try and deliver regular, a regular set of things. So looking for things that don't take a lot of time that you can get something out the door that people will like, but also thinking about what can we build that maybe take a bit longer, but it will make more of a significant difference. We started with what we had. So we kind of had the idea of a registry for systems. But it wasn't really built in a way that made it easy to extend. So it was effectively largely about runbooks It was basically a kind of, it was more like a relational database. You just had rows for each system. So now if I moved from one team to another, and I was the tech lead for over 150 of the systems, you had to go and update 150 rows effectively. So it's better if you think about that as a graph. So the first thing we did was we converted that to be a graph. And then the graph was there with the ability very easily to add new new nodes. And so we have a, there's a thing at the FT called Biz Ops, which is basically, a systems registry, but it's more than that. It's like every service linked to the teams that own it, we've been able to bring in information about GitHub repositories, AWS resources, because we already had a standard from a long time ago about having unique system codes for systems, you can tie lots of things together. And then you can start exploring it. And it's got a GraphQL API, so you can ask interesting questions and say, Can you find me all the services that aren't that are not owned right now? But can you find me all the services were? So one of the interesting things we did quite early on was, Are there services that have S3 buckets that are open, publicly open, where we've said that this service has PII information in it? Because that's immediately telling you something really interesting that like, this is one we should probably focus on is it and actually, quite often, you'll find out that the stuff that's in the in S3 is actually fine. But you should at least have to have that thought. So being able to automate the kind of questions that that you ask as well. But also, we spent quite a lot of time just selling, selling what we were doing internally to, to our customers. So I always took every opportunity to talk at tech all hands or to run a panel at the internal conference, or to write a blog post, to try and find out what people were where people were frustrated with something and where we can help. It is difficult, because you always require teams to work with you a bit when you're adding some new feature, and they're all busy with their own, like their own needs. So So part of it is can you give people enough notice, like in six months time, can you spare a team for a few weeks or more? I think that that kind of helps? Or can you send someone to go and sit in that team and do the thing for them as well?

Aaron Randall  32:24
What was the most popular tool or software you shipped in the engineering enablement team?

Sarah Wells  32:34
Well, I honestly think Biz Ops is still like, it's still just really the fact that you could go and look things up. And I knew we were doing well at the point where people who weren't in our team would post a link to Biz Ops when someone would say "Does anyone know who owns this service?" and someone else would post the URL and you go, well, that's, that's good. But on top of that, there was quite a lot of nice sort of visualization. So there's a tool called SOS, which was system operability score. And this was at a point where we had lots of services that didn't have a very good runbook. I mean, mostly, they just didn't have a runbook. So we automated scoring, the runbooks. So it was it was, you know, a little bit like, okay, it's really important that the service is owned by a team. If it's a if it's one of our most important services, is there an out of hours rota? Is there anything in the section about failovers? And a lot of it was quite straightforward. It was like, is there something there at all. So you know, it could literally be someone's gone to be filled in later. Although I think we did look for things that just said to do, basically, we can score, we could score the runbook. And then we can aggregate the scoring, and show teams, how they were doing. And then groups how they were doing. And then we could basically compare, basically show people how they were doing compared with the other groups. There were two things about this. For some people, they're really competitive. So we would have people who would come to us and say, I want to get 100%, what do I have to do to get to 100%. And sometimes that was actually difficult, because maybe there was a like, there just wasn't a way to do it. But we would try and this and that. And you would see people posting screenshots in Slack saying, "Hey, we've overtaken you". So that worked in one respect. And what I hadn't realized, was around the same time the FT started doing OKRs. And the thing about so objectives and key results. The thing about this is you set an objective, and your key result is something that you can measure. It's even better if you can measure how you're doing throughout the quarter to see that you're making progress. Well, it turns out if you've basically given a score, you've just given people the ability, a really simple way to set a key result related to observability. So people would say we're going to improve our SOS to be from 70 to 90. And so that had quite a big impact. It only lasts for a certain amount of time, because it isn't as good at catching the place the point where someone's information is out of date, if there's information in there, but it's wrong, that's a lot harder to automate. And we did have a manual follow up, which was that our first line operations team would review all of the critical systems yearly to look at that information and do a manual review of it as well. But that kind of shows, you know, you might get a lot of feedback here, lots of great stuff out of something, but it's not going to work forever. Sooner or later that's not the problem, something else is the problem. And that's where you need to be to be focusing, focusing your time. So I think, yeah, I think that worked. But generally, another one that people have liked recently is that the team that managed DNS configuration, we had to move DNS providers two or three years ago. And as part of that move, they basically moved DNS to be infrastructure as code. So you can make you can make DNS changes by by in a GitHub repo and raise a PR, however, there's still feedback, saying, it just takes a while for you to review the changes. So they looked at the kinds of changes that people made, and they identified some changes that are really low risk. And they added some rules. So that basically, if you raise a if you were to raise a PR, and it's adding a new section, or deleting just a section as a whole, they could just automatically approve it. Or if it was something that when they knew the cyberSec team orght to have a an opinion, they could automatically add that someone from the cyberSec team onto that PR. So they just started, there's a really good blog post on the FTs technical blog, which is on medium, it's FT product technology, about this, which is basically, you know, here's, here's where we started, started the work. And I think that's something that I really liked, because it's, it's automation, it's listening to our customers, and it's like having a balanced view of like, of risk versus autonomy. Because I think you've always you want teams to be able to autonomous, but you also want to protect them from making mistakes that you want to protect someone from accidentally deleting the DNS entry for something critical. I think that's, that's something that you ought to do as a platform team.

Amy Phillips  37:30
Yes, it sounds like a great idea.

Sarah Wells  37:32
Yeah.

Amy Phillips  37:33
And I suppose, like, at the FT, you know, it's like, a very large organization, like, super critical, highly visible. So, you know, I can see it makes like tons of sense to have engineering enablement to sort of set these things up. There's, I'm curious, like, on your thoughts of like, should every company have something like this? Or like, what's the point where you actually say, engineering enablement, is actually going to really help us and we should, we should go and get that set up?

Sarah Wells  38:01
I think it's probably to do with it has to do with how many people you have working in engineering, I think it has to do with whether you have enough people doing work where you want to end up with a slightly more complicated architecture, in order to allow them all to make progress. So, you know, I wouldn't recommend people adopt a microservices architecture when there's one team of people working on something. But when you have five or six, maybe maybe you might introduce some level of that. And when you get up to like, 250 people working in a tech team, you probably go a bit further, once you get to that point, I think you're going to have people that are spending time doing this sort of stuff, whether they're one person in a team who's dealing with all of the little niggles, or whether you actually extract those people and have them work for something that solves it, let you know, do you do you solve it locally? Or do you solve it more globally? And I think, often you want a bit mix of both, because some things are very specific to a particular team. But some things it's like that you're looking at those local problem solvers. And actually, they're they're doing stuff that other people are also doing. And it's just not it's not the most effective use of people's time. So I think it will, it's like it's a classic consultant answer to say it depends, but I think what it comes down to is, does it speed you up for your other teams having this? And you could, you could try it out by saying, you know, we know this is a particular problem. Let's form a feature team that's going to work on it for a month and see, does it have an impact? Does it change our ability to to make business changes. Early on at the FT and it's kind of before I was really involved in this because there's been a move towards this for a long, long time. Now when I when I first joined we did 12 releases a year for the website. And if you wanted to get a new build a new system you'd buy a server and put it in the server room, and everything. So there was investment then to, like make it much quicker to, to spin up a server. And you could actually see, you could see the impact of that point, you could see like, we're releasing code a lot more frequently, it takes less time for us to get that first release out. After a while, it's much harder to measure it. Because you're already like the FT does pretty well on the accelerate metrics probably do 30,000 changes a year. So you know, we're doing a lot of change. And when people say, How can you? How can you show that your team is providing value, it's actually quite hard without removing that team. But but it is still there and removing some of that like pain for day to day, you know, you need to tend to your tend to your software estate, and the people in engineering enablement teams tend to do that.

Aaron Randall  40:58
I love that. I'd love to switch now and talk about the team itself, kind of the makeup of the team. And I read a quote that you said previously about when the fact that when you joined the FT as a senior developer, you were one of four or five women in development team. And now in London, your team's around 35% women and non binary, what steps did you take to achieve that improvement as an organization?

Sarah Wells  41:24
Ah, I mean, I think there are, there are lots of parts to that. But probably probably a main one is actually Cait O'Riordan, saying we're going to do it. And we have a target to be 50/50 by 2023. I can't actually remember the exact details. But but to say here is a here is a target we have for our department, and then to be to be specifying OKRs for it, quarter after quarter. And everyone knowing that this is kind of an expectation. So. So you're, you're thinking in terms of how are we doing in terms of our hiring, and being willing to say, we've got 100 CVs in for this role, and they're all men, go back to the go back to the to the recruiters and say, this is this doesn't seem possible, really, that there are no women at all. And women's just one aspect, obviously, there's tons of other aspects of diversity that are really important, we probably made more progress initially, on women, and that's partly because it was one of the bits of data that we also had. So when I was I was the first woman tech director. There'd been no, there have been no women architects, we kind of didn't, we moved away from architects and moved to principal engineers. But there were no women architects, I was the first woman principal engineer. But then we got to the point where probably 40-50% of Principal engineers, were woman, technical director, by the time I left, we were the majority women, on the technical directors, you know, only only marginally, but it's amazing compared to pretty much anywhere else. Partly it's that people see, they see the path. And, and it's perfectly normal for a senior person in the discussion in the technology team at the FT to be a woman, which I just think sets that like expectation. But it's it's really around the data. So when I became a tech director, every time that we did a promotions round, we'd look at the data. Were we putting forward men and women at similar numbers? What were the current salary distributions within each role for men versus women, because you want to make sure that there isn't some systematic bias there. And you want to do the same for other aspects of diversity. But it's harder to do that until you have that data. So the FT did introduce into the HR system, the ability to say, to say more about yourself, you know, to say, what's your background, you know, all kinds of levels really. And I think having that data and actually looking, looking at it is, is useful. It's difficult sometimes, because there may just not be enough people in a particular area for it to be meaningful, a meaningful thing, but at least it just gives you a framework for going oh, you know what, this person's definitely not being rewarded the way that their peer is, it takes time as well because you know, when you start from a position where there hasn't been a very obvious pay band, so we'd introduced like we introduced about there is a pay band. And initially there was a lot of, well, here's our here's our sort of internally shared not really very public with everybody, but the hiring managers knew about it. And then we'd look at where the outliers were. Because then the first thing you're trying to do is make sure that you're fixing those. And we started off with pay bands that had a definite overlap, because, because basically, otherwise, you had so many outliers. But I do, I do think that like, you start with that, but actually, it gets easier, the more that you already have people in place, because quite often you get recommendations, or people, you know, people come and join you because they've heard its a good place to work. And you're, you go from having to make a special effort to make sure that you have a diverse interviewing panel, which, you know, incidentally, has an impact on the people who are, who are showing that it's diverse. Because if you as a woman engineer are in every interview, because we're trying to show that there are women here, what you're not doing is the other stuff that could get you promoted, so you have to make sure that it's rewarded for them. But eventually, it just becomes much easier, because it's just natural that you have a diverse interview panel.

Aaron Randall  46:11
That's really inspiring. Great. I mean, so many things you mentioned there and like OKR setting, I guess setting it from the top having leadership talk about it. You mentioned Cait really driving a bit of that, hiring and pipeline diverse interview panels, that kind of stuff. Really impressive. What was the biggest challenge in doing all of this?

Sarah Wells  46:30
Ah, I mean, I think that, that there's an element of people feeling frustrated that it's not perfect, but people want you to be really, it takes time to do anything. It takes time to do anything like this. And along the way, it's, it's, it can be frustrating for people, I guess that's a challenge. It is a challenge I think for for white men, who are thinking, where's my opportunity gonna come from? You know, I've had people say to me, Well, of course, I'm not going to get promoted, because I'm a white man. And it's like, well, you know, it's that quote, of if you're, if you're used to your privilege, you know equality looks like oppression. And I think that can be can be really, you have to recognize it. It's, I think, what I would try and say is, it's mediocre white men are not gonna get promoted, right, that's, that's what's mostly happening is you're picking the best people. And now you're actually making sure that if those best people aren't white men, that you're actually gonna see them in, you're actually going to consider them. And there's definitely an element of like changing what people think it looks like to be a leader. You should recognize different, different styles as being valid.

Amy Phillips  47:57
Wow. So we are so nearly at time, I want to just ask you one final question, Sarah, before we jump into our kind of wrap up quickfire questions, but you've shared so many amazing stories and experiences of your time at the FT now we know that you did recently leave and you're enjoying some time off. But can we ask like, what's gonna come next, do you know?

Sarah Wells  48:18
Um, yeah, I do know, I, I left because I'd been there a long time. And I was quite exhausted, I really did need a bit of a break. But amazingly, I've agreed to write a book for O'Reilly. So pretty much now I'm going to start, I'm going to start writing it. It's about microservices. It's called Enabling Microservice Success. And it's really, about how microservices, if you want to be successful, is about more than the technology. It's about the organizational cultural setup that you need for that as well. So, so I'll be looking at, you know, what do you need to do? And, and where are the things that can really trip you up? If you don't, like change the way you think about how you build. How you build software

Amy Phillips  49:08
Wow, that sounds incredible. I'm very excited to read that.

Sarah Wells  49:11
I am really excited. I'm so excited.

Amy Phillips  49:16
Okay, so we do just have our final quickfire questions to wrap up. So what's your top book recommendation?

Sarah Wells  49:25
So the two books, three books that I always end up recommending to people, and I noticed, actually, actually, within like, looking back at your other podcast, people have mentioned them Accelerate, Team Topologies and The Manager's Path are the three that I often end up recommending to people. So I'm going to recommend something different, which is I found it's really interesting to read things that are not specifically sort of aimed at software development, and think about how they have an impact. So two that that I found Inside the Nudge Unit which is about behavioral economics in the UK Government. So it's about how do you influence people to do things. And so things like if you put someone's name in a letter, or if you say 95% of people have completed their tax return by the end of November, you kind of encourage people to do stuff. And it's much cheaper than spending money to, to invest in, in more sort of infrastructure or anything. I find it really interesting because it really when I look at it, I went, Oh, this is how we influence people within software development too you know, this is you make it attractive, you make it easy, you're your social, you use that like sense of other people. So it's good. It's a good book for that. And it's based on, there's a book called Nudge Theory. But this one is specifically Inside the Nudge Unit is more about how government used it. I just found it quite interesting. And related to that The Checklist Manifesto, which is Atul Gawande. And he's talking about how they, how they how they had a group of people who wanted to improve healthcare outcomes across the world. So they didn't want it to be about spending money, because they wanted it to work everywhere. And they found that by borrowing the idea of checklists from the aviation industry, you could make a significant difference in terms of outcomes for things like surgery. And the checklist isn't here's how you do it, it's here are things that if you do that, you may not automatically think about but that just gives you more of a chance for success. So for example, if a surgical team introduced themselves to each other, and tell each other their names before they start the surgery, it's more likely things won't go wrong, because it's more likely people will speak up when they see something. Like when they see someone trying to cut the wrong leg off, you know, it's like, you know, you know the name of the surgeon, you're able to, you're more likely, I mean, this sounds silly, but this is the kind of thing that can get rid of those stupid mistakes. So it's a really interesting book, it's not very, it's not very long, I always like books that aren't super long to read. And you can totally see again, how that impacts how you could use that in software development.

Amy Phillips  52:01
Great recommendations. Okay, so number two, then What are Who is your number one tip for keeping up with the industry.

Sarah Wells  52:10
So I just find Twitter, like Twitter works for me, like, I think you can curate the people that you follow. And it's quite sort of bite size and you see people you know, saying something that makes you think, or they provide a link and as long as you find a way to kind of squirrel those away so you can go back to them later I find I've found that a really good way for me to to keep up to date with what's going on in the industry, basically.

Amy Phillips  52:41
And then number three is Who inspires you.

Sarah Wells  52:44
Um, so I I want to say Tanya Reilly because she is so good at telling a story about technology. And her talk and blogpost about glue work is something that I recommend to people frequently because so so the idea is that glue work is stuff that's important. But it's not necessarily something that companies promote people for. So you need to be really conscious if you're doing that glue work you know like organizing stuff, fixing small problems, being the person that documents things, you need to make sure that it's recognized in your organization as something of value and you know at the Financial Times people will will say this is glue work I want some you know, I want to find someone different to pick this one up. So I think I just I really, I really like Tanya I find her like very engaging and she's writing a book at the moment about staff plus path and it's going to be excellent.

Amy Phillips  53:48
Fantastic. Okay, great. Another book. Okay, then we have our final question. This is a special one for you Sarah because we know you are a very keen cook. So what is your favorite dish to cook?

Sarah Wells  54:01
Ah, um so yeah, so basically lock down has totally got me into like, elaborate, elaborate cooking because I'm not like commuting back from London. The two things so recently pasta we've been making pasta so like actually making ravioli which has just been really good fun. But before that it was it we got really into cooking sichuan Chinese

Amy Phillips  54:30
Wow

Sarah Wells  54:30
We bought this book called Every Grain of Rice by Fuchsia Dunlop and just started cooking things from it and it is absolutely fantastic. It's really hot. Generally, like there's a lot of different chili in in the recipes but like we often cook it and  look at the things you've cooked and go. I can't believe we've cooked that it actually looks like we know what we're doing.

Amy Phillips  54:56
Okay, so then finally, Sarah, where can people find out more about you?

Sarah Wells  55:01
Twitter. So I'm on. I'm on Twitter, @sarahjwells. That's probably that's probably the best way. So I literally I literally bought myself a domain to set up a blog about three years ago and I still haven't published a blog post. So it turns out I need a deadline, basically.

Amy Phillips  55:24
Fantastic. Well, thank you so much Sarah, this has been incredible, like so many great stories. So lovely to hear about, like all the things you've achieved at the FT. And I mean, like, congratulations, I think well done, because it sounds like you and the rest of the team, but you've really made some massive changes there. So yeah, thanks for sharing about them.

Sarah Wells  55:43
Well, thank you. It's been a pleasure.

Aaron Randall  55:45
Thanks a lot, Sarah.

Amy Phillips  55:49
We'll be sharing all the links and show notes plus the all important doodle over on humansplus.tech. I'm Amy Phillips. This is Aaron Randall, and you've been listening to the Humans+Tech podcast.

We're thrilled to be joined by the incredible Kelsey Hightower!

Kelsey is a Principal Engineer at Google, an author, and a prolific speaker and tweeter of tech trends. Kelsey is a vocal Kubernetes advocate and has played a massive part in teaching the Tech industry about the power and intricacies of Kubernetes. Kelsey is also possibly the kindest and most helpful person in Tech today!

Listen on your favourite podcast provider.

Scroll down to read the full transcript of our chat with Kelsey.

Kelsey's quick fire answers

Kelsey's top book recommendation is The Foundation by Isaac Asimov.

He's inspired by all of the super ICs such as Rob Pike who had an idea and did the work to bring it to life.

The most ridiculous thing about Kelsey is his frugalness.

Kelsey has some strong feelings about pineapple on pizza. "I don't think there's anything wrong with people who prefer it. But I don't know if it's necessary."

In this episode we cover

1. How Kelsey became known as the nicest person in tech [00:01:57]
2. Kelsey's background and how he got to where he is today [00:05:59]
3. How to go from running your own company to joining the big enterprise world [00:08:53]
4. How Kelsey stays up-to-date on tech [00:12:33]
5. On how to give people advice [00:15:12]
6. Self-taught vs University education [00:19:01]
7. Dealing with frustration when learning [00:21:01]
8. Kelsey's experience of going from a data center to Principle engineer. How to move from step A to step B [00:27:57]
9. Responding when you feel like you're the token under-represented person [00:32:18]
10. The one thing Kelsey wishes everyone would take-away to help Tech become a better place [00:35:55]
11. Open Source as a model for collaboration and a framework for disagreements [00:39:08]
12. Kubernetes, and whether it has lived up to the hype [00:41:58]
13. How to influence [00:46:49]

Find out more, and follow Kelsey

Find out more about Kelsey the person in this brilliant Protocol article

You can follow Kelsey on Twitter @kelseyhightower

Full transcript

Amy Phillips  0:01
Welcome to the Humans+Tech Podcast. I'm Amy Phillips. And this is Aaron Randall

Aaron Randall  0:06
Hi.

Amy Phillips  0:07
And today we are thrilled because we are joined by the incredible Kelsey Hightower. So for those of you who somehow missed out and you're not already following Kelsey, you should know that he is currently Principal Engineer at Google, an author, a prolific speaker and tweeter, a tech trends. And he was an early voice for Kubernetes. And I think for maybe many, possibly most of us in tech, early awareness of like the power and intricacies of Kubernetes all came from Kelsey. He's also possibly the kindest and most helpful person in tech today. Kelsey, welcome to the show.

Kelsey Hightower  0:42
Happy to be here. And thank you for that amazing introduction.

Amy Phillips  0:45
So great to have you here. So one of the things we'd like to kick off with and do for all of our Humans+Tech guests, is draw a doodle for them or of them, but also for them. So we're going, Aaron's going to show you your doodle, and we'll maybe just get your your thoughts.

Kelsey Hightower  1:03
Alright, I definitely see that we're in NFT territory. So for those that can't see this, this is like something I would have drawn with my eye closed. But I can see the light at the end of the tunnel, or at least a beard and two eyes at the end of the tunnel. But you know what, these days? I guarantee you we throw this on Open,Sea, we might fetch at least $50,000 For something like this.

Aaron Randall  1:32
That's a fair, fair valuation. Yeah. And a fair critique as well. Yeah, I will confess the most people I draw end up looking like sausages with eyes. And it's not reflection on you. It's definitely on me and my drawing, but it'll take it.

Amy Phillips  1:47
It's also a bit of a test. I think of just how kind people are but you are very, very positive, nice constructive feedback. You're like off the scale kind for that.

Aaron Randall  1:57
Kind, even in spite of that drawing kind. Yeah. Great. So I actually, I want to stay on the theme of doodles if that's okay. And mention Julia Evans. So we we had Julia on the show a few months ago, Julia is the creator of Wizard Zines. I'm sure you're familiar with her work. She's an amazing doodler and amazing developer. And as I said we had her on the podcast a few months ago, and she actually brought you up. And I've got a quote here from her being on the show, which I'd love to read to you if that's okay. Julia said, "he did teach everybody about Kubernetes. Once I had a question about it, and I don't know, somehow I ended up talking to him on Twitter. And he was like, oh, yeah, your problem sounds really interesting. Do you want to get on a video chat and talk about it? And I was like, yes. Oh, my God. And we had this really helpful video chat about what problems I was having with running Kubernetes. He was so nice. And I was like, Who is this person? It made me really think about how I could be more helpful to people in the future, you know, like, he's really a different level". And I just thought, like, what a powerful thing for someone to say about someone else, particularly when they're not in the room, or they're not even there was never a plan for you to hear that. But that's what Julia said. And I love that quote so much. And so tell us, how did you become known as the nicest person in tech?

Kelsey Hightower  3:12
I always thought about, like what I wanted to be remembered for in life, you could be remembered for how much money you had. Because you can't take it with you. You could be remembered for something bad you did. Or you can have a lot of people around the world be able to tell stories, like Julia has, and I wanted to be remembered in that way. Even if I'm not the most famous person in the world, but just to authentically resonate with real people, and make things just a little bit better. That is something that I strive for, actually. And so if being nice is the requirement. Well, I find that rather easy.

Amy Phillips  3:53
That's incredible. Yeah. What a great way to think about things. Have you..has that always been the case? Like have you applied that throughout your life or like it's very much a kind of, in tech, you know, like, unfortunately, I think within tech, there is quite a lot of room for people to to be a bit more empathetic and sort of share a bit more bit niceness. But like, is this something you've you've carried with you throughout your your life?

Kelsey Hightower  4:20
I would definitely say it's something where I've gotten more comfortable with over time. And I think the requirement for most people is that you have to be comfortable with yourself and your own achievements, to find that place where you can be happy and want to see others do well. I think someone who's a parent, I'm a parent, I have a 14 year old daughter now. And throughout her life. I've always celebrated her individual accomplishments. The first time she learned how to walk, the first game that she'd ever won, that first A on the report card. And I think as a parent, you really learn how to just be happy with the success of other people even if that doesn't mean anything directly for you. In our tech careers, it's really hard because we all want that promotion. We all want to fix that bug, we all want to be known as the smart, brilliant engineer that built something so innovative, that you've changed the world. And so sometimes it can be challenging to witness other people do that, before you do it. And we tend to respond in negative ways sometimes jealousy is very strong, right? So you see someone else celebrating. And in that instant, in that moment, it's hard for you to find that happy place to celebrate with them, because you're not sure how this benefits you. And so for my career, the more successful I got, I started to realize that there will always be something to do. And so I started to try to prioritize, sharing what I can with others, and just like the parent, being extremely happy, when other people are successful.

Amy Phillips  5:59
Oh, yeah, that's incredible. Could you tell us a little bit, Kelsey, about your kind of your journey through to where you got to today? Because I think it's an incredible story. And I think the best thing I was reading, as, as I was kind of doing a bit of research today is that, unfortunately, and hopefully, like, you know, it will change very soon. But like, unfortunately, there are not that many people of color in your position. And actually, you know, what, how did you end up? Like, how did you get to where you are today?

Kelsey Hightower  6:30
Probably luck, if I'm being honest

Amy Phillips  6:33
That's probably true for all of us, really

Kelsey Hightower  6:35
Yeah, there's the decisions that you make at a certain time you're presented with situations, your preparation, plus, you know, that equals opportunity and your ability to take advantage of those things. So early in my career, when I was exposed to, you know, computers, probably through video games, like most people in the early start, and then through a technology Student Association program in high school. I was introduced to just a wide range of computing things from photography to AutoCAD. It really kind of opened my eyes that there is more than just writing code or, you know, working at a company like Microsoft, there's so much to be done. And in my early career, I was one of those people who are self taught no college degree, I reached for the IT certifications, the A+ certification to be exact. And even with that new level of skill, I was still reluctant to apply for one of those corporate jobs, right? You're looking at the job posting, they want 200 years of Java experience. They want two lifetimes of you know, Linux experience. And look, I don't have any of that. I don't know anyone that has any of that. And so like most people, I was discouraged from even applying for those jobs. And funny enough looking back on it, I found it easier to start, my own computer company, I had a small computer store in Jonesboro, Georgia. And we focus on things like service calls, we would go out to small businesses and connect their network printers, install Windows 2000. And then in Georgia, when there's a lightning storm business was good. All those 56k modems plugged into the wall, you would have 1000 customers show up like, Hey, let me guess your internet isn't working. And it will because of those $10 Win modems, right? They're like half software, half hardware, but they couldn't deal with any surges. And so I used to just keep hundreds of modems in stock and wait for it to rain. And you would get all of this business. And that really taught me this empathy stuff, customer service stuff, entrepreneurial spirit. And then eventually, I did get the courage to jump into the enterprise. And I'm skipping over all kinds of nuanced details. But that was my start into tech.

Aaron Randall  8:53
What changed to give you that courage? Can you tell us a bit more about going from running your own unique compute store to actually joining the big enterprise world?

Kelsey Hightower  9:03
I mean, five years of my life, were very entrepreneurial, in that space with the computer store the service calls, I managed to hire one or two other people to come help. I was also managing a comedian one of my good friends, Ronnie Jordan, and I was on the road I drove across the country. I've seen Ronnie perform in arenas. And I've managed a few other comedians at that time because I just took my business acumen and applied it to a different space. And I was also like the IT department for the company behind the scenes, which was Latham Entertainment. They did movies like Kings of Comedy, and there's a few others. And it was just all of this fun, but then I got married. And I was like, do I really want to travel this much? Do I really want to work this hard to try to collect invoices and bill people? Like if you've never run your own business before, there's this thing called net 90, and that's when you do the work and they pay you in 90 days. If they pay you on time. And so it's really hard being an entrepreneur because you're the last one that gets paid. And then so when you look at some of these job postings, you're like, wow, people go to one job from nine to five. And they get paid on time, every two weeks like clockwork, with no invoices, Sign me up. And so my first job was a contract to perm. And it was, you know, at Google in one of their data centers. And so I had this interview, they drill you on the specifics around Linux, and racking and stacking servers, the whole nine. And it really felt odd from going from being your own boss for five years, traveling the world seen so many things, to someone quizzing you about low level details of Linux and what it's like to populate servers in a data center. But it was a great entry point into corporate America in terms of getting a job in tech.

Aaron Randall  10:54
And how do you ready yourself for interview, obviously, the love of computers came from video games as a kid, and then presumably you learnt a lot about technology and particuarly hardware, I guess, through your own computer store. But what what was like that inflection point where you, you found you were ready for, what I would imagine a pretty difficult strenuous interview at Google to like meet the bar?

Kelsey Hightower  11:18
I think, and maybe it wasn't true at the time, but I think I got to a point where I just realized that there's no company that would be able to determine my worth, I was able to make it on my own, I was able to travel the whole country., I was able to save as much money as I managed to save at the time. I don't think I was looking for validation nor acceptance at that point. At that point, in my mind, it was like hiring other people, when I said try to get people to join my team. I'm not necessarily as the business owner doing you a favor, it's the other way around. It's a privilege to get someone that wants to come and contribute to your cause or your mission. And so then I think the interview process was very different. So it was one part, showing off my skill set, and all that I've acquired in terms of skills to that point. But also, I'm doing you a favor by joining your organization, and bringing my talents to you. And I think that bit of confidence, that bit of perspective, is what gave me the courage not to just, you know, go for that first job, but to feel confident that I could just hop around. And it wouldn't count so much against me, because I did hop around quite a bit in those early years, every six months, I was off to the next job getting that pay raise, and introducing myself to new challenges.

Amy Phillips  12:33
It's amazing. Yeah, there's the debate, isn't there of whether job hopping is a good thing or a bad thing? And I suppose like, it depends where you're at in your career and and how that looks. So it's really interesting. You're known so much for your kind of your your teaching, and I guess the the learning you do that you still do that leads you, like that people know to come to you and ask you questions like, do you? Do you have any like specific tips or techniques or things that you use to actually, I guess technology is such a broad area, such broad industry, like, how do you go about staying up to date with everything?

Kelsey Hightower  13:13
Yeah, so looking back on my career, I think I did a decent job investing in the fundamentals. You know, when I worked at Google, inside the data center, I really understood Ethernet really well. I understood how switches worked, understand how to automate, you know, level low, low level infrastructure. Pixie booting the whole nine. And then every company that I went to, I just was very patient and lived in the moment. If you do that, for 15 plus years, you start to just have this deep understanding of the fundamentals, the products come and go. Right, those things change over time, including open source projects, but the fundamentals tend to remain. And so one thing I think, that I did a good job of is keeping my curiosity as well. This curiosity to continuously learn and so you combine curiosity with a great understanding of the fundamentals, anytime something new comes out, I'm motivated, number one to pay attention, to download it, and then I can evaluate it based on my previous experience and understanding. And what I find is that even though we talk about all this new stuff coming out, the fundamentals are roughly the same. Right? They Envoy feels a lot like Nginx. Okay, maybe the configuration is a little different. Maybe the default set of features are a little different. But fundamentally, data comes in, processing the routing happens, data goes out, and I can now map those fundamentals to different tools and services.

Amy Phillips  14:44
That's quite interesting. We had a guest earlier in the year, Jon Topper who does a lot of like DevOps. And he mentioned that actually, I wonder what your thoughts on this is that younger people coming into the industry almost struggled more because they haven't been exposed to so much of the bare bones kind of foundational IT and like networking and things that perhaps everyone was forced to go through sort of 20 years ago.

Kelsey Hightower  15:12
Yeah, I think it's so important that when we give people advice, we also give them the timeline. You know, it took me 15 years to get to this conclusion, I've had this experience. So this is why my answer is of such, if you would have asked me the same question 15 years ago, I would have given you a different answer. And so even with the new technologies, I always encourage people new to the space, new to the technology, to be patient. go as deep as you can, if you take something like Kubernetes, for example, you can go super deep and learn a lot of fundamentals of a system like that. And I think it's true for any programming language or service that you're responsible for taking care of Be patient, live in the moment, and go deep.

Aaron Randall  15:57
Julia, also, has mentioned, again, a previous podcast guest, has mentioned a very similar thing to you that really resonates with that point about, like, the core concepts, don't change the fundamentals, at the same time, learn the core principles, and the rest will be straightforward. Which is the I think, such a great learning. I'm really interested, this is a very practical question. But I'm really interested as someone who is also patched about technology, like how over your career, how have you made time to pay attention to all the new technologies and the new frameworks that are appearing and kind of evaluate them and presumably, outside your day job, at times and like keep on top of those trends?

Kelsey Hightower  16:33
I don't. You know, I think about my core skill set. I think I like the concepts of computing, execution environments, operating systems, and software that runs on top. And if I keep that as my core, well, the Linux system calls haven't changed that much over the years. Okay, so I'm kind of fine there. The way we build applications, right, there are new programming languages, but in the day, they make roughly the same set of system calls. Okay, I'm pretty good there. I do like API design. So I'm very interested in things like gRPC, or the OpenAPI spec. So anytime I see something in that area, I'm quick to pay attention to see how it stacks up to the other API frameworks. Now, when we get into the front end stuff, you know, I'm just not that type of person, I don't have great artistic skills. If I'm being honest, I have no artistic skills, when it comes to the UI side of things. So I'm always curious, like, what people are able to do with things like, you know, the mobile applications, or Next.js. So I try to pay attention to my experience with those tools. I may not necessary sort of side the time to learn how to build a mobile app on my own, because I do kind of want to stay focus in my area of expertise, and then the branches. And the last thing I'll say here, though, is, I know that those things exist. So I think that's half of the battle, to at least be aware of what you're not an expert in. And then I try to find the ability to say, well, well, how would Next.js interact with things on the backend, my gRPC, or RESTful interface? And typically doing those examples helps me understand like how those technologies are related. Even if I'm not an expert.

Aaron Randall  18:20
It's great.

Amy Phillips  18:21
It's really interesting. And it seems that so much of this is linked back to perhaps the early days when you did go into IT. And that's kind of where that foundational stuff came from. I wonder if you hadn't been self taught whether you would have necessarily actually had that deep dive because I think college courses tend to be maybe broader, and shallower, perhaps discourage even that, like, find the thing you're really interested in. And it's just, you know, certainly when I was at college, it was sort of, you can pick one of these three modules, but you have to pick one, and you sort of just went through like that, that one will be fine. It wasn't necessarily what you had the passion in.

Kelsey Hightower  19:01
Yeah, I was out on a university tour. Just  earlier this week, and I was there with one of my colleagues named Bobby Allen. And he's graduated and he has a Master's in computer science. And I'm a self taught engineer. And we also got to spend time with the president of the university and some of the students there. And I remember the students all had a very similar set of questions. Should I go and get my PhD or not? Right? People like Kelsey go out here and they make an impact at the industry level. I'm ready to go do that now. And I thought Bobby had a really good perspective on this and Bobby said, and he was simplifying things here. So anyone that disagrees with just gotta listen to the analogy and the way he explains it, and I think he did a good job. At the bachelor level, you're kind of regurgitating the body of work that exists in the world. at the masters level, you're challenging the body of work, and at the PhD level, you should be adding to the body of work. in that space. So I think as a self taught engineer, it's not clear what you're doing, you're just there to solve the problem. And so given that you don't have the constraints of trying to force yourself to remember the existing body of work, you have a bit of freedom to just make it work. And sometimes you end up creating something new that no one's ever seen before. Sometimes you just stumble on rediscovering what people have already done, you know, think about the average, Google search, how to get this printer to work with my computer. And so then at that point, you're kinda in copy and paste mode, and it doesn't work. So then you get creative. Well, my situation is a little different from this one. Let me try this. And that gets you into that kind of researchy mindset. And if you're really coming full circle, maybe you're not writing a PhD thesis, but you go write that blog post to show how your experiment lead to a solution. And now you're also find yourself adding to the body of work.

Amy Phillips  21:01
Yeah, what a great way to think about it. One thing to make this apply, I suppose to a few people who are learning new things is, I'm going to assume that like everyone, there are points where it just doesn't work. You've hit that frustrating wall? How do you deal with that frustration of, you know, the docs have messed out the first three steps, and you just can't get this thing to even start up?

Kelsey Hightower  21:25
Yeah. Envoy was like that most recently. Like, I come from a world of Nginx, and Apache, and those web servers and proxies, they had a really good focus on hand written configuration files, right? They were easy to crack by hand, you could search for great examples. And I'm like, sweet, Envoy it comes out. And I was introduced to envoy via the isto service mesh. But as someone who likes to go deep, I'm trying to figure out well, how does Envoy work by itself, before we get into its place inside of a service mesh attached to a control plane? Fundamentally, it's a proxy. So I'm like, Alright, at least I can know what this is. How do you configure it? Oh, my God. This thing is like a Json scheme, protocol buffer generated thing, and I'm sitting here like, Oh, my God, all I want to do is proxy this port to this other app. Come on, this can't be that hard. And honestly, three days, I'm sitting here, like, it must be me, I must, I must be at the point where I need to retire, I am no longer confident to consider myself a technologist because I can't do this task. And I remember reaching out to people like Matt Klein, the inventor of Envoy who works at Lyft. And this is where Envoy comes from. I was like what am I doing here? he's like Kelsey, these config files were never meant meant to be written by hand, what you're looking at is the protocol buffers specification of the config, there is no equivalent at the time. And so here's how you navigate what they call the docs. And there's really just the API specification. And you have to basically take the code base, and the comments there, plus the docs and examples you found on the web to try to glue something together. And so that was super frustrating. So I had to put it down, revisit, put it down. And then I realized what service meshes were, they were basically Envoy configuration compilers. And I remember tweeting that I said, I think I finally understand what's going on here. The reason why we need isto is the only way to configure this thing. that feels like that's a good way to describe it.

Amy Phillips  23:40
I'm glad you shared that story, Kelsey, as we've been talking a lot about Envoy, and i now know we also need to consider isto at the same time. So yeah, the putting things down and coming back though. Like, I tend to just put it down and be like, Okay, I haven't got time for this, I go like, I go and do this, like nice task, I can definitely tick off the list and just feel like I've actually achieved something.

Aaron Randall  24:04
It sounds like when you talk about your experience, Kelsey that like, sort of teaching yourself and going through the self learning process and almost like being forced to go off piste taught you how to ask questions and taught you how to think outside the box, and think laterally, do you think that maybe we do put too much focus and onus on to the traditional routes through academia versus like enabling people that choose to not to be successful in tech as well?

Kelsey Hightower  24:34
Yeah, I mean, I think academia has this purpose, right? You know, it's structured learning. Some people need that because, you know, different people have life situations, they just need to get away from home. They need to get into an environment where learning is encouraged. Other people are learning. There are people who have learned things before and they know how to get from start to finish. So I think structured education is a wonderful thing to have as part of the equation, but I also tell those people that go that path You will never stop learning. Kubernetes came out when I was what 32 years old. There was no college curriculum for that at that time. So if you wanted to learn it, you would have to learn a different way of learning. So I think self taught is an everyone's future, if you want to be in this business, because that degree will be quickly outdated if you want to keep pace with what's going on in the industry. So there is no experience, like experience. So for me, my learning muscle was you could think about this you're 18 year old in 1999, small business owner, and you go out to a small insurance company and they ask you, can you run our small IT department? Can we just contract your services? What do you know about Windows 2000, and connecting multiple offices and network printers and you say, I can do the job, you show up? It's after hours, they hand you the keys? And they say, all right, hopefully by morning, things will be working, is that correct? It's like, ah, guaranteed, it'd be working. So here you are, in the middle of the night in this insurance store, or insurance company after dark trying to figure out how to hell to connect this office to this other office, and you've never done it before. And I don't know if you've ever tried to search for technical solutions using AOL. It's a very, very different experience. And so at the time, I'm sitting there, like, it's now 3am, I don't want to be the person to explain that we don't know what we're doing, and so you finally get it to work. It's 5:45am, they open at 730. So you polish it up, you step back and be like, Wow, that was way harder than it should have been. Also, I hope it works once they start to use it because I have no idea on how to troubleshoot it at this point. They show up. They sit down, they crack their knuckles, they lean back, and they click. And data comes up from the other office on this side. And you're sitting there like Oh, my God, pay me I'm out of here. But you're forced to figure it out.

Amy Phillips  27:13
Wow, that's amazing. So actually, that's an incredible, like, the best way, I think, to learn how to use the web, like at this sort of similar time I was at university. And at that time, sort of early days of search engines. And we used to get asked as part of like modules to be like, prove you've searched three different search engines for this information. And that was like, you could search whatever you wanted, you didn't have to find a solution. You certainly didn't have to do anything with that information. So yeah, it's like the real world, things definitely give you quite a lot more. It feels like that's a story straight out of the Phoenix Project as well, like.

Aaron Randall  27:57
I'd love to go back to your contract role at Google. So that your first entry to Google I guess your first role there. And I'm sure plenty of people listening, are really inspired by your career and where you've got to and the position you hold today. And wondering how you go from that first role in a data center Google as a contractor to someone who has such a high profile and respect and status. What What's the advice you give people for that bit in the middle the magic that takes you from Step A to where you are today?

Kelsey Hightower  28:29
Well, for me, I think just putting myself out there. In order for people to connect with the stories, you have to tell them. And so if I never spoke at that local meetup at Georgia Tech in Atlanta, to talk about Python iterators versus Haskell iterators, maybe I don't have the courage to get on the larger stages. And so I think it's all about telling your story. And honestly, when I look back, I was telling my story, as I was going, every meetup, every spontaneous Q&A session, every podcast, every blog post, I was always telling my story, and I got really comfortable learning in public. And so then I was open to sharing, I was open to getting the feedback that yeah, you don't quite understand yet. Take this new advice, and then see where you land. And so I think when you no matter where you start, your story is important. If you're a flight attendant for 20 years, and then you decide to get into tech, well, there are people who also want to understand that story, and only you can tell it. I think that's the biggest thing that we all forget. We believe that there's only a subset of society that is qualified to share their expertise. But the truth is, we all have these very unique stories. And so I think learning how to communicate, learning how to tell my story in a way that was authentic. I stopped worrying about being right, and stating the facts. And then I started to spend more time being authentic and honest. Here's my understanding of the problem. Here's what I think about the solution. And I think people find a way to resonate with that it just feels honest, it feels like I'm listening to the person, not necessarily the marketing material, or what you would like me to know. And so I think that has been the key throughout my career is figuring out how to communicate.

Aaron Randall  30:32
I mean, it's really inspiring. You know, on the one hand, it's very inspiring, I think, wow, I want to be more like that. On the other hand, you know, talking to you, it's clear that you're alongside being honest and learning in public, you're a very smart person. And I'm sure that if I tried to be more honest and more in the public domain, I'd be making plenty of mistakes. And people would there'd be more people to see me fall. Have you? Did you experience that? Did you? Did you make mistakes in public? And what did you do about that?

Kelsey Hightower  30:59
It turns out, most people actually want to do the right thing. Most people want to be helpful. I know it's awkward, because in society, if you say hi to a random person, they go into defense mode. But truthfully, if someone were to fall, the average person would reach out their hand to catch them, or to help them up. And so in tech, typically, if you're not arrogant, are not an asshole, if you're a person that is being honest, and asking honest and authentic questions, and you're wrong, most people would jump in and try to help. And I noticed that as I was not afraid to learn in public, people would always reach out and say, hey, they might even DM me and say, Hey, you don't have that part quite right. Here's how it works. And I'll ask, Hey, do you have a moment to jump on a hangout, so I can take notes and dive even further. And then I was always intentional about returning the favor. If you ping me, and I can do anything to enrich your understanding of something, then I would go out and do that. So I think the concept of becoming smart is understanding that there's always something you can learn and being willing to learn. And then you'll see the teacher show up.

Amy Phillips  32:18
Amazing. Yeah. And on the sort of telling your story and getting comfortable telling your story. Like I think one thing that's so amazing is that like, you're so well known for tech. And I think one of the things I see in a lot of like women in tech, and there's a sort of these subsets and you can be you can be famous for being a woman in tech, not necessarily, you know, no one respects the tech you know, Do you have any and I think that's probably like many people in this sort of minority groups end up shouldering this burden of educating everyone else, doing all the inclusion work. But for you like I guess, firstly, I suppose has it been intentional that you've sort of very much tried to stay in this sort of like, I'm a tech leader? And do you also have any sort of tips for other minority folks for how they can perhaps escape that like, hey, just you're here as the token person?

Kelsey Hightower  33:17
Yeah, this is a very big challenge, because different groups may have no experience with other groups. And so for them, you've been described by the media, you've been described by a television show, you've been described by their family members. And so for them, they think they know who you are already. And if the thing that you really are a software engineer, a product manager, a QA person, or person who have invented their own programming language, that's not in their list of categories that you can even be. And so when they meet you for the first time, or they see your name on a conference proposal, you don't look like you belong in that scenario. And there's been a time even after I was a well known keynote speaker, and it was a very technical conference, I won't mention the name. And it's one of the first times that my CFP, you know, talk proposal got rejected, and I said, Oh, maybe it wasn't any good. Let's just leave it at that. And then I remember getting an email a few weeks later, they said, Hey, we noticed that we overlooked your proposal. Would you like to come speak at the conference? Now at that moment in time, I looked back at all the previous speakers over the years. This is a very popular conference, by the way. There was no one that I thought looked like me, or for most underrepresented groups ever at that conference. And I was wondering to myself, did they just need me to be the token speaker to fix that situation. And I thought about and I wrestled with myself and I say, You know what, I'm going to do it, token person or not. And I'm going to show people why this should never be a problem for anyone else again, I remembered that talk. And it felt so amazing. I gave them every aspect of Kelsey every aspect of my culture, every aspect of my expertise. The live demo was crisp, I showed the code I showed the concept, I showed the mastery of those concepts. I left no stone unturned. It can be entertaining, it can be educational, I brought a bit of swag to the stage to say, Wow, this is what we've been missing. Is this what that is about? So it sucks that we have to bear that burden. But again, it's amazing that I have that opportunity.

Amy Phillips  35:55
Yeah, that's a great way to think about it. Yeah. Sometimes you feel like really? But yeah, you're right. Like, that's the moment prove to them what they've been missing. Is there, I mean, I suppose like, for anyone listening to this podcast now, like, not necessarily just about, like, you know, like, dealing with race and sort of like, underrepresented people, but like, you know, also learning and empathy and helping people. Is there one thing that you actually wish everyone listening to this would, would take away and, and try and action to make tech a better place?

Kelsey Hightower  36:33
I think people forget, you're human first. It's such a simple, simple concept. You're a human first. And you're all connected. You're no better than anyone else. You're no worse than anyone else. Yes, you're sitting in first class, and you probably paid $10,000 for that nice lay-flat seat. But the pilot controls your destiny. They decide whether we land safely or not. And so as a human first, how hard is it to think about just treating people with respect by default? How is that really so hard? If someone is in need of help, can you just not extend a hand. Is that really so hard. And I think society has created such a fear based system, where you're always scared that you don't have enough, you could win the lottery for $10 million. And you'll be afraid that you won't be as comfortable as you need to because you're not a billionaire. Look at that. That's crazy. And so I think I wish people would just spend as much time learning Python and TensorFlow and machine learning as psychology and human and mental health, and what it's like to be nice, what it's like to be kind. What is it like to build a really healthy society that challenges the old norms. You don't always have to fear the unknown. Sometimes, you can just work hard to understand the unknown. And if you're in tech, listening to this, you do this all the time. There's always a new programming language, there's always a new outage. And then we spent all this time trying to study why it happened, and how to prevent it from happening. And then we go the extra mile to build tools to encode our learning into the platform. All right, let's do the same thing for society. You can go to the school board meeting, and have questions about the curriculum, offer to sit in on the curriculum planning, you are human with this elaborate set of skills. Twitter is not your only course of action. shitposting is not your only course of action. And so I think as you realize how much power you have, as an individual, as a human that's connected to everyone else, I just wish we would celebrate that too. Stop calling those soft skills when it's the hardest thing to do.

Aaron Randall  38:50
I love that. I think that, you know, that's a really profound sort of societal lessons in there, particularly the new teaching treat others like humans. If you if we zoom into the tech community that we're all a part of here. How do you hope the tech community can like change over the coming years?

Kelsey Hightower  39:08
You know what I think the tech community has done a good job, the power of Open Source, just looking at 20 years of my experience in open source. Most people cannot understand this. People who've never met, not even clear of each other's interests can find common ground, gain consensus, write the code, merge it and everyone else benefits. This is this is a mind blowing concept. It is almost like this utopia of humanity where really, we can find common interests, solve common problems. And if we have a dispute, we actually have a framework to deal with it. It's not war. You just click the fork button. And then you can start a new branch, and we've all witnessed communities split apart and come right back together. That is we're not always gong to agree on everything, but we need to have a framework for disagreeing, trying out these separate ideas, and then taking the good parts and putting them back together to continue the whole thing going. And this happens a lot in the open source world. So I think we really have to understand as a tech community, why does it work so well in open source? And I think there's some things that a lot of companies miss. So a lot of us are technologists typically are employed by a company that pays us to use technology for their goals. But one thing we forgot is that this open source mindset, it's so beautiful, there is no promotion process. In open source, there is no system, software engineer level five versus the level seven. So we don't even ask those kinds of questions. If you can contribute, we welcome your contributions. If you have a question, if I have answers, well, we're happy to create these communities of answering and leveling up other people to contribute. That is something I wish we would actually study. It's actually here already, this is not a fictitious one day in the future. This is right now, there are hundreds of 1000s of projects that exhibit this behavior. Now, what we have to understand, though, is just like any society, there will be bad actors. One thing we have to be cautious of is not allow people who are bad actors to have excuse because they write the best code. That's unacceptable long term. And it's going to hurt your community overall, if you reward that behavior. So I would just like to give a big shout out to the whole distributed, open source ecosystem, all the people who participate and have made that thing sustainable to this point, that is something we should look forward and be proud of in the open source community, there's still work to be done. Not saying it's 100% solved. But it's a framework that allowed me to get started in a way where the gatekeepers were not allowed to build their moat around it. So I'm really appreciative of the open source movement.

Aaron Randall  41:58
That's a it's great. It's so nice to talk about open source in that way as well. I'll be honest, I haven't thought about it like that. And you're right. It's, it's a it's a profound way of working in many ways. And it's still in the open source theme then. So obviously, you've been a vocal Kubernetes enthusiast since the beginning, do you think that it's lived up to the hype?

Kelsey Hightower  42:21
So there's the hype of, in the hype, let's talk about when the hype came, because it wasn't always hype. When Kubernetes came out, I was working at CoreOS. And we were building our own Kubernetes like thing called Fleet, hashi Corp was building Nomad, Docker was building Docker Swarm, and Mesos was the big elephant in the room. So people saw early days of Kubernetes was like, Oh, my God, that's cute. Google thinks that they're going to enter this space, there's enough competition, it ain't gonna happen. And so it was more like, this is a little side project, people were just waiting for Google to become disinterested, and abandon the project. And so in those early years, there was not a lot of attention in what we will call hype. Now, once we start to see it working, and some people would say I had a little bit to do with that, these these things, where we're showing people it working, here's what you're doing now. Here's what Kubernetes does. And it was so authentic, it was so close to the actual problem. There was no additional marketing, it was just authentic, bringing people in who understood the problem space. And then eventually the hype came. Right? People starting to say, Oh, this is the new Linux, this is the new foundation. This is the new land grab. And so then we started assigning this term Cloud Native and it's a term that existed before but it was re, it was revitalized through this Kubernetes pipeline. And every company was like, Oh, here's the same thing, but cloud native, and it works on Kubernetes. Kubernetes, is going to cure cancer, you broke your leg, you could open up a jar of Kubernetes sauce and rub it on your leg, and it would just heal itself. And a lot of the practitioners like what are you talking about? That's not what Kubernetes does. And people's like, it will do it though. And so we lost the narrative. So that hype became it's going to be the cure to the cloud is going to solve private and multi cloud, it's going to solve everything. It's not what it does. It's just not what it does. It's a thing that layers on top of the fundamentals, VMs, networking load balancers. That's what it does. It layers on top. And what it really does, it gives us a contract on how to utilize those things. In the wild wild west of random API's. Kubernetes came and gave us a unified view on that type of architecture, the practices of a decade ago, we finally serialize them to an open source project. And we did it in a way that it was extendable that people can add their own new types, their own new workload types and abstractions. And that's what Kubernetes is. And so did it live up to the hype? I think where we're at now is we got to the peak of that curve. Everyone's promising all of these things, but at the same time in parallel, there's another movement that's happening, which is a Serverless movement, and managed services is saying even if Kubernetes is perfect. Why would you wanna run this stuff yourself? So now Kubernetes is running up to a new challenger. It came and challenge other systems. And right in the middle of its own lifecycle, there's a new challenger was saying, but why would you want to. And so I think that has humbled the community. And now we're focused on real problems, again, like day two, configuration management, and security and scalability and integration into our workflows. And now we're back into that comfortable place, we can tone down the buzzwords and get back to engineering.

Amy Phillips  46:00
Yeah, that's incredible. I love that. That's a great story. So I mean, you mentioned there that you certainly, were one of the kind of the voices that did sort of alert people to the power of Kubernete at the beginning, and like the, you know, like the the fact it was interested in was solving real problems. So and I think that really highlights like how much of an influence you are in the way that kind of like shaping how people are thinking about tech, like, what, like, what have you learned and kind of your journey of reaching that level of influence? Like, how can other people, especially without kind of like any implicit kind of authority, you know, not managers, or anyone with a sort of an assigned job title, but how do people actually reach that level of influence?

Kelsey Hightower  46:49
Well, it's something that is given to you. People give it to you. You don't you don't choose your Twitter followers, they choose you. And what happens is, why did they choose you? Now, you could build a reputation on being the person who's angry all the time and talks about that everything sucks, and it should be burned down with no solutions. And then that will become unsustainable, no one can be mad all the time. And so for me, it was just more of this authenticity, like in the early days of Kubernetes, I remember diving deep into the codebase, doing minor refactorings here and there being part of the engineering session is to say, Hey, back in the day, the Puppet Agent had this authorization flow, where it could join the puppet cluster, by using this tls certificate management workflow. We should do that in Kubernetes. And then it becomes true, building some of the components, you know, a lot of the prototyping and showing people what if this existed, and doing it in a way that people can touch and you're standing on stage, and they're looking and saying, Wow, I'd never thought of it that way. And I've been comfortable with the person to create the prototype, show what's possible, and then falling back and letting someone else take it and run with it and bring it to production. Because I think we need a whole community to do this. But I think you have to ask yourself, what place do you want in that influence? You know, because there's a lot that goes into it. And so for me, I prefer telling stories and inspiring people into action. Can't make anyone do anything, I'm not your manager, I'm not your boss. But if I show you the art of the possible, and it's authentic, and you can see yourself doing the same thing, well, you tend to nudge people in a certain direction.

Aaron Randall  48:31
And that is a fantastic place for us to wrap. So unfortunately, we are running out of time. But what a great point to end on. Before we do go before we let you go. We do have four quickfire questions we love to ask all like Humans+Tech guests. So I'm going to fire away and interested to hear your answers on these. But for question number one, what's your top book recommendation?

Kelsey Hightower  48:55
The Foundation by Isaac Asimov. That was the first sci fi book that I read nonstop into in all the plot twists, the study of human psychology with a technology undertone. I just thought it was a masterful way to think about society, in terms of like the big picture over like 10s of 1000s of year period. So it's an amazing book. If you haven't read before you go watch the series on Apple TV, I would recommend the book first.

Aaron Randall  49:22
Haven't read it but added to the list for sure.

Amy Phillips  49:26
Sounds great.

Aaron Randall  49:27
Nice question to who inspires you in tech?

Kelsey Hightower  49:31
Well, there's lots of people that inspire me, but you know, I really gravitated to the likes of people like Rob Pike and all these what I call super IC contributors. it's all these people who had an idea and they did the work to see it come to life. And they stuck with it long enough for people to grow a community. I think there's the same as that. Some people have ideas and some ideas have people and so when you can take an idea and turn into a community. I've always been fascinated by the technologists who've managed to do that.

Aaron Randall  50:07
Question three, what's the most ridiculous thing about you?

Kelsey Hightower  50:12
I am a minimalist. And it's, it is ridiculous how frugal I am. I mean, it is, you don't understand. It's ridiculous. Like, my wife is like, Kelsey, this is ridiculous. And this, the reason why it's ridiculous is that there's no reason for it. at all, it's just very extreme frugalness. And it's, it's beyond cheap. It's frugal. It's this, this this weird thing that I'm with. And it doesn't make any sense. Like, I'll have a $4,000 laptop. But I'll be concerned about paying 89 cents for a snicker versus 88 cents at Walmart like that penny means a lot. And I don't want to waste the money. And so there's this thing where it's not necessarily balanced. If I don't assign value to something, I am definitely not the person just to ignore its costs and move on, even if I can afford it or not.

Amy Phillips  51:06
I think not sounds very sensible, personally, but I think I'm in that camp as well

Aaron Randall  51:13
resonates with you. Great. And final question. What are your thoughts about pineapple on pizza?

Kelsey Hightower  51:20
I used to work at Pizza Hut in my last year of high school, and I didn't understand I felt Why? Why do you need it on the pizza? Tastes all right. It is not great. By the way, it's not something that I would reach for. So look, you know, I don't think there's anything wrong with people who prefer it. But I don't know if it's necessary.

Aaron Randall  51:43
Well that is a firm answer, and I respect that. And you're speaking from a position of authority. So we'll have your word on pizza? And finally, where can people find out more about you?

Kelsey Hightower  51:54
There's this amazing Protocol article that just talked about my career. They interviewed some of my friends throughout my lifetime. And it's on Protocol, it's a tech news outlet and it just cronicals, my kind of journey into tech from McDonald's to where I am now. That's a good place to kind of learn more about Kelsey the person and I'm always on Twitter, sharing a variety of ideas @KelseyHightower, my DMs are open. And I tend to engage with people when they do reach out. So that's me.

Aaron Randall  52:23
Amazing. We both read that protocol articles on it is great. I can confirm. Amazing Kelsey, thank you so much for taking the time to talk to us today. It's been an absolute pleasure and loved hearing your story. It's been a lot of fun. Thank you.

Kelsey Hightower  52:35
Thanks for having me.

Aaron Randall  52:38
We'll be sharing all the links and show notes plus the all important doodle over on humansplus.tech. I'm Aaron Randall. This is Amy Phillips and you've been listening to the Humans+Tech podcast.

We're excited to be talking to the one and only Michael Lopp, aka Rands from the incredible https://randsinrepose.com/. Rands is an engineering leader at Apple, having previously been VP of Engineering at Slack, head of engineering at Pinterest, as well as being the author of a number of amazing tech leadership books, including Managing Humans and The Art of Leadership, small things done well.

Listen on your favourite podcast provider.

Scroll down to read the full transcript of our chat with Rands.

Rands quick fire answers

Rands recommends reading Boyd: The Fighter Pilot Who Changed the Art of War, or if you don't fancy that read Bird by Bird [00:48:57]

Steve Jobs inspires Rands [00:50:11]

The most ridiculous thing about Rands is his love of American sliced cheese, the really bad kind [00:50:51]

In this episode we cover

1. Surviving the fall as a new manager [00:01:30]
2. Rands's vision of feedback [00:09:51]
3. Working with people who have different communication styles and the post Rands wrote about it, Lost in Translation [00:14:20]
4. Why and how to Say the Hard Thing [00:21:37]
5. Hearing the hard thing and the three types of feedback [00:28:34]
6. How introverts can level the playing field [00:40:55]
7. How to manage your energy as an introverted manager [00:44:08]
8. The OODA loop [00:48:57]

Find out more, and follow Rands

Rands in Repose

Rands Leadership Slack

Full transcript

Aaron Randall  0:01
Welcome to the Humans+Tech podcast. I'm Aaron Randall. And this is Amy Phillips.

Amy Phillips  0:06
Hi.

Aaron Randall  0:06
And today, we are so excited to be talking to the one and only Michael Lopp, aka Rands. Rands is an engineering leader at Apple, having previously been VP of Engineering at Slack, head of engineering at Pinterest, as well as being the author of a number of amazing tech leadership books, including Managing Humans and The Art of Leadership, small things done well. And of course, we'll all know him as well for his excellent blog Rands in Repose. Rands, welcome to the show.

Rands  0:31
Great to be here. Thanks for having me.

Aaron Randall  0:32
Thanks for taking the time. So one of the things we like to do with all our Humans+Tech guests is to draw a doodle of them. I'd love to show you yours and get your thoughts and feedback.

Rands  0:43
Great. Let's start there. Let's do it.

Amy Phillips  0:46
So hopefully, you can now see the masterpiece.

Rands  0:50
Oh, lovely. I really love that you did the gradients and all of the detail, I think the beard, the beard is good.

Aaron Randall  1:07
I'll take that. My work has been described as a sausage with features. And I regret now not drawing, now I can see you wearing glasses. I should have put glasses on.

Rands  1:18
Yeah, you should have done. But I mean, it looks like it was like a weekend of work here. Right? So

Aaron Randall  1:24
1000 hours? Yeah,

Amy Phillips  1:30
So. That's the important important stuff covered, we can get down to all the secondary stuff. So Rands, you've written a number of posts about making mistakes, and particularly how new managers can drastically overestimate their abilities. And then they sort of inevitably go through something you call The fall. Can you tell us what you mean by the fall?

Rands  1:51
Or the new manager death spiral. It's really, the core of this is sort of this belief that when you become a manager that like, well, now I'm in charge, so I have to be right all the time, which no one would actually think is like a reasonable thing. But it's kind of like irrationally, what you think when you're sitting in that meeting or on that, on that zoom call, or Google call or whatever, and kind of like, everyone's kind of looking at you. And it's, there's a lot of pressure there. And that's, it's inevitably people try to never be wrong. And like, I think it comes from a good spot. But like, you're going to be wrong 50% of the time, like you're going to miss make mistakes a lot of the time, and rather than sort of obsessing about sort of the failure and the lack of, you know, confidence in those sorts of things, that the thing that you need to get your head around is that number one, that's okay. And number two, and this is sort of how you, you get to it being okay, is you understand that, even though this sucks, and something did some commitment was not made or some failure occurred. There's just incredible value in that thing occurring. And the sooner that you mind that uncomfortable, horrible situation for that learning, the less the more that you kind of see failure is less of this punishment, or this thing that you're letting your team down or, or whatever, and more sort of like, Okay, well, that sucked. And I never need want to do that. Again, I think there's just a lot of new manager thing, manual things that new managers do that, like not wanting to fail, that just sort of contribute to sort of an inevitable sort of, I call it the new manager death spiral where they just kind of, they just they start to, they don't ask for help. They don't delegate, they think failure is not an option. And these things just turn into sort of this weird situation where new managers, especially new managers, I think our engineers are not necessarily predisposed to be great with humans. It kind of turns into a nightmare scenario. So and you think it's only at the beginning, but I've done it several times over the course last 20 years.

Aaron Randall  4:08
And what what can you tell us what your first sort of great fall was the first mistake, a big mistake you made as a manager?

Rands  4:15
I don't think was the first but it's the one I get asked in a version of this question. And so when I think of this engineer at Netscape, and this is my first couple years as a manager, she was she was asking for feedback. And I'm like, absolutely. And this is literally just starting as a manager, and I, you know, I did the most vapid, worse version of this typed up stuff of sort of recollections in the last month or so. And I looked at it and I was so proud that I type some words like, yeah, and she read it and her reaction was just exactly what I wrote, which is, she was nice about it, but she was just like, there's nothing here. That's actionable. It doesn't reflect reality. And this is most of the conversation where you're helping me grow. And it was absolute F. And I only, like at that moment when I realised what the responsibility of feedback was, especially in this sort of review scenario where it's like, No, no, no, no, you don't get a phone. This is This isn't like YOLO, knock some words together and say something that is trite and pithy. This is like, this is a huge amount of work, and you fail on this thing, and eroded trust with this person, etc, etc, etc. So it wasn't really just, it wasn't like, you know, the product didn't ship it was just letting the team down. And it's why I've, since then, I've just gone incredibly deep on feedback, not just being a part of reviews, feedback, being a thing, I'm always doing feedback never being a surprise and feedback being this. You know, it's the pithy thing is, it's a gift. And it really is, is when you hear it, you kind of like, oh, cool, a lot has something to say about this that's relevant to how we're doing on the thing, as opposed to like, Oh, geez, I'm in trouble, because a lot has to be back for me, right? So it just really pivoted my perspective around the craft of feedback. And how important is to building trust in a team? That was a good answer.

Amy Phillips  6:14
There are so many bit's I've written down. But what I did want to just touch on was you mentioned about eroding the trust?

Rands  6:25
Yeah.

Amy Phillips  6:26
How do you how do you come back? Because I think there are, I mean, we probably do this all the time, right? Say the wrong thing at the wrong time, or in the wrong way? So how do you recover from a time where you actually have eroded the trust with your team or with a person.

Rands  6:43
Let me let me talk, let's talk about the new manager perspective around that, which is the belief that you like for this case, we just talked about with me giving bad feedback. I just felt like she didn't trust me at all. It wasn't the case. It was a bad moment. It was a erosion of trust. It wasn't a deep it was it wasn't gone. But so that's number one is not to think like it's a switch. You weren't asking this, but like, like, like, like, all right, I am no longer credible. It's like, No, you just have a ding here. There's a black guy here. So in the The answer is, is super easy to say. But it's hard to do, which is whatever that thing is that I screwed up on. What did I do with that? With that employee for the next year, we talked feedback every month, for 12 months, I kept a running log of how things were going. And some months, I had a lot of things to say. And some I'm like, this is kind of the same stuff. But I just demonstrated over time that I was gonna be consistently good at this thing. So you'd have to ask her whether I succeeded in rebuilding trust. But I know, month 12. It was like, when we when I did the review. And this is where you want to get with reviews. The review was boilerplate. It was everything we'd already talked about a million times. And it just happened to be a time where there was money or whatever was going on. And but it was like, we're like, cool. We do this all the time. This is where we're at. And this is the current plan for you to grow. And well, why is there any questions about this? Like, no, that's right. This is what we're doing. So that was that was like joy that she just expected that the feedback was constant and useful.

Amy Phillips  8:18
Did you acknowledge the fall to her? Like, is that something which you actually? Yeah. How did that go? Like? Sounds as bad as the fall itself.

Rands  8:33
All the stages of grief. What happened afterwards? I think I was defensive when she was like, This is garbage. I'm like, No, it's not I work hard. And whatever. The first time back, when I'd kind of redone it all. I just, I apologise. I was just like, that was really poor. And here's my new strategy here. Here's v2 of what I consider to be the feedback here, I think it's probably this was a Python was an F, this is a B, and but more importantly, this is our This is now our playbook every month, we're going to go back to this I'm going to talk about you have these things that you want to over your career. I am going to work with you every month and get you there over time. So it was it was hard. But it was just back to the first question. It was sort of like, it wasn't like this, I'm not gonna get punished. I mean, I mean, I was punished myself worse than maybe she was feeling bad about me as a leader. I don't even know. But it was it turned it into literally why this answer is good is because I have a very articulate vision of what I think is important about feedback now. And it came from screwing it up so badly. So it was it was hard to tell her but it was I think the time before talking it was worse for me when I was like, I'm super horrible at this like how am I gonna get better?

Aaron Randall  9:51
Can we can we talk specifically about that? What that vision on feedback is now like, I'd love to hear your learnings about how you got to a good place with giving great feedback.

Rands  9:59
I was writing about it this weekend, I, the way I start with someone is I kind of say, I ask  this question, which you probably read somewhere and something I've written in, which is do you want to be when you grow up? And everyone smiles? And they giggle a little bit when they hear that? And they like, what? And I'm like, No, no, no, what, and I don't whether you're right out of university, or you're 30 years into your career, I'm interested in your answer. And if you just want to have a fun little conversation about becoming a writer, super, let's have that. But at some point, I'm going to scare it to, what do you want to do? And they're gonna say, Well, I'm not sure I'm like, Okay, great. Here's the path. And I have a whole model of sort of growing leaders, which is, this is a long Holmes time do we have like, there's a path to CEO, there's a path to CTO, there's a path to VP of engineering, there's a path to kind of chief architect. And then there's a whole nother path of, I don't want to do any of that. But I would like to work on leadership skills that doesn't have one of these three letter acronyms next to it. So. And all of those are valid paths. Now I say those and it feels saccharin and sort of opportunistic to be like, you know, you want to be CEO, let's go figure out how to do that. You got to remember the last eight and a half years before going to Apple, all of these people that were talking about CTO VP, were real people. And I could point out and say, like Stuart's like this, or Cal is like that. So I could really actually have a conversation because they've seen those people working and doing their thing, and saying, cool, cool, like, and then we have a conversation about what it means to be a CEO, CTO, VP, and kind of say, Okay, what are the things that you Where are your gaps, relatives that are sort of the heading in that direction, whether you're interested in management, a very seasoned manager, and we just have a conversation to kind of figure out what are the things to put them on the this sounds really easy. This takes multiple conversations over time. But we start to just figure out, Okay, cool. You really, really love banging on the keyboards and building things. And you're always right now you believe that's always what you want to do. But you want to talk about leadership. All right, that is probably, I could see that being CTO, I could see that being architect, I could see that being individual contributor plus leadership, like, Great. Okay, let's talk about those three. Talk more, more, more. Alright. So no, I don't ever want to play politics. No, I don't want to all this other stuff. All right, we're kind of leaning towards more of the IC plus leadership role. So it's this winning, it's this edgy winnowing and education process to try to figure out where we're going to head there. And then eventually, we, we sort of say, okay, cool, you eventually kind of want to be a VP of engineering. So you want to, you don't want to build the machine, necessarily, but you want to run the machine and you want to run the humans there? What are the skills you're going to need? And how are we gonna get you there? And, again, it sounds all really aspirational. But it could be boiled down to, you need to work on your presence in groups of people. Where can you can you run a meeting? Can you give a presentation, there's this there's this marketing, good marketing aspect to being a VP of engineering, which is being out there and communicating at scale. You don't have that right now. Cool, let's go figure out how to get you to do that. Like these are the things opportunities, I see over the, you know, the average slack year or Pinterest, year or whatever, that will sign you up for that and get you those those, get the experience in place. So you can kind of work on it, and then talk about it every month.

Amy Phillips  13:28
I suppose there a whole load of translation that comes in on that as well, right? Because the hardest is the translating that into reality. So

Rands  13:37
it is it there's but there's also once you kind of have a rough contract signed, you, I may not be able to come up with the things you need to do right now. But once I know that, that Mary is really interested in this type of leadership development, I am now on the where one of my new project is showed up. I don't have time for Oh, this is perfect. This is a perfect leadership exercise for Mary, right. So there's also just an opportunistic thing that you're doing as a leader all the time, I'm sort of looking at all the people and all this stuff and kind of shifting things around. So it may not be like definitive at the moment. But again, with iteration with time, you can usually find things to translate it into an action plan. Right?

Aaron Randall  14:20
So glad to use was a translation as well, because then we're talking it's the another blog post called Lost in Translation where you give examples of work with different types of people with different I guess, personality types. Can you talk us through kind of situations where you've had to work with people that are very different to you personality wise and how you like, bridge that that difference in in character and way of communicating?

Rands  14:45
I was literally in a meeting this morning, where I needed to remember that article. It's a I think the rule is that different humans hear things in very different ways. And what you think is just a throwaway sentence in that status report, or that Slack channel can trigger someone else really, really badly. And you don't even know it. So it's in, it's just like these things, especially in a time of slack. And we're all distributed. And there's all these communication via the wonderful tools like Slack, it's just, it's even more important to kind of understand that. Anyway. Number one is being aware of who having the reading the room having the situational awareness to know, I'm in this meeting with seven other people. These are, these are, these are important people who are going to take this message, and you're going to share it with a lot of other people. So I'm making this up right now. But it happens all the time. And which means the casual YOLO conversation, where I'm just being lop, rands, whoever, and kind of just shooting from the hip, not the right move, because everything that I'm saying, is being taken, interpreted and fed into some other grapevine or thing elsewhere. So there are these moments where you know that every word matters. And it's not just every word, it's also saying the thing. Hey, Ted, this is what I think we should do about this problem here. In Ted goes, huh? Yeah. And I'm like, tell me what you just heard. And it's one of my most powerful tricks is going back to me because he says, You said this. I'm like, I didn't say that at all. And I could tell by the way, you were nodding at me that you were half listening, and you didn't actually hear what I said. And you have different values and different things that you want to do. And Ted's amazing, by the way, but he says I don't I'm like, that's not what I said, I said this, he's like, oh, no moment, there's so there's this, there's this game, it's not a game, it's a very important thing, but of knowing where you are, knowing how you're communicating, know how and your partners in this situation are hearing, checking in error correcting, reading the money being notes after because someone's definitely taking meeting notes and reading it going? Nope, that's not what I said over there, or that was nothing but I want capture there. So it's it, I joke, that like a huge amount of my job is moving piece of information a from position one, over to position two. That's like most of my job, especially in a larger company. It's this information economy. And I've got a bunch of it, and I'm selling it and I'm buying it. And I'm trying to like keep track of it all the time. I don't know the answer your question. There's so much to tell you.

Aaron Randall  17:47
I've got about 100 questions to follow on.

Rands  17:52
My other thing is I always when I hear something, and I know it's one of these sort of important moment meetings, I always say, hey, what I heard you say was this, just to make sure that everyone is signing the same verbal contract by what is being said and heard.

Aaron Randall  18:11
I love that, I use that as well actually in one on ones like back to people to like in reverse to make sure that I'm understanding what they're saying as well as, like, as just generally.

Rands  18:20
It's complex and also, when it's contentious to right you're like, like, like, that didn't strike me quite right. You mean this? Oh you really did mean that okay.

Amy Phillips  18:35
What about with people who actually have, like, very different styles? Like, do you get any sort of resistance to your kind of communication style and delivering information in that way?

Rands  18:48
There's definitely the humans that communicate in a very different way. Like there's in you, again, reading the room, you've got a note, there's like the literalists out there, they're like, that are super mad about that, that should have been a witch. And by the way, like, it seems trivial, but it's actually a big deal about bringing clarity to communication, but there are there like, folks out there that are that kind of, you know, amped about it. And they, it's not really as much. When you say resistance, what I hear is sort of like, I'm saying these things, and they're not hearing it, I I will quickly deal with that. It's more just having a good sense of the humans that are around me, and knowing how they need to hear things and being aware of that. So that person that we're thinking of, you're thinking of and thinking of that's like, I know that you know, something I do with folks like that is I tell them beforehand what I'm going to say so that they feel like they're part of it, and they're not sometimes I was like, No, we can't do that ever, because engineering is hard, I will actually give it to them beforehand to both hear their feedback, but also to make it so that when they're in that social setting where they're normally just sort of like the, you know, we can't do it, folks, they're already on my team, they've already been a part of it. So they're in that's just one of many ways to sort of deal with the folks that are, you know, different than AI in terms of how they communicate and how they get things done. So it's being aware of those folks and having whatever interface mechanism that you have to build for them. Because every time it gets like, when I'm in that meeting, and I'm kind of riffing on this now, where someone's like, just blocking, or you know, they're mad about something, it's there's something there, which is real, but irrational and has nothing to do with the topic. It has to do with something else. That is a thing that I or their manager, or if their work for me have to go and actually figure that piece out. Because they've been there's, there's something else that has nothing to do with this topic. That is, it is the issue, if that makes sense. We are a super hypothetical mode now.

Aaron Randall  21:05
I love that, that idea of like, I guess like giving context ahead of time bringing them along for the journey and kind of like getting buy in I definitely, I've seen teams where if you give people enough context and autonomy, autonomy, like they really can hop on board straightaway and crack on with that horrible difficult problems. Like give them a surprise and say, this is the thing you need to do. It's so different, right? I love the way you articulate that.

Rands  21:29
Lots of lots of failure that has given me this strategy.

Aaron Randall  21:34
It's a great learning.

Amy Phillips  21:37
It also something it made me kind of think of your Say the Hard Thing, posts as well. Which is one of the hardest things like what's your like? Well, firstly, could you talk us through like, what is Saying the Hard Thing? And then like, how do we how do we actually do that?

Rands  21:53
Yeah, it's so you got this person, you're working with Frank, and he has this behaviour that is suboptimal, whatever that thing is, and you know it almost instantly. But you've worked with him beforehand. He's a friend from a prior gig. And for blah, blah, blah, I'm making this up, because I've lived it so many times. And rather than saying, hey, Frank, this behaviour is suboptimal. You can We'll talk later, I'll get into one on one, that whatever. And maybe that's the right thing at the time, but it's not the place to kind of highlight it in that meeting, or whatever is going on here. But you defer it saying the hard thing is telling him right then right now, this is something that isn't working because of xy and z. And it's super hard. But if as I look at most of the horrible people, situations I've created on my time, it's because I, I didn't do it early, I waited until the review, or I waited until you know much later. It is the classic it is the classic reaction to a performance improvement plan. Everybody says it in some of it's true in sort of denial, but that I didn't see this coming. They didn't because you didn't say the hard thing. And a while ago, and by the way, it's now 10 times worse, because it's amplified, you didn't deal with it, whatever that bad behaviour cost was growing as it was going on, blah, blah, blah. It's just to me, that that pain of doing it whatever that pain is professional pain at the beginning, is so much less than doing it later. And I've learned it so many times that I perhaps pre optimise to say something sooner than maybe others. But here's the idyllic hopeful eventual outcome there is. prank. This isn't working. Oh, we're friends. Why are you telling me this? No, no, no, you're my manager. It's all different. Then we have the conversation, we get through it. Just hand wave through a very hard thing. The next time that I say it two weeks later, because he didn't really actually hear me because he was defensive. And I didn't communicate it. Well, blah, blah. So here it is, again. He's like, Oh, well, there is a pattern here. And, and suddenly, there's a thing back to the building of trust that's going on. It's really, really amazing, which is, over time, both of you are willing to tell him and he is willing to hear these things, which means we're taking all of this air out of this sort of moment of review time, because maybe he's still working on it when we get to reviews. It's not the first time he sees it. I say we'll talk about the second time I'm putting this here because it's still a thing. He's like, yep, and I know what we're doing about it. This is what we're doing about and I'm like, Yep, that's right. I'm making it sound so easy. It's not because there's you know, people in feelings out there, but it's getting out there as quickly as possible. So that you can start having whatever drama is about or the conversation or the date or whatever that sort of thing is So, and it's, I think it's just, it's a, you can you can abuse this, you can be that person who's always telling the truth. So there's, uh, you know, this is the way it is and saying the hard thing. So there's a way there's definitely it's not a catch all, but it's certainly from a feedback to people perspective, I think it's just something that can save you a tonne of a tonne of time down down the line as you're having these big conversations with your team with your humans.

Aaron Randall  25:36
And then you said, in that post that a good place to start practising feedback is with new employees. How do you do that? And why a new employee? It's so great for this.

Rands  25:50
The what I do with new folks is, so I have one on ones. One day, I'll be dead and they'll be this gravestone it'll say Rands don't forget to do your one on ones. It'll say on my gravestone, cuz it's the only thing anyone's gonna remember. The but one on ones are sort of religion for me, because they're just that time to do what we're about to do. One of the things that we're about to talk about, which is just that weekly time to actually have a conversation. So with new folks. I, number one, one on ones are not status reports, their conversations about topics of substance, I always have a couple of things ready. But after a couple of times, folks realise are this sort of bidirectional high bandwidth things. But at the first one, where I've probably done more talking than usual, just because it's the first time I finish, and I say, hey, do you have any feedback for me? And never in the history of forever? Has anyone ever said anything? They're like, they're like, no, you're doing great. I'm like, thanks for saying that. I'm failing Paul, about 40 to 42% of the time, but it's good. So I keep on doing that. Because one on ones or every week. And eventually, they realise and I'm not going to stop asking. And they say something, and they say, Hey, here's a you were nervous that that one on one or that presentation, I'm like, Yes, I was, I was totally not prepared. I was totally yoloing. And I was not nearly as prepared as I like to be for those sorts of things. And in my head, it's this moment where we've flattened the org structure a little bit. I'm not this human who is their boss, I am this human who is on this journey with them. And they are willing to give me feedback. And this helps in both directions. Number one, they start to say things to me, like he screwed this up. And it doesn't happen overnight. But also when I have a thing I said, Hey, remember, like, like, we now have this contract here where we can do feedback in both directions, I can now say something, and when it's bad stuff, or it's harder to hear stuff, it's less of this way, because this is just a thing we do. Like Well, the other thing we do here, as opposed to like this, it's this time of year, and we're giving feedback, we've just sort of made it kind of normal, right? So it's just, and by the way, after a while, you don't even know you're doing it anymore. It's no longer feedback. It's just not having my one on one with Julia. And by the way, we got we were yelling about something and it was pretty bad. And then we moved on to the next thing because it was you know, that's kind of how we roll. Right? So it's a stigma being taken away. And by the way, like, as I'm saying this as a coffee is kicking in here. It's what people want. They want to like actually hear how they're doing from people that they trust. This is super malleable, like, sign me up for that all day.

Amy Phillips  28:34
I mean, yes, but it's also tough, right? Like so how do you toughen up to like hearing the hard thing you sort of talked about in your post about the three types of feedback? No big deal, slow burn, and just plain hard? Like, How do you how do you learn to handle those?

Rands  28:53
I'm the only one that in those three that is really hard is that? Well, there's hard, just plain hard and slow burn, which are kind of the same thing. And slow burn is like you hear this thing. And then you start to go like, wait a minute, she was telling me something super important, but she was pulling her punches. And this is actually super hard thing to hear. And then there's it's hard to hear. I think for both of those cases, whether you slowly learn that it's hard or it's immediately hard. You know, like, if your gut reaction is not correct, your gut reaction is as a human is when you've been punched is to punch back. When in whatever way you want to articulate that and that's not that's not what leaders do, right? So it's, to me, there's this digestion process that starts in terms of actually hearing it and I can tell you, when it's really really hard feedback or something which is really complicated like my wife knows this. I just I shall I just go into this little shell of, I need to think through this and see how I feel about it and do the implication analysis and, you know, reflect on that past behaviour and data, but almost like clockwork, and it's not like, guaranteed amount of time. There's this point where I'm like, Alright, I get it now. And it's days, sometimes it's days where I'm like, it's like, I'm on my bike on our three of the ride. And like, I get it, I got it. And like, I was working on it for the last two days. And it's this puzzle of I sort of sort of like you're trying to sort through it and be like, okay, Kate, let's get on piste. And let's put that aside here. I did these things. Did I deserve this? No, I disagree with that. But they meant it. So like, blah, blah. So it's, there's this point where you're kind of like, you've resolved it, and perhaps you know, what your next step is, that's not necessarily a requirement. Sometimes it's just like, Alright, I see the hand that I've been dealt, I'm not sure what my next card is, or how I'm gonna play this, but at least that So that to me, is the thing is, and, and knowing that there's time for me, maybe I'm slow, just kind of noodling it and kind of getting through it is the most important part. Again, but to start with, like, your first reaction is just garbage. It's whether it's a well, I'm useless, or they're completely wrong, or whatever that thing is, there's probably some truth there. But it's much more nuanced is much more Shades of Grey to it, and you want to get through all those shades and figure out kind of like, truly what was said, what's being asked, or what's developing in terms of the situation?

Aaron Randall  31:45
I've when I read about you describing slow burn, I just say articulated perfectly, what I've felt so many times where I've been like, that was a great one on one I have with Alice, and they'll be on the commute home half hour later, suddenly hit me like what she was saying. And I thought, Oh, no, I just realised what I'd like what the feedback was, to me that was so politely delivered that it took half an hour, it's about me to get it. So it's like, as you say, like with your cycling example, it's slow, slow solution, I guess, to come back to you.

Rands  32:15
Or the other one is, they're introducing a thought, which is a bunch of other feedback that now you can smell is coming. They're just like trying to crack the door open a little bit. And you're like, I'm like, What did they wait, what was that? That was just like a throwaway into the comment into the one on one thing like, Oh, I mean, I

Aaron Randall  32:38
I think, to your point that you've got reaction, when you get hard feedback is you've got punched, you want to punch back. Obviously, with the slow burn with example, it's too It's too late. You're out of the room, you're on your cycle ride, you're you're realising. But have you got any advice for us and other managers around when you get that just plain hard feedback? So yeah, you can interpret it immediately, you're in the moment with that person, and your gut reaction is to be defensive and punch back and so on. Like, what is it? What What advice can you give us to cope with?

Rands  33:07
It is in this hypothetical scenario, is action required in this conversation? Like, is he or she asking for something? Because my, my answer is to want to say, I hear you loud and clear. I need to digest this, and understand what you actually said, because I heard this sort of stuff. And I kind of want to punch you right now. which we've never say that, obviously. But I mean, it's, we're joking, but it's true, which is like I really, if it's something which is really, really hard that you know, you it's, I had this tweet a couple weeks ago, well, on communication, it's like, say that, if some version of say the hard thing, say it again, ask them to repeat what you said. Say it again. Give them the night to think about it. And ask them again, the next day for the whole thing again, and that that time between the end of all that repeating and the phase two is the digestion and just letting them get to a true understanding or you're completely wrong. And I have these questions in which that's great. Let's go have that conversation. That's the human mind. human brain just needs time to kind of work through that. I, you know, to me, it again, there's two things, it's understanding it, which I think is required. And then there's the other piece, which I like to do, just to feel empowered as a human is also, what am I going to do about this? Again, not required, but incredibly useful. And you're like, well, this is awful. And I did this thing horribly. Okay, I understand it now. And I'm gonna do these things. But they're two different things.

Aaron Randall  34:52
I love that. I love the idea of just acknowledging that. As a human, you need to go away and take time to digest.

Rands  34:58
Yeah, yeah, that's great. Yes this is a kind of had a HR partner tell me like, no, no performance feedback on Friday because he wants to be able to talk to the person the next day and actually get the feedbacks, and not the whole weekend because it can spiral there. So

Amy Phillips  35:18
yeah, I mean, that's so important. Yeah, like, having been delivered lots of feedback in my career, on Friday afternoon. There's plenty of time to think that one through before Monday, it's definitely not a restful weekend

Aaron Randall  35:33
Wait, no shipping changes and no feedback on Fridays.

Rands  35:42
You want to check in you want that check in relatively quickly, because you can just spiral you can that's the piece and it's in, it's a conversation, you're actually doing this negotiation as part of this, which is really important. And, again, if there's only if it's one sided, like, then you're gonna, you're gonna you can, there's situations where the person is just going to spiral out of control.

Amy Phillips  36:03
Yeah, that's great. Yeah. So quite a few things you've, you've kind of talked about, as we've gone through Rands, and also from when I first read Managing Humans is, am I right? To think that you're an introvert?

Rands  36:17
Huge introvert.

Amy Phillips  36:18
Okay, let's get to one thing that I was thrilled to read when I was reading Managing Humans was the positive side of being an introvert. So Aaron and I are both introverted. And we sort of find like, the world is so extroverted, and particularly as you get into kind of leadership roles, it seems more and more like you're expected to be an extrovert, it's just assumed you're an extrovert, right? How have you, like, is that your experience? And like, if so, how have you dealt with that?

Rands  36:47
So little, little unscientific survey I've been taking for, I think, three or four years, I, back when we did presentations in front of humans, you know, in like buildings and stuff. I'd have I have to stick when I open up a talk where it's sort of get to know the audience and sort of like, how many engineers here how many, you know, marketing people, depending on whatever talk I happen to be giving. But one thing I always ask is almost always a leadership crew. Audience or interested in leadership, I said, How many? How many introverts in the room? And here's the fascinating thing. I've done this 50 times. And maybe there's a selection bias, because they're coming to see me or whatever. But it's like, it's not coming to see me as like at conferences with lots of people and whatnot. The vast majority 60% of the audience identifies as introvert, not extrovert. So for leadership kind of sampling, right. So I think the thesis, I agree with what you're saying, and that there seems to be these impressions that or requirements that leaders have this extrovert tendencies. I agree with that. I think you're, I think a lot more introverts as leaders than you think. And it's because I think we have these superpowers relative to listening and to de escalating and to communicating well, and because we don't speaking for myself, now, I don't want to be the spotlight. I despise the spotlight. It's very scary for me, and I can do it. And I've developed skills to be able to do that. But like, let's be clear me on stage talking to 500 people is a very, very introverted tasks. I'm not talking to anybody. I'm up there alone.

Amy Phillips  38:35
Yeah, stages are much safer.

Rands  38:41
introverts don't get that they don't they think that Oh, I can't do that. I can talk to my people. I'm like, I'm up there alone. All I have to do is listen to the laughs or the silence when I'm second or whatever it is. So anyway, it's a it's a, it's a very, there's a lot more introverts than you think it's just the extroverts are so loud, that we think they're done. And they're so and they're amazing, by the way, but they're a different set of humans there. But they get all the attention because they love it. And we're like, you just go for it, like go stand on stage and do your thing or talk to the people or dominate the conversation or whatever you're gonna do there. So anyway, a lot more introverts in leadership than then your question might imply. Did I answer your question, though?

Amy Phillips  39:22
It does. I'm surprised. I mean, you're questioning more about all the extraverted behaviours that we're all going through. If we all stopped, something would flip.

Rands  39:34
Yeah. There's a set of skills that are very that extroverts get for free, and it's super annoying, because they do it so well. April Underwood, who was our Chief Product officer at Slack. She could get in front of the whole audience the entire company unprepared and give you 20 minutes of inspirational product strategy. jokes. And like, I know how prepared she is because she was in the meeting before me when she's like, I've done nothing to prepare for this and she gets up. And it was like this beautiful keynote, and she just crushed it. That is, I am, I am much better at that than I was 10-20 years ago, but I still must set my slides up. And I must like, I must get everything ready. And I will practice a bit for a new thing and whatnot. Because I have had to build the muscles and the habits to be to be good at that. And you have to do that. As well as knowing you're in a meeting that you're the product leader for that you're the one who's listening and blah, blah, blah, all those other extroverted things you have to do, there's a whole set of skills you're gonna have to get good at that are not natural. And you're gonna see these introverts, extroverts that are so good at it and super annoying. And they're so funny too. Dang it.

Aaron Randall  40:55
Because we've all worked with amazing extroverts, and that that's a great example. How do you I want to say keep up, like level the playing field, you know, one of the things that I've personally experienced working with talented, amazing extroverts is that they love thinking and problem solving on the fly, and bring them into that. And I'm so bad at like, solving on the fly I need to go away and digest and think, but like, how do you presume that someone is done this a lot, like get comfortable with that?

Rands  41:23
I am. I'm super bad at what you're describing. I do have an answer. But like, in that meeting with powerful extroverts, where it's 10 to 20 of us, I as Rands, and person who has done things that are interesting, still really, really struggle in that in that group of people with their bad shoulders. And in all the things I do so well, it's still hard for me, the the story that I'm telling myself about how I do it is twofold. Number one, if it's 20 of us, I'm quiet. If it's three of us, I won't shut up, because it's a small knowable set of folks. So what I will tend to do before and after that big powerful meeting is I will probably have met with a good chunk of those folks, and had a very vicarious debate with them about things that I think are important and blah, blah, blah. And by the way, I have selected those people deliberately because they're going to extrovert their ways of that meeting in a way that will be super impressive. And by the way, they're carrying my religion as well. So I'm sort of delegating to the extroverts to kind of take my stuff and to kind of drive in that meeting. And I will also follow up with them after but I'm doing a lot of behind the scenes work. And I do have issues with this because I do think I should be showing up in that meeting more but it's just, it's it's hard because I am listening to every single word I am keeping a complete mental map of everything being said and as best I can in these virtual times. What's going on and what's shifting around. And but I am generally less public engaged than my peers would expect me to be

Aaron Randall  43:07
somebody that and actually that, that that's okay. Like it's okay to like make our peace as introverts introverted leaders with with those kinds of situations?

Rands  43:15
I think so i think i think there's times the extroverts, because I have things important things that I'm responsible for. Some of the extroverts would like me to see me be more my word, no one else is flashy, and being like, boom, well, we can't ever do that. And here's what I will say that afterwards and get that into the bloodstream in a way that is effective, but it probably maybe is more efficient to have it out there. And because some other extrovert wants to debate with me, but I know that she does, and I don't want to have that debate. I'll have a debate later.

Amy Phillips  43:52
And if one kind of final question I suppose about, well particulary about being an introvert is, how do you manage your energy? Hmm.

Rands  44:04
I have an answer. But can you be more specific?

Amy Phillips  44:08
Yeah. So like, if one of the things that sort of say, extroverts being very like, energised by all the meetings and talking to people and doing things, as an introvert, particularly managing people, it can be tiring, right? Like, people aren't bringing the energy to you. That's from when you're alone later. So have you got any kind of ways like structuring your work or like techniques or things like that to handle that?

Rands  44:35
So there's, there's I have three tests that I'm always looking at relative to energy. They are. Am I sleeping enough? am I eating well? And am I exercising? Could we have any more vanilla vapid answers to managing energy? These are super important. These are super important. Because if the answer to any of those three questions, am I sleeping well? am I eating well? Am I exercising? If I'm not doing those things. Energy is all screwed up. Let's pick on one. And there's other things to learn from failures on on those as well. Let's just pick on one like exercising. Two things about exercising, exercising, it's good for you. Like, I'm gorgeous, right? I do most of my hardest work on my bike, in terms of the hardest things I have to think through in terms of programmes or people or politics, or bla bla bla. So if I'm not doing that, especially now during COVID times when we're stuck in these meetings all the time staring at each other. I'm not doing that I'm actually not doing my job as a senior leader in terms of moving forward on big things having the time to do that. And yes, I can block it off on my calendar. But when I blocked it off on the calendar, it means I jump into Feedly or Doom scrolling or doing whatever it is, it's not the important work. So that's number one is am I doing the important work? And am I getting exercise and like the interesting part of exercise might be to you that is healthy it is and that's great. But that's not why I do it. I do it because that's when I do import work. And by the way, it's also healthy. Let's go to another one about energy. Am I sleeping? Well? There's the obvious part of that, which is like, Am I getting enough sleep to be able to be coherent and get things done? Yes. No. Why? Here's the interesting thing. Sleep gives me energy, if I have enough sleep, I get energy. But more importantly, when I'm not sleeping, it usually means something is wrong, mentally, or stress wise at work, or whatever. And that is an early warning to me to go and say like, Oh, I'm not even admitting it yet. But I have a problem with this person or this situation, whatever. And I'm losing sleep over it. Because my brain is smarter than me. And it's telling me in the middle of night, you should actually worry about this. And sometimes it's just weird stuff about like stressing about whatever. But very often, it's like, I need to go work on this. And it goes back to energy because I need to go fix that so that I go sleep so that I have the energy to go do things. So in food is kind of like the same thing there as well as like, of course, eat well. I'm not eating well. Well, what is the root cause of that? I'm booking too many meetings. I'm not, I'm not carving off time to do that sort of thing. So there's all of these interesting things that are feedback loops around those three very basic human things that are all about energy. And I use those whenever I see one of those one of those, any of those three goes into the red. I'm like, because exercise to you. Why am I not doing? I'm busy? Why am I busy? Oh, I'm not planning on? Am I personally not doing well? Oh, this is like, this is a warning sign about something else I need to go fix there. So all of those, I think your question may have been different. But all of those are to keep me to a certain amount of basal energy, but also early warning signs with things that can actually really hinder it. The other thing is, and this is maybe the soundbite is, I also have to have 30 40% of my calendar, blocked off and not in meetings, which is really hard to do in the larger company with a lot of teams. But this is work for all of us. This is paying attention. And you're nodding because I'm saying these things. And this is all work to like have this conference. And it's like, it's it's, it's I gotta have those times, which are just like a cool, I'm gonna go Doom scroll, I'm gonna answer some slacks or this sort of thing. But I don't do that if I do eight hours straight. I'm exhausted. And you know, something's wrong. That was a long answer. But

Amy Phillips  48:39
no, that was a fantastic stuff. So just to very quickly wrap we have three quickfire questions that we'd like to ask all of our Humans+Tech podcast guests. Yeah. So number one, what is your top book recommendation?

Rands  48:57
It's this book called Boyd. And it's about this gentleman who is not a good human being, by the way. But what he does is he, he he was basically a fighter pilot. And then he figured out and then he started to want to build jets, fighter jets, which What in the world is have to do with leadership? All I have to tell you is go read the book, because it's about how to think about critical decisions. I have never highlighted a book more than this book. And by the way, not a good guy. It's you can't it's not you're not gonna like him a lot. But the way that he breaks down very complex political situations, like how to get a fighter jet funded by the US government is absolutely interesting. He introduced this concept called an ooda loop, which is go look it up. Which is way too much overkill for most of the things we do in our political lives as humans right now, but just that he brought up this lens to kind of look at these things is super interesting. If that totally bores you You should go read a Bird by Bird by Anne Lamott, which is one of the best books on writing ever. So you want to read about this horrible guy

Amy Phillips  50:11
and who inspires you?

Rands  50:16
I am I'm still pretty, pretty bullish on Steve Jobs, not the best human in the world. But as an Apple person as a person living in that pool right now I you know, it's just like everybody. He's a complex individual, but it's still I still like, I'm like, why are we doing this isn't? Yeah, that's right. We should be doing this. little short cut around this. And this isn't the steel echo of this, this gentleman who built this amazing company.

Amy Phillips  50:45
Amazing. And then what is the most ridiculous thing about you?

Rands  50:51
Oh, gosh, um, I have a set of eyes. After all this eating thing I just said before, there's some like comfort foods I have that I think would repulse you. And I don't think I could tell you what they are. But I'll tell you one. You know, like, there's American cheese, like the slice cheese. There's like that. There's like good versions of that. And then there's, like, made in vats somewhere in Nevada, from from sand. And you know, those are delicious. They're so good. And there's there's no nutritional value at all. And there's a couple others that are like that. And I think they're all from when I was a kid long ago when I got used to like this horrible, awful processed cheese food. So good.

Amy Phillips  51:43
Finally, where can people find out more about you?

Rands  51:46
Yeah, there's two places. There's a Rands in Repose blog where I write that's but the place you should really, if you want to hang out, there's a Rands Leadership Slack. And the quest if you want to do it is to find out how to get invited. It's really easy, but you have to go figure it out. There's about 16,000 people in the Rands Leadership Slack now, and about three to 4000 active daily. And I think it's other than the books, I think it's one of the things that I've had a chance in building to kind of, that I'm super proud of in terms of, by the way, I don't do anything, it says people there. I mean, I nudge it. And then there's a code of conduct and we're kind of like, making sure everything's going well. But the amount of learning that's going on there every day is is shockingly high. So figuring out how to get an invite, and it's not hard making it sound like it's this big deal. Like go figure it out.

Aaron Randall  52:41
It's a great community. I've been around for a while. I love it. It's really amazing.

Amy Phillips  52:45
Fantastic. Thank you so much for taking the time to talk to us today. It has been absolutely so much fun. We'll be sharing all the links and show notes plus the all important doodle over on our website, HumansPlus.tech. I'm Amy Phillips. This is Aaron Randall and you've been listening to the Humans+Tech podcast.

We’re joined by the incredible Jon Topper, CTO/CEO of The Scale Factory. Jon founded The Scale Factory way back in 2009 and they now help organisations of all sizes design, build and manage the foundations of their digital businesses.

We chatted about scaling, Kubernetes, and why we should all be thinking about boring tech.

Visit here to listen on your favourite podcast provider.

Scroll down to read the full transcript of our chat with Jon.

Jon's quick fire answers

Jon recommends the book Accelerate by Nicole Forsgren, Jez Humble and Gene Kim

Corey Quinn's approach to Twitter inspires Jon.

The most surprising thing about Jon (if you haven't read his Twitter profile) is that he's polyamorous.

In this episode we cover

1. The Scale Factory, how they help companies design, build and manage the foundations of their digital businesses [00:03:56]
2. Scaling, and why being in the Cloud doesn't solve the challenge of scaling [00:08:43]
3. Why Kubernetes also isn't the answer to all your scaling concerns [00:10:39]
4. Common scaling pitfalls [00:13:59]
5. DevOps, and whether it's a reasonable expectation [00:15:26]
6. The SRE book [00:20:33]
7. Boring is Powerful (video:blog:slides), or the dangers of following shiny tech [00:22:32]
8. Innovation days at work [00:29:43]
9. Simon Wardley's Pioneers, Settlers, and Town Planners concept [00:39:05]
10. Dan McKinley's Innovation tokens [00:43:16]
11. Jon's experience with therapy and why he recommends it to everyone, and especially to men [00:46:15]

Find out more, and follow Jon

Follow Jon on Twitter and LinkedIn.

Jon is the CEO and CTO of The Scale Factory.

Full transcript

Amy Phillips  0:02
Welcome to the Humans+Tech podcast. I'm Amy Phillips. And this is Aaron Randall.

Aaron Randall  0:06
Hi.

Amy Phillips  0:07
Today we're joined by the incredible Jon Topper, CTO and CEO of The Scale Factory. Jon founded The Scale Factory way back in 2009, and they now help organisations of all sizes, design, build and manage the foundations of their digital businesses. Jon's a frequent writer and speaker, and in 2017, was named DevOps leader of the year at the DevOps excellence awards. Jon, welcome to the show.

Jon Topper  0:30
Thanks, good to be here. I bought that award, by the way, it was one of those kind of things, publishing companies these days, now that people aren't buying magazines try and find other ways to be relevant. They run these award shows, they sell you like a seat at the table for a grand or something. We bought a couple of those. And so I got an award. It's great. All it all it really did was get me loads of loads of stick from my fellow DevOps people, which, you know, has some value in itself. But yeah, I don't pay a lot of attention to that award. That would that was the claim at the time. I've reined it in since then. And we fired that PR agent as well. Hello.

Amy Phillips  1:15
Well, now we get to award you with something else. Right. So as you may know, every guest on the Humans+Tech podcast gets awarded with a personalised, photorealistic doodle from Aaron. I'm not going to have any part of this oney. Aaron, drew this. And here's your's for your evaluation.

Jon Topper  1:40
That's certainly better and more valuable than the DevOps leader of the year award. Yeah, I guess you've got a bit more hair on there than I actually have now. I went for the Coronavirus chop and actually buzzed my hair off like about a week in because I was pretty sure that we were going to be locked down for a while and my hair needed a certain amount of maintenance. So it all just came off. So that is amazing. If I've got here, this is great for your listeners, obviously. I'm going to show you my Songkick mug. I think one of you gave me when we were together back then with with another Aaron doodle so

Amy Phillips  2:16
I definitely didn't give you that mug Jon because I did not get one of those mugs.

Jon Topper  2:20
Oh wow.

Amy Phillips  2:21
I'm very put out by this.

Jon Topper  2:22
Oh, wow.

Amy Phillips  2:23
I just got shown this mug a number of times. I've not got my own mug.

Jon Topper  2:27
That's unreasonable. I will send you a Scale Factory mug. I'll get my people on that.

Aaron Randall  2:33
Have you got drawings on those mugs?

Jon Topper  2:35
I mean it's a it's a geometric logo. There's no real there's no drawings on there. But I could draw on it for you. It'll come off in the dishwasher though.

Amy Phillips  2:46
Well,

Aaron Randall  2:47
Amy told me I'd got the moustache wrong, by the way.

Amy Phillips  2:49
I mean, my initial thought was that the moustache was quite messy. And I'm not sure I really associate that with you, Jon.

Jon Topper  2:55
Right. Yeah, I mean, I used to do the curled moustache thing. I went for about a year and a half every two years actually properly waxing a handlebar. And it was a massive pain in the ass. It's frankly, like it's getting getting two sides of a moustache symmetrical, would often take sort of five or 10 minutes in the morning to get it quite right. And so yeah, I eventually just grew it out and gave up. So no longer no longer a feature of my my appearance, unfortunately.

Aaron Randall  3:25
Awesome. Jon. So I mean, obviously, Amy and I have known you for a long time many years now. And so for our listeners, we actually met when you were you supported us as we worked at Songkick and building our initial infrastructure there.

Jon Topper  3:40
Yep.

Aaron Randall  3:40
A long, long time ago. I was there before you two. In fact, I think

You were, yeah, that's true. Yeah, I joined and I got to enjoy your infrastructure work. And back then it was all about physical servers in data centres.

Jon Topper  3:56
Yep.

Aaron Randall  3:56
And now obviously, we're pretty much all in the Cloud. How has this changed the type of work that you do?

Jon Topper  4:02
And I mean, there's a lot less time spent sitting around in cold rooms or driving on the M25 with a car full of tin which is, which is a positive, I think we're able to have a much larger impact on people's businesses these days, I think the in the sort of old days when when you were racking hardware and doing that sort of thing, it was quite nobody would hire an external business to do that if they were big enough to have people to do that themselves. And so we were often doing that sort of work for smaller companies. And today, we're able to kind of go into into sort of enterprises and I will not even go into right sit in this very chair where I've been for the last six months of lock down, you know, logging into systems and and deploying them from there. Everything just moves much more quickly, as well as the agility that we have as a result of cloud is It's pretty amazing. And I guess not really something that I would have imagined sort of back then I think, I certainly wouldn't have imagined that the people who sold books would be selling it to. So and that was a bit of a bit of a shift, right. The book and CD company wants to sell us servers that I never see what, what. But yeah, it's, it's had a profound impact. I think on everything, I think I would I take issue a little bit with the idea that we're all in the cloud, I think, the that's definitely true of sort of tech first businesses and the SAS businesses that you know, you guys work for, and a lot of businesses that we work with, and I think Amazon and Google, Microsoft all recognise that there is still a huge opportunity in in, in getting stuff out of data centres, to the point where, you know, Amazon is still throwing, throwing funding programmes at people who want to move, move workloads in, and they are still building new products that are geared up towards making that story easier. And so I think there's still a sort of long, long tail of businesses who are running their own kit, and are not in the cloud. But that's only getting smaller, right, you know, most most, most of those businesses probably are also building things in the cloud as well. And are looking for an excuse to get that stuff out of their buildings and stop employing people to put wires together and sit in cold rooms typing on keyboards and stuff.

Aaron Randall  6:31
When you say that, are you nostalgic for those days at all, as somebody spent a lot of time in those data centres.

Jon Topper  6:37
I so I guess my career trajectory has taken me from practitioner to business owner, right. And so today, my job is spreadsheets and webinars. Right. And so I guess I'm nostalgic for anything that looks like technology practice. I'm not necessarily nostalgic for the for the sort of the data centre days, but there was something certainly in the height of summer, there was something quite pleasing about being able to go and sit in, in an air conditioned room away from everybody. But I used to find that the the background sort of white noise of a data centre would basically cause me to go mad, like you start getting, I start getting audio hallucinations, I imagine my phone ringing, I'd be constantly checking my pocket where the phone would have been vibrating, had it actually been ringing. And so you do get a little bit do lally when you've been in a data centre for a long period of time, and and often provisioning a new new platform, you're there sort of two or three days, crimping cables and slicing your hands open on poorly manufactured rack mount kits. Thanks, Dell. I don't I don't really miss it. I remember that time fondly. But I don't miss it.

Aaron Randall  7:48
That felt like a definitive no.

Jon Topper  7:49
It took a while to get it

Amy Phillips  7:54
I feel you're kind of glossing over they some of the benefits of the sort of offices that had a server room in the office though, like you know, right? Beer fridges are not nearly as big as server rooms, in my experience.

Jon Topper  8:07
Yep. Yeah. But also, server rooms typically not as cold as you would like your beer to be in the large part. And most well run facilities won't allow you to take liquids into them anyway. which is also part of the problem.

Amy Phillips  8:21
Well run might be the key

Jon Topper  8:23
Yes, yeah, I did at one point work for an organisation that had a data floor in a sort of adjunct to the where the office was that we were working. And and I wouldn't necessarily say that was particularly well run. But they didn't let us take our beers in there.

Amy Phillips  8:43
So I mean, it sounds like the sort of work you've been doing over the years that has like, radically changed. Like, from within sort of The Scale Factory, like, I, I'm guessing a decent amount of your work now is actually in the cloud or around the cloud. So yeah, what is it about like, so for someone that's not sort of hands in deep on this stuff? Like, what, why? Why is there work? Why is the cloud not just scaling itself? Like, isn't that kind of what it does?

Jon Topper  9:10
And so after a fashion, yes, there are certain certain parts of cloud that do take away a lot of that pain for you. But there's also a substantial amount of, of the cloud that doesn't, right, I think, we coined the name The Scale Factory originally, because, in part, we sort of recognised that there was we'd be solving a lot of the same problems repeatedly that so this is sort of stamping out of infrastructures following common good practice patterns was where the sort of factory idea came from. And scale was kind of at the time that seemed interesting, right, was that it was an interesting part of the the type of work that we were doing. And so it just sort of stuck. Today, I wouldn't say that we concentrate on scalability as much as we used to. And I mean, you're right, we are all in on the cloud. We're an Amazon Web Services, consultant partner and, and so everything that we do these days is is Amazon focused. But we are equally as likely these days to go and, you know, create or tune a CI/CD pipeline, or to go and do a security audit and improvement piece of work or something like that. So the scaling is a bit less bit less relevant. But at the same time, I think the the assumption that you can just throw your, your app onto the infrastructure and expect it to scale is not correct. still hasn't ever been hasn't ever been correct.

Amy Phillips  10:39
Hang on, but Kubernetes

Jon Topper  10:42
let's not get into the cave, Amy. I mean

Amy Phillips  10:48
For people who are not in there, like why Why? Why is Kubernetes not the answer, right? Because I think this comes up so often, right? I'm going to put it on Kubernetes, so that it just scales right, it will fix all my problems.

Jon Topper  10:58
Right? Yeah. And I mean, No, it won't. Or at least it I think,

Amy Phillips  11:03
You have new problems

Jon Topper  11:04
yeah, you replace your existing problems with with the problems of running Kubernetes. And so Kubernetes, at its heart isn't is sort of designed to solve a scaling problem. But it's also there to solve the problem of we as engineers, we're all doing the same stuff, right? We were all writing bluegreen deploy scripts, and we were all, you know, defining how our apps interacted with our load balancers, and all that kind of stuff. So what Kubernetes offers, which is really powerful, is a consistent interface to all of those problems being solved for you. It still requires you to be thinking about, you know, what, what, what, what is your what resources do you have? Is your application using? You know, how much? How much RAM or compute do I need to give to every instance of this particular part of the application server? Where's my data being held? How available does that need to be? And what is what's my database performance? Who's backing it up, like all of that kind of stuff, that these are still problems that somebody has to solve somewhere? That the story of the cloud is one of commodification, right. So in the old days, when we were working together, at Songkick, we built a lot of this stuff in a data centre. And the sort of highly available MySQL Cluster was something that had been very sort of meticulously put together by hand, using open source tooling and sort of off the shelf monitoring tools and that sort of stuff. But ultimately, someone i.e. me had spent the time plugging those those pieces of Lego together to get to the outcome that we wanted. Today, you get a highly available MySQL Cluster by making an API call and saying Amazon, can I have some, MySQL flavoured Aurora. And then you can just go and talk to it. Some of the scalability problems have gone away there, but you as a developer still have to be choosing good schema shapes, you know, adding indices to the right places. And the cloud lets you get away with a lot more of the awful crap that you used to not be able to get away with, because you have the limitations of the physical tin that you bought, but ultimately, there is always a point where you have to go and tune it or, or interrogate it for statistics to make different decisions. And so that there's always going to be a requirement for, you know, the type of operational thinking and skill that we provide. Because the assumption is that not everybody in your organisation who is good at cutting code, making features, building something that users want to want to use, and that delivers actual business value. The people who have those skills don't always necessarily have have skills in the, you know, algorithmic complexity understanding of their database queries. And so you always have to spend a bit of time on that stuff. And adding Kubernetes to the mix, doesn't make those problems go away. It might might change the way that you think about them, and it might move where they start to become a problem. But the the problems are kind of inherent in what we're doing. I think

Aaron Randall  13:59
so. So I guess if it's not scaling phenomenally is what you're saying, then, like, what are those most common pitfalls that you're observing right now?

Jon Topper  14:07
I mean, today, it's still the same pitfalls, as they were, you know, 10 years ago, my database performed really quickly in production, because there was no fucking data in it. They're, like, as soon as you soon as you move, move, so that database in development performs really well, but you move it into production, and suddenly you've got millions of rows, then the way that that that system performs, looks different. And so the kind of operational thinking that goes into making these decisions about how I use data or how I build my application is still the thing that is missing, I think, for all of the sort of positive sides of the of the DevOps movement as it as it was, I think we're still in a position where the people who are cutting code are not often invested in how that code is going to look when it's running in production. That that was that was the problem that that that DevOps sort of sought to fix. I don't think it was ever really fixed, or at least from my vantage point, as someone who gets a phone call when things are broken, you know, it looks like that's the case. So there's a selection bias here, right? We are working with customers who have called us because things aren't going the way they'd hoped. And so maybe outside of my kind of bubble, everyone's doing a really great job of everything, but I doubt it.

Amy Phillips  15:26
DevOps is an interesting one there, right? Because I think one of the big benefits of DevOps was kind of this sharing of responsibility. You don't get to just throw it over the wall, and it's someone else's problem.

Jon Topper  15:38
Yep.

Amy Phillips  15:39
Do you think it well I suppose? Well, the challenge I always see is the kind of the How do people develop the skills? Or or how many of these skills or what sort of level can they develop these skills to? Because yes, previously, you had someone who, you know, 10 years, actually as a sysadmin, who's been on call and dealing with the all these sort of incidents out of hours or whatever, they, they've got a huge amount of experience. So

Jon Topper  16:06
yes.

Amy Phillips  16:07
Is that a, is that something that a developer, say, frontend developer is now working in DevOps? Like, is that realistic, that they actually can get those skills? Or is it just a matter of time?

Jon Topper  16:22
So I think there's a you can you can learn this stuff, you can actually learn this stuff, right? This, this isn't some secret sauce, I think you're right, that unless you've sort of lived with it for a period of time, you don't, you don't gain the sort of fluency or kind of intuition around it the same as with any other skill, right. And the, I think the, you know, to bring this back to the sort of humans part of the Humans+Tech story, I think, as sysadmins, operators, so forth, we were very used to being lone wolves, we would spend a lot of time in these dark rooms, you know, saying no to people, and sort of preventing change, because change is the thing that causes everything to fall on its ass. And ultimately, we as people who became skilled at those things, and found it very or find it very difficult to teach those skills to others, find it difficult to find the patience to do that, right. And I speak for myself as well, I've, I was not a good sharer for a long period of time. And, and the sort of the, the power of, of knowing all of this stuff, and being able to sort of mete out that information to people as a sort of as a skill that only you had, and I think probably pushed some of my reward buttons. These are all things that I've discovered in, in therapy over the last couple of years, which I recommend to everybody, and especially sysadmins. And, and so I think we made life difficult for ourselves by not being willing to share or assuming that the the the people that we were providing this information to were, were too stupid to understand it. And that does a real disservice to basically everybody. So I think the other the other thing that made that did a difficult story, or maybe less realistic was that the DevOps community didn't really have any say anything like a manifesto, right? The Agile Manifesto is very clear. Sort of statement of intent. And the the DevOps world never really had that sort of clear this is this is what it's about, it had a lot of dogma, and it had a lot of kind of pithy catchphrases, we don't really use the word DevOps these days to describe what we do, partly because I think it's kind of table stakes. Now, I think that the the sort of shared ownership thing is what people are expecting to see. And we work in a DevOps-ey way, but we were no longer calling ourselves DevOps, a DevOps consultancy. And, and people just didn't know what it was. Right. And so a lot of organisations went through their lives, deploying some monitoring, letting the developers have a login on that monitoring platform, and calling that DevOps not really sure that's entirely entirely the full story. So we've picked up a lot of good practice, we've picked up, you know, CI/CD, we've picked up decent monitoring, we've picked up infrastructure as code, and you know, deployment automation, all that kind of good stuff. But all of those were technical solutions. And the the real kind of meat of the problem has with every problem, right? As you go through your career as a technologist, you eventually learned that all the problems are their meat sacks that are pushing the squares, not the things that go on in the machines with the squares on them. And so I think we could have as a community spent a bit more time talking about sharing knowledge and, you know, that sort of culture of practice stuff, then we ultimately did, and whilst devopsdays have has a lot of talking about around that every devopsdays that I've been to, has some variant of the open space session where someone sits and says, so how do I convince everybody to do DevOps? Right. And that's the sort of the extent of the story. And so it was never really clearly defined enough to be picked up by, by people, I think. And whilst ultimately I think it was a force for good and improvement, I think the more actionable stuff around SRE, is perhaps a kind of better, better framing of this stuff today.

Amy Phillips  20:33
Well, it's also a book. I think that's kind of back to the manifesto. Is there's one book that everybody references and that's fine.

Jon Topper  20:40
Yeah.

Amy Phillips  20:41
Like, you can just like, we all have it on our bookshelves, obviously.

Jon Topper  20:44
Yep. Yeah.

Amy Phillips  20:46
Yeah. I mean, it's like people reference it. And you have literally the SRE book. That's fine. We're all on the same page, which we did with Continuous Deployment as well. Like, yeah, I think when you have a single book, like Agile Manifesto had that Manifesto, but yeah, it was like DevOps missed out by just not having the defining book.

Jon Topper  21:03
Yes. Yeah. I think that's probably a fair assessment. I think that there are plenty there's plenty of criticism, you can levy against the the SRE stuff, I think the the sort of Google centricity of it all is, is a little bit grating to some people. And, you know, we we certainly when we're talking about in the consultancy work that we do, we we meet loads of teams who were very, very clearly definitely doing the Spotify model. And you kind of interrogate that and find out what they're doing and sort of realised that what they're doing is cargo culting, something that was not actually what Spotify were doing in the first place, and thinking that's going to help if you cargo cult Google's approach to problems, and you're not Google, and which you come back to the Kubernetes story, I suppose. Then you're you're not going to see the same benefits necessarily, all of these decisions need to be made within the context of your own business, and the business outcomes that you're that you're driving for, rather than just the sort of technology story, which is a bit more common in our landscape, because we are technologists, how we refer to ourselves,

Aaron Randall  22:08
Not meat sacks?

Jon Topper  22:11
Meat sacks when it's other people. A friend of mine who who's been consulting in this for much longer than than I refers to the human beings as the carbon units.

Aaron Randall  22:24
Meat sacks plus tech, we'll go for a rebrand.

Jon Topper  22:28
I look forward to seeing the doodle for that in fact,

Aaron Randall  22:32
Absolutly not. I'm gonna move on from scaling, Jon because you're a fairly prolific conference speaker, I've watched a bunch of conference talks over the years, and they're great. One of my favourite. One of my personal favourites is your Boring is powerful talk, can you tell us what boring tech is? And why we should care?

Jon Topper  22:57
Yeah, sure. So boring tech is the stuff that's been around long enough to work properly, I think it's probably the the really sort of pithy version of this, right. And this is, you know, in, in opposition to the sort of trendy stuff that pops up that gets a big sort of following behind it, because it's new and exciting. But as technologists, we're very much inclined to follow follow the changes in technology, that's what's exciting to us, right, we didn't get into tech, because we wanted to use a BBC Micro for the rest of our lives, we were sort of excited by the new things that that are available, and we sort of follow those and and so we we tend to be inclined to maybe put some of these sorts of technologies into production environments, way before they're ready. And boring is powerful is sort of my way of saying you should be critical about which new technologies you put into production. And particularly because often the people making technology choices are the the developers who are writing the code, they're very close to the user, they're very close to the business domain. And and in many cases, the the things that become readily popular are so because they are they have what I call a low meantime to Hello World. So you can download the thing from Hacker News or wherever it is, you get your up to date tech  zeitgeist information from you can install it and you can get the thing apparently running enough to be able to run some of your own code or display your own image or something like that. And that pushes your dopamine buttons, it goes great. This definitely works and now it's in your in your ci pipeline then it shows up in production. And unfortunately the things that are optimised for good meantime to Hello World are often have often traded off against literally everything else. So most newer pieces of technology are not very well put together in terms of how you deploy them, or how you back them up or how they can be secured or whether the default configuration is correct, and so forth. And so what you end up with if you if you sort of follow this fashionable approach to technology choices is that you put something into production, that is then an absolute nightmare to keep up or to keep working or to conform to the SLAs, you've created your customers or what have you. And in in that particular talk, I talked about MongoDB and MongoDB, as a really good example of this. Because at the time, it was exceptionally trendy, it was this kind of like, Hey, you don't need to worry about database schemas anymore, which, of course, is very appealing to the type of people we were talking about earlier, who would just throw data into the databases and assume it would scale. And it got a lot of attention, it was very easy to get up and running, you could download a package, run the run the daemon and then start throwing data into it felt felt really kind of compelling to use. And it was it was released sort of version 1.2 was like December 2009, which is more or less when, when we founded The Scale Factory, in fact, and it wasn't until August 2011, that you could actually authenticate yourself against it as a as a sort of different user until that time, all users were equal. Everybody who could open a TCP port to it could squirt data in there. And and it wasn't until March 2013, that you had any kind of role based access control. So the only sort of security features that that probably people who are writing software, with user outcomes in mind aren't necessarily thinking about these sorts of things in compliance industries, or we at the time, we were working with a pharmaceuticals business, or at least a SAAS vendor who was selling to the pharmaceuticals industry. And they actually needed all of this stuff. So they got a certain certain way down the line to producing this software using MongoDB. And then they found that they couldn't actually legally put it in production because they couldn't conform to the governance requirements that the the laws that they were following, put in place. And it wasn't until November 2016, that MongoDB actually passed a data safety test. Right, Kyle Kingsbury is Jepsen kind of, you know, cap theory testing mechanism didn't prove MongoDB as actually, it's gonna hold on to your data forever, until, you know, seven years after it was originally originally launched. So there's a real sort of caveat emptor here, right that the newer something is, the less likely it is to have these really important operational characteristics. And unless you are, unless you've got somebody in your organisation advocating for these things, at the time, which you're choosing the technology that you're going to build your apps on, you can easily back yourself into a corner where you've invested all this time and energy building a billing platform on something that ultimately can't work the way that you want it to. And so, boring tech, today, MongoDB is a boring technology, right? It's, it's got it's had enough eyeballs on it that it probably works properly. If you have a problem with it, you go and look it up on StackOverflow. You're not busting out a debugger and like the source code, which if you're if you're adopting things too early, you find yourself doing. And so the the sort of advice that I give around this is that you should really be choosing to, to adopt these kind of exciting technologies only where there is a tangible business benefit to doing so like this is the thing that will differentiate you and your product from your competitors. And because if not, then all you're doing is buying yourself a painful time. And I mean, going back to the Kubernetes story earlier on, like Kubernetes is still a little bit exciting. It's a new technology. And for a long period of time, the only way to run Kubernetes was to install it yourself using just sort of hodgepodge of shell scripts that it was, it was open source. And we've frequently come across customers today who are still running the versions of Kubernetes that they deployed back then because they're too scared of touching it because they don't all their business runs on it, but they don't know how to upgrade it. And they don't know whether it's working for them properly. Today because you can buy a commodified version of a Kubernetes runtime Kubernetes control plane from from a cloud vendor, that is now a more boring choice. And so you can go and do that know that the the cloud vendor is taking care of the the sort of janitorial work that's required to keep keep the thing alive. And so it's a better choice.

Aaron Randall  29:43
Yeah, really interesting. I just how do we, you know, as you mentioned at the beginning about that BBC Micro like, how do we as like humans working in tech teams who do love these dopamine hits, balance that dopamine hit plus a desire to actually keep up to date with the latest tech trends. Yeah, with building with building boring tech from boring?

Jon Topper  30:03
Yes. Yeah. So that's a really insightful question. Because I think if you don't keep keep a check on that stuff, then this exciting tech will appear in your production infrastructure because somebody wants to scratch that itch. And so that I guess the way that we do this, in our organisation, we we have a sort of a budget of development days that the team can draw down on in the same way that they would book a holiday, they can book a development day. And they can use that time for anything that they can, reasonably with a straight face tells me has business value to The Scale Factory. And most, for the most part, that's people doing stuff with tech, but it's occasionally also some will take that day to go and do a course on communication or something like that. And the so that we're sort of channelling that instinct into, into, into a sort of controlled, controlled outlet, which is quite helpful. And the, the other thing that we do with Dev Days is, if the if the outcome of that dev day is in some way valuable to us, such as someone's using it to learn a new tech, so they can write a blog post about it, for the company blog, they get that day back. So there's this sort of, perpetual cycle of if you if you can spend that day valuably in some kind of reputation building manner. So one of my team, Tim, is a contributor to the Kubernetes documentation, special interest group, and he spends some of his Dev Days contributing to to sig docs, I've got a couple of people on the team who are getting better at putting themselves out there as conference speakers, and so they use their days to prepare that material. But yeah, in to bring back to your original question, it's about sort of providing an outlet for that, that stuff. And making sure that design decisions are taken collaboratively rather than individually. Because I think if you have a lot of eyes on this sort of thing, then it can get reeled in a little little easier. And plus, of course, because we're working for customers, rather than building stuff for ourselves, you sort of have to get the buy in from the customers, I think they want to want to do as well. So it's one of the as we've, as we've shifted from being a sort of, I guess, an engineering consultancy, as in that most of the team doing hands on engineering work for customers on a day to day basis, to a more strategic and design and architecture consultancy. And then the sort of the shift in the team has been around becoming more aware of business outcomes and being able to draw a straight line between the technology and what what the what the business is trying to achieve. And that's been difficult to teach actually, it's, it's not always an easy thing to, to rein in I guess the the instinct to, to just go and build something that's fun, or, or justify the thing that you want to build in terms of the the business outcome, which at least is the next step in that direction, I guess.

Amy Phillips  33:14
It's interesting though, like, I've definitely worked in companies where needing to have a little bit of shiny Tech has been quite important from a hiring point of view, right? You know, actually, like, when people are looking for new jobs, it's like, oh, I want to, you know, I want to get into this language, or I want to be using whatever. And so there is also a little bit of pressure that you can't,  well for some people, like some teams I've been, it's kind of like, our all of our tech is a bit too boring. We need some more shiny at attract new people.

Jon Topper  33:43
So what one of our long standing larger clients have been going through a, a very long, long term strangler exercise to break a huge Java Oracle monolith into micro services. And they intentionally chose Scala to do that. Not because they thought it was necessarily the exactly the right tool for the job. But because the business domain of this problem is so fucking boring, that they figured the only way they could get people who could who could, the only way that they could interest people come and work on this platform was by doing it in Scala. And so that was that was a major part of their choice to do that. It was the hiring choice. I mean, now they've got a lot of fucking Scala to run so I don't know whether that's, that's worked out exactly the way that they intended. But it seems to be going okay, so far, because at least they're they're microservices, rather than a Scala monolith. But yeah, it's a reasonable it's a reasonable concern. And I would, I would argue a little bit I think, I don't believe this very strongly, I don't think but i i would argue a little bit. You don't want a team full of people who chase shiny new technology. I don't think I don't think that's what you want around like, I I'm biassed towards, you know, wanting people who look at a new tech and go, Oh God, that doesn't look like it's going to work because that's the that is the sysadmin ops mindset, right? That's you want people who can you want your sysadmins should be pessimists, right. That's the only way that you can sit down and enumerate all the things in which a platform will go wrong. So you can go mitigate it. And if all you have are optimists and I think the people that chase the shiny technologies are often optimists, and then that stuff never gets considered. And, and I think that this is borne out a little bit in we were within our Amazon partnership, we're part of a programme called well architected, which is a review framework that Amazon provides, that we go and use this framework to assess somebody's practice on the AWS platform against Amazon standards, and sort of make them some recommendations and say, Oh, you should be doing this differently, or you're doing quite well here, or have you considered this, this technology here, and the thing that we find that the framework is split into five pillars, and one of those pillars is operations. And operations is by far the worst scoring pillar for pretty much everybody. And the majority of that, I think comes down to one, the idea that if you put it in the cloud, Amazon will just take care of it for you. Right, that's a that's definitely a sort of a fallacy. And there's the optimistic idea that nothing ever goes wrong, which anybody who's worked in production systems for any amount of time, will tell you is also a fallacy. And it's under invested in, teams don't spend time thinking about failure modes, because failure dealing with failure modes is sort of its insurance policy. It's, it's not sexy, it doesn't add business value, necessarily. It's it's more that the time that you spend on good operations protects revenue, it doesn't create it. And so it's not seen as important. People don't write down their how things work, people don't share and share amongst the team, how you would recover from the top 10 incident types that you might see. And your teams are just pretty bad at it. I think this is a I think this is a human condition thing, I think we're inclined to think that everything's going to be fine. And occasionally, you need someone to show up and say, Hey, that limit that you've got set really high on this particular part of of your AWS account means that if you accidentally check your Amazon keys into GitHub in a public repo, which happens plenty of times, and then someone could spin up those instances and mine Bitcoin on it, and not only will they be mining Bitcoin, there'll be costing you about 25,000 pounds per hour. While those systems run, like, should we should we tune that down a little bit? So thinking through those sorts of scenarios is a very pessimistic, but pessimistic thing. And and people don't like to think about worst case scenarios. It's not It's not fun.

Amy Phillips  38:06
Yeah, definitely.

Jon Topper  38:07
I would argue that's maybe why our pandemic response has been so terrible. But maybe, maybe politics isn't the topic we want to stray into. In the UK,

Amy Phillips  38:20
We've got we've got people in the audience who are in much more sensible countries, so well, then some people are out and about having a great day, walking in the park listening to this,

Jon Topper  38:30
I've got a number people on the team who are not from the UK originally, and a not inconsequential number of them went back to the countries that they were brought up in for the duration of the first lockdown, because A they wanted to be with their families. And B, they thought that they might do a better job of containing things in Portugal than than we would manage here.

Aaron Randall  38:51
Yeah. Just to just to wrap that, though, I really love that point. You made about like, your hiring plan. And like, do you want to hire those kinds of people? I guess, like, Yeah, do you want to have shiny tech to get those kind of people? I think that's a really interesting way. It's like framing that problem.

Jon Topper  39:05
Right? And I think so. Simon Wardley, who you probably are broadly aware of, because he's spoken a lot of sort of ops and tech related things, and talks about the sort of the evolution of technology and how it goes from being something that you create that you have to build yourself with your bare hands and maybe a soldering iron or two, all the way through to commodification where you can just you know, the power we're using today right 240 volts 50 hertz, comes with a 13 amp plug, which is why that's a commodity, we don't have to worry about it. And he talks about the the evolution of technology along that that spectrum and that you you have different types of people involved at each part of that journey. And so there's this talk of Pioneers, Settlers and Town Planners and the pioneers are the people who are like going out breaking new ground and trying new things. Those are the shiny, shiny technology chases right that Let's let's put this thing together, really exciting kind of, you know, you need people like that to invent things that you can't if you're if you're sort of if you're trying to build disruptive applications, or you're building something brand new that no one's ever seen before you need people with that sort of mindset, they are important individuals. But then you also need the settlers who will take the jagged edges of those solutions and the kind of spit and duct tape adhesives and and polish them up and make them a little bit more more palatable. And sort of get them into a position where they're, they're a bit less dangerous, and that they're a bit better, better known. And most businesses sort of get to there, right at the the far end of the evolutionary spectrum are the town planners, and they're the people who are making it really boring. They're the people who are sitting in rooms deciding what shape a 13 amp plug should be and sort of pulling all of these these sort of strands together and commodifying it Amazon are town planners in the infrastructural sense. So if you look at the the evolution of say MongoDB, the sort of Genesis part of its lifetime, you had the pioneers who were building this thing, right and debugging it and running it in production, you know, keeping both pieces when it fell apart. And And over time, that open source project grows into into a commercial entity that is working on that thing and stabilising it and listening to the pharmaceutical customers of the world who say, actually, would you mind putting a bit of TLS on this, right and securing the thing. And then you've got Amazon at the far end of this, I guess MongoDB is a bad example this because Amazon's MongoDB implementation is a MongoDB compatible layer against their own technology. But they've essentially commodified a MongoDB compatible database service that you can now consume without needing to know anything about how you install and configure MongoDB. And this is a this is all part of the tech lifecycle. And the the argument is that if you're spending time pioneering on something that has no business differentiation value for you. Or if you're if you're doing town planning, but you're not selling commodified things, then you're probably spending your time in the wrong places. And there are there are other sort of related concerns, such as in the Pioneer landscape, you should probably be using agile, to run your delivery because it's, it suits the nature of that work. At the town planning and of the equation, you're probably looking at ITIL, and ISO 27,001, and all that sort of the standards following stuff because the pace of change is a little different, you probably doing Prince II project management and that sort of thing, because the Agile model doesn't fit that world. And so making appropriate choices of technology processes, and how you spend your time. And based on where you are in that lifecycle is a really important thing to do. And that's part of part of the consultancy work we do really is to sort of look at, look at what an organisation is doing holistically and sort of try and understand whether they're trying to, you know, fit fit a pioneer problem into a town planner shaped hole.

Aaron Randall  43:16
And when you talk about that pioneer problem in a town planner shaped hole in your conference talk you you talk about this idea of innovation tokens design is that like somewhat related this idea of like being able to afford a send a few pioneers out to try something out?

Jon Topper  43:29
Yeah. So I can't claim to to have coined the innovation token terminology, that's a guy called Dan McKinley, who wrote about it while he was working at Etsy in 2015. And you're looking at me, like impressed with my recall. I wrote this down earlier, because I knew you were going to ask me about this and I didn't want to take credit for someone else's stuff.

Aaron Randall  43:52
You ruined that one

Jon Topper  43:56
Ditto the MongoDB timeline, I've got my talk slides of it. So So Dan, Dan has a blog post that that's, that's called. It's not boring it's powerful, but it's something about boring, choose boring technology. And yeah, the the idea is that you have a limited number of innovation tokens to spend. And so you should spend them wisely and wisely means in the pursuit of the business differentiation, outcome that you are working on. So at Songkick, for example, your innovation tokens were all very well spent in doing the sort of artists search or the the ticket purchasing or the things that made Songkick essentially Songkick. Spending those innovation tokens on I don't know building your own database, which thankfully you didn't do, because I would have shaken someone to death if they'd suggested it. You do need a little bit of fear as a sysadmin. So we said, The yeah, if you've spent that if you've spent that time kind of doing things that that looked like, you know, building infrastructure components, that wouldn't have been a smart move. And that's why it was sensible at the time for Songkick to bring me in as a as a contractor to do those things. Because there was no need for anybody in Songkick to be good at racking hardware and configuring switches and so forth. There's a bunch of sort of hard work that you do up front to get that stuff running. But then later, the the sort of day to day operation stuff, other people can easily do with a bit of, you know, training and assistance. And that's, that's broadly how we think about the cloud stuff today is, most most of the businesses that we work with don't need sort of high end, Amazon solutions, architect professional level individuals in their organization for the whole time. Because once they've stood something up that broadly works, everything else is iterative from there.

Amy Phillips  45:52
That's interesting. It really strikes me, Jon, when you talk about these things that the so much from your years of experience, like you've seen..

Jon Topper  46:01
I look old and tired. Is that what you're saying?

Amy Phillips  46:07
Like, oh, I've come across this thing, or I've seen this as a consultant. I imagine it's easier to you've seen it 20 time before.

Jon Topper  46:14
Yes. Yeah.

Amy Phillips  46:15
That's also true, it kind of like sysadmin started was thinking of almost with the DevOps is, actually if you haven't got years of experience,  you haven't seen the database fail in that way three times previously, it's harder to work out what's happening, right? Do you, when you sort of look back to when you started, like, is there like, Is there a tip you wish you wish to have given yourself like 10 years ago as you started out on this sort of journey?

Jon Topper  46:44
Oh, that's a good question. I think 20 years ago Me was a cocky little fucker really, and and was was cockier than his than his own abilities. And, and in a way that sort of set me an ambition to kind of become as good as I thought I was, there's a bit of that. But I think I've, my professional career, in my personal life and everything else, I've been very independence, I've been very sort of like, untrusting of other people and you know, not not feeling like I can rely on people to do a good job. And again, plus one for therapy, that I'm sort of unraveling why that is and making a good understanding of that. I sort of wish I'd done therapy earlier, I guess the advice is like at 21 22, go see a therapist to to work out who you are. Because I'm now today, having spoken to therapists for sort of two or three years now I think, there abouts, I feel like I have a much better awareness of myself and a better understanding of my, my sort of biases, and enough of an understanding of those biases that I can now correct for them in the moment. So if I feel myself kind of going a little bit too independent on something, I can rein myself in and ask for help from somebody, which I would never have done back then. That said, You know, I think being fiercely independent did mean that I had to learn a lot of stuff, right? In order to sort of live up to the image I portrayed for myself. And, and so, you know, this is very sort of psychology, psychiatry stuff, I suppose. But like every strength is has a weakness and vice versa. Right. There's, there's a sort of a flip side to everything. So my, the flip side of my being sort of untrusting of other people and very independent meant that I had to go and figure out how this stuff worked myself and become become good at it. And so I think it's that I think that the message for me of that era would be you need to lean on other people a bit more often. And, and let them in to help. And and I wouldn't have listened to myself, had I been given that advice at 21. Anyway, so I guess that's kind of moot. I think that the when you talk about the the sort of, you know, I have seen a lot of stuff, right, and I think consultancy is definitely a part of that. The other the other sort of part, I think is that I'm, I'm blessed with a really good memory, like, it's not photographic. It's not, it's not a sort of, you know, sort of superhuman thing. I just remember a lot of things, and coupled with a good understanding of the fundamentals. And I think you can solve any problem, right? So I remember a lot of the stuff, and I kind of remember where the Apache config flags that I haven't touched for, you know, 10 years or something. And there are certain kind of failure conditions that I can go, you know what I think it's x and y based on these two other things that I've seen my understanding of the domain lets me sort of cut off a couple of things that it almost certainly isn't and narrow down on the problem pretty quickly. And so it comes across. It comes across as expertise. And I suppose it is in a way but but to me, it's it's about remembering stuff and having a grasp of the fundamentals. I think that's the the thing that if, if anybody's listening, wants to kind of improve at their operations stuff in the technical sense. And a really good understanding of the foundations of how we build this stuff, I think is is the is the key. I, last year, I think, hired hired someone who was kind of, I don't know, 25 or something. And so they'd never run a BGP session on a router, or had no real concept how the DNS system fits together. And there were a couple of outages that happened that year, where I sort of sat down and walked through the kind of how this actually happened and he grabbed  his head, and how does any of this work? And at that point, I think he's achieved enlightenment, because actually, none of this stuff should work at all, because it's all built on on foundations of trust, and, you know, assumptions from the 1970s. And the fact that any of the internet is still working in the slightest is nothing short of miraculous to me to be honest.

Amy Phillips  51:33
I, you moved on quite quickly, but like, I really wanted to say like actually thank you for like highlighting how one of the things we've touched upon in previous episodes, is how it can be quite hard and lonely when you're leading. And you can be quite alone. So yeah, I think you're the first person who's really actually been really quite open about actually, everybody should just go and get therapy go and find out who you are which I think

Jon Topper  51:58
particularly men, particularly men, right, I think

Amy Phillips  52:01
I think everybody,

Jon Topper  52:03
probably everybody, I think men need to hear the message more, right? I think I talk very openly about my therapy experience, partly because it's been really helpful to me, and I like sharing things that help us one of the reasons I talk a lot at conferences is that if I've learned something that's really useful to me, I think other people might want to know it as well. And so I talk about having been through therapy, and partly because of that, and partly because I think we still live in a world today where, you know, asking for help as a man is considered weak. And, and that's bullshit, frankly. And there's, I feel much, much stronger as a result of going through therapy and sort of understanding myself. And I guess I'll put this out there, if anybody's listening and would like to talk about going into therapy, and sort of would like to have some fears about that allayed or otherwise, then I'd be more than happy to sit on a on a zoom or a hangout for 30 minutes or so and sort of talk through it because I think it was therapy's seen as a little bit of a bit of a dark art almost right, you sort of you people don't talk about what they talk about in their therapy very often, right? Because it's very personal and, and quite rightly so. And so from, from an outsider's perspective, it looks like you go and sit in a room and get interrogated for an hour at a time. And it's really not, I mean, it can be like, times when it needs to be, but it's, but it's really not like that at all. And it's, it's also it's quite a technical discipline, there are a lot of different types of therapy. And, you know, for someone who is going into therapy for the first time, it sort of doesn't matter, like what the modality is like the the sort of, is this jungian or freudian? Or is it psychosynthesis? So like, all those kind of words, might as well be like, do you like puppet or chef, like, it's a really kind of religious viewpoint for the people who practice therapy, but for the people who are receiving it, like, it sort of doesn't matter. And, but yeah, I'd be more than happy to kind of, I guess, offer some words of comfort to anybody who was thinking about going into therapy, particularly as a as a man. And, and I would seek to encourage them to do that, because I think it's a it's an important powerful thing. And particularly, as you say, like, as a lead or a leader. For me, I own the business. You know, I'm the CEO, the CTO, every everybody, the buck for everything stops with me. And I don't have a one to one with anybody, like, Who am I going to have a one to one with? It turns out that therapy and external coaching are the ways to do that if you're that sort of high up in the organization. And I've sort of I've solved the therapy problem. I've done a little bit of coaching as well. I think there's more coaching in my future around around certain things. But asking for help is the thing that I've learned to do in later life that, I think is the thing that marks me out just having finally grown up along with, you know, the gray hairs and my beard, which are expected of someone who knows Unix as well as I do.

Aaron Randall  55:12
Amazing, Jon, thank you so much for sharing that sentiment that was like, such a profound and an insightful answer. And it's really nice to hear that.

Jon Topper  55:21
I'm glad. I'm glad it comes across that way. It was not my intent. But I do feel pretty strongly about it. So

Aaron Randall  15:27
Yeah, no, it's great. It's really great. And we, I mean, we should wrap here. And that's a really great, great place to stop. Yeah. An incredible high, we have lots of learnings. And I do want to wrap with our usual three quickfire questions. If that's okay.

Jon Topper  55:41
Yes, yeah.

Aaron Randall  55:27
And we like to ask these to all of our Humans+ Tech podcast guests, as a question for you is, what's your top book recommendation?

Jon Topper  55:50
So it would be remiss of me to not to mention the book that I talked about incessantly in every presentation that I give recently, and that is Accelerate, which is the the sort of I can't remember what the subtitle of it is, but it's the it's the DevOps book that has statistics in it. Right? It's the only is the only sort of numerical study, or quantitative study of the things that we've been preaching dogmatically for a decade. And so for me, that's really important, because it allows me to point out some science and say, you know, that the science says you should do this. And I think that the authors are Nicole Forsgren, who is Dr. Nicole Foster, and in fact, who's the primary author, and the person who's done the actual science. Gene Kim and Jez Humble are there as well. I don't know whether that's whether they had major input into the into the stats, but their names are on the front, at least.

Amy Phillips  56:45
Jez Humble had a reasonable input.

Jon Topper  56:48
Right, that's a that's yes. I think that i think that's likely. And and, yeah, I recommend it in in most of my most of my talks, I think the only if I'm going to levy criticism against it, it's that the out the sort of outcomes, that there's a, there's a sort of assumption that you're measuring performance. And the performance is all about rapid delivery of software and low, low error delivery of software, it doesn't make any attempts to draw those parallels with business outcomes or sort of commercial goals. And so it falls a little short there for me, but as a, as a tool to offer a bit of quantative proof for the dogma we've been spouting like, very valuable. Awesome, it's the it's the it's the questions that a quick fire right, not the answers.

Aaron Randall  57:41
Quick fire question number two is who inspires you in tech?

Jon Topper  57:46
Well, that's an interesting one, because I guess my my lone wolf tendencies have led me to kind of not really sort of identify with the idea of being inspired by others, which is interesting and a topic for Tuesday morning, maybe. And but I guess, in the, in the realm of, of what we do today in the cloud industry, I mean, Corey Quinn is someone that I think is, is pretty inspiring, if only for the sheer volume of tweets that he manages to churn out. And so I guess he's inspiring from a sort of personal brand perspective, I think he does it extremely well into the promotion and so forth. And, you know, it's the sort of broad reach that I would quite like, for the consultancy work that we do, but there is no possible way that his approach would work for us. Which is why it's inspiring I think, to go, you found your you found your audience, you found your, your sort of tone, and it's really working. I don't want to sound like that. Thanks.

Aaron Randall  58:54
Nice. And finally, what's the most surprisingly non tech thing about you?

Jon Topper  59:00
That's a different question to the other ones that you've been asking.

Aaron Randall  59:02
You can't prep for this one my friend.

Jon Topper  59:05
I definitely had an answer for the other one that you're asking. Ask that again the most surprisingly non tech thing about me?

Aaron Randall  59:13
Yeah.

Jon Topper  59:14
And so something that that would surprise other people if I told them it is that what you're looking for?

Aaron Randall  59:24
something surprising that is non tech about your life. Oh,

Jon Topper  59:27
yeah. Okay. I mean, I'm polyamorous. I mean, that's, that's not that shouldn't be surprising to anyone who's looked at my Twitter bio, but yeah, I'm a person who enjoys multiple romantic relationships and doesn't really believe in monogamy as a as a concept or, or a structural norm. So I guess that's, that does surprise some people. I'm not as vocal about it as I used to be. I used to sort of because it was new and shiny to me, I guess I was, I was often quite vocal because it would differentiate me and maybe shock people a little bit. But today, it's just a really normal part of my life. So I'm married, my wife and I've been together for over 20 years. My other partner, we've been together for 10 years. And it's all quite normal and boring these days and, and as domestic as you can be in a pandemic and between two houses. But yeah, it's, it can be surprising. I think it's it as a lifestyle choice it's becoming more, if not more popular, then certainly more visible these days. And it's I think, my my ethos in life, career, everything else has always been to sort of question the norm and sort of ask yourself, does this apply to me? Is that a, is this norm a rule that I want to follow? And many times the answer is no. And so I've sort of chosen my own path. And that's, that's one more way in which I've done that. And the other way is, you know, self employment, um, sort of just just a control freak, really just like to

Aaron Randall  01:01:01
Are you saying you're a pioneer, then Jon, in some ways.

Jon Topper  01:01:03
I, yeah, probably. In some ways, yeah, yeah.

Aaron Randall  01:01:10
Awesome. Thanks for sharing. Amazing. And finally, where can people find out more about you?

Jon Topper  01:01:16
Erm so I'm reasonably active on Twitter as @jtopper, where I tend to complain about things mostly these days, to be honest. I'm not as active on Twitter as I as I have been in the past. So Twitter is somewhere I go for tech news, but I don't don't tend to be quite as vocal myself there. I should probably turn that around, actually. And do a bit more kind of thought leadering there.

Aaron Randall  01:01:44
Awesome. Jon, thank you so much for taking the time to talk to us today. It has been so much fun.

Amy Phillips  01:01:50
Thanks so much.

Aaron Randall  01:01:56
We'll be sharing all the links and show notes plus the all important doodle over on HumansPlus.tech. I'm Aaron Randall. This is Amy Phillips and you've been listening to the Humans+Tech podcast.

Julia Evans, creator of the awesome Wizard Zines joins us to chat about drawing, how to survive having a manager, and brag documents!

Julia's a software engineer and also an amazing illustrator and storyteller. She's the creator of Wizard Zines, the famous comics that explain complex tech in a short, simple, and beautiful way.

This episode, along with all our previous episodes, is available on your favourite podcast player. Listen and subscribe here.

Scroll down to read the full transcript of our chat with Julia.

Julia's quick fire answers

Julia's book recommendation is The Manager's Path by Camille Fournier. (Camille also joined us on an earlier episode of Humans+Tech!)

Julia's number one tip for keeping up with the industry is to keep asking questions.

She's inspired by Kelsey Hightower for his Kubernetes knowledge, but also because of how much time and effort he puts into helping others.

We also cover

1. What is Wizard Zines? [00:01:49]
2. Learning about strace [00:03:41]
3. Julia's most popular zines - Bite sized Linux and so you want to be a wizard [00:08:25]
4. Help! I have a manager! zine [00:08:56]
5. Manager-report relationships, and why it isn't just your manager's responsibility [00:09:57]
6. Why managers need to give context on their decisions [00:10:49]
7. How to talk about promotions and compensation [00:12:48]
8. The structure of one-to-one meetings, and what to talk about [00:18:16]
9. Personal values at work [00:22:31]
10. Turning up with solutions to problems [00:24:07]
11. What makes a great manager? [00:31:11]
12. Lara Hogan’s Manager Voltron [00:35:08]
13. Want to get your work recognized? Write a brag document [00:38:23]

Find out more, and follow Julia

She blogs at https://jvns.ca/ and has all her zines on https://wizardzines.com/

Julia's also on Twitter.

Full transcript

Aaron Randall  0:01
Welcome to the Humans Plus Tech podcast. I'm Aaron Randall. And this is Amy Phillips.

Amy Phillips  0:06
Hi.

Aaron Randall  0:07
And today, we are so excited to be talking to the incredible Julia Evans. Julia is a software engineer and also an amazing illustrator and storyteller. She's the creator of Wizard Zines, the famous comics that explain complex tech in a short, simple and beautiful way. Julia, welcome to the show.

Julia Evans  0:24
Thanks so much for having me.

Aaron Randall  0:26
Um so one of the things we like to do with all our Humans Plus Tech guests is draw a doodle of them. And so I'm particularly excited today, given I get to show my doodle to someone who can actually draw. So yeah, I'd love to show you yours and kind of get your thoughts and feedback if that's alright?

Julia Evans  0:41
Wow, I would love to see a doodle. This is very exciting.

Amy Phillips  0:45
Okay, I just put it up for you.

Julia Evans  0:48
Oh, this is incredible. I love it. Um, this is really I think this is better than my drawing skills. Actually.

Aaron Randall  0:59
Absolutely not. You're making me blush

Amy Phillips  1:03
Aaron's ego is just growing

Aaron Randall  1:07
Julia says my drawing is good.

Julia Evans  1:09
I truly only draw stick figures. And I, it's not because I can do better.

Amy Phillips  1:20
That's great. Well, you're very, very polite, I think. It's always I think the test of how kind our guests are. Awesome, so onto onto your work. So Wizard Zines. So these have been around for years and I think I've certainly been referencing them and sharing them for years. But for anybody just in case there is anybody out there who doesn't already know your work. Could you give us like a brief intro, like what is it that you do?

Julia Evans  1:49
Yeah, so I write these small like zines which basically what they are is they're tiny books, which are maybe 20 pages, about topics that usually topics that I'm mad that no one told me about before. And we're gonna be talking about one of those today. And so I kind of tried to write down like very briefly like the things that I like most wish I could have told my past self about that topic in maybe like 20 pages, and they're usually like there's a bunch of like comics. But the main point is that they're short and tell you what you need to know.

Amy Phillips  2:22
That's awesome. I saw you tweet just the other day about how sort of online courses are always advertising about 50 million hours of training and all these amazingly huge numbers and you're like, I do completely the opposite so like it I think it's so obvious when you say it, but nobody seems to be doing that. So it was it always does that always the goal that these were going to be the shortest possible to like teach you the most you possibly could get into like 20 pages.

Julia Evans  2:49
I guess so. I actually started writing them because I had RSI, so I started out like blogging. I've been blogging for a long time. I loved it, but I couldn't type for a while. And so, and maybe I also couldn't write that much. So I started writing these very short things just because those were like the constraints that I had in my own like body. But I still wanted to be like writing on the internet. Um, so I'd write these like very short comics about, like, things that I thought were interesting or that I wanted to share that I would normally have written a blog post about. And then it turned out that people really like them. So sort of an organic thing.

Amy Phillips  3:22
So awesome I just think it's so effective, right? Because I never feel like what I love sharing about, like, when I show them to other people is it's like, Hey, I know you're super busy. But literally, you only need two minutes read this thing. And I just like, there's no excuses. I know that there's no excuse to not read this because it's so effective.

Aaron Randall  3:41
We actually had them in my previous job, we had them some of the posters printed up and put on our fridge in our office for like, people who weren't even in tech were learning all about netstat or strace, or whatever it was, at the time. It's amazing. Yeah. Really cool. I'm really interested in how you went through this process of giving up your full time tech job to start this?

Julia Evans  4:05
Yeah, um, so I left my job almost a year ago. I didn't start it. I started it maybe five years ago, I guess. Um, and so I started it kind of on the side, and at the beginning, I didn't charge for my zines at all. Um, and then I started charging for them. And then I was like, Oh my God, this actually makes money, which was very surprising that I could write like strange computer comics and sell them to people make money. I was like, okay, that's strange. But I was like, okay, it'll only happen once. And then I like made another like zine about maybe the command line, and then that also made money and I was like, okay, like something is happening here. And so I think I kept doing that for maybe like a year and a half. And then I'd been at my job at that point for like, six years, and I was like, this is kind of long enough for this job. And I left and I have not yet gotten another job. So yeah, here we are.

Aaron Randall  5:03
Amazing

Amy Phillips  5:05
That's so awesome.

Aaron Randall  5:06
And are you working on these completely by yourself or do you have other people who help you like condense the topics down or do some illustrations and so on?

Julia Evans  5:13
I do all the interior illustrations myself that that is to say the bad ones there there's like cover art, which looks good. But the less technically complex ones. Basically, if there's a stick figure I drew it and if there's like a beautiful illustration, I hired an illustrator to draw it, that that's how it works.

Aaron Randall  5:37
Nice.

Amy Phillips  5:38
So So how do you choose your topics?

Julia Evans  5:42
Um, yeah, I think it's always a difficult I think I read about things that I think are really confusing, I guess, um, or that like are causing people a lot of problems. So for example, like, I think a lot I started out my first one was about strace, I guess. Um, and like, I saw that well, I was at that point, I was, I think I called myself like the chief developer advocate for strace, because I was like, I think people need to know about this tool. And like, I saw that people didn't know about it, and I was obsessed with it. So I think I try to write about things that I think are a little bit like under loved or like underserved. But that I think, that are important to know about, I guess, and that are fundamental. So I read, I don't write about things that change very much. So for example, I don't write about like, I don't know, JavaScript anyway. So I shouldn't write about JavaScript frameworks, it would be a mistake. But I wouldn't write about JavaScript framework. I try to write about stuff that hasn't changed for maybe five years, 10 years something like that.

Aaron Randall  6:40
I love that. And that point you make about the fact that once you've got those things in your toolbox, that kind of they're not going away, either because it's 10. Right? It's been around for so long, and it's really consistent. It's fundamental to what we do in tech.

Julia Evans  6:49
Yeah, exactly. Like with HTTP. It's not going to change. Like,

Aaron Randall  6:54
yeah, that's awesome.

Amy Phillips  6:55
it's really interesting, actually. Cuz I think like, I don't know if like it's the same around you but in London over the last few years, like coding bootcamps have become incredibly popular. And actually, what's really interesting is you get these really great, like sort of junior entry level developers coming out, but because they haven't got like computer science degrees, so actually, you have this kind of, there's some foundational stuff which they have to pick up quite are they there's quite a lot of learning they do on the job. So I think it's really interesting. Like, I think it's really great. You have these like, easy accessible, kind of foundational topics as well, because definitely, those are the people who I think I try to learn as much as they possibly can in like, the first three months on their job.

Julia Evans  7:33
Yeah. And, and I think it's pretty common for people who are further along in their careers to to not know these foundational topics either, like, I, I have two Computer Science degrees, and I never learned in my computer science degrees, how the DHCP Protocol works, you know, like no one told me what the host header means at any point during my computer science degrees. And so like, I feel like a lot of the time even if you do have like a more traditional background and you come out of school, and maybe after a couple of years, you're like wait, there's some stuff I really don't know, and you still need to learn it right? And that's fine.

Aaron Randall  8:03
Yeah 100%, I was going to say exactly the same thing. Like I have a computer science degree as well. I think we all do, but I was like, I still needed these zines to help me that's perfectly fine as well. Yeah. And you have a bunch of zines now, do you have like a stand out most popular one that people always like know you for or, or particularly love?

Julia Evans  8:25
It's hard to tell. I think the one I think people really love Bite Sized Linux. Um. What else do I hear about? I have one called "So you want to be a wizard", which I really love because it's about how I learn. Um,

Amy Phillips  8:43
I love that one.

Julia Evans  8:43
And I think it's sort of about like, I don't know if I think of it sort of as like the foundational zine.

Amy Phillips  8:56
So one of your other zines, one that we particularly like is your "Help! I have a manager!" zine, which the title just makes me laugh like, that's people's reaction. It's so great the way you describe the role of a manager, and probably better than most managers out there. Certainly a lot of managers describe their own jobs. But how did you learn about what your manager's job was? And like, how do you learn to work with them?

Julia Evans  9:24
Um, so I think the way I learned is I had a really great manager, who I worked with for a long time, maybe three years. His name is Jay. Hi, Jay. If you're listening to this, um, and I think what I learned from working with him was sort of just like what, like a really great, like, healthy, like, professional relationship with a manager can look like, you know, like, I was like, Oh, this is like how it should be. And that's, I basically, like wrote this zine as being like, here's what I learned from working with Jay, if that makes sense.

Amy Phillips  9:56
Yeah, that's great.

Aaron Randall  9:57
I love that and I really love um so there's a doodle at the beginning of the zine, which I hope is ok to share but it's two stick people, so you drew it, one of them says, like, isn't managing me their job. And the other one says, You're both adults working together, it's your job too, and I just love that idea that, like, at some point, you decided to be like an active participant in this relationship was was this with Jay that you decided that you need to co-own this relationship? Or was it somewhere else on the line?

Julia Evans  10:28
Yeah, I think that that, that that's how I learned it from working from working with Jay. Exactly. Like, I think, I think I learned like, what it meant to grow in that relationship, if that makes sense. I'm like, how it should actually work. Like, I might have had an abstract idea before, like, like, what it meant. Or maybe if you asked me if I should, I would have been like, sure. But I don't think I actually knew like how it worked.

Amy Phillips  10:49
Was it something that like he did, like how did you like it feels like at some point, there must be kind of some training or education or something to sort of like demonstrate to you that this was, this was how the relationship should form? Like, how did he go about teaching you that stuff?

Julia Evans  11:06
Amazing. I feel like you should have him on the show and ask him because I bet he would know the answer. I don't know. I mean, I think I think one thing that was really, that's really helpful in general, to me is like, anytime I, let's say ask my manager for something and they explain, like, why they can't do it, you know? And they're like, okay, these are like, the actual constraints of dealing with. Um, I think I've always found that really helpful. Because then I've been like, Oh, I see. This is like how the system I'm working in the works right. And like, there may be some constraints, but I didn't know about.

Aaron Randall  11:39
That's an interesting point. And I find that actually as a manager as well, that idea of like not leaving a void or filling in the voids with with actual context, I guess to explain to you like why decision certain decisions have been made. It's actually really important as well. And I guess as you're working with with Jay and becoming like a co owner of this Manager-Report relationship. What did you find are the biggest things that changed as a result?

Julia Evans  12:05
Um, I think I think I felt a lot more. Like, at the beginning, I think when I had a manager, like, I'd go to a one-on-one, and I'd be like, what do I talk about? Like, what? Like, do I need to be like justifying my existence to this person? Is it okay, like, are we? I don't know. Am I doing enough? And and I think that, like, once, we found a good way of working together, I didn't feel that sort of like, insecurity, you know, which really helped. I was just like, okay, like, I know where I stand, and I know, like, like, where we are. Um, I've already forgotten the original question.

Aaron Randall  12:42
I was, I was asking, really, as you began to co-own this relationship with your manager, I guess, like, what were the biggest things that changed as a result?

Julia Evans  12:48
Oh, yeah. So yeah, I feel like like understanding how, like how the relationship works really made me a lot more confident at work, and made me feel better about things like like when I started having a manager I'd be like, like, if we had to talk about like promotions or like compensation, I was just like, oh my god, like, I can't have this conversation, right? Like, I've no idea how to start. And like, once I had, like, a more clear relationship with my manager I'd be like, Oh, yeah, let's just talk about this. It's not a big deal, right? Like, like, I would know how to start this conversations. And everything got a lot less stressful.

Amy Phillips  13:22
Yeah, that's a really great point. Like so many people. I've worked in places where they sort of measure those sorts of conversations kind of as like employee engagement sort of measure, like health check. And the question will be sort of like, Oh, I can have meaningful conversations with my manager about pay. And what they were trying to ask about was like, you know, I can understand the pay, compensation process and things like that. And actually what ended up sort of surfacing it was people being like, Oh, I don't know if I am allowed to talk to my manager or how do I start that conversation, it threw up a completely different situation. That was much more that people just didn't feel like they knew how to even begin.

Julia Evans  14:04
Right. Yeah. Like, it's like, what are the first words that are supposed to come out of your mouth? Like? Yeah,

Amy Phillips  14:11
Yeah, that's right. Yeah, it's like a taboo topic. Like, it was really interesting. I kind of I love the fact that you've sort of highlighted this, like, We're adults, we need to work together. Like, why do you think that's just not obvious from the beginning? Is it something uniquely to tech? Or is it just like maybe the kind of manager-managee relationship? Do you think?

Julia Evans  14:31
Um, I don't, I think maybe it's, my guess is that anyone when they kind of like join the workforce doesn't really know like, how it works. You know, like, I feel like when I was a kid, I would read like the business section in the newspaper, and there's like, all these articles about like, how to do things at work, it was the most boring section. But now I kind of understand like where it's coming from, is that there a lot of adults that read the newspaper who are like, I don't understand how to like navigate my workplace, or like how it works. maybe like reading the business section to try and understand it. And so I feel like it's a problem. Like I don't think like, the way the modern workplace works like in tech or outside of tech is like obvious to anyone, like when at the beginning, right?

Aaron Randall  15:14
Totally. I mean, you covered it. I think you touched upon this so nice and succinctly in the zine with this sentence. Remember, managers are only human. So it's like such a wonderful phrase. And they're also like, Well, yeah, first of all, thank you for calling out the obvious but overlooked part of managers like we're all humans as well. But how, how do you think we normalize this and remember that both the people in this relationship are are humans and people will have off days and bad days and good days and so on?

Julia Evans  15:40
Yeah, I think I found it pretty helpful to learn about like so for example, once I I was asking my manager something about like remote compensation, um, because I worked remote. I've, I've actually only basically only worked with managers remotely. Anyway, and I think I thought at that time, that manager had some control over this. And what I learned was that he had no control over this. And he was like, you know, if you have an idea of like a case I can take to HR you can tell me but like, I this is not something but like I control it, you know, like, and that was like a kind of big eye opener for me because I was like, Oh, yeah, of course, like, in retrospect, it makes sense that like, you know, in like, a large growing company, like, like managers only can control some things. But I didn't like have any model at the time of like, what things a manager does have control over and what things they don't

Aaron Randall  16:37
make sense.

Amy Phillips  16:38
I think it's something that like, sometimes as a manager, you sort of don't want to maybe reveal how little control you have over over the workplace. It's kind of it's nice, sometimes people think you can do things and achieve things and you certainly have weeks where you don't manage to do any of these. Best not to mention it.

Aaron Randall  16:57
It's Patty McCord, who was Chief Talent Officer at Netflix we had on a previous episode, she said something about when you get promoted to become a manager. She said what was that phrase? She said, Oh, Congratulations, you've got two new things. You've got a new business card with your name on and you've now got the ability to read read your reports minds. I love the idea of like the fact that suddenly you become superhuman that you forget that actually, we don't know we're doing either lots of times, so call out. One of the things you've been mentioning, Julia actually is like one on ones. And again, that's a great topic that's covered in the zine. And you have some really nice suggestions for areas and things like promotions and other benefits you can talk about. What for you, what do you think is the purpose of having a one on one?

Julia Evans  17:40
So I think this might be different if you work with your manager in person. So I don't have a really good sense for that. Um, I worked remotely and so my one on one was the only time that I talked to my manager face to face ever, basically, right. Um, and so that that was like where the entire relationship got built and like, like cuz we didn't like we already talked over Slack but we didn't talk otherwise at all. Um, I guess unless it was in a meeting and so that's kind of how I thought about a one on one is you know like this is like your entire relationship with this person. Um but I think it might be different if you work with someone in person.

Amy Phillips  18:16
It's really interesting that this all came about cos like through remote working like do you like how did you kind of manage the one to one like, was there a structure right like Was there some sort of structure or format that went in because like you said, I think when you're in an office you kind of have these extra things you think about like which is where should I do this one to one like Should we go for a walk or is this the right meeting room like when you're doing this remotely? Particularly I suppose for a lot of people who have suddenly unexpectedly now doing this remotely? Like were, was there like extra or maybe not extra in your view, but like was there like structure and things like that around the around the meeting as well?

Julia Evans  18:55
I know that some people like to do really structured one on ones I don't think I've ever had those, um, I think it's been a lot more like, okay, I'll show up. Maybe I'll have some ideas. Some things I want to talk about, like, there's a project that like, sometimes I'll just be like, okay, let's like brainstorm some some things about like this project we're working on, like this problem that we have to solve, right? Or sometimes I'll be like, Hey, I noticed that this like problem with the team and like, what do you think about that? Like, what can we do about it? Um, I definitely like I think, I guess I think about one on ones a lot of like, like a place like problems or like talking about them. I think that can be really fun. Yeah,

Amy Phillips  19:32
It's really interesting. Like, do you think that your one one's like, always have a similar style? Cos I think that's the other thing, isn't it? You can sometimes end up in a little bit of a rut, like a one on one is always a discussion about the project or, you know, career or something like that. Like, how do you kind of mix it up? Because you call out so many different topics and things you can be covering in one to ones like should people be actually trying to move through those? A few of those topics at least?

Julia Evans  19:59
Yeah. I think it's important to talk about different topics because like, I feel like, again, like, I think in my context of like, this is your entire relationship with that person. Like, if there's someone who could be working with for like many years, like, it seems silly to only talk about one thing every time you talk, you know, like, you have to talk about lots of things to like learn how to work together effectively. And like, there's a lot of different, I don't know, like, there's compensation and there are projects, and there's like team dynamics, and there's just like, what's going on in the company in general? And like, what, like trying to understand that together?

Aaron Randall  20:33
Do you have space to particularly where you don't have that physical bumping into each other in the kitchen or in the office to catch up? That kind of the watercooler chat? Do you have space in your one on ones to like, get to know that person is as a human like, it's no more than just the work topics and the things you're working through is as employers, as colleagues, sorry.

Julia Evans  20:54
Um, I think other people like I don't know, I think different people have different approaches to this remote. I think that one consequence of working remote for me has been that I don't have a great idea of like, my coworkers personal lives, you know, like, like, there's some people who have like, become good friends with and who I actually know and other my friends. And I would like talk to them outside of work, but for most people, I think I have a sort of vague idea of like, this is what this person is like at work, you know, I know that they have kids, like maybe two. Like it's like a little I think that, like the details of their personal lives are a little sketchy sometimes. You know, like, I know, maybe they like cars. I don't know

Aaron Randall  21:32
How about as you transition to Wizard Zines and focus on that, working mostly independently, have you found going from my work in your team to working by itself.

Julia Evans  21:43
It was great to work in a team. I mean, I definitely miss having co workers and I've been trying to like figure out how to how to build out working with for people like now I work with freelancers sometimes which is really great. Like I've been working with a really great designer, which is fun, but it's definitely it's super different.

Amy Phillips  22:03
So what back sort of on the one on one stuff like, it kind of gets interesting with the, it's kind of feels hard for me anyway, if you don't have so much personal relationship with your manager, like, how do you bring up a problem with your manager? Like, is there a certain length of time that needs to elapse in the relationship before you feel comfortable, or is that other stuff that you feel like you can actually do to make this easier to like for people to actually bring more of themselves to the meeting I guess?

Julia Evans  22:31
Yeah. I, I'm trying to figure out how I think about this. Because I think that having a personal relationship is really different than having a work relationship and trying to like articulate how, what I mean by that. So for example, like at work, there are a lot of things that I value, like, I think it's important for there to be some, like for people to be included, right for people to be treated fairly. Um, and I think of those as sort of like my personal values at work. If that makes sense. So that's not really like, and I feel like I end up like bonding with people over things like that. So being like, okay, like, I don't understand the engineering levels. I don't think other people understand them, either. I think this is a problem, what should we do about this, you know, and I feel like that's a little bit more of like a like, like, that's not like strictly like, this is related to my programming job. But it's also like it is about my values, and what's important to me. Um, and so I think I built a lot of relationships at work with people like along those lines, right, which isn't necessarily about like what I like to do in my personal life. Yeah.

Amy Phillips  23:39
That's really great. I love that you brought up the values like that's so key, I think, like companies usually always have values that are written down, but actually, I don't think very many individuals like really take a lot of time to think about their individual values. And actually make sure that you're applying those so yeah, that's such a great point.

Julia Evans  23:57
Yeah, and I think I found it pretty easy to find people who sort of like share my values at work. And I think it's a nice thing to be able to like work with them on over over over a long period. Right?

Amy Phillips  24:07
Yeah, totally. And I think that's also kind of ties into this, like, in your zine you talk about the keeping conversations mostly constructive, bringing ideas and solutions and things like that, again, such a great point. Like, I'm so glad you brought that up. Because I don't think people necessarily always feel empowered to propose, like, they see a lot of problems and don't always feel empowered to actually come along with a load of solutions and ideas. I think you capture that really, really nicely. Yeah, super awesome.

Julia Evans  24:36
Yeah. And I think what I realized about like bringing up problems, I think maybe at first I thought that by managers would have more of an idea of how to solve solve the problems that I saw that they did, you know, like, I'd be like, oh, here's a problem and I thought they would just know what to do. As your laughter indicates, it turns out that this is not the case.

Aaron Randall  24:59
Did you discover that you wanted to be more proactive in bringing potential solutions to these conversations because there was a gap missing fromyour managers ability? Or was it something else?

Julia Evans  25:09
I think often they were able to do something, but I think I just realized that, like, my input was valuable, if that makes sense. Like, like, it wasn't that like, they just like, knew exactly what to do. It was more like, oh, we could all figure out what to do, if we all think about it. Um, but I think just realizing that like, if you see a problem, maybe other people don't know that, let's do that either. Otherwise, it wouldn't be happening. And so like, maybe your input into how to solve it is, you know, valuable.

Amy Phillips  25:34
Do you think there was something in like, your team or, or your managers like reaction that actually helped you realize that because that actually sounds like such a powerful thing to actually realize that you know, your your ideas and solutions really matter? And, you know, you your ideas are totally valid say, Was this something like maybe in the structure of the conversation or the feedback you've got or something like that, that actually really reinforced that for you?

Julia Evans  25:59
Yeah, I think Think that, like seeing people actually put my ideas into practice was really helpful. You know, like one, I think one big example of this, I can't think of a small example right now. Okay, now, here's a small example. Um, once I was mad about, I was working as an infrastructure engineer, and I was mad about our job description, because I thought it was too like,. like, it was like, Oh, you should know how to do these things. And I was like, This is nonsense. I didn't know how to do any of those things when I got this job. So obviously, you don't need to know how to do those things. Like, this is silly. Um, and so I brought this up to my manager at the time, and he was like, oh, yeah, great point. Why don't you write a different job description? That's more like how you think it should be? And I was like, oh, yeah, I could do that. Right. Like, probably I've never written the job description before, but why not? Um, and so I did. And then, you know, I got the feedback. I made the changes and they put it on the website. That was it, you know? And so I think like, like having yeah, being able to like actually see your ideas through. Instead of people being like, oh, that's cool. Like, that's the problem, but we can't do anything like really being like, yes and I think is really is really amazing.

Aaron Randall  27:09
That's awesome. A lot of that sound as well, like, you wouldn't be able to get that at every company. It sounds like something that's very much about like having a culture of like trust and autonomy as well. Is that is that the kind of things you had in that business?

Julia Evans  27:20
Yeah, yeah, I think that's really important. Like, it's hard. Like, you can't tell people like, Oh, you should tell me your ideas if you don't implement any of them. Right. Like, yeah, there definitely needs to be that ability.

Aaron Randall  27:34
One of the, I mean, staying on the kind of trust topic, I guess, one of the things that you mentioned previously in the chat was around promotions and kind of this idea, I guess, that there are a taboo subject. And I love this point, you make in the zine about treating promotions as just a normal thing that you can have a conversation about with your manager. And, and actually the idea that if their the people in their team are getting promoted, that makes the manager look good as well. Yeah. What kind of techniques do you use to actually have those kinds of promotion conversations with the manager?

Julia Evans  28:05
Um, this is a good question. So I think the last couple of times I got promoted, I was working with a manager who was already pretty good at getting people promoted. I think that I didn't realize that this was a skill that like managers could be better or worse at getting their team promoted. And I said that it is that some managers are not very good at this. Because well, anyway, for various reasons. And so I think that made it a lot easier, because if I, like I made I think maybe I brought up some, like, concern that my compensation and he was like, Oh, yeah, let's get you promoted. And I was like, Okay, sure. Let's do that. And then, you know, we did.

Aaron Randall  28:59
It sounds so simple when you say it like that.

Julia Evans  29:02
But I think that's really been my experience with it. Like, I think I've been very lucky in that way where I've had managers who have been like, yeah, like, let's get you, okay. And then they sort of explained to you like what what kinds of things I need to demonstrate. And then I've demonstrated the things.

Amy Phillips  29:19
It does seem so simple when you have someone who really understands, like it feels like it's the it's kind of the translation, right of there's a system in place or a document that exists that says, This is the stuff and it's like, the difficult bit is actually translating that into behaviors or projects or, or tasks that you can actually use to demonstrate the abilities. It's definitely it's definitely there are times where it's easier and harder.

Julia Evans  29:46
Yeah, yeah. And I think there is a social aspect to promotions that I didn't understand it all before, like much earlier in my career where like, I think at many companies to get promoted, your manager needs to explain to other managers why you should be promoted. Um, and so I think they like they need to feel confident in those conversations too. And like, that can be stressful for them, especially if they haven't done it very often before. I think it's kind of like sell you a little bit. And like, they don't want to be turned down. Because that makes them look bad, right? If they're like, Oh, this person should be promoted, and everyone else was like, No, definitely not, you know, and I think I didn't realize that there was like, that extra layer of like, you know, like, like a calibration unit or whatever that people had to go through.

Amy Phillips  30:28
Yeah, yeah, definitely. Yeah. And I think that kind of really comes into this like relationship side of it. So I think probably that's the other thing that maybe, well, everybody maybe doesn't really realize quite as much the value is managers need to have good relationships with other managers for those meetings, but also, I think, you know, people need to have good relationships with their peers, even in other teams because there's probably quite a lot of those moments coming along. Where calibration or being picked for projects or whatever it is actually don't realize that, you know, those comments you're making over lunch are really affecting you being put on this cool project or not.

Julia Evans  31:08
Yeah, yeah.

Amy Phillips  31:11
What do you like you mentioned kind of early on that you were, you've got lucky and you had like a really great manager. in Jay like, what? what's the what's your definition of a really great manager? Like what was the what was the stuff that you you got that meant he was better than all your other managers?

Julia Evans  31:26
Oh, man. Okay, great question. Um, what are what are some things let's try I would love to know also what, what what your definitions are? Um, okay. So I think the big one is likes managing. I'm like, I really love it when managers are like, Oh, I love my job. Like, I'm obsessed with this job. I got this team and they're doing all these cool things. And I get to like, tell everyone about it and like help them do it. Um, so I think I think that's huge. What, what else? I think there's like understanding the company really well, right? And like, understanding like the systems in the company, like how do projects get defined? Like what's going on in the like political ether, right? Like, I think I think that's, that's super valuable. What? What else is important? I've never been a manager and so I have trouble thinking about like, what the skills are, if that makes sense.

Aaron Randall  32:28
Yeah, I mean that that last point, you made a great one though I guess it goes back to a previous point you made as well, which is like, understand how the company works and the process side and also if your manager knows how it works, they can do things better for you, like get you promoted, and navigate that world. So yeah, it feels like yeah, yeah, totally, like a massive part of what you need to love as a manager to be good at, I guess so. Yeah, I definitely agree with that.

Julia Evans  32:49
Yeah. And there's definitely like executing engineering projects, right, which is like a huge thing, right? So it's like, okay, we have like this big project. Like, can they provide the support needed to like, get it done. which is I think there's a lot of like sub skills in that, right. But it's really important.

Aaron Randall  33:05
Nice. I would add another one to this as well maybe which again, you've already provide the example for, which is great is the the job spec one, like that idea of your manager coaching you through that, knowing that actually, you already had a great answer. And you could make this thing better and not just rewriting it for you and like letting you own that was a really nice example of them giving the space for their teams to do amazing work as well.

Julia Evans  33:25
Right, right. Like sort of like giving people stretch projects, and being like, hey, this is like what you could do next. Yeah, that's very true.

Amy Phillips  33:32
Yeah. Yeah. So awesome. Yeah. And the building whole relationship thing, right, I think Yeah. Like, that's the kind of foundation for everything. So I think, I think it's often just assumed it will happen, but it's certainly not. And I think when you're a new manager and you walk into a team, you're a bit like the new kid at school. You've got to do the work, you know, to get to know these people. Prove that you know some stuff and all of that. So It's definitely there's definitely some skills around that piece as well.

Julia Evans  34:02
Yeah, for sure.

Aaron Randall  34:04
One of the things I found very helpful, I'm interested in seeing if it's the same for your Julia is building that peer network of people that are going through similar experiences. And you can talk to about your experience maybe is working with your manager as an example. Is that something that you found, you've like invested in and built by either people inside your previous companies or maybe friends outside of work?

Julia Evans  34:25
Yeah, definitely. I think both with friends outside of work. I have like a Slack with like eight friends, where we talk about things and we're like, oh, this is what's going on. And what's nice about that is like as you grow together over time, like you learn more, right, and you like, you all have new problems. Which is really nice. Like, it's like you have gradually ascending levels of problems. By which the harder problems not worst problem hopefully, but like different problems. Um, and also at work, I had a few people who I tried to have weekly one on ones with again, because if I didn't have one on one with someone, I would never talk to them. So yeah, and that was super helpful

Aaron Randall  35:08
With that peer network that you built with your eight Slack friends, is that do you think they encompass your manager Voltron? As. Lara put it like your different sets of skills that other people will support you on?

Julia Evans  35:19
Oh, man, that's a great question. So yeah, because the Manager Voltron is all about like, they're like, your manager is gonna be missing some skills and you might need some, um, I don't know if that if that's like, I think it's definitely helpful. I'm trying to go where I would go for like, I I think a lot of my problems would be work problems like like problems that were maybe like more specific to the company. So I might go talk to like, maybe like another tech lead, you know, or like, like someone else at the company and be like, hey, like, I like I have this like, weird situation, like, what do you think, but also for technical problems. I think it can be really helpful to talk to someone like outside of the company to get a different a different view because often if you're working with like some technology like someone at some other company has had like similar problems like maybe they're ahead of you and like they're like no you keep on going down this path like this will happen. So I think like having a network like for people at different companies is extremely helpful for getting some perspective

Aaron Randall  36:21
Definitely

Amy Phillips  36:23
Yeah, it's definitely definitely on that tech road. Is this the way you would do this. definitely don't do that. I'm really curious that you said like, what I love the fact that in the in the zine you you put in kind of topics and kind of like great sort of things from other people. And we've got like, stuff from Camille Fournier's great book, The Managers Path as well as Lara's Voltron and things like that. How do you pick because like, I've kind of always a bit like, there are eight. I mean, those two are excellent. But there are eight million great books out there like how do you actually condense this down and go this is the one thing that will add to the zine and it will help at least a few more people.

Julia Evans  37:07
Yeah, so I only recommend stuff that I found helpful if that makes sense and I think I don't always find everything I read that helpful for me personally. So like Camille's writing, for example, is like, sometimes I'll read like just a blog post of her's, right? and I'll be like, Oh my God, my mind is blown. Like, who are you? How did you explain everything in this one blog post? Yeah. Like Camille is just outstanding. I like like her book The Manager's Path is is incredible. Um, and I also like Lara has written so many great posts that just like really, like condense the issue and like, you're like, that's it. That's what I wanted to say. But I didn't know like, or like, say, I don't know, I think I guess I would say I don't find most things helpful. And so I just like try to stick with the things that I find really helpful.

Amy Phillips  38:02
I think that's a great answer. I think like that. You're like, well, hang on. Wait, why? Actually I kind of like that your starting point is like, no. Unless you're really convinced.

Julia Evans  38:12
Yeah, there's definitely so many takes about tech culture, you know, and I feel like it's better to sometimes just let it wash over you like, okay,

Amy Phillips  38:21
definitely.

Aaron Randall  38:23
Julia, so you've got a blog post on the site called, "Get your work recognized? Write a brag document", which I love by the way, can you tell us what a brag document is and why you recommend people write one?

Julia Evans  38:34
Yeah, I would love to. Um, okay. So I think what happened here is, maybe I was talking to a manager about careers. I don't remember exactly what happened. And he was like, Julia, why don't you just write down like some stuff you did? Maybe you called it a career narrative. And I was like, Okay, I will write down some stuff I did. And I was like, okay, cool, this is really helpful. Um, and then I think, like, I realized that the reason that writing down some stuff you did is helpful is that like, managers do not know what stuff you did, actually. Like, I think that like, there's this idea, right? But like, if you do good work, people will recognize it, which I think is just like, it is like sometimes true. But I think it's like, probably not true. in a way that's like a little disappointing, but also like inevitable because like, people will just like, forget, you know, or like didn't see what you did. And so, and I think also in particular, one thing that I was interested in, is I think often women are less likely to like kind of promote their own accomplishments. I think I was often actually quite good at putting that accomplishments. But I think like, not everyone is right at some some people's like work. Like, you'll be like, Oh, hey, this person did this amazing thing and people will be like, really, I didn't know like, like it like and they won't realize like, how Important that person's work is. And so the idea of a brag document is the this basically, the idea is that, like, your manager should be able to know the facts of like what you did. And like, why it was important. And I kind of like, I was working the way the way, like, this brag document that came up is I was talking to my coworker, Carla Burnett, who's the best. And we were like, hey, let's organize a workshop for like, women to like, sort of like write down like our accomplishments. And then so that we like have something when it comes to getting promoted that we can go hey, here's stuff I did before like, Oh my god, you're the best, right and humble, like, like, That's the dream, right? Um, so we did this workshop and we came up with this like brag document template, and I think we shared like examples of like, what we what we'd written for ourselves. And the process kind of like spread throughout the company. And a lot of people ended up writing them and I think when I left someone told me that like the support team, like whenever someone new joins the support team like someone on  support would sit down and be like, Alright, you need to write your bag document, here's how it works like, here's the file. So it really kind of became a thing. And so I think after like it existed at company for a while, and people were really doing it. I wrote a blog post about it. And I was like, Hey, you should do this, like this is this is the thing that works, you know. So that's what it is.

Amy Phillips  41:24
So awesome. So we'll definitely link to that in the show notes. But like, I'm just sort of flicking through now so, I love that you've got like a full brag document template included in there. So for anyone who's just doing the audio, but obviously they should be reading as well as like, you've got like goals for this year, goals for next year. projects, collaboration and mentorship, design and documentation, company building, what you've learned, love that that's like so easy to just lose track of like all these, like when you're learning something is so hard, isn't it? And then like you immediately move on you forget that I never knew that thing. As well as outside of work. Super awesome.

Julia Evans  42:02
Yeah. And like, I think what I also realized was when I talked to some of my, like, more experienced coworkers that they'd be like, Oh, yeah, I do that. And I was like, Oh, well, no one told me I was supposed to do that, you know? Like, it's really something that I think a lot of people have been doing for a long time.

Amy Phillips  42:15
I think maybe it depends on the sort of companies you've worked up because I think if you've come from like a bigger company, or more established companies, they perhaps have like these kind of performance reviews, which structure like, self review in a slightly similar way, maybe. But I like it. I definitely haven't had that consistently. In all the companies I've worked at. It's definitely like, now I'm at the stage, right, like, can pick the best elements from all the different companies I've been at. But, you know, you definitely don't get that in the first sort of four companies you work at, so maybe that sort of ties in as well.

Julia Evans  42:50
Yeah. Yeah, I think so. But yeah, and also, I feel like, there's something a little bit different about performance reviews to me, which are like, I would write a lot more in a brag document that I'd write in a performance review. You know, like, if I was writing a self review, I feel like I would write like, 200 words. And if I was writing a brag document, like for, like everything I did, I might write like seven pages, you know. And it's like, here's all the stuff.

Amy Phillips  43:09
I think the name like, really influences it. Because it's not like self review. It's balanced. It's not balanced. It's bragging, it's only the really good stuff. I think that's what I love most like, I've worked in places before where I've had, like, so in, sort of, in England or Britain, we're quite self deprecating, you know, don't really brag about stuff. We're not good at bragging. When you work at companies that also have like US offices where people are bragging, but they're well naturally used to kind of like, selling themselves, right pitching their ideas and stuff. Wow, that was really hard to balance self reviews because the British ones were always super critical. I didn't achieve anything. I know nothing. You're like hang on wait, stop.

Aaron Randall  43:52
I think the point you made around the naming that you made Amy, like the fact that it's a it's called a brag document. Like you can't, you can't do like, you can't go halfway on it right? You have to go. You know, you're not filling the template in properly, if you don't brag.

Amy Phillips  44:06
Exactly. And you don't really want it to be like, yeah, if you've only got a couple of lines, you're still not bragging. that's just quietly mentioning.

Aaron Randall  44:13
Exactly as Julia said, seven pages or nothing.

Amy Phillips  44:18
So really sad to have to break this up, but in the interest of time, I want to move on to our super fun quickfire questions. So all of our guests on the humans task, humans plus tech podcast, try and get our actual podcast name correct. All of my guests get asked the same four questions. So Julia what is your top book recommendation?

Julia Evans  44:47
In this context? Definitely The Manager's Path.

Amy Phillips  44:50
Oh, yeah. Yeah, I feel like I literally got it right next to my desk. Just keep that one right there. It's, I like the fact that, like, it's relevant to so many different people, right? Like, yeah,

Julia Evans  45:01
yeah, like it's helpful, even if like, I've never been a manager and I still learned so much reading and it was also like, this is what the job the tech lead is. And I was like, you know, taking notes and then once I became a tech lead, I was like, oh my god like this. Like no one told me what my job. Okay.

Amy Phillips  45:17
Yeah, the tech lead role in particular seems to be the one that we keep the secret the biggest secret is about.

Julia Evans  45:25
Yeah, it's even secret from the tech leads often.

Amy Phillips  45:30
Most definitely. So, next question, what or who is your number one tip for keeping up with the industry?

Julia Evans  45:41
Um, I think I try, I don't think of it as like the industry is moving ahead and I am following it. I think I try to think of it more as like what are my questions about what I want to learn about And try to like, make sure that I'm like continually asking questions and like, trying to learn what I want. Does that make sense?

Amy Phillips  46:00
Yeah, that's a great one. So who inspires you?

Julia Evans  46:05
Um, Kelsey Hightower. I think like, what one thing that was really because like, obviously, he gives all these incredible talks. Um, and like, he like he taught me about Kubernetes like through his talks, and I was like,

Amy Phillips  46:23
he taught everybody about Kubernetes

Julia Evans  46:24
He did teach everybody about Kubernetes. But like, in addition, I think once I had a question about Kubernetes, and I don't know how I ended up DMing him because I certainly would not have DMed him about my question. I don't think but somehow I ended up like, talking to him on Twitter. And he was like, Oh, yeah, like, your problem sounds really interesting. Do you want to just like get on a video chat and talk about it. And I was like, Yes. Oh my god. We had this really helpful video chat about, like, what problems I was having with running Kubernetes he was so nice. And I was like, Who is this person? Um, and I really like I am not that great. And it made me really think about like, how I could be like more helpful to people in the future, you know? Like, like he's like really at a different level.

Amy Phillips  47:11
Yeah, he is incredibly helpful. It's quite staggering. Definitely, I agree with you definitely makes you feel a bit bad. I should help more people, I'm not even doing a fraction of what he does.

Julia Evans  47:22
Yeah.

Amy Phillips  47:24
And then what is the most ridiculous thing about you?

Julia Evans  47:29
Oh, no. Wait, I have no idea how to answer this question, though. I didn't know how I thought about it. And I really don't know what to say.

Aaron Randall  47:37
I feel like this question is really mean, Amy because no one ever really knows what to say. You're all good Julia.

Julia Evans  47:45
What's the most ridiculous thing about you?

Amy Phillips  47:48
I think it's probably the most ridiculous thing is I take I'm gonna take ridiculous in a slightly different way that I spend a lot of time thinking like, I really love writing and actually I do very little writing. I spend a lot of time thinking I like writing and a lot of time reading often about writing, but I actually do little amounts of actual writing. Which feels ridiculous to me.

Julia Evans  48:10
Yeah, I've the current problem right now with biking, where I really love biking and I'm not doing any.

Amy Phillips  48:17
Like, it's like a different hobby isn't it. It's like, I really like thinking about doing this.

Julia Evans  48:23
Yeah, yeah, totally.

Amy Phillips  48:25
So finally, where can people find out more about you Julia?

Julia Evans  48:30
I've a blog. Um, but you can find by googling my name, probably most easily. Um, I'm on Twitter. I post a lot of like comics about currently CSS and things that change over time. My zines are at Wizardzines.com.

Amy Phillips  48:48
Amazing. Thank you so much for talking to us today, Julia. It's been awesome.

Julia Evans  48:53
This has been so fun. Thank you.

Amy Phillips  48:55
We're huge fans of wizard zines. And so anyone who hasn't checked those out already, they should definitely, definitely go check that stuff out. But yeah, thank you so much.

Aaron Randall  49:05
Thanks a lot, Julia.

Amy Phillips  49:07
We'll share links to all the zines and books and other cool things that Julia mentioned over in the show notes on humansplus.tech. I'm Amy Phillips. This is Aaron Randall. And you've been listening to the Humans Plus Tech podcast.

Hi, we're Aaron & Amy! We’ve been managing tech teams for a combined 14 years, and over this time have learnt (often painfully) what does and doesn’t work. When it comes to building tech teams, we’ve learnt there’s no “one size fits all” approach, but there are some useful questions you can ask yourself in order to build the perfect team for your company.

Note - we’re using the term “team” to mean an autonomous group of people working to solve a specific problem. This may be a cross-functional product team working to increase retention, or it could be 3 developers working to make the database scale.

The Big Three!

Think you want to build a team? Great! Before getting into the details, start with The Big Three questions:

Where’s your product headed?

It’s hopefully rare that you’ll need to build a team to solve the problems of today. Usually we’re creating teams to set ourselves up for the future, so take the time to focus on what you’ll need in the next 6-12 months.

Do you have a well-defined product roadmap and a stable tech stack, and you’re looking for developers who can join your team and solve incremental problems for the business? Or perhaps you have a very unknown product future, and you need a team who can move quickly, ship lots of hacky prototypes, and validate ideas? Or maybe you’re somewhere in-between. Your answers to these questions will shape the type of team you need.

Work closely with your product owner to answer this question, they will be able to help you understand where the product is headed.

Have you validated the problem?

It’s easy to think that adding teams is always a good thing; that having more teams magically leads to getting more things done, but that might not always be the case! Before diving into the design of a full team, make sure that the problem exists, has been validated, and covers a technical domain that a team can own.

Not all validated problems deserve teams. Sometimes they’re too small, too vague, or simply not valuable enough to work on right now. If you can’t see a clear path to solving the problem then it can be better to wait – teams are expensive.

You can’t validate without doing. Form the smallest possible team to identify and answer the biggest open questions, and incrementally grow as you prove the team’s impact.

Do you really need more people to achieve this?

Sometimes there’s more work to be done, but the mission or technical domain is closely tied to another team. This could be a sign that the work should be tackled by your existing teams rather than by hiring more people. The more people involved, the higher the communication overheads, and you can end up moving more slowly as a result.

Start by assessing how easy it is for your existing teams to achieve their goals and try to optimise here first. In many cases the teams themselves can find smart ways of working to achieve bigger goals without needing more people. If this still isn’t enough, and an additional team would reduce existing team autonomy, then it might simply be about making some tough prioritisation calls to achieve your most pressing goals.

Unless the autonomy is definitely there we prefer to re-prioritise work rather than accidentally create a team that needs permission to perform.

The ‘Design your team’ checklist

Once you’ve answered The Big Three, it’s time to get into the details of what your team setup looks like.

How many people should you hire?

Once you’ve answered The Big Three, it’s time to think about how many people you should hire into your team. Often the budget will have been set before you reach this point, and your team size will be pre-determined based on what you can afford. If this isn’t the case, then you’ll need to decide what the right team size is.

It can be tempting to hire as many people as possible, but proceed with caution! Adding more people means scaling up the support system surrounding them, you’ll need more managers, more onboarding capacity, more office space, as well as the technical ability to run more teams in parallel.

We generally try to create teams with 3-6 developers per team – this is manageable from a communication perspective but big enough to create peer support and cover holidays and sick leave.

Permanent or not?

Hiring permanent people isn’t the only way to increase your team size. We’ve seen great results from teams that include contractors, consultants, and even interns. If you’re not totally sure that the problem needing to be solved will still be relevant in 6 months, then a not-permanent person could be perfect. These people tend to come in and start adding value quickly - they’re used to starting in new teams, and in many cases they’ll bring experience and skills that might be difficult to hire for.

The main gotcha to watch out for is that these people are not permanent. This is fine if the problem they’re working on is something that can be solved now, but if they’re working as a team member, make a plan to allow them to eventually leave without leaving a huge gap in your team.

If you're not sure whether a role should be permanent or not, err on the side of hiring contractors. Remember, these are humans, not resources! Hiring permanent employees is hard (and painful) to undo.

Generalists or specialists?

There are two broad categories of developer; full stack generalists and stack-specific specialists. Neither is “better” or “worse”, but one is almost definitely better suited to your needs.

Full stack generalists are perfect if you’re finding your feet or want the team to focus on lots of different parts of a problem. It can be easier to prioritise the work that needs doing rather than trying to find work suitable for specific people, and people in the team get the opportunity to learn new tech skills.

Stack-specific specialists work best once you know your direction and can commit to the technology stack. They have deep, and often niche skills that are critical for highly specialised, or high risk problems.

Unless we obviously need specific skills or experiences we prefer to go with generalists to give greater agility.

How are you going to build a diverse team?

No matter which way you look at it, diversity matters.

People with different backgrounds, life experiences, and opinions bring fresh perspectives to the problem. If you want a team that’s able to think outside of the box then you need to be hiring and retaining a diverse team.

Hiring processes are often biased toward people who “fit”, in the worst cases this boils down to selecting people based on their looks, hobbies or even, interest in drinking beer. Of course people should be able to work well together but thinking about how a candidate contributes to the culture rather than fits the existing one is a good place to start.  

It’s never too early to start working on team diversity.

What additional skills does your team need?

All teams need to decide what to work on, and how to work together, as well as write code, test it, and release it to production.

Some teams succeed without dedicated experts setting vision and ensuring quality, others struggle. Dedicated experts bring skills and experience that can quickly get a good process running but again, adding more people increases the communication overhead as well as the demands on the overall company support systems.

If you don’t choose dedicated experts make sure you know who will be picking up the stuff that still needs to happen. What are they dropping to make space for this?

What levels of experience do you need?

As you hire a team you’ll need to choose the right level of experience for each role. More experienced people are great at solving bigger, more complex problems whereas more junior people often enjoy getting the day-to-day stuff right.

Hiring only experienced people is an expensive approach, but although junior people cost you less money they need proper support and training to help them become the experienced team member of the future.

Everyone, no matter what level, wants to learn and progress. For more junior people this is usually straightforward, giving them increasingly complicated problems as they grow. For more experienced people you might need to think a bit harder about how you’ll mentor and grow them.

We like to focus initially on hiring an experienced, core team. Later these people will be able to support juniors and grow your team.

To recap

Start with The Big Three. Once you can confidently answer those, you can start designing your team.

Two things to remember:

• Hiring is not the default – if you’re not sure, it’s probably better to not hire. Remember, these are humans, not resources. Hiring is hard to undo.
• The finer details are more forgiving – it doesn’t matter if you don’t get the smaller details of your team exactly right the first time round. Your team is a smart group of adults, trust them. You can course correct as you go.

Building teams is hard! But if you’ve read this far it means you’re taking it seriously, which is good – great teams don’t happen by accident!

Pat Kua joins us to chat about Tech Leadership and engineering culture.

Pat’s an incredibly experienced tech leader, most recently as CTO at N26. He’s also a regular keynote speaker, mentor, author of 3 books, and curator of the awesome Level Up newsletter. He recently launched the Tech Lead academy with his first course - Time Management for Tech Leaders.

This episode, along with all our previous episodes is available on your favourite podcast player. Listen and subscribe here.

Scroll down to read the full transcript of our chat with Pat.

Pat's quick fire answers

• Pat's top book recommendation is Thinking In Systems by Donella Meadows.
• The one tip Pat wishes he'd received when he first moved into tech leadership is to find a mentor.
• Martin Fowler inspires Pat.
• The most ridiculous thing about Pat is that he doesn't think he's very funny.

We also cover

1) Time management for Tech leaders, and especially for Tech leads. [00:02:01]

2) TechLead.Academy, and Pat's new course Time Management for Technical Leaders [00:03:38]

3) Multiplier vs. Maker modes and how to prioritise your time [00:03:47]

4) Productivity tips and using a Send Later email feature [00:06:01]

5) What makes a great tech lead? [00:07:50]

6) The tendency to over-do process [00:10:21]

7) Why Tech Leads need more support, and often from outside an organisation [00:12:10]

8) Conflict resolution and other tech lead responsibilities [00:15:00]

9) The things Pat wishes he'd known when he started out as a tech lead [00:17:03]

10) The things that Pat wishes every developer knew about management [00:19:21]

11) Pat's recent talk The Secrets of a Strong Engineering Culture [00:20:56]

12) How to grow a team from 50 to 370 people (at N26) and maintain a great engineering culture [00:24:52]

13) Breaking down dependencies and Conway's Law [00:31:03]

Find out more, and follow Pat

Find out more about Pat at https://www.patkua.com/ and make sure you sign up for Pat's awesome newsletter levelup.patkua.com

Full transcript

Amy Phillips  0:02
Welcome to the Humans+Tech podcast. I'm Amy Phillips. And this is Aaron Randall.

Aaron Randall  0:07
Hi.

Amy Phillips  0:08
Today we're so excited to be talking to the one and only Patrick Kua. Pat's an incredibly experienced tech leader, most recently as CTO and N26. He's also a regular keynote speaker, mentor, author of three books, and curator of the awesome Level Up newsletter. He's recently launched the Tech Lead Academy with his first course 'Time Management for Tech Leaders', so Pat, welcome to the show.

Pat Kua  0:32
Thank you for having me. It's a great pleasure to speak to both of you.

Amy Phillips  0:36
So to dive straight into possibly maybe our favorite part of the show where

Aaron Randall  0:42
the most important part of the show

Amy Phillips  0:44
definitely the most important part of the show. It's really kind of like customary for us to draw all of our Humans+Tech guests a doodle of them which we put in the show notes. So I'm going to show you your doodle be great to get some feedback you know, just we're going for like likeness of course.

Pat Kua  1:02
Okay.

Aaron Randall  1:05
I'm really sorry in advance.

Pat Kua  1:06
This is exciting. I have no talent for drawing, so

Aaron Randall  1:09
I would, neither do I apparently.

Pat Kua  1:13
Oh, that's really good. I like it, I like it

Aaron Randall  1:20
I really focus on, I think I've got the glasses right.

Pat Kua  1:25
You've got all the characteristics

Amy Phillips  1:33
Yeah.

Aaron Randall  1:34
Amy was saying before for the show that I made you that like a sausage

Amy Phillips  1:37
I think you came off like kind of unfortunate. I think people had longer hair look less like everyone's kind of same basic shape.

Aaron Randall  1:51
Say, yeah, there we go. Great. Well, that's the important stuff done. Sorry again, apologies in advance. And so as Amy mentioned, you recently launched TechLead.Academy.

Pat Kua  2:00
Yeah.

Aaron Randall  2:01
Where you're running a course on time management for tech leaders. Why do you think time management is such a common problem for tech leaders?

Pat Kua  2:08
Yeah, it's one of those issues which, you know, I think not just tech leaders struggle with, but anybody in general. And one of the things that I think was really beneficial, or I learned a lot through consulting was how to manage my own time. It's like one of those things where you kind of have to be independent a lot and try to work out how to get the most done, often without a lot of support. You know, you're obviously working with the team and things like that. But it's one of those things that I think a lot of leaders when they fall into this role for the first time, nobody's really given them skills. So just like a lot of other skills that are needed to be a good leader, nobody's teaching them these are important things you need to focus on. And so what normally happens is when people fall into that, that sort of role, you know, they're sort of overwhelmed. I think, by all the other things that they have to do that they don't really think about how do they manage their own productivity. And you know, there's kind of the awareness problem, you don't know what you don't know, and then realize that it's a problem. And then you're maybe a little bit overwhelmed to actually solve it. And so you know, one of my things that I normally do for first time leaders is walk people through how to manage their own time. Because, you know, the less time you have, the more reactionary you're going to be, the more stress you have, the less time you end up with, and you end up in this vicious cycle. And so I want to help people basically change that cycle to a positive cycle of if you manage your time well, you'll be able to react a lot more thoughtfully, you'll be calmer, and then that will actually help you create more time.

Aaron Randall  3:38
That's awesome. And without giving away too much in the syllabus because obviously that's your job is to teach it a sense of the kinds of things you're going to cover in that course.

Pat Kua  3:47
Yeah, absolutely. Um, you know, I think one of the topics I cover in there is kind of like this difference between sort of maker and manager mode. I kind of prefer the term multiplier because not all technical leaders are managers, but you know there's a difference between working at a keyboard tapping away deep thought, and then switching into lots of context switching lots of interrupt mode of meeting to meeting to meeting conversation to conversation. And those two worlds don't really mix together. And you know, I've been there myself where you're just sort of caught in between. And if you're not explicit in managing that sort of separation of sort of maker versus manager or multiplayer time, then you're just going to get really stressed out. So that's an example around that sort of example. I think one of the other things that I can sort of cover is really about, like, how do you start to prioritize your time? This is one of those things that you know, when you're working as an individual contributor or a team member, normally the team has a process to manage priorities. But suddenly, when you're that sort of leader, it's like, oh, you just have this influx of things. Lots more things to do. You don't really know you say yes to everything. And once again, part of the art of prioritizing is knowing what to say no to or maybe not yet, and how to break things into smaller chunks. So that's another sort of key thing about a key topic that we cover.

Aaron Randall  5:08
I mean, I wish I had this.

Amy Phillips  5:11
Like these are skills I definitely would love to have. Like it is really hard, though. And I think it's, I've definitely seen a lot of I've been in a lot of conversations where people are saying, like, you know, I'm going to, you know, I need to, I don't know, write this piece of documentation, should this be a JIRA ticket? And it's like, you know, yeah, so like you say we've got really good processes for prioritizing and tracking, like normal, normal work. But as soon as you step outside of like, it's not code or it's not something the team cares about It can be really hard to fit that in.

Pat Kua  5:41
Exactly. Yeah. And I think one of the things that I noticed is that you tend to like watch other people when you're in that sort of thing about asking them how do you like cope with this, kind of a building out toolkit, and I think that's the other sort of side of it is that you kind of never done with it. Like, I still always look for other productivity tips and ways that other people do things and I still learn from like everyone about like different, you know, ways of managing email or calendars or other sort of time activities. Yeah. And so you're never ever done.

Amy Phillips  6:10
I love that, like, how can we get a productivity tip? Like I love these things.

Pat Kua  6:15
Yeah. So my favorite is actually using the Send Later in Gmail. So part of that is it's like as a manager or leader, you know, some people feel like you have to instantly respond. And obviously, if you do this to people who they perceive you as a leader, they feel you know, they have to respond to you immediately. And sometimes when you're processing a whole bunch of emails in one block, I don't want to trigger a whole bunch of replies immediately. And I don't want to like sort of stress other people out so I love the whole Send Later kind of feature. My hack before it was actually available in Gmail was actually to put calendar reminders in so I'd save drafts, and then have calendar reminders to actually send them. We couldn't quite connect something like Boomerang, which was an add-on to Gmail just because it has access to all your emails

Amy Phillips  7:02
I think that's so important though, like I do, like I'd love to be able to work as a time which you know, suits me and obviously other people ideally should do the same. But sometimes that is like, Saturday morning at eight o'clock and it looks terrible. I don't want to say that everybody should be writing emails at eight o'clock on Saturday, but for me that actually sometimes it's exactly when I want to write them. So yeah, I love that send later. People must this I'm so productive at eight o'clock on a Monday morning.

Aaron Randall  7:32
12 emails go out and same time. Yeah. I do that thing with it where I give it like send in the morning at 9am I always make it like 9:04. What monster leaves it at a round number? Yeah.

Amy Phillips  7:50
Awesome. So I love the bit, that sort of you mentioned as well there about like people falling into this role becaus e I think one thing Aaron and I were actually talking a little bit earlier about tech leads and it's like It's such a critical role. But also, it's quite a difficult role, because it's probably the first time you're in kind of leadership. And you are probably still writing quite a bit of code, but also sort of playing this multiplier right. I know that you've actually given quite a lot of talks about and actually read a book about as well. which is quite cool. So what what do you think makes a great tech lead?

Pat Kua  8:23
Yeah, it's a good question. You know, I think a great tech lead is a person who knows how to be flexible in their leadership style. And I think part of that is obviously you build up experience over time. But I think you know, the trap that a lot of first time tech leaders fall into is still thinking like a developer, right? They want to be the expert person, they want to deal with all the hard problems they want to be seen as the go to person for all the questions and information. And you know, if you're with a team of very inexperienced people, you know, the most senior developer a tech lead may be suitable to be the person who gives answers. But that's not going to be sustainable as people learn and grow. And you know, as more work comes to a team. And so I think that's a real key for a lot of successful tech leaders is that they know how to adapt that style. I think the other thing, why I sort of focus on this sort of adaptability is, you know, everyone is really different. Everyone has personal preferences, styles, communication, wants and dis-wants. And you know, I think a lot of first time tech leaders fall into that trap where, you know, everyone will they believe that everyone acts and feels the same as they do. And I think that's the interesting thing. And you know, this both being like managers and leaders, of the variety of people, things that your preferences and differences that you've never ever done, you can never really predict. You think you'll you know, you know how somebody's gonna react, but you never, you're always surprised, right? And I think that's the thing of like a good tech lead of being able to be flexible in understanding you know, some people will maybe want to have one to ones and be told news personally. Other people would perhaps like to read things more so than be dragged into a meeting or, you know, have some time to digest information before talking stuff through. Some people will want to work through a problem other people need to talk through a problem. And so you know, there's all of these different styles that you sort of build up over time through experiences. And I think that's what really makes a great tech lead.

Amy Phillips  10:20
I mean, love that. Yeah,

Aaron Randall  10:21
that's awesome. And when you're talking about those traits, it made me think about the times I've helped create new tech leads in my teams over the years. One of the things that I've noticed in them is that they tend, there's a tendency to create process everywhere, as they're stepping up. And I've seen it as a patten I've observed I was wondering, have you seen that and why do you think happens?

Pat Kua  10:45
Yeah, I think so. I think some of the process that I think comes is you know, people going you kind of imprint like you think about like what other people have done who you like, either respect or often it's the I don't want to do this bad thing because I had a bad lead or a bad manager. So I'll do the opposite. And so it's often like the strong reaction to, you know, this kind of first time falling into that role. I think it's also just an actual consequence of learning. Right? So I think, you know, I've studied a little different learning models, if you take the shoe heart re shoe is like you follow the rules, right? And I think the process is an example of following rules. And then over time, you start to work out those rules start to break, they don't apply everywhere. Oh, my goodness, this world is much more complex. Hopefully, people get there really fast instead of, you know, using this process and overhead all the time. And I think that's the hard thing about a lot of leaders is that they don't get a lot of support. And, you know, the experiment is kind of their team, right. And so that's kind of a hard thing to experiment with, because it's having impact on people on work product. It's harder to make mistakes than you know, writing a bit of code on a sort of dev machine and having it break. And so I think that's why a lot of organizations and it's great to hear that, you know, you've been supporting people in that, because I also think it's a responsibility of all leaders to sort of support new leaders, because a lot of organizations do it really poorly.

Aaron Randall  12:10
Mm hmm. I mean, let's talk about that as well that's a great point. Amazing that TechLead.Academy exists, and that you've created something that helps train tech leads, but why do you think that needs to exist? Why why tech is not getting the support they need in house?

Pat Kua  12:24
Yeah, I, it's an interesting question, because I've puzzled a long time around this. And I'll give you a little bit of history about how a lot of the training that I sort of built came about is that, you know, I also suffered as a first time tech lead. I got a call from staffing, you know, asking me to take on this role. Nobody really walked me through what was the differences? Like what did I need to focus on what did good look like? Where did I have skill gaps? Or, you know, where did I need to start focusing, you know, my own personal development. And you know, sometimes it's like one of those things where that sort of sink or swim kind of experience can really turn people off leadership or it can really, you know, help you gain a lot of confidence. And, you know, I saw a lot of people go through this process of being a first time tech lead, I talked to a lot of people around this in the book as well. And I think one interesting thing is a lot of support. Learning development often comes from kind of the people team or HR department. And it's kind of interesting, because they kind of have a high level idea about like what these people do, but it's out of context, and they don't really know the day to day. And so the consequences is they often organize leadership training it has a cross section of people across the organization. It's really great because you build a network and you learn some generals and leadership skills, but the scenarios that you're going to play with and the problems that you're going to face in your context as a tech lead, are very different than if you're going to be leading a team, say in marketing or in a sort of sales team. And so it's very hard to then translate that sort of theoretical or the classroom experience into, like, here's a situation gonna have like, what are your options? How are you going to deal with it? What might go wrong with that. And so I realized it had to come from people who sort of been there before, but also who could teach because I think that's the other sort of aspect of it is that, you know, obviously get other people at tell other tech leads, here's how you have to do it. But once again, that adaptability is a reflection of experience of understanding people will lead differently, they'll have to also take on skills differently, they'll need to learn differently. And so it's just really hard to get that support for a lot of people.

Amy Phillips  14:34
Like, like, I think it is really interesting, like when if you're lucky you get some in-house training, but but yeah, it probably doesn't help you balance like the, you know, one hand you've got, like some production incident that you're suddenly quite responsible for, but also, you know, someone else on your team is upset in a different, completely different reason in a different way. And you kind of got to juggle these two new problems.

Pat Kua  15:00
Yeah, exactly. Yeah. And and one of the examples that we normally cover in the course is around sort of conflict resolution, right, with developers arguing over which library do I use for this thing? I have two solutions, and you just have these developers butting heads. It's like, now you have to come in and like, work out how to get this, you know, through. And that's something that people just don't really, you know, get walked through that example.

Amy Phillips  15:22
Yeah, so true. And I think probably one of the other things, which I think is maybe uniquely difficult at this stage is that I think most tech leads are kind of promoted into the role like like, especially like new tech leads which means they go from being one of the team to suddenly leading this team. And that's quite a difficult transition as well, I think.

Pat Kua  15:41
Yes, yeah, definitely. There's sort of that peer to being a leader, sort of transition, change in relationships. I also forgot to add that I think with tech leads in particular, there's a slight difference as well with them stepping into a leadership role, or the tech lead role because there's also this idea of architecture that often doesn't really get talked about and so this is something that, you know, a lot of developers have never had an experience with, because their tech leads took care of a lot of that, right. So if you're building a new system, you're often in conversations with people in operations infrastructure, if you're in a place where you host it, you have a lot of procurement processes, potentially, a lot of upfront planning, you have to involve support people, you have to think about all these other things. And often the rest of the team aren't even aware about a lot of that responsibility, because the tech lead was taking care of it. And so when they fall into that role, that's another trap is that any of these sort of broader systems sort of architecture perspectives, they don't realize it's their responsibility. And no leadership course is going to teach them that it's actually they have to deal with these

Amy Phillips  16:44
And I guess that ties right back to the whole time management challenge as well, which is, you've suddenly got this whole you're expected to have a, I don't know like a two year roadmap and you're worrying about this bug.

Aaron Randall  16:59
And you've got no time to write code.

Amy Phillips  17:03
One of your talks you've given in the past Pat was called 'What I wish I knew as a first time tech lead' What, What do you wish that you had known? or What do you wish that every tech lead knew when they started out in the role?

Pat Kua  17:17
Ah, that's a while ago that talk. So I was going to have to think back but off the cuff, I think. I think one thing is like how your where your value is or where your reward center is. And I think that's why it's an interesting thing of thinking about this maker versus multiplier mindset. Because I think, you know, makers, you get the satisfaction. And I know, this as a developer, I still love writing code and seeing the output and seeing this kind of fast result. But then when you're leading a team, you're often not writing a lot of code and you're kind of like feeling guilty because it's like, ah, but like, I don't have anything visible like I haven't been putting features through. And you know, that's another thing that fits the time management thing of like you're trying to put as many features through as every other developer, but then you're also trying to take care of all these other responsibilities. And actually just simply that message and helping new people in that role understand, actually, if you're spending that much time writing code, you're probably not taking care of a lot of other things that you are responsible for. So it's okay. And nobody is giving them that reassurance of actually, you know, like, here is where you should be adding your value. And here are the sort of, I guess, signs that you're doing this, you know, the team is healthy, the code quality isn't diminishing, is that, you know, developers productivity is going well, because you're managing things like build times, test times, being able to deploy things really rapidly give people fast feedback, working well with product people, so that, you know, it's balancing technical risk, as well as delivering value not just going off and building your own technical solution, because it's fun. You know, it's all of these interesting sort of reward signs, but nobody tells you what they are. And I think that would have been, you know, just a simple walkthrough of like, what this role is why it's so different. And also just how to prepare yourself for it.

Aaron Randall  19:05
That's a great I remember, like, after a little while of tech leading having to ask myself the question like, what am I not doing when I'm doing this? And when I'm writing code, there's always stuff I should have been doing that no one else in team would have done because not their job as they're not the tech lead. And yeah, just falls to the wayside.

Pat Kua  19:20
Yeah.

Aaron Randall  19:20
Good to remind yourself.

Pat Kua  19:21
And it's really interesting, actually, because I think, you know, there's the what I wish I knew as a first time tech lead, but I think actually, there's something that what I wish every developer knew about leaders and managers, because I think that's the other flip side is that people don't understand the value add. And, you know, I'm a little bit tired of developers kind of automatically dismissing managers as overhead or leaders, because there is a huge value add, and often their association is really with bad management, bad leaders, which is totally understandable if people get thrown in there for the first time without a lot of support, right, it's a bad system that kind of does that. But there are also so many excellent leaders and managers out there and they do add a lot of value and I think that's something that I wish that a lot of developers and makers really understood about the value of good management, the value of good leadership, because it just makes everyone's life a lot easier.

Aaron Randall  20:08
How do we do that? That's such a great point.

Pat Kua  20:12
Well, I don't know how you how it's possible. But I think one thought experiment I've had, but it's a little bit harsh, is like forcing people to have a bad manager and then to have a good manager, because then they start to realize the contrast effect.

Amy Phillips  20:26
Yeah, I think that's true. I mean, I feel like most people, unfortunately do have certainly had at least one bad manager. So yeah, but it's it is quite surprising to me how many people have not had a good manager or not, maybe not a good manager for them. I think that's the other piece, right? Like, yeah, yeah. It's such a shame like the poor people who've never had a good manager. It's like they're missing out so much.

Aaron Randall  20:52
It's really disappointing, very sad.

Amy Phillips  20:54
It really is. Yeah.

Aaron Randall  20:56
So you recently gave a talk called The Secrets of a Strong Engineering Culture'.

Pat Kua  21:00
Yeah.

Aaron Randall  21:01
What do you think are the key elements in creating a healthy culture for a tech team?

Pat Kua  21:05
Yeah, I think there's a lot of things that leaders can do around culture. And I think the first thing I want to sort of say is that culture is not something that you create, for me, it's something and I use the metaphor of like gardening. And in reality, I'm a really bad gardener. I can't keep anything alive I think I'm not consistent enough, maybe I care more about people than about like plants. But um, you know, like, a gardening sort of metaphor, you can't force a plant to grow. Right. And I think that's the other thing is that I think sometimes there's this metaphor of like, leaders, being parents treating people as like children, and I don't really like that metaphor, because you are also dealing with adults, right? So they also have a sense of individuality. You know, and, for me, a lot of the things that you can do as a leader is really thinking about those traits that you couldn't foster that sort of create the best environment for those people to thrive. So that's the sort of fertilizing metaphor. Thinking about like, what nutrients or sunlight, or water, but also being very deliberate about the type of culture that you want to create. And I think that's the exciting thing about being a leader is that you sort of get to focus on that a lot more, right? So if you want to encourage more collaboration, you know, measuring people as a team, rather than as individuals is a really great way of starting to sort of do this and encourage people to want to work together because they're measured by being working together, versus very individual sort of targets or goals. You know, I think the other thing that I see about cultivating good engineering culture is that, you know, there's a big mindset shift. I'm working on a course about systems thinking, and it's all about mental models. One of the mental models we're talking about is like the idea of, you know, developers, like just people that you tell what to do, right? They like factory workers, you like build the plan, and then everyone just, the developers will execute and you know, I don't know of any developer that's like that unless they've been beaten by the system, where all their creativity is already been sort of beaten out of them for being punished. But most engineers want to learn, they want to solve problems, and they want to add value, right? So the reason why I think a lot of developers get into programming is because they get to solve problems. They learn new tools, they learn new approaches. And I think that's a huge mindset shift of thinking about how do you foster that environment where you basically are sort of giving them hairy, bigger problems, but also making sure that they can solve them without sort of failing spectacularly. But you don't need to be the person that is like the person solving the problem for them, and then telling them how to actually solve it. It's really creating that right environment where people feel empowered. And you know, I think one of the good books around this is the Dan Pink's Drive book, which talks about this sort of autonomy mastery purpose, where, you know, the autonomy thing is that developers get to choose, I guess the way that they break down a problem they may not necessary get to choose the problems that they have, because every organization needs to have like priorities, right? So there needs to be some sort of how it links to the greater good. But I think that if that's done well, you can then link that to the greater purpose of the mission of the company of whatever the product is and help people see that path to how their work contributes for greater sort of good. And I think when I think about the engineering cultures, where it's like, really good and versus where it's really bad, it's often where, you know, developers are really close to the customer, because they can see the impact of the work that they're having an immediate value. The further I think developers away from an end user and a customer, the more that they're just going to start to play around with tools because they don't really understand how their work solves real world problems. Yeah, so there's some of the things that I would be thinking about with like engineering culture.

Aaron Randall  24:52
That's awesome. Um, I guess, leading on from that, you know, so you mentioned before we started recording the podcast, you you've worked at N26 and grew the team there from five to 110 people did you say?

Pat Kua  25:05
it was from 50 to 370 People

Aaron Randall  25:07
Oh, wow. Even more so. So significant growth. And by the way, I love the gardening metaphor for culture. I think that's amazing. My question is, as you take a team though that kind of growth, and a culture presumably does change, like how do you keep a healthy engineering culture through that kind of rapid growth and scaling?

Pat Kua  25:26
Yeah, so one of the things that we were really deliberate with, with our growth was really thinking about at different scales and stages 'what does autonomy look like?' And I think this is one of the hard things about people who've been at startups, and they see that rapid growth is that, you know, there's a sense of impact feels less like if you're five people, it feels like can change everything. But you know, when I left N26, I think the whole company was about 1700 people. Right? And if you were one of those early stage people, obviously it's like, well, like what are the rest of the people doing? What am I doing and and how is that actually having a big impact? And I think part of the art, I guess, of scaling an organization through that process is once again trying to help people understand where their boundaries of autonomy, or, where their purpose, right. So having a developer that's trying to fix everyone's sort of product issues. firefighting is okay in the very, very early stage of a startup. Because it's not very probably many customers, there's not too much sort of code or too many products. But as your product sort of grows, as you have more complexity, you're just going to be on a path to burnout. And so that's one thing that I really wanted to balance out is helping people understand it's not because like, we don't want you to have access to all of these different products, but you know, you're not going to be able to do that sustainably. Right. So you know, we have lots of engineering teams building lots to code evolving lots of products, one person can't keep all of the changes in their head, and that level of complexity without you know, breaking down or burning themselves out at some point. And so what we used is what I call the Target Operating model which talks about what is a stage of, for a certain stage of the organization or number sort of size, what is a good balance of that structure that allows us to maintain the right level of autonomy and alignment. So, as a counter example, it doesn't make sense to have 50 teams when you have 50 people, right? So that's obviously too much overkill. And it probably doesn't make sense to probably have 20 teams either, because then there's small teams, lots of coordination. And so as a sort of team or group grows, it's trying to like create those identities that allow teams to work. So rather than having lots of people, it's really thinking about units as teams, and how do they work well, effectively around a particular goal or unit where they can have value, autonomy as much as possible. And also they can have a lot of speed without needing to coordinate with a lot of other organizations. And this is kind of, I guess, The inverse Conway kind of law of thinking about, okay, looking at your product, what are the areas that can be mostly independent, and grow a team and then maybe a small department or organization there. So to give you an idea, when I came in, we were about 50 people in tech, which included helpdesk and security. And then what we had with Target Operating Model Version One was planning for about 120 people. And so here is where we decided to have sort of very clear team boundaries. At least nominally, a lot of them were obviously very empty and theoretical until we actually started hiring people. But at least we understood about the sort of areas where, you know, we didn't want to add more people to a certain product because it wasn't complex enough, you just have people stepping on each other's toes. Other product areas, were not enough engineers, a lot of people on the path to burnout there as well. So they needed a lot more capacity, but also there was a lot more sort of essential complexity. So you can add in more teams that took care of certain parts of complexity there. But then, you know, as we hit about 120 150, people, obviously just having a lot of teams around, if you will, then even just taking a planning session with one person from each of those groups. You know, that's a meeting with 15 people, which is quite a lot as well. So and so this is where we evolved our model to go to Target Operating Model 1.1 where we introduced the idea of groups, so groups being a sort of collection of different teams in a product area. And then they will focus on a particular theme. So as an example, we had a group around payment infrastructure. So if you've ever dealt with payment infrastructure, it's very complex, very low level lots of standards. And also being a bank in Europe we had and moving to the UK into the US with lots of payment schemes galore. And so there's a lot of sort of, well, essential complexity, but it's also a little bit invisible because you don't really see it from a user perspective. So we can have a group around that. We could then have lots of sub teams within that group that could be focused on certain areas of complexity and grow and manage that. And then, as I left, we started a office in Barcelona, which ended up being about 110 people. We wanted that to be mostly independent as well. And, you know, the organization was growing. And so we also introduced the idea of segments. And this is the idea of how groups connected to a segment in that they will try to shift the same sort of major business goal. So we had a group around growth, for example, around sort of customer onboarding, all the things to do with sort of, I guess, SEO, all the onboarding channels, sort of lifecycle, which is a little bit more expensive, I guess, in banking, because of identity verification, and all these other processes. So all the groups that had anything to do with customer growth, were then sort of grouped together in a segment. And so that segment could sort of manage all its parties, and it's really just about trying to minimize the dependencies to reduce coordination. So teams and Groups can be as effective as possible.

Amy Phillips  31:03
So in terms of the sort of breaking down dependencies, I guess I'm kind of curious on like, that sounds like a very nice, neat growth sort of path, I imagine it gets messy in moments. But like, how did you go about like, was there, was there a time where you sort of realized like, Oh, actually, these two teams, they're in completely different places, but actually had some unexpected dependency? Like, how do you actually like, break those things apart?

Pat Kua  31:30
Yeah, it's a really great question. And I think I know a lot of people that go oh, another reorg or whatever. And I think part of that is a realization about Conway's Law. If you're adapting Conway's Law. One of the interesting things that I didn't really maybe appreciate as much as a consultant of helping companies go through this approach is, you know, as a consultant, you come in, you see a snapshot, you help people model like the domain, come up with dependencies, and you know, people then implement it, but in a startup really rapidly growing the interesting thing is the product changes really rapidly as well. And so I think that's the other thing is that, you know, as you add in complexity, the business is taking a bet, you don't really know how to deal with that complexity. So it's like, Okay, give it to an existing team. But at some point, you know, the complexity maybe has a life of its own, and it's a product area significant enough. And so if we're refactoring our architectures to maybe pull out a service, it also, then logically concludes, we should probably pull out a team to focus around that business capability. And so I think that's the thing, just like you get code wrong, and you have to refactor, sometimes rearchitect pieces, you kind of have to do the same to your organization as it's growing and learning. So I think that's the thing that I saw really rapidly in a very hyper growth sort of environment, just because product changes really, really rapidly, more complexity keeps adding in. And so you have to kind of respond to that and you make mistakes, right? So what you thought was going to be maybe simple actually. Now, there's a pendency because maybe a product person wanted a connection where there wasn't there before. And so it's like you still ship the product, because it's important in any business to ship. But then you kind of go, Oh, we have some tech debt or organizational debt. So we now need to like maybe deal with it more sustainably. And so that then leads to a refactoring or revision over the organization.

Amy Phillips  33:23
I love the way you described that and kind of like the technical terms, because if they I think people do panic, then they're like, oh, reorg everything's changing, but actually, they're really comfortable. Everyone's really comfortable with the idea of you refactor code, you don't always get it right. There will be bugs. Not the end of the world. So yeah, that's really nice.

Pat Kua  33:39
Yeah, I think part of the art was I was speaking to a CTO who struggled with this is that I think they went through too many iterations, too much variation. And I think that's the interesting thing about the change is that there's a difficult art. I don't know science, whatever, around trying to find the right time and place to make changes. So too early, you're probably going to end up over engineering an organization, too late and there's going to be a lot of sort of pain. And too frequently people are going to get that sort of change fatigue. And I think that's a interesting thing that people should be really deliberate about when they're sort of thinking about the organization design structure about, is there enough reason to do this. And one of the analogies I kind of think about is kind of pain driven development is it's kind of like, you know, sometimes you have parts of the codebase. It's a little bit like gnarly, but you can live with it, right? And then it's like something that you kind of keep coming back to every day that's really slowing you down. You really have to do something about that. And I think that's the same sort of idea and this is harder in the organization sense because you get so many different signals from people about you know, I don't like this, you know, that's not working or whatever. And, you know, part of the art is in trying to find, I guess, a common theme that is really having a big effect impact. So I look for sort of strength of signal, consistency of signal, and then applying my sort of systems thinking head on, is it a side product? Or is it actually caused by something, in our, sort of structure. So I don't want to just simply put a patch on it, but actually, I want to deal with that, like more holistically. And so I wouldn't like react immediately when people say, Oh, that's wrong. So we need to change something. But I'd really be looking for signs that gave me a sense of like, if we fix this thing, this will give us a good runway for another six to 12 months of we've made significant improvements for everyone.

Aaron Randall  35:37
Nice. I'm frantically writing notes, but so much I feel like I'm learning so much right now.

Amy Phillips  35:42
This is a selfish podcast we just...

Aaron Randall  35:48
It's just for ourselves yeah. Back to the 'Secrets of a Strong Engineering Culture' presentation, you gave, talk you gave, one of the things you mentioned on that is a five step recipe. I was wondering if you could tell us about that and talk us through it.

Pat Kua  35:59
Yeah. I can't, I have a really bad memory. So

Aaron Randall  36:03
I've got, I can prompt you.

Pat Kua  36:07
I need my crib notes. Yeah, maybe you can prompt me. Maybe I can talk through reasoning.

Aaron Randall  36:15
Yeah, of course. Yeah. So step one is gather input. Step two is publish tech culture. Three is prioritize key improvements, four is decide on actions. And five is repeat.

Pat Kua  36:24
Yeah, that's right. Thank you.

Aaron Randall  36:28
That's a great talk, everyone should watch it.

Pat Kua  36:30
Yeah, thank you. So I think, um, yeah, so it kind of follows a retrospective, but at an organizational level. So that's the way that I see it. And for me, software organizations are complex entities. And this is the whole thing about you can't just take Spotify model and and implant it into your organization. So you kind of have to work and do a bit of homework about actually understanding about what are your actual problems. So that's the idea about really gathering input. And you know, as a as an example with a target operating model, one of the first things I did was actually run team retrospectives with everyone. And I really tried to focus people on, I don't really want to hear about, like the problems within your team, I want to hear what's constraining your team. Like, I want to hear about the things that you feel your team can't address. You know, I expect you to be able to improve your own process your working team culture, but actually I want to understand a little bit more about how you work with the environment, but also the good things because I don't want to lose those things. And so that's the gathering input process. And then, Can you remind me the second step, sorry,

Aaron Randall  37:35
Publish your tech culture

Pat Kua  37:38
Sorry, memory like a frog. Yeah, no. So yeah, so publishing, I think, is a good way of really trying to codify it. And I think there's a power to simplification and I think by publishing it, you have to simplify. And I think it helps people understand what is what your culture values, and I think particularly If you're trying to nudge your culture in a certain way, that's also an important thing. You know, I'm always conscious that, you know, stated culture and culture in action is always a little bit different. But you also want to be clear about what you're going to reward. And that's really that stated culture. Right. So and I think it's to be fair with people, you want to be clear about what that is. I don't think it should be done in a vacuum. It's something that you should really be cultivating. And so that's one of the things that I was like listening into with teams as I was doing retrospectives was like, asking, you know, trying to listen for what is it that makes this organization different from other organizations that works here that if we lost that, it would feel like there's a big loss in the identity. So codifying and publishing I think helps people sort of rally around it, and then also helps give people that common vocabulary.

Aaron Randall  38:49
Hmm, that's awesome. I feel like when you talk about that, it sounds like almost going through the process of writing it down for the outside world. It's like a version of rubber ducking where it makes you sort of really think about how to best articulate it. If you really hold it true or not? And yeah, that's really, really cool. Yeah.

Pat Kua  39:03
And it's a really great way for you to keep yourself accountable as well of like going back to Am I doing something? As an example, you know, I knew that N26 was quite a pragmatic sort of culture, right. And so I knew maybe I needed to tone down my own personal idealistic sense, having come from a consulting background of actually not trying to do something that's too much of a stretch goal, but actually has to be really grounded in a lot of value, right? So to has to have a clear, concrete outcome has to be actionable. It's not just about like, complete blue sky thinking. Step three,

Aaron Randall  39:40
Prioritize key improvement areas.

Pat Kua  39:42
Yeah. You can't do everything. So this is like, once again, the whole time management thing, right. So I think the thing that every leader looks for is really the high impact actions. And I think that's the thing and, you know, I think a lot of startups and you know, like N26 included you always say that you're going to do a lot of things. And then things get out of hand or things distract you and you don't quite complete all those other things. But I think that's why it's quite important for leaders to go up with a list of here's all the things that we're going to do. But also, here's the things we're not going to do to manage expectations.

Aaron Randall  
And that's actually as a team, what you're gonna, what you're gonna do what you're not going to do, Yeah, awesome. Awesome. And number four is decide on actions.

Pat Kua  
Yeah. And so that's kind of really about, like actually taking care of them. So I think one of the things in communicating change is you want to be clear about I guess what's gonna happen next. So I think people are saying, you know, what does this mean people want to have an answer about okay, what does it, what does it mean for me in my day job, like, do I have to change something? Do I have to act differently, like I think that's that's a group responsibility. I don't think it's a great sort of idea to once again say, here's the ideal without giving people concrete things they can do to actually make steps towards that.

Aaron Randall  
Great. And five is repeat. It's great.

Amy Phillips  
I think it's really interesting. Like I love the I love the sort of like the actual writing it down and sharing it. Like, I think that's a step. Like I think it's really easy to hear things and be I go and I go and make that I can make this improvement, but you forget to kind of loop it back and actually really help people see I heard you, and we're doing something so you lose half of the benefit.

Pat Kua  
Yeah, and I think that's a really great opportunity for a lot of leaders is that I think that's the, I guess one of the key things is working out how to shape that culture. You know, I think that's one of the reasons why a lot of people jump into a startup very early on because you can kind of shape and mold that culture, but trying to shape a very large organization and change that culture becomes a lot harder the bigger it gets, you know, I'm very impressed with a lot of the turnaround, I think from Microsoft that Satya has had in sort of Microsoft, which from my point of view was not always a developer friendly ecosystem, unless you were sort of Microsoft stack. But you know, now it's, you know, with GitHub and lots of other sort of open source stuff. It's been really interesting at that sort of transformation. But it's a hard journey. I can only imagine.

Amy Phillips  
Yeah, I agree. I mean, like the I think the the thing that's really impressive is the speed at which they've done it, because I think that's the other thing that sort of, I mean, I'm a very, very impatient person. So like, for me, whenever you kind of go into these cultural things, like you're lucky if it's like six months, but often it's, you know, way longer to make significant changes. Yeah, it's like, I guess I suppose that's probably another piece that's kind of interesting. It's like what are what is the sort of realistic timeframe for you know, real team change or like that even yeah, just even within like a normal team like how, how long would like it take to properly bed in a cultural change?

Pat Kua  
It's good question and I'm gonna give you the consultant answer. I'll ground it in a couple of reasons. Right. So I think it's not just about change, I think it's about what sort of change. And one of the reasons, you know, step one around gathering input and trying to understand the pain points is, obviously change will be a lot easier if people can understand how it helps their life get better. If it's change for the sake of change, then people are obviously going to resist and if they don't understand the value that they're personally going to have, they're not necessarily going to buy into it or they're not necessarily going to take action. And so I think that's one of the reasons why change by itself isn't so useful. It's really trying to understand what change is, you know, helping, right. So, you know, when I was consulting, I used to work with development teams who did a lot of manual testing. And it's like, like, I'm just like bashing my head on the keyboard redoing this test again. And again, it's like, wouldn't it be interesting if we could like automate this and then we wouldn't have to be doing all that typing, right? And it's like, over time, people started to understand, okay, like, like, I am wasting a lot of time running through the same scenario again, and again, I've written the scripts that only I can run that I can't share with my other team members. Maybe if we merge them in some way we could share, then we could actually save some time. And you know, that helping people understand how the change addresses their problem, I think is a key element to helping change accelerate. You know, I think the further out that change doesn't mean to somebody or a team, then it's not really gonna have so much of an impact. So that's why I don't think you can really instigate or you can really say how long change is going to take. My favorite mode of doing this with teams is really using sort of iterations or sprints, whatever your terminology might be as experiment cycles, right? So that's the beauty I love about retrospectives is that actually we can start doing a change next week. And we don't have to commit to it for life. If we don't like it, we can decide to roll it back, right? So we can try it out. See if we have a better life. We like it. Let's do more of it. And, you know, hopefully those habits start to or the positive habits that actually have impact start to escalate. Yes.

Aaron Randall  
Am I hate to be the bearer of bad news, but unfortunately, we are running out of time. But before before we let you go, we have four quickfire questions that we ask all Humans+Tech podcast guests so I'm gonna dive into these. First one is what is your top book recommendation?

Pat Kua  
I'm a big systems thinker. So I love Thinking In Systems by Donella Meadows. It's really accessible, easy to read. Yeah, love it.

Aaron Randall  
Awesome. Amy, you're nodding your head like you know it

Amy Phillips  
I love it, yeah great book. I think it's very interesting stuff.

Aaron Randall  
Nice, question two is what tip do you wish you'd received when you first moved into tech leadership?

Pat Kua  
Find a mentor. So I think that's somebody that's something nobody ever told me about. a, uh, yes, I would have loved to have that advice.

Aaron Randall  
That's amazing advice. And that's, by the way, great advice for anyone in any kind of tech leadership, right?

Amy Phillips  
In Tech, I thought you were going to to say. Nobody mentions it, for the first like, 10 15 years of your career, and it turns out, this is the secret.

Aaron Randall  
But then you you get like four of them. Okay, question three is who inspires you in tech?

Pat Kua  
Oh, who inspires me in tech? I have to give a lot of, so I spent a lot of my career at Thoughtworks and I have a lot of respect for Martan Fowler. Not just because he is like an amazing person who can summarize content in a really simple way. That's definitely something that inspires me, but the thing I want to point out is how he uses his platform to support other people. You may have noticed, probably over the last five years, maybe even earlier, he's getting a lot more people to publish articles on his platform, because he knows he has something that he can use, that helps people amplify their message. And I think that's something that I really appreciated from the sort of social and economic justice pillar from Thoughtworks is not just about tech or making money, but actually trying to use whatever power or influence you have for good. And I think he was a really great example of that of, you know, if, you know, he can't make a talk he would introduce and pass it on to somebody who might not have those talking opportunities. He was very generous with his own sort of personal platform. And it's a really great example of sort of paying it forward. And I think for me, that really is something that I really get inspired by and one of the reasons why I enjoy teaching and coaching and helping other people grow.

Aaron Randall  
Hmm, that's great. Very nice. Question four, finally is what is the most ridiculous thing about you?

Pat Kua  
Oh, I'm not very funny. I love laughing

Aaron Randall  
We'll take it, very nice. Finally, where can people find out more about you?

Pat Kua  
Yeah, you can find out more about me at PatKua.com or if you want to join the Level Up newsletter, it's at levelup.patkua.com

Aaron Randall  
which you absolutely should join. Amy made me join because it's great.

Amy Phillips  
It's such as great newsletter like, you know, I'm subscribed to quite a few newsletters. They kind of arrive weekly, but whenever your one comes in, it's always the first one I open it's like, I just I love the little like, like little stories you write. It's not just like four links. It's like, yeah, you give the context. So yeah, genuinely love it.

Pat Kua  
Thank you.

Aaron Randall  
Very nice. Pat, thank you so much, again for taking time to talk to us today. It's been a lot of fun.

Pat Kua  
Yeah, it's a great pleasure to speak to both of you. Thank you very much for having me.

Amy Phillips  
Thanks so much.

Aaron Randall  
We'll be sharing the links in the show notes plus the all important doodle of Pat over on our website, HumansPlus.tech. I'm Aaron Randall. This is Amy Phillips and you've been listening to the Humans+Tech podcast.

We're joined by the amazing Meri Williams, previously CTO of Monzo, MOO, and M&S, as well as host and co-curator of the incredible LeadDev conferences. Meri's an experienced technical leader, one who's really technical - check out her story of soldering satellites!

In this episode, we chat about creating fantastic conference line-ups who also happen to be diverse, pressures of being a high-profile CTO, ways to build and maintain an incredible network as well as all the usual book recommendations.

Scroll down to read the full transcript of our chat with Meri

Meri's quick fire answers

• Meri recommends the book Talent Is Overrated by Geoff Colvin
• She follows Alice Goldfuss to keep up with important things in the Tech industry
• Meri is inspired by other great leaders including Lara Hogan, Camille Fournier, Jeanette Trapani, Jesse Link, Maria Gutierrez, Marta Jasinska, and Eileen Burbage

We also cover

1. LeadDev Conference [00:01:13]
2. LeadDev and addressing the need to work on soft skills [00:02:46]
3. Nick Means and his amazing storytelling talks [00:06:04]
4. Creating diverse line ups [00:06:46]
5. The Medium post explaining how LeadDev broadens the funnel to encourage diversity [00:09:49]
6. Working with organisation such as Black Girls Tech and Women Who Code [00:10:08]
7. Leading during a time of crisis [00:14:01]
8. How to manage remotely [00:17:33]
9. Katie Womersley's LeadDev talk on Building and Scaling Distributed Teams [00:17:47]
10. How to successfully join teams and build relationships when you're remote [00:21:47]
11. The pressures that come with being a visible CTO [00:28:25]
12. On not looking like a typical CTO [00:31:19]
13. Mentoring CTOs and the patterns of help they need [00:37:20]
14. The different flavours of CTO skillsets [00:37:37]
15. Tech promotions are often job changes [00:41:03]
16. On building and maintaining people networks [00:42:42]
17. The quickfire questions [00:51:28]

Find out more, and follow Meri

Follow Meri on Twitter

Full transcript

Aaron - Welcome to the Humans+Tech podcast. I'm Aaron Randall and this is Amy Phillips.

Amy - Hi  

Aaron - and today we are so excited to be talking to the one and only Meri Williams, Meri's an experienced technology leader Previously, Monzo, MOO,  M&S, and others, as well as being chair and co-curator of the wonderful Lead Developer Conference. Meri, welcome to the show.

Meri - Thanks for having me.

Aaron - Uh now one of the things we like to do with all our Humans+Tech guests is, I draw a doodle of them and I'd like to show you yours and get your thoughts to kick off the show. So I put up on the screen. Now  

Meri - I like it. Curly hair. Lego. That's pretty much my brand. So very

Aaron - I'm not sure what's on the T-shirt, but I wanted to capture the essence of your kind of playful tees as well hope that worked,

Amy - I felt that I should probably be some lasers or something. Like usually the cats have lasers, right?

Meri - I'm wearing a [inaudible] at the moment that have got like, dinosaurs going today is gonna be a good day with, like, a comet in the background. Very pandemic

Aaron - Um so as I mentioned in the intro, you're the co-curator and host of the Lead Developer conference. Which, by the way, is hands down my favourite tech conference out there. How did you become involved an what attracted you to this conference?

Meri - So I got involved, really before it existed, which was quite cool. So I I met Ruth Yarnit, who is the CEO of White October events That owns and runs the Lead Dev, U'm and I met her in like they really like the weirdest. It was like a dodgy pub in Reading's basement where some meet up was being held. I could remember who had talked me into going and speaking of this like, weird meet up in Reading, but somebody had and she came over and introduced herself afterwards. And then when she's like the hands down the best events person I've ever worked with, she's absolutely amazing uh so when she had the idea for the Lead Dev, which didn't have a name even at that point, it was just like we think there's some, there's something in, the missing thing in the market for people who like are leading and being technologists like we don't know what to call it. We don't know if it's a CEO's thing or what it would be because she's a really great events person. She was doing proper, like market research. And so she came to me and asked if she could, like, just get some time to show me some mock-ups of different possible schedules and I was like, yeah, I can do that but I can also get you, like, 20 tech leads in a room. Would you like me to sort that out? So. I got her a whole bunch of people who were kind of lead developers or senior engineers and eng managers and just got them all to meet with her and give her feedback back on. And she she had mock-ups of these different possible schedules with real people and real talks but different mixes. It was actually it was fascinating because the the one everyone really liked the best, was the one that was all kind of erroneously referred to a soft skills, right? Like because then they're not very pretty hard. But everybody loved that line up. But every also failed on the fundamental question that she asked at the end which was Would you buy a ticket or ask your boss to to fund you going? And everybody said no to the one that was all soft skills or leading team stuff, um and so yeah, so, so from from the beginning, there was the realisation that people in tech in particular are really wary of admitting that they need help or need to keep learning this kind of stuff. I find it really frustrating that a set of people who believe anybody can learn to code also believe that, like the soft skills fairy taps you with want at birth. And that's it. That's all the people you'll be able to handle for, like the rest of your life that you got a you know, a fixed amount of skills that you get. And so, yeah, from the from the very beginning, we kind of ended up. It was collaborating a lot on How do you how you get people to attend, who most need to attend who maybe the people who least realise they have to work on these things or are least willing to to admit that they need help on them. It's been fun, so yeah, she asked me after that to host the first one and then I've kind of gotten increasingly involved since then over the last six years.

Aaron - That's awesome. That point about getting people to attend who are least willing to admit they need to be there. How do you solve that?

Meri - So there's definitely some people who attend the LeadDev because they are sent to the LeadDev. They have their arms crossed at the beginning of the day. Go on, umm they you know, they tend to object to the code of conduct and object to you know, say things like it's unrealistic to see so many women and people of colour speaking which is a great, great attitude to bring to a conference. Makes people feel really welcome and valued, doesn't it? But then I think that they, you know, when you're surrounded by what these days like London was 1500 people last year. Like when you're surrounded by literally over 1000 people who do get it and who are talking about how yeah technology can be hard. But people are harder and maybe our biggest problems are not in, you know, whether it's this language or that language, but in whether people are collaborating effectively or teams understand each other and, you know, pointed in the same direction. And, I think a lot people kind of look around and kind of go like, Oh, right. It's not just my boss who thinks that I should get better at this, like there's a lot of people who are getting better at this maybe I should catch up. I think there's also people who, like sit with their arms folded sulking for the whole day and then never come back or, like, sit in the pub the next day you know, you can't you can't. This is the The corollary to the customer is always right. Is if somebody's really wrong. They probably shouldn't be a customer an I think that tends to be true. Um. And I think also the thing I love about LeadDev though is the other reaction that you get. And I, the person who says it the most and I love it the most from his Nick Means who does these fantastic talks. He does these amazing storytelling talks, which I imagine you've both seen. And I remember him speaking the first time he ever spoke at, LeadDev and he came off the stage and I gave him a hug and he went, these are my people. I found my tribe and he had not been around people who care about people as much as he had, even though he'd been a technology leader for a number of years. And he just felt embraced by the sense of oh, a whole bunch of people care about the people side of things too this is awesome and so that's the that's the much nicer side of things, I suppose.

Amy - I think it's really true. Like, I mean, I go to quite a lot of tech conferences and there's so many so much of the focus is on technology on just only technology, not technology. Plus people just technology. So, yeah, LeadDev definitely felt like a completely different style of conference um and yeah, I think the number of people you get each year just goes to show like, you know, everybody kind of agrees, like these are really valuable things to be to be talking about and learning about.  One thing you mention was about the line up and people being kind of surprised, like the number of women and people of colour you get, and I think, you know, unfortunately, that's still surprising in a tech conference like so many tech organisers, are sort of saying, You know, it's really hard we can't find more diverse lineups. So what's the second how do you find the diverse lineups without you know and still have fantastic conferences?

Meri - Umm, we've actually not found it difficult at all. So the first year we, we the very first year we viewed it completely as a kind of statement of what we were going to be about so we curated that initial line up very, very carefully, both in terms of like the mix of speakers, the mix of types of organisations they came from, the demographics of those speakers. But an like the topics like we wanted a really representative lineup because that's that's what it is. It's about representing the world, because if we're building technology and products and services for the world, we should probably try to reflect the world right. And that's I think that's um and there's obviously a whole bunch of good research and science to show that teams that do are representative are just much more successful. They tend to be higher performing. They tend to be more profitable, they tend to do much better. And so I think the What we did in the very first year was to curate that very, very carefully. And I think in a first year of a conference, it's really tough to just throw a CFP up and hope that a bunch of people like submit talks, right? They don't know who you are. They don't know what you're about. Your very unlikely to do well with that approach. And so I think that first year we curated it really carefully. We did do a small CFP just for the 10 minute long like Tech Lightning talks. But so we had the opportunity in that first day to kind of really show what we were gonna be about and that included having a representative lineup and Ruth, Ruth and I both feel pretty strongly about that element of visibility that it really matters. It's been fantastic. Actually, I've never I've never had to convince her on any of these topics. She has been right there with me or ahead of me every every step of the way. I think sometimes people give me far too much credit for how LeadDev has gone and  on uh., misunderstand that I'm like the tiny bit of the  iceberg that's visible above the water and she and her team, I think they do all the hard work with the organising over the out and then from the from the second year onwards, we we filled almost every talk slot with somebody who submitted to the call for proposals, and what we've done is a lot of, we've invested a lot in getting the top of the funnel for that um for  proposals to be as representative as possible we've actually published some stuff about this a few years ago and we can we can share the link up to that article. But we really focused not on the point of selection but further up the funnel. So, we from early on have actively approached various different kind of organisations like Black Girl Tech and Women Who Code and a whole bunch of those kind of kind of organisations because I think people assume that if you say nothing, everybody knows they're welcome. But if you say nothing, a lot of people are going to assume that you're like some of the other conferences that people hear about where this harassment happening and like not to tar every conference with the same brush. But just you know that it's not a universally pleasant experience or welcome experience on average. And so, I think people kind of wrongly assume that there's neutrality and there isn't. So you have to kind of overcome the lack of neutrality. So So we went out and said, like You are welcome here to a whole bunch of different groups and different folks. We also know this is some just to sort of re-cap some stuff that we're very upfront about what we offer, and so we will cover people's expenses ahead of time like we'll book the flights and cover the hotel. And you don't have to go into debt and wait to be repaid by the conference. And that broadens participation quite a lot because not everybody can afford to put a flight on a credit card or any of the any of those things. So we're very up front that we cover everybody's accommodation, travel and what and some expenses, and we're clear about what what proportion thatis. It's It's on every CFP that goes out and that, I think helps people just to A) know that people are gonna be treated fairly like not just the people who ask or who are, you know, pluck up the courage to question why a combination isn't being covered or something like that. I think it's terrible when people are expected to  pay to speak at a conference of its It's just skews everything to be so much about the big companies that can afford the big travel and expense budgets to send people out. So yeah being being really clear that people will welcome having a really clear code of conduct, that it's updated regularly that we do proper training for the conference staff on how to react to anything that does happen. So it's not just there for show its, It's properly enforced. Um, and that things will be very genuinely will be dealt with properly if needed. Ah, and then to yeah, I suppose try to treat people as fairly as we and be very clear what we what we offer an offer to everybody. So we offer everybody an honorarium, you gotta be a little careful. I think all conferences do with the concept of payment. If somebody is seen to be working across borders that can cause all sorts of problems for folks, it's an honorarium. It's like a gift rather than a a fee, because because it's it's an attempt to help make sure that it doesn't cause anybody any immigration or tax problems, but it's well, OK, so we do still have a couple of invited speakers. But those folks, we always we always pay them the same. Now, whether it's the same year on year depends a little bit. But if there's ever ever somebody who we really want them to speak, but they're going to charge a particular fee um, we make the decision on the basis of giving every invited keynote speaker the same fee even if other people haven't asked for it. Way don't fall into that trap of very bluntly. It's usually guys who ask um and there's plenty of conferences that they'll pay what the one superstar speaker, but then they won't pay the others in the same kind of bracket. And so we always make that choice on a kind of okay, yeah, but if we do, then we have to pay that to all two or three or four invited keynotes which I think is also just fair, but also strangely unusual.

Amy - Really fair. Um, so the recent LeadDev live conference, which was just last week, actually, it focused on how to be an effective leader during uncertain times. Do you have any tips for how people who are leading teams or companies can do a good job during a crisis?  

Meri - I think, Um. I mean, there were some great tips at the conference everybody should should go and check out those videos. when, when they're when they're fully published. Um, but I'm,  I'm the I'm the best and worst person to ask I grew up in a very tumultuous time in South Africa.  I grew up in apartheid South Africa. So a lot of what's happened in recent years is not umm, even what's happened. I mean, nobody's lived to a global pandemic in our kind of lifetime, right? But But I did live through a 40% HIV infection rate as a kid and that it felt pretty apocalyptic. You know, there is a whole generation that's been lost really in South Africa, and so I think, like, say, it kind of makes me the best of the worst person to ask. I think that anything that people have been coming round to over the last couple of decades is that you know somebody can't leave their personal life of the door. They can't just be their, work self at work. None of us even get to leave the house anymore. So, you know, maybe it's easier, but it's also possibly a little just over shadowing everything that we're all at home all the time on, I think the main thing that leaders can do is remember that people, are whole people and that we're all different. But we're all weirdly we're going through the same thing. And Katie Walmsley, who's VP of Eng at Buffer she said, It's the one really strange thing for her team, is it's the first time they are genuinely all experiencing the same thing. She's got a completely a fully distributed team, always different time zones, different weather, different seasons. This is the first time they're actually all having the same experience like they're all they're all in lockdown. They're all facing the same danger and that's been a weirdly kind of unifying but also very strange experience for for her and for her team. So I think, remembering that people are people and remembering that people might be different in how open they want to be, or are willing to be with the broader team about what's going on in their lives, like whether there's kid's or whether there's anything else happening, um, sick pet or, you know, there's all sorts of things that could be going on. Um, but those things are real and finding some way for someone to tell you that something is getting bad before it gets critical is really important. But I think there's not a universal way to do that. There's no one size fits all way to know. Some people are super, super private and some people are gonna tell you what they ate for breakfast, and like in extraverts are really missing the office at the moment, right? So even my wife, who is massively introverted. She turned to me a couple of weeks ago and just went, I've never felt this way before, but I'm missing people that was not what I thought it was going to be but wow yeah, so yeah, finding a way to,  for it, to be okay, to talk about some of those things, but it not to be just a new oppressive topic, to have to talk about everything everyone or pretend that it's OK when it's not.

Aaron - Yeah, that makes sense. Do you think that, that question, but for leaders, do you think there are specific things that we need to change or adapt as a leader leading a team remotely, now?

Meri - I think the the one really great thing again. I probably got from Katie. She did a fantastic talk a few years ago, at LeadDev in Austin about about leading a fully distributed team. I think I think this is from her, and she basically said, like, You should leave loudly every day, you shouldn't just like disappear off Slack or IRC or whatever you're you're team way of communicating is you should say goodbye to everybody. And it be obvious that that's you leaving at a reasonable time in your time zone because the way that you role model in when you just a you know green dot or a red dot on it is a bit different. If people see you leave on time or not leave on time um, you know, come in earlier or come in later or whatever else. And I think just being much more explicit in comms on, it reminds me of something Cate Houton said, which was, You know, the the big thing that's different about distributed teams is the same things go wrong as go wrong in the office, you just don't have all the same coping mechanisms available to you so things break faster because you can't just overcome. And the thing that thing that's wrong by like those people who were doing glue work to steal Tanya Riley's phrase like calming the people who are angry at each other down over coffee later in the day. Or, you know, grabbing some ice creams and taking the round to that team that's annoyed with your team. Or, you know, some of those things aren't available. And so things escalate faster and become more like real. I think that's what was born out in Google, did some research at one point where they genuinely thought that maybe these, you know, remote first teams were not a good idea, and they should be getting rid of them. And then the research they did found that it was that they were all much more effective.  But It is because, in order to survive at all as a distributed team, you have to fix some of these ways of working ways of leading like you can't be a silent leader of a team that doesn't see you in the office. What? What are they going to get there, um, direction from, or their understanding of what's going on from if if they don't ever hear from you? Like if they see you walk past than they might be able to infer something about your face or your stance or whatever else. But like that green or red dot on slack really doesn't tell you very much.

Aaron - I love I love that idea of leaving loudly. It's all that's so great. It's similar. It makes you think of that, that concept of like getting changed to start work, like getting into, like, getting dressed into work clothes to start work, even though your home and then getting change out them at 6 PM like signified that you're now like in your personal life. Yeah, that leaving loudly bit is.

Amy - I don't think anyone does that

Aaron - I've definitely done it.  I think the leaving loudly bit is great because you do so you you you fade into personal time at that point, but you're still accessing your emails because it's kind of convenient. It's not like you've left the office and everyone's seen you go. So yeah, it's pretty cool.

Meri - One of the one of the questions on the LeadDev Live Slack afterwards was somebody doing a sweepstake on whether all of speakers had been dressed like, properly dressed just above the waist or not. And I was like, I put shoes on I live in a part we're like a no shoes in the flat household but because it was like it was such a work day for me, I couldn't like I couldn't host a conference without my shoes on. I was just I sat down the whole day. It wasn't even like I was standing so like, something in my head that just went No, no, you have to put shoes on.

Aaron - And there was a, there was a point you mentioned around like being in the office and, like handing out ice creams and generally just stuff that you can do very physically and think about things like the conversations at the water cooler. Now I'm thinking about as people. Some people are unfortunately, losing their jobs. Some people are changing jobs and joining new teams and companies there's people that are joining new companies that currently in a new, fully remote world that wasn't that way four weeks ago. How do you join a company and build a rapport with your new team when you don't have those tools you're used to? When you worked, you know, physically in the same location?

Meri - I just think it's always just been such a luxury to be in the same location as people anyway. I spent the 1st 10 years of my career. P&G and I had teams that were in India and the Philippines and Costa Rica like there were multiple people who I was close with them and I was on a leadership team with them. Or, you know, they were, they were my partner in crime on my project or whatever but I didn't meet in person for, like the first 3 years that we worked together. So I So I always find it funny when people see it is such a huge barrier. I did have somebody who was and who took over my role when I, when I when I moved assignment once, who just she was not that much older than me, actually, maybe 10 years older than me max and she found it really uncomfortable to try and build build relationships when, and this is a point when video wasn't really a thing yet, like that's how old I am. Um, so you literally just like on a conference call trying to have a have a conversation, you never saw somebody's face you maybe had, had instant messenger, but it was MSN Messenger back when that was the thing again, showing my age. But yeah, I think that I think you could totally build great relationships with people, but I come from a generation that kind of what I mean. I got email, and then it was years to between getting email and Internet. But like some of my best friends, I made who I never met. I was part of like online forums and all and all that kind of stuff, like when when you're when you're a young lesbian growing up under apartheid South Africa, it's like not a lot of gay culture that you can avail yourselves with, right? So, like all I had was Xena, if you want to find lesbians on the Internet in the nineties like Xena Internet forum like Web forums, were the correct place, to go, some of my oldest friends are web people I knew only as kind of like their favourite character from this, like, frankly, wonderfully terrible TV show like camp as anything right? an It's so wonderfully terrible as well that like the GTA Workshop where they did all the Lord of the Rings stuff, their first project was doing all of the swords and costumes and things for Hercules and Xena. They're kind of raised that from the company history. Now that they've been Lord of the Rings and District District nine, right? Like, you know, you know, they're not really admitting to that so much. Yeah, I think you can form brilliant relationships with people. I think that I think the thing you don't get is exactly said You don't run into somebody making a cup of tea or like accidentally meet people. So you have to find ways, to, like, get that virtual watercooler effect. And so I think it's I think it's a good thing that you've got a load more companies that are having to be fully distributed because people started putting in there kind of like, you know, morning coffee break everybody makes a coffee and comes and is in a hangouts or is in Zoom or whatever else um one organisation that I'm working with at the minute one of the really senior people there is Ah, like a meditation instruction. So he's he's running meditations every week for the whole company and they're recorded. And you, can, listen back to them and do them again. It's like it's like like self created Headspace. It's amazing and there's uh, there's another couple of teams I know that I'm doing fika every day, this kind of Swedish tradition of coffee and cake, you know, three o'clock in the afternoon, every day and they're and they're starting to do that. I mean, I'm working with a couple of different organisations at the moment, so sometimes they overlap. I'm like, it's lovely to see you are just gonna rush to my other online fika. At some point, it could happen. Figure out how to like have have them all dialled in on my screen and just activate the mic for different ones and not know ever accidentally like it's just it's just the comedy disaster waiting to happen right? If you're part of different social groups trying to hang out with them all, but I think I think you do that on um. I think the other thing is to encourage people who are already at the company if they either like, know something that could be useful or if they don't like. They're just in a completely different part of the business, and they probably wouldn't normally be on someone's onboarding plan to just go reach out and have a 1 to 1 like just you're not going to be on their official list. People that they must meet is they join. But it would be a good idea idea, to. And I think making it easier for the person who's joining to be like I will just throw a dart at a list of names and I will do a 1 to 1 this week with whoever that dart hits, but also the people who are already in the company to realise that, like they were totally have chatted to you very happily and like, realised that your choice of tea was worth having a conversation about or something. If they've been in the office with you, so why wouldn't they find half an hour? And in some ways you know this the thing that's interesting about about Covid about this situation is there's some people who were just boredom is the main thing they're dealing with right there. Just I wish they could get out the house and do the things that they normally do. But then there's also a whole bunch of people who have gone from having two jobs, you know, often like parent or carer and professional to having like six jobs. They're trying to be a teacher. and a nurse and a cleaner and a you know, personal shopper because their next door neighbour can't, um, can't get out to safely, get grocery. You know, there's this weird thing going on with, although we're all experiencing the same thing. Some of us are just way busier than we've ever been. And then some people have got, like hours more in the day because they're not commuting anymore. And I think that's the other thing that's worth thinking about is how do you load balance, understanding that the total reality for people, How do you load balance across the team? And so maybe those people who are not gonna have the most chilled out relaxed 1 to 1 with someone because they're, you know, running between doing seven loads of laundry and trying to look after the baby and, you know, and and and all of these things like, how did the other folks in the team step up and help with that? But then you're making it easy from both sides. There's also these things, like the Donut app in Slack, that will just kind of roulette you a person to meet with every week or those kind of things as well, which I think people could do more of. But we're also defaulting to having a lot more meetings than we normally would. We're gonna find a way to get on top of that. Everything is a meeting now and before you might have just interrupted someone for a couple minutes. We have to find a way of doing that, which is probably a slack DM or a text message or something. But this kind of default to being everything is now a one hour meeting that must be scheduled in is just, eating away everybody's time to do anything else, right?

Amy - So in your intro, Aaron mentioned um that Meri you've been CTO at loads of different places. You're pretty much known, well, certainly across London. There's nobody in London who doesn't know you probably across the world. What are the pressures of being such a visible CTO within the industry?  

Meri - Mm, I think sometimes people expect miracles. It affects things in a couple of ways. I think people have expectations, whether they're good or bad. There's definitely a bunch people who believe that anybody who's well known is like, automatically shit at what they do. And you must be a you know, all image or marketing, no substance person, which, you know, I sure hope I'm not, But there's definitely a whole load of people who that's they're kind of ingrained assumption is that you're kind of riding on your reputation and that that that's all there is to you, and there are definitely people who the opposite happens. Like, you know, everybody I know had heard of this person. They must be a miracle worker. I'm like, No, or certainly not daily right. Like like I'm good at some things. I'm like I'm really shit at some things. Like like any other normal human, um, the other the other side effect I suppose is just just a lot of a lot, a lot, a lot of inbound like people asking for things.  

Amy - Like podcasts...

Meri - And a lot of variation in how.. You two are my friends I'm very happy to do this, but like you know there's a lot of people out, and there's a lot of people who, um, are very demanding without without it being clear to me that they're gonna pay it forward. I'm not super transactional in how I interact with folks. I don't expect that if I do something someone, they will pay me back. But I do want them to pay it forward I want them to help somebody else in future. There's definitely some people who are very, like demanding and come across as very entitled that you owe them time like I have no idea who you are, and I know like a lot of people, So if there's zero, people who could like could possibly connect us in a way that this would not be a cold approach. We really don't run in the same like industry, let alone, so that's right on, because there's not, you know, in a sort of Kevin Bacon way. There's not that many technologies around, like two degrees of separation from so the people who I have zero connection too often not just like very salesy like salespeople are like, yeah, this many connections on LinkedIn and you have no routes to get to me other than an inbound. Maybe that's a sign that, you should pay somebody.

Aaron - You mentioned their about expectations of you, obviously, being so visible, one of things that you've said to me before, and I hope it's okay for me to repeat this. But you'd said something along the lines of I don't look like an average CTO and I think you, at the time you were referring to things like, you're wearing a T shirt with cats with laser beams firing out of their eyes and that kind of stuff. Can you tell me more about that and like what it means for you?

Meri - I think I just don't look like people expect a CTO to look. I think people expect a CTO to be like there's a joke, my mum's an accountant there's a joke she tells about how you know you're, she's actually quite extraverted, but her joke is that you know your accountant is extroverted if they look at your shoes when they're talking to you, and I CTOs have some of that same kind of like assumptions made about them, I think I think people expect CTOs to be like nerdy boys who have no social skills, who would rather be playing with the computer than talking to any people. Right? And like I am that in all but one dimension, which is gender. I grew up as a hardware hacker. I definitely was a lot better at computers than I was at people for, you know, most of my existence, but I think I'm more, well, I'm a woman and that's unusual um. yeah, the people who approach me and go, what's it like being a female and like you're not a don't use any female as a noun. It's not the right way to start a conversation with people. Yeah, I think I think I'm you know, I'm, uh, cheerful and loud. And a woman and yeah, not not dressed in a boring suit, which is more the CIO think I think I think CIOs are expected to be kind of grey and everything they wear and also and also their manner. But yeah, I think that's this sort of assumption that, yeah, I've had people assume I must be the chief people officer because I care about the people that things like No, no, like being good at the technology requires being good at the people. They're not separable things you can't There's not a world where, like, magically the right coding like just dissolves into existence or appears out of the ether, right, like there's more people involved. The fact that we as a society or particularly an industry we like. We align ourselves around which language we use to talk to the computers. How ridiculous is that? How? that is like the plot of a dystopian sci fi novel. But we think it's completely normal that there's like the Ruby people and the Python people and the Swift people like we literally have organised ourselves by which language we're choosing to use to communicate with the silicon and that that's normal. But I think there's a whole bunch. There's a whole bunch of it. I think what people are surprised by depends on what their own like background is, and there's definitely a set of people that I'm far younger and less formal looking than they expect. There's a whole bunch of them are like, I've literally had somebody asked me on an event What do you do here? And I went on the CTO on they literally went. But you're a girl. And I looked down an went Yes. Their reaction wasn't to be like that was a stupid thing to say I should reel myself in it was to try to test me on whether I understood technical things well enough to be the CTO. So they went. so how big's the server that this a major retailers with website runs on, I was like it's not one server, it's an entire data centre. It's 10 million quid's worth of kit. And they didn't even like they were not themselves technical enough to really understand some of the answers I was giving them. So they kept trying to, like, catch me out. But they just weren't actually technical enough to understand the questions they were asking, let alone the answers are like, why these were not smart questions to ask. It was a very entertaining. It was very entertaining, So yeah, I think what people. It's a long way of saying like I think I've surprised different people in different ways. It depends on what their background and expectations are.

Amy - I mean, I think I'm most impressed that you're still laughing about that story. I'm not sure, I'm not sure I'd be able to laugh at that one.

Meri - I think I tweeted about it as it was happening because it was so funny to me, I think like I just again it's the sort of best and worst thing I've had such worse things happen to me than that because of where I grew up. And, you know, I joke about being the one the Daily Mail warned you about, right? I'm like a woman with working and I'm an immigrant on top, which I think is worse than living off the state. But I've got to check the headlines regularly, to be sure, and I'm, you know, I've got a disability. And I'm neurodiverse and I'm queer and my wife is British. I'm literally over here stealing your women and your jobs, right? So, like in all of those things, there's a whole bunch of other shit. People hate me for a lot more than the fact that I'm the CTO who happens to be a woman, right? Like I've been attacked in the street before, I've had a lot worse than somebody just like making a shit assumption. And so anything that's that mild, I tend to just laugh it off like I get really angry if it happens to somebody else and I realised, especially with a friend of mine who's a person of colour who he got a lot more enraged about, hearing that I'd had homophobic slurs used against me at work. And I got a lot more angry about hearing that he somebody had used the n word to him at work and, like we were both furious on each other's behalf and, like, properly willing to go to war really, ready for fisticuffs kind of thing on each others behalf. But actually for ourselves, we're just like, yeah, actually, you know, it wasn't physical violence, so it doesn't really meet the bar to be worried about, which is a sad state of affairs, I suppose. But it's kind of interesting how, like your your your bar for what you will personally tolerate and your bar for what you will accept happening to somebody else is sometimes very very different.

Amy - Yeah, well, so it's like, no you know that's amazing it's just we've got lots more to get through. So one thing we really want to talk about is you mentor so many CTOs and other people as well, but particularly like a number of CTOs in the industry. What are the common themes that people need mentoring on?  

Meri - Um, for CTOs, there's, um I've ended up coming up with a kind of model of what there's like different flavours of CTOs um or there's different skill sets CTOs need to have in different kind of variations. And so pretty much everybody It's one of these things so if there's if there's broadly kind of four flavours of skillset that they're deep technical. And there's not many people who get to CTO in any kind of reasonable size place that is still hands on keyboard like Keeper of the Algorithm, they tend to end up in a kind of chief architect or chief science officer is what some places call it, whatever that is but like that, there's some folks who're just having that depth of technical expertise, but there's there's not many folks who get to a CTO job without without having had that at some point in their in their career. And then the other three are basically like, ah, technical strategy, figuring out what the plan is, which things to build, which things to buy, how to take whatever probably messy, monolithy-looking thing that you've got today and move it to something that's more maintainable and more and, you know, possible to keep running in the future. Uhh bunch different like leading the organisation or the strategy, people management, leveling up as people manager The point where you get to having 10 reports is different to the point that you have 20. Different to the point. you first manage a manager, different to the point you first manage a director like there's just some differences along those parts on then the final strand is kind of, I tend to call it commerciality, but it's all the other stuff. It's all the general executive leader type stuff, and there's definitely a set of CTOs who got the sort of the more showing my hands, not sure that'll be useful, but like there's definitely people who are super comfortable in the deep tech. They are getting comfortable with strategy and their big problem is around leading a bigger organisation. They need help on how to do comms effectively how to convey a vision how to even have a vision like there's a whole bunch of that kind of stuff and that there's a set of CTOs who never do any of the commercial side. They're never an equal partner at the executive table, like helping come up with the company strategy or helping the total company to perform well. They're like they're the tech person and they only contribute to the tech stuff, I think that's, a career-limiting move. But for some folks, it's the thing that they want and so what people need the most help on kind of depends on where they are, if that's a kind of, rather than it's not like a continuum right they're different skill sets. It's more like a graphic equaliser like a bar chart and so, where what people need help on tends to be one of those categories. So either, like how to modernise because usually if it's deep tech, it's that they've fallen behind in what, like modern looks like and they've ended up in a world that's a bit too far behind for a bit too long or how to do technical strategy, or how to get people bought into doing often the hard or expensive thing that is essential to do but nobody wants to admit is really going to need to be done, or organisational strategy, including, like hiring, firing, developing people how to how to grow the team without breaking it. Or that kind of more commercial side of things, there there's some folks who just like they go to their first exec meeting, having been promoted to CTO and they're like they were going through a P&L. I don't really know what that is like, so and it's fair, like a lot of a lot of what's a bit weird about the tech career path is that we a lot of our a lot of what feel like promotions are actually career changes. Like if you're a senior engineer and you become a manager, you are now a very junior manager. You know none of your past experience has really prepared you for the management role that you're now in, right. You're almost kind of moving sideways them down a little bit, and starting over with a new skill set and the same thing can happen with that commercial skill set. Or if you've come from, like a Project Manager type background, you can suddenly get to a point where you're doing tech strategy, but you haven't ever actually done any of the deep tech stuff. And so you start to worry about whether you're able to set the right strategy without having been hands on keyboard, which you totally can. But you need a strong partnership with a really good senior engineer, or principal architect or somebody who's going to be like, Yes, your mental model is correct and therefore this is a perfectly sound idea or you keep saying that word, I don't think it means what you think it means and we should talk about that before you take this down for the board. You need to have that relationship with someone in order to be comfortable.

Aaron - I love the fact that you called out the career change bit as well because, well, because for me, you know, I mean and many other people have gone to that experience moving, even moving from like a developer to tech lead and engineering manager like it's a completely different job, but no one tells you it's a different job until it's too late. Until you're there, you're doing it and you say you're trying to learn rapidly and your at the beginning of a brand new career

Meri - and something about you that you can't admit that you need help, Which doesn't fucking help either. Yeah,

Aaron - exactly. you've got to pretend you actually know what you're doing when you 100% don't. I want to get back to this we spoke about the fact that you're a very visible CTO in industry. I think it's something that comes along with that I've noticed from knowing you for quite a while now is that you're also incredibly well connected. As part of that, you have this incredible network of people you presumably can lean on as like peers for advice and guidance and often give guidance to as well, I imagine I'm really interested in two things. One, how you built that network over time, but two, the other bit is how do you maintain it now it's so big as well and you know so many incredible people.

Meri - So the worst named training course I ever went on which this does answer your question, I promise, was called Sex at Work, and literally somebody rolled that out to a company that I had 100,000 employees. They rolled out a training course called sex at work. They later renamed it to, like, I don't know what was it called, like gender essentials on something like this anyway. But it was It was eventually a course, about like, how how men and women operated differently and like that, it was that this was relevant in the workplace. This is this is a while ago now. Okay? So 20 years ago, I still wouldn't forgive it for what it was called originally, but but yeah, and one of the one of the and a lot of it was terrible, and a lot of it was, like very binary about gender. There were only two genders and all, and it was very stereotyping. A whole bunch of it was bullshit but there were a couple of useful things. One of them was like one of the things that I said was, unless men hear something as an order, they think it's optional. But if you want, it is not okay to give women orders, particularly if you are a woman asking another woman to do something you have to ask and you have to, It has to be okay for them to say no um and that that led to a lot of frustration, but the other part was that basically a thing that said a lot of a lot of women feel like they have to constantly maintain a relationship in order to, ever be able to ask for anything or or even provide help. So, you know, if they feel like the moment they've missed that monthly catch up, the relationship is dead. You know they either have to make a big deal and fix it and then never miss that monthly catch up again or they can, you know it's done now they can never ask for help again. Where as like the sort of stereotype of the guy's behaviour is like the person that they haven't seen since freshman, You know, the first week of university. They'll ring up 15 years later and be like, Hey, buddy, I just need a quick favour and just ask anyway, right? And I I think because I had had the expensive of coming over to this country 20 years ago now, time is a weird and strange thing, but I go home and my best friends. If it's been five years, it feels like it's been five minutes and we are just like the minute we're back in the room together or back on a video call together or whatever. It's like no, like we've got a lot to talk about because time has passed, but it's like nothing is different. And I suppose I realised that if I if I have that relationship with friends from back home and I've moved a lot in my life, I kind of I left home at 13 and I I went to a state boarding school, which is a thing that I don't think exists here. It's ah, it's a little bit of a weird concept people and uh I left the country at 18 and then I left again and moved to a different part of the UK and then again, and it's like I've kind of started over again a number of times, and but I have have a bunch of people who are okay that we don't talk every week or every month, or whatever. But I'm back in the country and I'm like, Hey, I'm gonna be there in a month. You want to hang out and it's great when we do. And so I suppose I have taken an approach of just going.I don't have to have a hugely actively maintained relationship with everybody. It could be fine to not see someone for five years, and I'm gonna be totally okay if they then reach up me like I got a big career decision to make can I just get your advice about it on? I'm always fine if they do that. I'd never react badly to someone doing that. And I'm I'm not perfect at it yet. But I then try to convince myself that if I have a question like that, if I wouldn't react badly to it, maybe they won't either. So there's a couple of folks who I would, you know, if you made me write down my list of mentors there's people on that list who I might not have talked to in four or five years now, but the minute we talk again, it will be like no time has passed and they totally wouldn't mind if I do reach out. And I'm just like, hey, so I'm deciding between this job and this job, and I just I feel like you're gonna have a great bit of perspective for me. Can we talk about it and if they call me up are like, people keep saying Blockchain and I don't know if it's bullshit or not, Can I just Can you explain it to me? It's usually bullshit. Almost every database it doesn't need to be Blockchain like. Stop pitching VCs on your blockchain thing that doesn't need to fucking blockchain I'm sorry you can edit that out

Aaron -
It's staying in.

Meri - blockchain is just a solution looking for a problem 95% of the time. The answer to the second part of which, like, how do I maintain it, which is kind of I don't. But I'm OK with not doing that and very kind of I'll catch up with people when I see them, and it's cool when I do, and it's fine if we're not in touch regularly and like I mean very bluntly, both of you have called me up, having not seen me in a bit and gone like I'm facing up to, like choosing what new job to do can we chat? Like, yeah, that's it every time, right and sometimes convince you to come work for me, sometimes don't. it's a Lara Hogan talks about that a bit like about being someone's forever manager like they, sometimes you can be a better mentor to somebody when you're not their line manager. Like when you used to be their line manager. You know them quite well. You can probably give good advice even without gaining lots of new context, because you have had a sufficiently strong understanding of them that you're like, not starting from zero. But sometimes being a bit more distant makes you more useful as a mentor than you would be otherwise. And then I try to be good about also knowing when I'm, like, not gonna be a useful mentor. I'm not, I'm not gonna have good advice because I don't have the right experience or would have to learn so much about the situation. And so, like I think I think I try to do. But I'm not always great at is like switching into coaching, right, so that when I think somebody's got the best answer within them to switch into asking questions rather than giving advice, in terms of like the making the network in the first place. Some of it's just about this thing of having moved around a lot. I think I just I'm quite friendly and so I do get to know lots of people in whatever company I join or city I move to or whatever else. And so I'm quite good at that. I'm quite bad at faces. I'm fairly face blind. And so I'm a bit better than like I will write notes down or when people still used business cards a lot. I'd like somebody to move this gun. I'd be immediately scribbling on the back the back of it, so I'd have some way of remembering who they were when I'd met 50 more people that day. And so, like, I quite I know nobody likes LinkedIn, and it's terribly like passe of me to say that I do. But I quite like that there's someone's face and name and usually Twitter account. I'm like, Ah, the three bits of information I need to triangulate who the fuck somebody is in one place so that's the other side of it I suppose, like happened with people. I'm also now much happier, like admitting that I'm terrible, at facial recognition and so, like you've probably see like before LeadDev now I'm just like everybody. please, just forgive me if I look blank when you say hi I probably do remember who you are. I'm just not good at connecting that information with your face like that is what and so, it's great cos a load of people have now. I mean, it's hilarious when somebody who I do know really well and would not like mistake in a crowd like that goes, You might not remember me we worked together for like eleven years and I'm like, no, I remember you. I mean, neither of you ever has to be like, Hi, You probably don't remember my face, but this is who I am But now but now people who are kind of like on the border of that they'll somehow be like Hi. So we did work together for three years. But you may not remember who I am and, like, tried and I'm like thank you. I really appreciate that you read my thing about face blindness and you're acting this, but it's kind of weird. It's cool. We're hugging now. Although in a post-Covid reality I don't think that I can be hugging people anymore feels like that's like it's like it's a personal attack. If you If you hug people by default now, right, it's endangering people. It's not cool,  

Amy - it's not cool. You can't even get near them like yeah, no hugging.

Meri - I'm trying to popularise like jazz hands from two metres away. Like as a greeting.  

Amy - Unfortunately, we're running out of time before we go. We just have four quickfire questions for you. Meri. So we ask all of our humans plus tech podcast guests, these questions. So no pressure. What is your top book recommendation?

Meri - Um, Talent Is Overrated. Is a really, really, really worthwhile book to read. It's a little dry, but it changed how I managed people in a really significant way.
Amy
mm Good recommendation. Did you read that one Aaron?
Aaron - Yeah, I loved it. I gave a, conference talk. Where that really inspired a bunch of  content, yeah, incredible. Definitely read it.

Amy - Um, And what or who is your number one tip for keeping up with the industry?

Meri - Um, Alice Goldfuss is who I probably learned the most from both about, like, sourdough and pot plants. And she has plants that eat things like carnivorous plants, but also like whatever Alice cares about in terms of the, um, like operations of databases or anything like that. Like I she's usually six or seven months ahead of where I need to care. But that's why she's great to follow because the things that she's concerning yourself with. I'm like, Yes, I'm gonna have to care about this soon. I should pay attention.

Amy - Uh, that's great. So who inspires you?  

Meri - I think a lot of people inspire me that that's that whole thing about, like having lots of mentors in in particular, like people, I draw a lot of inspiration from Lara Hogan, Camille Fournier, Jeanette Trapani, Jesse Link, ho leads Twitter in London, um, Maria Gutierrez over at Intercom these days. Marta Jasinska, who we've both worked with before Amy at MOO and then there's a, they all tend to be the sort of manager side of things. There are a bunch of ICs as well, who I do follow to be more kind of in their particular area. Oh, and Eileen Burbage as well this Passion Capital VC and like the original investor for Monzo who ironically like, she's one of the people who I often, she's who I ring up and go,hey like I think I'm moving jobs and I just want to sanity check that the choice I might be making with you. And she's always fantastic about just being like it's cool, like we don't have to hang out. We're both super busy. She's the busiest person I know. She I'm pretty sure I've seen her with a BlackBerry in one hand and an iPhone in the other, actually texting on both of the same type like she's that level of busy I do not know how she handles the life that she got she's got like an entire football team's worth of children as well, it's it's absolutely ridiculous, I don't know what sport they're gonna be great at it, but she doesn't have 11, it's 5 but anyway it's way more children than most sports require is what I'm saying on, but yeah she's busiest person I know, but she's fantastic of being like if what you need is half an hour to go like I don't know whether I should take this job on that job, but I'm freaking out a little bit. She'll always find that half an hour, our for me and I really appreciate it. And in the same way, there's there's been times when I've gotten to pay that back or pay that forward by helping her with other people she needs helping. So she's she's someone I really, really, really rate.

Amy - Amazing. And so then Meri, what's the most ridiculous thing about you?  

Meri - Um, I don't know. There's plenty of things other people think are ridiculous about me that I don't think a particularly weird. The one, the one that you know already because I tell it is a joke sometimes is I am, I soldered it something that went into space when I was a teenager. I built part of a satellite. So basically, I peeked at 16. I could never be as cool as like the nerdy 16 year old was  and it's all been fucking downhill since then is probably one of the most ridiculous things about me.

Meri - I feel like a lot of me is ridiculous. I don't know what the right answer is. What would, you two know me? What would you have said the most ridiculous thing about me is.

Aaron - Should we be asking, What's the most unridiculous? The most normal thing about you?

Meri - The most normal things about me? I don't know. I'm seriously asking that. What would you have said is the most ridiculous thing about me. I want to know.

Amy - I think I'm gonna go for your T shirts because I think I've been genuinely quite surprised by more than one of them.

Aaron - Yeah, 100%. Same for me t-shirt collection as, when I went to Google Image Search to find a picture of you to draw the doodle it's just like amazing t-shirt after amazing T-shirt

Meri - That is that the thing that surprises a lot of people about me is the whole T shirt thing is totally a recent thing. So when I worked at P&G, which was like 10 years, I don't even own jeans because I was just in business casual the whole time. And so I was in, like, shirts and ties sometimes, but usually just like a collered shirt and slacks. And I literally didn't own jeans for about 10 years because I just didn't ever get to wear them. and then when I went to work at the Government Digital Service, which is the first job I had after and before nobody in London knew me, I didn't I'd had been up in Newcastle. I'd been to like, a couple of BarCamp London's. Maybe so, but I really, really was not well known in London at all. Back in 2012 I've only been around for eight years. Um, yeah, that was like I could, like, actually choose what clothes I wear, but I'm like autistic enough that I basically wear uniforms. I'm not good, with lots of different textures and stuff so I usually have, like a whole set, a whole cupboard full of the same colour jeans and then a whole bunch of very different T shirts it fools people into thinking that I like wear different things actually just the same thing every day. It's just different. It's just different instances. It's the same car, right? It's like, object oriented programming. It's just that the, for instance, with the different colour and a different thing on it. But like a whole bunch of people were really like they see photos of me from in the before time and they're like, But that doesn't even look like you. Yeah, I know somebody once did a mood board for the Government Digital Service, and there was a guy called Mark Stanley who's fantastic but like was a qualified lawyer and wore like a three piece suit and an actual bowler hat and his version of like dress down Friday was he would wear actual blue suede shoes. They were very cool. He, also once went to a meeting with a particular minister, he was not a fan of wearing cock and balls cufflinks, which I always admired him for he was not very pro LGBT Rights so I thought it was a very fair minor protest on his part. But somebody wants to the mood board which actually had him in his full like, three piece suit and me wearing a T shirt that said intellectual hooligan on it and apparently the summary of these two things that was what GDS culture was like.

Amy - Ah brilliant, and finally then Meri, where can people find out more about you?  

Meri - @geek_manager on Twitter is the gateway to all of the various locations on the Internet and I think I'm the same on Instagram. And I have ah, separated Instagram specifically for meat which is at meat leader on the on instagram.

Amy - Fantastic. So we'll be sharing all of the links and books and things you've referenced in the show notes, of course, along with the all-important doodle as well

Meri - I want a t shirt with cats and lasers on it. I feel like this is the missing element of my collection that...

Amy
can also make it with your brand new doodle, right, Which is obviously what we've all been waiting for as well,

Aaron
I was going to say Meri, you know, like, I'm not saying that it should be your new Twitter profile picture. I'm just saying it could be

Amy - Meri, thank you so much for taking the time to talk to us today. It's been amazing.

Aaron - Thanks so much. Meri.

Meri - Thanks for having me.

Amy - We'll be sharing all the links and show notes, plus the all important doodle over on our website. HumansPlus.Tech. I'm Amy Phillips. This is Aaron Randall and you've been listening to the Humans+Tech podcast.

Kim Scott, author of the New York Times & Wall Street Journal bestseller Radical Candor, talks to us about feedback, growth management and why reading novels is a great way to improve your management skills.

Scroll down to read the full transcript of our chat with Kim.

Kim’s quick fire answers

• Kim recommends reading novels. Her favourite is Middlemarch by George Eliot.
• Kim's favourite way to keep up with the industry is Twitter. She recommends following Walt Mossberg, Kara Swisher, and Dick Costolo.
• Kim is inspired by Jack Dorsey.

We also cover

1. What is radical candor? [00:02:28]
2. Compassionate candor as a way to avoid obnoxious aggression [00:03:20]
3. Why Kim chose Radical Candor as the name for her book [00:03:55]
4. Why our first job, and our upbring makes radical candor rare [00:05:56]
5. Kim explains the quadrants of Radical Candor [00:08:16]
6. How managers can help their teams to avoid obnoxious aggression and ruinous empathy [00:10:54]
7. Focusing on the positives to help people see what success looks like [00:11:33]
8. The Centre for Creative Leadership's Situation Behavior Impact framework [00:12:46]
9. The Situation Impact Action framework [00:14:34]
10. Removing emotion from feedback [00:14:51]
11. How to get good at giving feedback [00:15:52]
12. How Sheryl Sandberg gave Kim some painful criticism [00:18:03]
13. Re-creating the 'walk with me to my office' feedback opportunity when working remotely [00:22:47]
14. Tips for managing remote teams [00:25:09]
15. Why Kim turned down the opportunity to be CEO at Twitter, and how she felt about it [00:27:06]
16. Gradual and Steep growth trajectories [00:29:40]
17. Rewarding Rockstar employees as well as Superstar employees [00:33:27]
18. Fixing a 'promotion obsession' culture by rewarding Rockstars [00:38:38]
19. How Apple rewards Rockstars with a glass apple [00:39:35]
20. What can you do to build trust in a team [00:41:40]
21. The Second City and why improv skills are really good CEO skills [00:43:20]

Find out more, and follow Kim

Find out more about Kim at RadicalCandor.com and ImprovisingRadicalCandor.com

Full transcript

Amy - Welcome to the Humans+Tech podcast. I'm Amy Phillips and this is Aaron Randall. Today, we're thrilled to be talking to Kim Scott, author of The New York Times, The Wall Street Journal bestseller, Radical Candor. Kim's also led teams at Google and worked for Apple, as well as being a CEO coach for companies including Dropbox and Twitter. Kim, welcome to the show.

Kim - It's great to be here. Good to see everybody all over the globe. Hope everybody's doing all right.

Amy - And so you are famous for encouraging people to give good feedback. That's certainly where we kind of, like came, came across you and, like we've learned loads about that from you. So I'm gonna just start off by asking you to give us some feedback. So it's kind of tradition which each episode of Humans+Tech that we draw a picture of our guest so I'm just gonna share my screen, and show you your doodle we'd love to hear your feedback

Kim - and you're starting. My first feedback is you're starting in the right place with Radical Candor. You're soliciting feedback instead of giving it so Okay, so so I love the doodle. Here are the things that I love about the doodle. I love that the two by two is featured for I love a good two by two. And so, so you got the essence of the book there in the picture of the book and a very succinct way. Uh, those are my glasses, those are the glasses I'm wearing right now and and I love that I love the lines coming out towards it. If I had to say I miss one thing, I miss my nose. So how's that for feedback?

Aaron - You know, this is the best feedback I've ever got for a drawing. Yeah, I do. I tend to not draw noses on people for some reason. So that's that's fair feedback,

Amy - I think also, incredibly, polite. I think we just got the masterclass in how to give nice you know, constructive feedback

Kim - compassionate candor, hopefully

Amy - We're like going to go straight into the real stuff. I think we've kind of touched upon it already, but your book, Radical Candor. So it's kind of you, it feels that you single-handedly introduced the tech industry to feedback. Can you tell us exactly what you mean by Radical Candor and why did you choose that as the name for your book?

Kim - Sure. So Radical Candor is really about caring personally at the same time that you challenge directly. If you want to abstract even more, it's about love and truth at the same time. Now there's very often we have this idea in our mind that there's a false dichotomy between showing someone you care and telling them when they're screwing up. And the fact of the matter is that the two things are intimately linked, and so that's the idea of radical candor. Why did I call it Radical Candor? Uh, yeah, I got If you write a book about feedback, you're going to get a lot of feedback. And I did get some feedback that that is fair. That a lot of people were using the term radical candor is an excuse to act like a garden variety jerk. And that's not what I meant by radical candor and so, uh, in the second edition of the book, I actually call it compassionate candor. So if you're in an organization where people are are using radical candor is an excuse to behave badly, feel free to call it compassionate candor to remind them that there's a difference between radical candor and what I call obnoxious aggression , obnoxious aggression is what happens when you challenge directly. But you forget to show that you care. So why did I call it Radical Candor? Was it that was the second part of your question right now. So the reason The reason? Well, first of all, it sounds cool. Uh, in fact, I have to credit. I have to credit Dan Pink, who has written To Sell is Human, he wrote Drive, he's written a lot of great books. He wrote Win and I gave a presentation about radical candor. But at that point in time, I was calling it tough love. And Dan was like, I love your presentation, I love your ideas. But tough love just doesn't sound good. And we were in an elevator together, so he gave me some radical cantor and then he helped me come up with something better. Somewhere between the first floor and the 14th floor, tough love became radical candor. So thank you, Dan Pink for help naming the book. The reason why I liked radical candor is that radical to me imply something very fundamental. And as I said before, if you abstract up the idea of caring personally and challenging directly, it's really love and truths and these are very fundamental human values, love and truth. And so that's part of why I called it radical because it's fundamental. And then the other reason why I called it radical is because I think that to me it's rare. It's so rare that we get this at work in Tech or in any other industry. That's one of the things I've learned. And so that was also partly why I called it Radical Candor. And why candor? Why not truth? To me truth implies, if I tell you, I'm gonna tell you the truth. I'm kind of implying like I've got a pipeline to God and, you know, am I allowed to curse on this podcast?

Aaron - You can do what you want

Kim - okay? And you don't know shit from Shinola. That's an expression from the south of the US, and that's not a great way to start a conversation. So, to me, candor implies, Here's what I see. I want to share with you what I see. But I also want to hear how you see it. So that's why Radical Candor.

Aaron - Awesome. I wanna touch upon a point you made that quickly. Which is, you said, that radical candor is rare. Why do you think that is?

Kim - I think it's rare for a couple of reasons. I think so sort of what causes us to have a fail on the care personally dimension. I've worked with a lot of different leaders, a lot of different people, and I've never met anyone who said, I don't care about other people So I'm gonna be a great boss. But that's not what moves us down. I think the vast majority of people do have an instinct to care about others. So I think what happens on the care personally dimension begins when were about 18 19 20 years old. We're right at that moment in our lives when our egos are maximally fragile and our personas are beginning to solidify to protect those fragile egos. And right at that moment someone will come along and say, Be Professional and I think for a lot of people, sort of without even realizing what we're doing, we sort of translate that to mean and leave your emotions, Leave your true identity, leave your humanity, leave everything that's best about you at home and show up at work like some kind of robot. And you can't possibly show you care personally if you're showing up at work like some kind of robot. So so a big part of this book is about encouraging people and giving people specific suggestions about how you can bring your full humanity to work. So that's one problem. I think the second problem begins much earlier. It begins when we're 18 months old. We're just learning to speak and we're painfully honest as children and our parents say some version of us and every culture has a version of this saying. If you don't have anything nice to say, don't say anything at all and and so this has been pounded into our heads since we learned to speak, and now all of a sudden you become a leader, a boss, a manager, and it's your job to say it, and that is really hard. It's really hard to undo training that's been pounded into you since you got your first job and since you spoke your first word and so one of the things that I've done to try to make it a little bit easier for people to be radically candid. So that radical candor is more more common. And less rare is to give words to what happens when we fail on one dimension or another. You ready? Ready? Okay, here's the words. So So sometimes we remember to challenge directly. Remember to be honest with people about what we really think, and we forget to show them that we care personally and that I call obnoxious aggression. I mentioned that a moment ago, and sometimes people call obnoxious aggression sort of the asshole quadrant. But I decided not to call it that for a very specific reason. When I did that people would use the radical candor framework and used these terms I'm about to share with you as sort of a new Myers Briggs personality test, and I beg of you, don't use it this way. These are mistakes that we all make interpersonally and conversations day to day these are not personality types. We all are probably at least once today, obnoxiously aggressive and very often the problem when we when we are obnoxiously aggressive when we have challenged someone in a way that doesn't show them that we care when we realize we've been a jerk instead of moving the right way on the care personally dimension of radical candor we move the wrong way on challenge directly, and we wind up in the worst place of all what I call manipulative insincerity. And that's what happens when you're neither caring nor challenging. And that could be the false apology. It can also be simply the sort of a backstabbing. It could be passive aggressive behavior, and and that's the kind of stuff that really makes a workplace toxic. That sort of manipulative insincerity combined with obnoxious aggression, and it's kind of fun to tell stories about those experiences. But the fact of the matter is, the vast majority of us make the vast majority of our mistakes in what I call the ruinous empathy quadrant and ruinous empathy is what happens when you do show you care personally but you're so concerned about not hurting someone's feelings, not giving offense that you failed to tell them something that they'd be better off knowing. So that's radical candor, what it is and what it isn't.

Amy - Oh, yeah, I recognize so many of those. Yeah, and those the quadrants, then that you referenced in the beginning when you were giving us feedback.

Kim - exactly

Amy - so I one of the things. So I manage people. And I think quite a lot of people listening to this podcast manage teams. How do you help people who you manage learn to sort of move out off those different quadrants? Like, how do people actually build the confidence and the skills to be able to give feedback well?

Kim - I think there's there's kind of an order of operations to this, and the first thing you can do is you can model it by doing exactly what you did by starting with soliciting radical candor. Don't dish it out until you prove you can take it. So ask people on your team to give you feedback and then respond to it really well when you get it, and that can begin to build a culture of radical candor. The second thing to do is to really focus on the good stuff when you're a leader. Part of your job is to show people what the possibilities are to paint a picture of what success looks like and praise, as it turns out, is a much better tool for doing that than criticism is. Which is not to say that criticism is not important. So you start by soliciting criticism, then give praise. Next you've created a better mind space for yourself and for the other person to offer radical candor. And that's that when you when you offer criticism in a way that is humble in a way that states your intention to be to be helpful in a way that is quick, these conversations should be sort of two minute and impromptu conversations. It shouldn't feel like a root canal. It's more like brushing and flossing for your relationships when you when you want. When you praise in public and you criticize in private and when you offer the kind of criticism that's not about personality, but rather about something the person can change so you can use, The Centre for Creative Leadership has this framework called Situation Behavior Impact, and that's a great way to make sure you're focusing on something that that someone can change. So I think that that that you can really model this. But there's a 4th step here, and the fourth step is really, um, you you need to make sure you're gauging how what you're saying is landing. Because if I if I have a team, for example, if I have a team in Tokyo and another team in Tel Aviv, radical candor is going to sound very different in Tokyo than it does Tel Aviv. And so, in fact, when when I was in this situation, I called radical candor for the team, and in Japan, I called it polite persistence. But I would not have called it polite persistence for the team in Israel because they would have thought I was telling telling them not to be as clear as they wanted to be. And so so it's really important to adjust how you're talking for the culture that you're talking to, but also crucially for the person. So if you're being radically candid with me, you're gonna have to really go further out on the challenge directly dimension. Than maybe you're even comfortable doing cause I'm not always the best listener. But if you're being radically candid with my sister, who's a great listener and and maybe more more sensitive than I am. You're gonna have to really attend to the care personally. dimensions. So you need to adjust. You need to choose the right vector, depending on how the person is is responding. So I think that's really important. Does that make sense? Does that help a little bit

Aaron - Yeah, definitely, that's great. I actually love the fact that you brought up the model the SBI situation behavior impact model that you referenced there as a way to structure that Amy and I  actually wrote a blog post on SIA, which is a very similar concept Situation Impact Action, but very, very similar. And as a manager, I actually have it written up in a book on my desk and I, whenever I know I've got feedback to give someone I always go back to the book before I give any feedback quickly, go back to refresh myself and talk through it and kind of remove the emotion and think about the fact and use that structure to give great feedback or hopefully great feedback.

Kim - Yeah, and I think it's you touch on something that's really important. You want to remove the emotion from yourself because if you get too angry or too frustrated or as least if I get too angry or I get too frustrated. That's my path to obnoxious aggression. But at the same time, I have to go into those conversations being willing to accept emotion from the other person. Because I think one bit of advice I have for people is just eliminate the phrase 'don't take it personally' from your vocabularies because we do take it personally when we get criticism and part of your job as a leader is to be almost like an emotional shock absorber.

Aaron - Definitely. And it's interesting you talk about it as someone who is a seasoned leader. But people that are listening to this podcast now particularly first time managers, I guess the question for them is people find this inherently difficult to give feedback. How do those people that are new to management, haven't had the practice over and over again get good at this?

Kim - Yeah, it is, you know, it's really interesting. First of all, if you're a first time manager, I feel your pain. It is really it is hard, and it is isolating, and the vast majority of first time managers don't get any management training at all. They just get thrown into the deep end. So it's and that's scary. It's a scary situation also, I think at least when I first became a manager, I had this very complicated relationship with the role a friend of mine put it this way. She's she said, Kim, you hate the man and now you are the man. But you're a woman, you know, very complicated and so, so the question is, how do you resolve your own sort of relationship with authority? And I think all of us have a complicated relationship with authority, and it becomes more complicated when you become the authority. So a couple of pieces of advice I have for new managers on on overcoming this one is that the vast majority of new manager's are reluctant to give feedback because they are reluctant to hurt someone's feelings there. Its ruinous empathy. And so I have two suggestions. One. Think about that moment in your career when someone gave you some feedback that may be stung a little bit in the moment, but stood you in good sted for the rest of your career, and then think about that moment in your career with when either you someone failed to give you some feedback and you wish you had gotten it or you failed to give someone some feedback. So I'll give you I'll share my stories with you. But if you can think of your stories than I think, it will really help you hook into that desire to be kind. And I don't want you to lose that. But to realize that the feedback can be an act of kindness when delivered correctly, does that make sense? All right, you want you want my You want my painful getting some painful criticism story. Okay, okay, So so that this happened. This is it's in the book, but I'll tell the story. So this happened shortly after I started working at Google, and I had to give a presentation to the founders and the CEO of a bunch of other executives about how the AdSense business was doing, and I walked into the room and they're in one corner. Was Sergey Brin standing on an elliptical trainer, peddling away wearing toe shoes, Not what I expected. And there in the other corner of the room was Eric Schmidt. He was CEO of the time, and he was so deep in his email it was like his brain was plugged into the machine and I wondered, how the world am I supposed to get these people's attention? I felt totally nervous. Luckily for me, the business was on fire, and when I said how many knew how many new people, how many new customers we had added over the last couple of months, Eric almost fell off his chair, said, What did you say? What do you need? How can we help you? Do you need more marketing dollars? Do you need more engineering resources so I'm feeling like the meeting's going okay. In fact, I now believe that I am a genius. And as I walked out the meeting, I walked past my boss, who is Sheryl Sandberg. And I'm expecting a high five, a pat on the back, and instead Cheryl says to me, Why don't you walk back to my office with me? And I thought, Gosh, I have screwed something up and I'm about to hear about it and Sheryl began the conversation by telling me about the things that had gone well in the meeting, not in the feedback sandwich or the shit sandwich sense of the word, but really seeming to mean what she was saying. But of course, all I wanted to hear about was what I had done wrong. And eventually, Cheryl said to me, You said um a lot in there. Were you aware of it? I kind of made this brush off gesture with my hand and I said, yeah, I know it's verbal tick No big deal, really? And then she said, I know this great speech coach  I bet Google would pay for it. Would you like an introduction? And once again, I made this brush off gesture with my hand. I said, No, I'm busy. Didn't you hear about all these new customers I don't have time for a speech coach and then Sheryl stopped, She looked me right in the eye and she said, I can see when you do that thing with your hand and she made the same brush off gesture. I'm gonna have to be a lot more direct with you. When you say um every third word, it makes you sound stupid. Now she's got my full attention and some people might say it was mean of Sheryl to say I sounded stupid. But in fact, it was the kindest thing she could possibly have done for me in that moment, because when she said it to me just like that, that was when I knew I had to go to the speech coach. I probably wouldn't have gone otherwise. And by the way, she wouldn't have used those words with someone else on her team who was maybe a better listener that I was. But those were the words she had to use with me. And when I went to see the speech coach, I learned something important. She was not exaggerating. I literally said um every third word, and this was news to me because I had been giving presentations for my entire career. I had raised money millions of dollars for two startups giving presentations. I thought I was pretty good at it. It was almost like I had been walking through my whole career with a giant hunk of spinach between my teeth, and nobody had had the common courtesy to tell me it was there. And so this really made me wonder two things really What was it about Sheryl that made it so seemingly easy for her to tell me? But also why I had no one else told me. And and it was really thinking about that, that I came up with the care personally challenge directly because I knew Sheryl had my back. She really showed that she cared personally about not just at an employee level, but at a human level about everyone who worked directly with her. But she also was was not hesitant to tell us when we were growing up. If we needed to know about it.

Amy - Well, yeah, that's amazing. It's definitely one of my favorite parts of the whole book. Like, I think there are so many bits, like the fact that you know, so much. Like she had some positive feedback in there and the timing. And, you know, the fact that you say she was the first person to actually point out something that you know, everyone else that clearly had seen, Um, one thing I was really wondering about. So in the kind of current time most people are working remotely, sort of sort of successful pieces you said about that feedback was she  grabbed you straight away, it was like a walk with me to my office. Immediate feedback. Yeah. Do you have any tips on how, like, how do you recreate that sort of walk with me to my office when everybody's remote?

Kim - Yeah, it is, really. It is really tough. I had was I have twins who are 11. But when when I was pregnant with them 11 years ago, I couldn't travel. I had teams all over the world and I couldn't travel. In fact, for the last couple of months, I couldn't get up off my couch. I was I was on bed rest, and so I had to sort of figure this out. And one of the things that I learned is that if you are working remotely and you're a manager, there's a couple of things that really can help it work. One is, to, if you're if you're on a call, let's say, with five people that one person makes a mistake. Just text them at the end of the moment at the end of the meeting. Do you have two minutes after this meeting and and and also work really hard not to schedule yourself and everybody else back to back. I know that there's a lot of people who are are advocating for Zoom in moderation and I agree be be conscious. Not everything needs to be synchronous. We can get a lot done, asynchronously So so if you have a couple of minutes after the meeting, just just create, recreate that moment and just make it a two minutes facetime chat or or Google Hangout or whatever technology you're using but do make it a video conversation, Because one of the things I found when when I had all these remote teams and I couldn't travel to them is that if you're very conscious of using video, you can get so you can't get 100% fidelity. But you can get, like 70% fidelity of the in person conversations because you see the person's expression, you see at least a little bit of body language, and that gives you a much better opportunity to do what I was talking about before to gauge their response to your feedback and to adjust how you're you're talking accordingly. So I think just two minutes right after it could be really helpful. Another thing for remote workers. That I think is for remote teams that I think is really important is if you're gonna have one on one meetings. Have more frequent one on one meetings, like instead of, ah, once a week or once every other week meeting for an hour. Have three or four meetings a week that are 5 10 minutes, that is. Actually, it's it's sort of counterintuitive, but especially right now when things are are so stressful, a lot happens for people in a week, and shorter check ins are really important. Have it's also easier to work in for people who have children at home and they're trying. They're suddenly have a second job of teaching. Uh, it can be easier to fit in a 10 minute meeting in between things than an hour long meeting. So So I think the fewer longer meetings you can have, the better in this in this time. Does that help? A little.

Amy - Yeah, that's great.

Aaron - I'm definitely as well a sucker for that back to back meetings thing. I love the idea of having a bit of space, so you got time for a feedback and also grab a cup of tea and your breath, so

Kim - yeah, yeah, I gotta go to the bathroom occasionally too. And that that was that was true before, But I think it's even more true now because I think before we were more conscious because you have to go from place to place. So 30 minute meetings for 25 minutes. It's still important to make a 30 minute meeting 25 minutes an hour long meeting, 50 minutes so that people can chat in between, can get a cuppa tea and go to the bathroom like we still have our physical needs.

Aaron - Definitely, definitely. I'm really glad, actually, that you brought up your family when you were sharing that story because it reminds me of another anecdote in your book and which is I hope is ok for me to hare this but back. In 2008 you were approached for the CEO role at Twitter and what you shared with you, what you shared in your book was at the time you were 40 years old and pregnant with twins and at that particular stage in your life, you said, I'm not saying I couldn't do the Twitter CEO role. I'm just saying that I didn't want to. What was it like for you going through that experience shifting between steep to stable growth in your career and actually having to say no to certain opportunities like that CEO role?

Kim - Yes, it was, really. First of all, it was It was a big mindshift for me when I when when someone called me and said, Would you be interested in throwing your hat in the ring? I thought about it and I called my my doctor, and I asked her what she thought and she said, Well, what's more important to you, the hearts and lungs of your children or this job? So she put it in very stark, and I don't I don't say this to be discouraging. Like most women who are pregnant are not 40, pregnant with twins. So I was in a very high risk pregnancy. There's plenty of other women who were pregnant who could have taken on that role. But but my my situation was specific and, you know, and I was 40 I might not get another. I was lucky that I got pregnant at all, and so I might not get another chance. So there was a lot of reasons why this was the stakes were especially high for this pregnancy, and I was really glad she put it to me that way because then it became I mean, it was easy. That became a very easy choice when she presented it to me that way. And but I still had to make my peace with it. And one of the things that I found is that I was doing. I have been, so  at the time I was. I was working for the AdSense team, the YouTube team and the DoubleClick teams at Google, online sales and operations, and I'd been doing that role for a few years, so I was pretty good at it. And I had built a team that I could really rely on, and it turned out that Google was like the ideal place for a high risk pregnancy because there were snacks everywhere and there was like a lap pool that I could that I could swim on. There was there was actually a, uh, masseuse, who specialized in massage for pregnant women one floor up like so you couldn't have I, I will always always be grateful to Google for helping me through that that that time and and the fact of the matter was it wasn't like I couldn't work. I was still doing good work and I still had a job that was that was, ah, a big job. So so I could do that. And the reason I could do that was because I could be on gradual growth trajectory in that job because I had been doing that job. I knew how to do that job. I had a team I could rely on. And that was that was it was really important for me at that stage in my career to remain on a gradual growth trajectory not to not to take on a new role that was gonna require me to be on a very steep growth trajectory. And I think all of us at different phases in our career. We're all always, hopefully trying to do great work. To have very high performance, but at different moments you're on a steep growth trajectory where you really gunning for that next job and there are other moments when you're not on a steep growth trajectory. When you're on a gradual growth trajectory, and you want to save some of your energy for something outside of work, so it could be an artistic endeavor. It could be that you're a great painter and you want to get home and paint, or that you're a great actor and you want to be in all and shows after work. Or it could be family. You you could have an ill parent to take care of or you're starting a family. And so I think it's so important for managers to understand where people are in their growth trajectories and to make sure they're managing them appropriately. So I call it sort of sometimes your in superstar mode, and that's when you're in a steep growth trajectory and other times you're a rockstar mode, and that's where you're doing great work, and you'll continue doing great work. But you're not necessarily shooting for the next big job. You're you're solid as a rock in rockstar mode.

Amy - It's such an interesting like concept, like I think, so many companies and certainly maybe most companies in my experience seem to be really set on the idea of you're performing or you're not performing. This kind of like the there are different stages in life in different maybe just different times in life where you want to focus on other things.

Kim - Yes and actually, your focus on other things brings a richness to your work that wouldn't otherwise be there.

Amy - Yeah. Yeah, definitely. Funny, actually. Funny story, we had, I used to work at The Guardian newspaper and um I was leading a test team. We had to build like a little widget for the website to show cricket scores. And we had one tester who loved cricket and we were like, perfect. He can test the thing. No one understands cricket scores right now. Right on. Then, unfortunately, he was at a cricket match and he got hit on the head by a cricket ball. Spectating turns out it's really dangerous. He went off sick. We stepped in. Well, okay, we can do this. We don't know what the numbers are. We work with the Sports department, he comes back a few weeks later. He's like, What have you done the numbers are all totally wrong. Turns out nobody knows cricket scores. That was Yeah,

Kim - Well, yeah. You know, it's when people when people are great at something. What's impossible for others is easy for them.

Amy - Yeah, um, I really, uh I really interested, Like so as somebody who say working in a company as a manager. But maybe not the person who gets to decide how everything works. Like, have you got any advice about how does a manager maybe introduce more of a growth framework like growth management framework, maybe mindset or approach to a company, which is more is using more like traditional assessment models?

Kim - Yeah, I really feel for you. I think, in Tech very often there's there's a strong bias towards people in superstar mode and other companies in more stable companies. There can be a bias towards people in rockstar mode, and so sometimes you might have a boss who wants to clip the wings of people in superstar mode. And other times you have managers who don't appreciate the benefit of having people in rockstar mode. And so how can you communicate this to your boss? I had it was very interesting when I was when I was a Google, their was there was a guy on my team who, really he was a customer support and he loved his job. He really loved his job and he wasn't necessarily interested in the next big role. And and he was very, very, very good at his job. And we we were doing calibrations for for bonuses. And he didn't he didn't merit as big a bonus as his rating would imply. And the reason why that happened is that they were stuck in the calibration process. They were saving all the highest ratings for people who wanted a promotion, and he clearly didn't want a promotion. And he sat me down and he said, The promotion comes with its own reward. It comes with a big step up and equity and a big step up and salary. I'm not looking for that, but I do expect to be rewarded for the work that I am doing now, and I do expect you, Kim, to value that. And I remember going in to my and it was difficult because of these calibration meetings. I'm sure you've been in them. It gets more complicated as you go up. So I went into my boss and I said I made this very impassioned plea. I said If we care about the core work that we're doing, then we must paid bonuses, high bonuses we must pay. We can't save the highest bonuses for people only for people who are on promotion track. And we changed the way we calibrated, and we made sure that we said on for this kind of work sort of 60% of the people should be a rockstar mode and 40% of the people should be in superstar mode. And we've got to make sure that we're we're giving performance ratings and bonuses that reflect the work they did that quarter. Not sort of this. A lot of companies they have what's called the performance potential matrix. And if you're not, and if your high potential hypo then then that means your your on  Superstar. Oh, you're on track to promotion. But there's no such thing as a low potential human being, and you certainly don't want to brand the people on your team who are who are in rockstar mode. As low potential like that's that. Then, of course, you're gonna not reward them properly. So So I really object to the performance potential matrix as a the words are wrong. That's why I replaced it with with growth and and you really need on a team to balance growth and stability. And you really need in a life to balance growth and stability. There are times when you're on a high growth mode and there times when you need to be in stability.

Amy - Yeah, it makes total sense.

Aaron - Yeah, definitely. I know from firsthand experience how much I've struggled with having rockstars and my team and, a system that only supports, um, promotions and title changes the way to essentially compensate people well.

Kim - Yeah, it's awful

Aaron - So it's good to hear. Yeah, but I don't think I fixed that or found a way to work around that. But it's great to hear there are ways of doing it. Particularly good ones

Kim - Yeah. I mean, there are a one way to do that is to make sure that there's that you're sort of explicit about what's the right balance of rockstar mode and superstar mode, and because sometimes we would be having these arguments. And the reason why they were unresolvable is because one person was thinking that the only people who should get the highest rating or people in superstar mode And so I was arguing for super high rating for someone in rockstar mode, and they were arguing. But they're not in super, so like it became circular. And so if you're very explicit, and if you make sure that you are clear with people that you're not gonna save all your highest ratings and all your bonuses for people who are on promotion path but like you don't want to create promotion, obsession in your company, you want people who are really good at their job and we'll keep doing their job if you don't screw it up for them by penalizing them for not wanting your job, like, why would you do that? And yet people do it all the time.

Amy - Yeah, definitely. It's an interesting one. So the whole kind of obsession with promotions, it's really difficult when when you do find that you sort of created that culture, I mean, is this the way to undo it like to actually just start rewarding people who are not on the promotion path?

Kim - Yes, absolutely. I mean, it was really interesting when I when I got to, I left Google and I went to Apple, and when we would start our classes. We would ask people how long they'd been at Apple. And there were people who had had the same job at Apple for a decade. And this was really striking to me, because if you had the same job at Google for more than about three or four years, it was like a badge of shame. And I think Google has fixed this has it. It was, you know, part of part of being in a super fast growing company. But I think Apple really honored did a really good job honoring people in rockstar mode because they did have a lot of people who have who were sort of like artists. They had this very special, very specialized talents and it and they didn't necessarily want to be to be leaders. But there had to be a way to honor people who had these talents that were contributing and not make them feel ashamed because they weren't taking on another bigger job. So one of the one of them, in one of the things that Apple did, for example, is they created this really beautiful, this really beautiful sort of glass apple and Jony Ive himself helped design it and it would get presented to people who had been in the same role for a long time in a way that was very meaningful for them and so there are a lot of sort of small things, I think, also setting up people who have a particular expertise as as the guru for this thing and allowing them to teach others if they if they have an interest. Not not everybody likes to teach others so you don't want to require. It needs to be a reward, not punishment. But But I think that that honoring expertise and craft is really important much more important than honoring someone who gets promoted to have a big team or something like that.

Aaron - Yeah, to think about I also did you get a glass apple?

Kim - No, I didn't. I did not stay at Apple nearly long. I was only there for 2.5 years, so I definitely did not earn my glass apple.

Aaron - Awesome. So we've covered feedback and we spoke about performance and growth, One of the things that you've also done in your career is and continue to so is coach a bunch of different CEOs in the industry. What's the biggest thing you've learned from coaching CEOs?

Kim - You know, it was really interesting and Radical Candor in the book, I tell a story about Ryan Smith is the CEO of Qualtrics, which is the survey company, and when I first met him, he was just assembling sort of a new team. So he had just hired four new people to work to start working together with with three veterans on the team, and he asked me a really important question. He said, What can I do to build trust with each of these people and to help them build trust with each other so that we can move quickly? And this is the central question I think of, of leadership and management is assuming you don't assuming that you believe like I do, that command and control is not the best way to to build an innovative team that's gonna do creative work. You have to replace those old notions of command and control with something, and the that something is really a human relationship that's based on trust, and the fastest way that I know of to build trust is to be honest with people about what you really think and to show them compassion at the same time is radical candor. And so that was something that that he and I really spent a lot of time thinking about. So I really admired him for asking the most important question first,

Aaron - nice. Must be quite refreshed when your people in that such senior positions that are asking those kind of powerful questions.

Kim - Yes, it really is. It really is. I mean, I always admired also Dick Costolo enormously when he was CEO of Twitter. He was, it turns out improv skills are really good CEO skills. That's a tactic if you're a CEO take an improv class. Ah, he's ah, he's a Second City alum And and he used humor with such grace, too. He was not. It wasn't one of those people that had a mean sense of humor. He had a kind sense of humor, and he used humor to share the truth with the whole company, but also to show compassion for the situation they often found themselves in. It was hard being in Twitter in those days, still is I imagine.

Aaron - Nice, unfortunately, Kim we are running out of time, um before we wrap. We have three quickfire questions, which we like to ask all our Humans+Tech guests so we'll dive straight in if that's okay? Um so. first question is, what's your top book recommendation?

Kim - I can't say Radical Candor. I guess. So I usually read novels, and my favorite novel of all time is Middlemarch by George Eliot. I think reading novels is the best way to develop compassion and empathy for other people. And so read novels. Read your favorite novels. Mine Is Middlemarch,

Aaron - which I never do either. I never read novels

Amy - We've talked about this. You need to read novels.

Aaron - I just read these kind of books

Kim - I tried to write that book to read more like a book of short stories for that reason because I think it is. It is all about developing compassion for other people,

Aaron - and the anecdotes really stand in your head as well those little stories as well, which remind you of the topics

Kim - it's easy to learn through fiction.

Amy - Yeah,

Aaron - you know it's okay. Quickfire question number two What or who is your number one tip that keeping up with the industry.

Kim - You know, I follow if you curate your Twitter feed very carefully. you will. You will find out what's happening. Err so who are some great follow Walt Mossberg follow Kara Swisher. Follow Dick Costolo. You'll see what's happening.

Aaron - Yeah, everyone says Twitter don't they? and finally number three who inspires you in Tech,

Kim - the people who I am actually very inspired by? Jack Dorsey in Tech, which I know is a controversial answer. But he is a person, I believe, of real principle, and I don't always understand why he makes the decisions he makes that I would sometimes make different ones. But I I I do find that if I'm able to listen to what he says and try to understand the reasons why he's doing what he's doing, there's a principle behind what he's doing. He's taking a principled approach. He's not. He's not, uh, he's not taking advantage of a situation for personal gain, and I really admire that

Aaron - Great Great and Kim where can people find out more about you?

Kim - RadicalCandor.com and ImprovisingRadicalCandor.com So RadicalCandor.com We offer talks and workshops, increasingly virtual talks and workshops to help people put these ideas into practice and Improvising Radical Candor. We actually made a sitcom a workplace comedy with the Second City, the improv group in Chicago and and it's ah, it's not your grandfather's management training. We came up with a really fun way to learn how to be a better boss.

Aaron - Thank you so much for taking the time to talk to us today. It's been so much fun. Great. thanks so much

Kim - Great, thanks so much,

Aaron - Thank you. We'll be linking to all the websites and doodles in our show notes. But if you haven't had a chance to read Radical Candor, grab yourself a copy and learn how to give amazing feedback and build trust with your teams. I'm Aaron Randall. This is Amy Phillips, and you've been listening to the Humans+Tech podcast.

In this episode of the Humans+Tech Podcast we're talking to the incredible Camille Fournier, managing director of Two Sigma, and author of the books The Manager's Path and 97 Things Every Engineering Manager Should Know.

Scroll down to read the full transcript of our chat with Camille

In this episode we cover

1. The Rent The Runway career ladder [00:01:05]
2. Progression.fyi [00:02:29]
3. How to build a good career ladder [00:02:58]
4. Manager READMEs [00:13:47]
5. The Manager's Path [00:19:24]
6. Camille's experience of moving into management [00:22:52]
7. Managing in startups [00:26:12]
8. Building a Peer Network [00:29:06]
9. Lara Hogan's Manager Voltron [00:32:16]
10. Camille's quickfire questions [00:35:22]

Find out more, and follow Camille

Follow Camille on Twitter

We were discussing Camille's books The Manager's Path, and 97 Things Every Engineering Manager Should Know.

Full transcript

Aaron - Welcome to the Humans+Tech Podcast. I'm Aaron Randall, and this is Amy Phillips  

Amy - Hi

Aaron - Today we're talking to the incredible Camille Fournier, managing director of Two Sigma and author of the books The Manager's Path and 97 Things Every Engineering Manager should know. Camille Thanks you so much for taking the time to talk to us today.

Camille - Thank you. Very excited to be here,

Aaron - So I want to start actually,  Camille with the serious stuff, um, so it's a Human+Tech tradition for me to draw a doodle of our guest and that goes out when we publish the podcast. So sure, Yeah, this is very serious. So I want to show you the doodle I drew of you and if we could just get your thoughts and feedback, so

Camille - All right. Wow. I like that. I have a necklace. Yeah, and the short hair. I think I think this is pretty good. Very talented

Aaron - you know, I did notice. Actually, you have, like, the best necklace collection Google Photos shows that

Camille - It's true.

Aaron - Okay, Now we've got that stuff out the way let's dive in. So Amy and I first learned about you a few years ago when you were CTO at Rent The Runway and so at Songkick where Amy and I were working at the time, we were busy building a growth framework or an engineering ladder for our tech scene and we found a blog post from Rent The Runway, which you wrote back in 2015. Sharing your teams growth framework. It was a simple spreadsheet, but the core skills, role and structure really influenced what we ended up developing at Songkick. So I guess thank you for doing the hard work. And also thank you for sharing it with the world.

Camille - Absolutely. I mean, I you know, I shared it with the world partly because when I went to do my own, I had several friends in New York City tech companies that slipped me there's kind of under the table and they were like, here's some ideas. And my my husband, actually still works at Google, and he kind of let me look over his shoulder at some of the things that they had done there, and I was like, Okay, great. Now I feel like I have some some baseline and I'm obviously my team also contributed a huge amount to to the product. And, you know, at some point it was like, you know what? like this is a lot of work, and we're all kind of trying to do the same thing. You think I should just share what we've done and make it a little bit easier for people to get started. And so that's that's kind of why I did it

Aaron - Follow up question I had was It seems like now nowadays it's becoming really common for people to do that. And you have a whole websites dedicated to people who've shared their growth frameworks like progression.fyi. You know, your growth frameworks on there and Songkick's is on there and there are tens of them from big companies. But it did feel like, I guess, as we were saying Rent The Runway was ahead of the curve there. And it also stood the test of time. So you mentioned that you built this thing with your team. But my my follow up question was, How do you go about creating such an amazing growth framework?

Camille - Yeah, I mean, like I said so part of it was I did get a lot of people to share information sort of off the record with me about what they had done. Um, and and that was that was useful. I mean, really, what happened was I actually did two versions of the framework. So the first time I tried to do one, we had a very lightweight sort of low detail. Um, you know, not that many levels framework that I rolled out. I can't remember exactly when, but But I rolled out, you know, maybe in 2013 early, 2014 something like that. And, you know, we did it because people have been asking for it and sort of felt like, all right, you know, we had, I don't know, maybe 30 engineers on the team or something at the time as they are. Maybe it's time to put some structure in place. Um, but what I realized after doing it was that we have actually made it. I hadn't added a lot of clarity to things and because I had tried to keep it simple in the interests of making something that people wouldn't debate and try to like, you know, precisely interpret and sort of check a bunch of boxes so that they could insist that they could get promoted like there's a common with among engineering managers that if you keep things somewhat vague, then people won't try to game the system like I've heard many otherwise, you know, pretty, pretty smart managers say that and what I found was by doing that. In fact, the opposite happened so people would interpret these kind of vague pronouncements of levels of seniority in the way that was most favorable to them and say, like, What are you talking about? Like I guess I'm only I'm only six months out of college, but clearly I'm already issued original. Oh, no, that's not That's not, you're a very great person, you know. So they have a bright career ahead of you. But you're not a senior engineer yet. I definitely had conversations somewhat similar to that in the process. And so, you know, I realized that I wasn't doing myself or my team any favors by being so vague and you know, I'm not the only person who discovered that this was a thing that needed to happen. So, you know, as I said, my husband works at Google. He kind of let me look over his shoulder a little bit more at the technical ladder that I see individual contributor ladder and and that was because I think, you know, I have no idea what they're doing these days at Google, I'm sure they change all the time. But Google famously has promotion committees, and and they had, I think, for a long time had a somewhat big ladder, and people were really frustrated on How do I get promoted? And how do I prove to this committee that I'm doing the work of the next level? And, you know, it's a big company. We're all doing different kinds of things. But I'm an engineer on Android. It's very different than a, you know, engineer working an infrastructure. And so you know, someone there. I think actually a group of people there had done a lot of work to try to add some color and detail, and that was just, you know, helpful. I didn't use like, a ton of what they had done directly, but it was helpful to kind of see some of the language around impact and scope and how it applied at a really big company to give me some more specific ideas, but I didn't want it to be, you know, we didn't want it to be like a generic ladder or something that would be appropriate for, like, a really big company like Google. So, you know, try to keep in mind that look, this is a small start up. Everybody here is working really closely on the product with the product team with other partners around the company. There's very few people I got in there really know people who are just able to only work with engineering, right? So try to make sure that whether it was the individual contributor ladder of the manager management ladder, we were still calling out the fact that this is a collaborative partnership around a product of the company that we're all really helping to build and taking the time to articulate some of that and some of our own core values along the way.

Amy - That's really great. How do you get around that like, how do you get to the right level of detail? Because I think like you say it's very easy to kind of think that the generic, very vague framework will be that the easier one to work with, but it's not. But also it can go the other way is where you end up with the framework that ends up being treated like a checkbox exercise, and everybody's trying to tick off every single thing listed on there. Um, what's the right level of detail?

Camille - I mean, I don't know that I have, like, a perfect answer to that, So I do think so. I do think in general, especially above like, very early career ladder levels where, like you can sometimes it be fairly brief because a lot of what you're expecting, like you're just right out of college. A lot of what you expect people to do in their first year or two. It's just like we just wish to see that you're learning and growing and becoming, you know, an independent engineer, you can kind of briefly say that sometimes, but I think you want more than a sentence or two. Um, yeah, but and you want more than, like a couple of facets that you're looking at, right? So So I think the key things that you absolutely have to be careful about is like, all right, First of all, like How are you? How are you defining the facets that you actually break down? This goes along, right? So, um so let me think so. Rent The Runway. I think I think I copied. Actually, this was one thing I stole from FourSquare's, they have been like, uh, you know, like, role playing game attributes, right? Like, you know, strength and wisdom And, uh uh, you know, intelligence. And what's the What's the other one? I forget anyway, you know, So it had these look sort of different, four different facets and we tried to kind of translate them into important areas of, you know, how do you get things done? What are you getting done? Um you know, how do you communicate and work with others? And I do think that thinking about the facets is pretty important because it can actually be really challenging to keep things not too long if you overlap in one bucket, a lot of different concerns. So to try to be a little more specific. I recently did an exercise in my current company that was uh, that was around redoing our management ladders, and I I was really just an adviser. So actually, one of one of my directs and a group of his peers really went around, they interviewed a lot of the senior management about what they thought the different levels of management should look like umm they did a big exercise to work on it. And we had originally had, I wish I could remember exactly the language we originally had four, for a separation of four things. But that was, like, very bunched up. So it was like there was a section on scope. Um, there was a section on that was just on like people. Um, and the, uh, this is gonna be a terrible anecdote because I cannot remember the actually made that just to make a terrible podcast. Uh, wait pause for a second and see if I can actually remember what precisely we did. But the long story short was that we had we had really, like, over over emphasized in one of those areas. Ah, ah. Lot of stuff kind of wrapped into it. And then there was, like, so what? It was just like on selection and recruitment. It was like we had four aspects. So one of this, like, sort of culture which is sort of shared between engineering, management and and individual contributor, so that's so that's no big deal. But then, somehow the manager ladder had, like almost everything in its scope section, and then we had this weirdly very, very bare like recruitment section was basically like, How would I be thinking about, like, recruiting? and building your team? Now that's important for managers. But the idea that it is one of the four important things that you talk about was not right. It was just like it was just like you can understand why it might have been done that way originally because the company was growing really fast. That probably was really top of mind for everyone writing the ladder then. But now it's like actually, I want to be able to put more detail that separates out kind of this size of team and scope of responsibilities of this manager, um, versus the way that they, uh versus the way that they actually, like, work with their peers and, like lead their projects and sort of the the the execution of how they actually execute things versus the way that they think about the people, not just recruiting, but developing people developing leaders on their teams. You know, dealing with high performance, with low performers, all of that kind of stuff. So by just sort of shifting it to be less, um, less bunched up in one of the four facets. We were actually able to keep the ladder relatively brief, like, you know, a few sentences for each of those sections, but still provide enough information for people to see and distinguish the difference between different levels. So I don't have, like, a hard and fast answer. I've seen a lot of people do a lot of different approaches here, Um, and you know, like friends of mine have worked very hard on, especially for individual contributors. I think this comes up a lot more right. I think, for managers. We all sort of intuitively kind of understand that there is something to team size or team team complexity of scope. That part corresponds to different levels of management. It's not that's not the only thing. It tends to be a big part of it for individual contributors. I think it could be a little bit muddier like, how do you tell that someone's having a bigger impact in their day-to-day. And so I definitely know people who have done different exercises to try to say, Okay, here are some core skills that we expect every individual contributor to have and grow along. And then we have different facets of skills that different kinds of individual contributors might be focused on to try to try to separate out and recognize different skill sets. I've never personally done that, but I've seen people try to do that as a as a way of accounting, for we have foundational skills and expect everyone to have. And then we know that like, Okay, you're like a frontend expert or your expertise is really on the product side versus your expertise is really on the infrastructure side. And so we're gonna have things look a little different across those two. Those two ladders, not just ladders but those two facets, I should say

Amy - So one of the, moving on to sort of other other tools and things that people expect around management is Manager READMEs. So it was your more recent book about 97 Things Every Engineering Manager Should Know and you wrote a piece about Manager READMEs. Um, could you share your thoughts on Manager READMEs?

Camille - Sure. So So I'm not a fan. Uh, and I got into a little bit of, ah, Twitter spat. At some point, I want to say it was like last year, maybe 18 months ago. Time flies, on the topic because I finally just, like, couldn't couldn't, you know, hold it back. And I wrote the Medium post on it that was a bit more inflammatory than what I ended up publishing in the book.  Just let me  tone that down a little bit because, you know, the Medium post was sort of written in a in a very quick you know ah manner. So here's my challenge of Manager READMEs. Um, I'm a manager. READMEs are useful when what they cover is, like, very basic nuts and bolts stuff like this is when I'm available. This is the best way to contact me. Um, you know, these are like some, maybe these are some of the things I'm working on, you know, this is, you know, this is the structure of my day, stuff like that. That's very almost, like fact based stuff that that's useful, right? And I can imagine that if you're in a remote team which we're all figuring out how to do right now as a as we speak probably certainly here in the States. Uh, you know, having that kind of information published somewhere is probably, like, super useful. I find where Manager README really fall down is is when, so there are two things that I don't like about Manager README. The first is that I don't like them as the guide to managing up to me. Um, which is I don't think that's what a lot of people who write them would call them. But that is totally what they're writing, which is basically like, here are my biases. Here is what I hear is what I say that I about myself. Um, so, you know, here are my quirks here, You know, here is what I expect from you to be successful. All that aside, these are all good things to know, maybe even some of these good things to write, but I find it to be a very, very kind of inappropriate way for a person in a position of power to relate to the people that they have power over. And I think that's you know, they're the two foundational things that I find about First of all. Look, I just think that often really ignores the power dynamics between manager and direct reports. Where, like, look, you, you have a lot of power over these folks. And so if you say something in that I have, you know, I believe myself to be very transparent, and I want you to tell me and you know, I love to get feedback. Please give me any feedback that you find, you know, immediately in the moment. That's what I really want. And then you write that you give it to them. They read it, they take it at face value, and then they try to give your feedback. And you react poorly, which look almost everyone does. I do and I try, like I've tried very hard to become a person who's good at taking feedback, but it's terrifying to give your manager feedback. I have the nicest manager in the world right now, and it's terrifying to give him feedback and, like he does not react badly. But it's it's a terrifying thing to do. So when you sort of put that out there for people, and then inevitably someone actually takes you at face value, does the thing you said you wanted and you react poorly. You really undermine your relationship with that person. And I think that the problem that I have is that my I feel like a lot of what people do when they turn it into this, managing up to me, document they because they don't call it that right. They call it a thing to help build trust. But that's not the way you build trust what you built trust by spending time with people you build trust by like working on projects together and going through stuff and talking and just getting to know one another and showing up for one another. So your behavior is what builds trust, not just words that you write in a document, and I worry that a lot of engineering managers are just are looking for an easy out for the work of, you know, building relationships. I just I think that's a really common challenge for people who come from engineering backgrounds where we think look like? If I could just automate it. You know, life would be easier if I could just write a document, a how to deal with me document. Then like everyone will know my inputs and outputs and they'll understand my api and you know it'll be great right? You are not a Turing machine. You know, you're not a predictable, you know you're not a finite state machine with very predictable behavior based on inputs and outputs. Uh, even if you think you are, you're not. Especially if you think you are probably especially not because you're probably not very introspective about that part of yourself. So I think that it's just very easy for these to become a way for managers to, you know, think that they're short cutting building trust, not really short cut that at all, and in fact, possibly erode trust by by not acting true to what they say they wanted to be.

Aaron - Yes, all this is making me think of like I think it's a related point, but just very quickly I want to read a line out of your book, about halfway through there's this is quote that says "the tech industry is filled with people who despise management, thinking it's not as important a job is writing code, but management is a job. It is a necessary and important job"  which I think is really powerful, quote. But the other bit there is like it seems like management is seen as an overhead or bad in the tech scene, particularly in the start up world. Do you think that things like Manager READMEs are fueling that? Or do you think it's something else?

Camille - Um, you know, I actually think, here's what I will say I think management is in a much better place in the tech industry than it. Was when I wrote my book, um, and it's certainly than it was 10 years ago when I really started to get a lot more into management myself. Um, there's still a long way to go, I mean, I do think that things like Manager READMEs yes, they are part of that old school management tech management thing. Like who created the most famous manager READMEs that you will never hear about is a very senior person at Google who is still there who I will not name, but like very famously had a manager README long, long ago. And it was from all accounts of people I know who worked somewhat with this person. Probably not immediately for. But, you know, I was very much like a you know, uh, it was very much had it wasn't quite as touchy feely in the problems that it had, as was what I think some manager READMEs nowadays do. But it was definitely an attempt to to get over the like need to talk to people and get to know her and Google kind of famously from management, I think they've gotten better at this overtime, but like, famously for many years, right, they had managers with 50 or 100 direct reports like they were very much like. Management is not useful, management is overhead. And and I do think that, like this manager README, things do come, I don't know that they come exactly from a tech industry that thinks that management isn't necessary, But I think there's a lot of a lot of first time managers who were engineers have this problem that they still can't really see value in things that aren't writing code and you know, and they just they struggle to really feel feel productive if they spend all their time talking to people on things like that, that just there's a little bit of a struggle getting over that hump of like actually, there is value in having meetings. You know, there is value in in writing documents and not just in writing code. And there value thinking about how we work together in the processes that we work in and so forth and so forth. I do think Manager READMEs tend to be adopted by people who are looking for shortcuts. Um and and that's I think probably, you know, I suppose like, you know, the biggest problem I have with it is, I just think they're bad advice for new managers and the kind of thing that new managers will do. And it will actually slow down their progression to becoming good managers because they think that they've gotten this shortcut that will take a while for them to realize that actually, it's not a shortcut, really probably undermining me on, and that's just sort of lost time when they could have just been trying to do the job and build the relationships and build Trust

Amy - Great point. Yeah. So your book, The Manager's Path really does, like, really resonates with people, sort of just moving into being tech leads. Or maybe they've been managing for a little while, but, like definitely a number of people who are in that sort of level come and sort of wave your book around very excitedly, and I think it is because it's very, very practical advice, But also, I think it is that sort of stuff which maybe doesn't, or didn't used to get shared so widely. Like you need to stop coding like it won't be your whole job. It's a different job. What was your experience of, like moving into kind of tech leading and management for the first time?

Camille - I mean, I think it was lucky. My, you know, my first experienced tech, leading and managing was a small team. And I, and I had a great manager helping me do it. Um, so, you know, I got to got to have my first major speculate experience be on a really interesting project with a team of people that I really liked, Um, that I have been working with for a while and a project I was really passionate about. And I was very deeply involved with from the technical side. And then I also got put in put into the management role of that team, and it was a small team  so I was managing, like four people. So not not a massive management role on, and the person who was managing me is actually, you know, he, uh, he and I still keep in touch. He's someone that I really you know, love and respect a lot. And he's always been on the like, mostly on the technical track. So he's a man, he's been sort of a tech lead manager several times, and actually he may or may not be managing lots of people now, but for the most part, he's always managed to keep himself in these sort of managing relatively small teams from a very technical perspective. But he takes it very seriously, and so you know, I've got I've got the benefit of having someone who certainly took the like work of really taking a complex technical project with multiple people working on it and making that project go well, he really taught me how to take that very seriously. And even though management was not his like passion, he was the kind of person was like, If I'm gonna do this job when I'm doing this job, I'm going to do the best job that I can of it on. So, you know, I think I was lucky to have my very first experiences be under someone who was very, you know, was really diligent about the way he approached these things and willing to teach me. And so I do think I was lucky that I had a mentor. Well, I'm sure that was like a lot of people get pushed into tech lead roles or even, you know, early management roles, and they don't have any kind of mentoring. They have no training, and it's just sort of like go and often they don't have any good role models. You know, I think I was. I was lucky you know, working for a pretty big company that had an established management process practice and it was not perfect. But you could see professionalism in the approaches to various kinds of management tasks, which again, I don't think you necessarily get access to or exposure to when you're at a start up, you have to kind of figure it all out yourself. And so I was lucky to have some of that exposure to good managers to some enough for mature processes for dealing with things and then have the very first person who mentored me through that. He's someone who was very diligent and thoughtful about the way he approached it, even though management was not necessarily his passion.

Aaron - That's the question that you mentioned that you were lucky enough to have a great mentor in your manager. In this, In this experience of transitioning, into, more management people that role, What do you do if you're in a very small company where you don't have that?

Camille - So my advice to people, at small companies is always like you need to build a peer network outside of your company. You can get coaching. I actually had a coach for a really long time when I was a Rent The Runway, so I definitely, uh, didn't try to go it alone, I actually had two coaches for a while. I had a CTO coach and I had a sort of personal coach, a leadership coach, and that was very, you know, I kind of needed both of them for different things. I also had a huge, peer network. So Rent The Runway I wasn't in the very earliest stages of matter. I had done some of it before, but I have never managed at scale that I was managing. I've never been an executive. I'd never been a manager managers. I had to learn a lot very quickly. And I really relied on a peer network of other people in startups who were maybe going through the same thing or had gone through it a little bit before I did. And so who they could provide some advice to me? As well, as those coaches to give me just different kind of pieces of feedback and information. Um, that was really helpful. You know what? I didn't Actually, I didn't end up getting a lot of peer feedback or advice from people at bigger companies. So for whatever reason. And I don't know, You know, looking back, I'm not sure if this is just the network that I had, but you know what? You will learn different things. Being a leader of a startup, then you might learn being in a big company where there's just there's so much established for you that you don't even know. Uh, you're getting, right. Like, you know, all of this stuff that, like, HR teams do at big companies. You have to do, maybe not all of it yourself but a significant part of it yourself, even as kind of a line manager at a start up right at my current company, Right. We have HR business partners. And if my line managers need help with something, Um, sure, they have their manager. They could talk to me, but they also have a great HR partner who is there to help give them advice on how to deal with tricky situations. And, you know, if it, you know, if we're trying to hire someone, we have a whole recruiting team, right? If we you know, if someone needs to take a leave, we have policies established, right, So there's so much that you don't actually learn. Necessarily when you're working at a more established company that you will learn at a startup that I think you know, you do want a pure network of people who are actually going through similar things because it's not super helpful to have someone you like. Well you just ask HR what the policy is because, like, I know you have to do that. So what should I do.

Aaron - How did you actually go about making those connections with those peers outside your company

Camille - I was lucky, uh, one of my best friends. Part of the reason I moved to New York is actually he moved to New York. And I went great. My friend Harry is in New York now. I have, you know, I have a good friend there, and I have an excuse to move there. Um and so he had started. He was basically the sort of engineering leader at Foursquare, Uh, for very long time. So he built that team from the tech side, and he he had, he's a very good networker. So he had gotten done a bunch of work himself to make connections with other VPs of engineering and CTO type folks outside in the New York City tech scene. And when I ended up in that role, he very happily brought me along, so I was like It's just very lucky, Frankly, to have this friend who himself is an amazing networker an, was willing to introduce me to people and I but I've seen other people do this without that person. And what I see is like, for example, one of my friends is named Juan Pablo. And he's been a VP of engineering and CTO of various companies a lot of like remote. But here in New York as well. And one day he just like, e mailed me and was like, Hey, like, would you like to get coffee? Like I'd like to talk about some things. I was like, You know, I don't know. That's God. He sounds nice. I'll give it a shot. And you know, we we have become friends and kind of built out a network ourselves, you know, so just kind of being willing to reach out to people and sure, plenty people are gonna say no, like, you know, if you reach out to really busy executives at startups like they're busy, they may not say yes, but sometimes just being willing to reach out and ask, you never know who's going to say Yes, And people do like especially in smaller startups scenes, right? So in New York, the scene is not tiny by any means, but it's not like San Francisco, where every person you run into on the streets is already in a start up. And so I think leaders in New York tend to want to cultivate their network a lot because we know that you know, the next person we want a hire or next job might come from someone that we know that we met at that party or that we just had coffee with that one time. So, you know, building on a network is a useful skill for anybody in a leadership position, I think kind of no matter what, especially when you're in a smaller a smaller area for start ups or for your industry. Um, I think the other things you can do, going to conferences that are local to your area that are around like engineering leadership and meeting people can be helpful. Like the LeadDev I know runs some great conferences. They've run some here in New York. They run some in London. So if that happens to be kind of in your geographic area. You could meet people there are a lot of people. There's there's trainings that sometimes the different companies will run. And sometimes you know that's an excuse. To get out there and meet people. So I do think that building a network does require usually requires a bit of work on your part. But it's work that will really pay off in the longevity of your career and probably in your happiness and success in the role.

Aaron - It's true, it's very interesting. I'm I'm thinking now about Lara Hogan's Manager Voltron, very familiar with that amazing tool we actually spoke to her about it, has offered on the idea of building up and actually did it with my engineering management group, and we filled it in together separately, but sharing some interesting like aspects of Oh, actually, this this corner's missing for lots of us on one of the questions was like now what? But that point you made about just reach out to people is I mean, yeah, that method. we use that, we use that this podcast and we've spoken to some, like yourself included some incredible people that I never would've dreamed we have got to talk to, you have written these incredible books and just amazing leaders in technology. And people generally just wanna talk, which is a very interesting learning points a

Amy - It feels to me like as well that it's one of those funny things where your network is almost outside of work. But it seems that actually, so many people are getting better at their jobs or getting the support they need to do their jobs from their network. That it feels like it should actually be something that companies are telling these new tech leads, like you also now need to go and build a network and here's your time. And some guidance on how to get started

Camille - Yeah, no, I mean, here, so in between Rent The Runway and my current job. One of the things I did was actually run a run, uh, like, sort of peer learning management class type thing here in New York with my friend Kellen. And, you know, we would run these sessions with 20 to 30 people that I mean, we did various format, but part of the goal of it was actually to help build networks, so, you know, it was very much focused on the New York City Tech scene, very much focused on, you know, managers, so we would actually limit the number of people from the same company who could attend because we wanted first of all, people to feel able to speak freely on not worry about their peer, like, reporting back, but also for people to meet people from other companies. So you know that that was like a really fun thing. It's hard. It's something that I don't really have time to do a full time job. But, you know, we actually had a ton of success just building out these, like peer learning groups where we, you know, we would either do like, you know, meetings once a week for a few weeks running, or the best ones are. Actually when we do like a day and 1/2 intensive were just bring everyone together and, you know, sort of draw on some common topics that we know most managers want to talk about, also some topics from the group's themselves, and have the group's really splitting out and talking to one another, mostly with us giving some moderation and feedback and setting up the kind of structure for the day, but it was just a really fabulous experience. We got really positive feedback from everyone that attended at night. I think definitely, we helped At least some of the attendees create much stronger local networks for their for their careers here, so.

Amy - Wow, sounds amazing. We need one in London if you want to come to London --- the number one way. Uh,  -- so we wrap up every episode of this podcast with three quickfire questions. So number one, what are you reading right now?

Camille - Uh, what am I reading, I'm actually reading. I'm not reading anything. Non fiction. I'm reading a fiction book. I think it's called Spinning Silver, silver is in the name. It's like a sort of fantasy, but it's kind of this, actually, like, kind of interesting. It sort of feels like a like a complex fairy tale. Uh, I'm enjoying it  It's very well, written

Amy - Sounds interesting. Um, And what or who is your number one tip for keeping up with the tech industry?

Camille - Keeping up with the tech industry? Um, my look, my number one tip, especially if you are a manager, is to cultivate a strong network of individual contributors that you know and trust um, and be willing to ask them dumb questions on and you know you could like, I also think like, eh, So I'm not a fan of hacker news, which I think is one way that people do it. I find it to be kind of a toxic place to visit, so I don't tend to tend to use that. But, you know, I do think with the right with the right cultivation, you can find people on Twitter that we're talking about interesting things, but certainly as a manager, it's more than just kind of knowing what's going on that's important. It's like knowing who to ask about what is real and what is I kind of like hype or not really ready and so cultivating a pretty wide network of people who are still actively writing code and could give you some got checks on things. That's certainly very important for me and keeping in touch with the reality of things in the tech industry.

Amy - That's really interesting. And then who inspires you?

Camille - Who inspires me? Um oh, gosh, uh, who inspires me? I'm sure there are plenty of people who inspire me. Um, you know, you know, my friend kind of inspires me. And she's like, You know, she's just, like, hilarious and positive and great at friendships and speaking her mind. And, you know, she's done some interesting things in the industry, and is super insightful. And, you know, I'm always and always inspired by people who I just find to be like, you know, really insightful and willing to willing to say, willing to speak openly, but also like not trying to be, like, hurtful about it, right? Just, you know, sort of want wanting to state their opinions, but also being thoughtful about the impact that what they're saying might have on other people. I just think, you know, is unfortunately not as common as perhaps it could be in tech.

Amy - That's very true. So, Camille, where can people find out more about you?

Camille - Where did you find out more about me? I mean, I have various, like, halfway halfway abandoned websites. http://www.camilletalk.com/ is one of them, but I mean, the easiest way is probably following me on Twitter at @skamille I very occasionally blogged in, like one of three different places. Uh, once I wrote a get a gist on GitHub That somehow still like ever, like, went more viral than I expected. I was like, I don't really want to write this as a serious blogpost. So I'm a little all over the place. But mostly, I think if you're you know, if you're interested in keeping up, you can occasionally check my Twitter, which is definitely a mix of a lot of things. It is not any one thing, um, and I do very occasionally blog. But you know, these days it's it's hard with a full time job and two kids and everything else. So

Amy - yeah, fantastic. Thank you so much, Camille. It's been absolutely amazing talking to you. So lovely to hear, like your experiences of moving into management, your thoughts on like, tools and techniques being used out there. Yeah, thank you so much for taking the time.

Aaron - Thanks

Camille - Thanks for having me

Amy - We'll be linking to all of the websites and doodles in the show notes. But make some time to read Camille’s books, The Manager's Path and 97 Things Every Engineering Manager should Know they're both jam-packed with wisdom to help you be an amazing manager.

I'm Amy Phillips. This is Aaron Randall, and you've been listening to the Humans+Tech podcast.

We're joined by the incredible Patty McCord, former Chief Talent Officer of Netflix, coauthor of the viral Netflix Culture Deck, and author of the book, Powerful: Building a Culture of Freedom and Responsibility, who talks to us on the Humans+Tech Podcast to share her lessons from working at Netflix and in Silicon Valley.

Scroll down to read the full transcript of our chat with Patty.

Patty’s quick fire answers

• Patty is currently reading - The Emerson Collective’s 2019 book
• Patty’s favourite way to keep up with the industry is Twitter.
• Patty is inspired by Laurene Powell Jobs, and also by her gardener.

We also cover

1. Powerful, as the Hitchhiker's Guide to the Netflix Culture Deck [00:00:37]
2. The Netflix Culture Deck [00:00:38]
3. The Perfect Culture, and why it can’t stay that way [00:06:55]
4. Does the Netflix culture only work in Netflix? [00:07:54]
5. Building a culture of candor [00:10:31]
6. Building a culture of fully formed adults [00:11:51]
7. On why challenging, meaningful work is more motivational than perks [00:13:50]
8. How to move away from a Perk-based culture [00:15:39]
9. Do you need to be C-Level to create culture? [00:17:52]
10. Shaking up the field of Management Leadership [00:20:11]
11. Disempowering people [00:20:47]
12. Having an A-Player in every position [00:23:14]
13. Hiring the team you need in the future, and why that might not be via interview panels [00:25:00]
14. Defining success [00:33:02]
15. Hiring managers should always be interviewing [00:35:12]
16. It's not what you know or who you know. It's who knows what you know [00:35:34]
17. On interviewing companies, especially ones without a Netflix Culture Deck [00:38:33]
18. Why staff retention is the wrong thing to measure [00:42:07]
19. Making your company one that people are proud to graduate from [00:44:17]
20. The most important HR Metric to measure [00:46:49]
21. The Emerson Collective [00:50:18]

Find out more, and follow Patty

Find out more about Patty at http://pattymccord.com/

We were discussing Patty's book, Powerful: Building a Culture of Freedom and Responsibility and the Netflix Culture Deck now updated to https://jobs.netflix.com/culture

Full transcript

Amy - Welcome to the Humans+Tech podcast. I'm Amy Phillips and this is Aaron Randall.

Aaron - Hi.

Amy - Today we're incredibly excited to be talking to Patty McCord, co author of the viral Netflix Culture Deck and author of the book Powerful, in which Patty shares her lessons that she's learned from working at Netflix and in Silicon Valley. Patty welcome.

Patty - Oh, thanks. I'm excited to be here.

Amy - So we came across you when we first read your book, which a few years ago now, and we've basically just been re reading it ever since. There's just so much great stuff in that. But for anybody who hasn't read it. Could you give us a brief overview of what it's about?

Patty - Sometimes I refer to my book as the Hitchhiker's Guide to the Netflix Culture Deck. People always wanted to know. Okay, that's really interesting. The things that you aspire to be. So how do we actually do it? So that's why it's very practical and pragmatic.

Aaron - Okay, I love you helped create the Netflix culture deck, which has been shared over 20 million times online. Can you tell us a little bit about what it is on? Why you think it went viral.

Patty - Well, we didn't write it for anyone other than the employees at Netflix. It was actually a document that we created for onboarding and and we wrote it, and I didn't write it and Reed didn't write it. I mean, we both had lots of influence on it, but what we would do was we would take a section and we'd put it in a Powerpoint presentation and we would talk about it with all the other leaders of the company and with every other employee. And literally anybody could edit it or make comments on it or disagree with it or agree with it. So it took about 10 years to write, and every chapter is built on the chapter before. So, for example, we really couldn't implement the ideas of freedom and responsibility until we had a you know, a group of really high performing people who are really interested in the work we were doing and really cared about the jobs that they were doing as well, right? So it's kind of you have to, every piece is kind of a building block to the next piece. So the true story of the virality of the culture deck is that, like I said, we use it as normal onboarding document. Reed Hastings, the CEO of Netflix, and I would get together with about every 10 new employees and sit in the room. Honestly, just talk through it, right? So we're driving to work one day because we carpooled. And he said, I met this woman last night, who's running this company, who started this company called, um, share, Slideshare, and she's sharing Powerpoint presentations online. And I said, god, that's a great idea I wish I had thought of that wonder what people are gonna put out there and he said, I put the deck out this morning. So that that is the absolute true story we did not like say, Hey, world, you should operate your company like we operate ours because we got the best idea. It was literally he thought it was a cool idea to put the presentation online. We had no idea at all that anybody besides, you know, an applicant to the company would care. So I said to him, I'm like, Oh God, why did you do that? That's the worst idea you ever had. I mean, it's the ugliest document known to humankind, right? I mean, graphically it's just really ugly. And and he said, You know, you never told me that, like I didn't want to embarrass you, but in secondly you're going to scare off all our candidates. And he said only the ones we don't want. But what what it did was it changed the way we interviewed, like the next day, because now we weren't talking about did you have all the right acronyms on your resume? Now we're talking about how do you really like to work? And what when are you successful? And what are you passionate about? And, you know, are you able to be honest with people? And it was just It was great. It was super helpful. So it was never intended to be the global viral deck.

Aaron - That's awesome. I mean, one of the things you mentioned there is that this thing took 10 years to write in it. I'm guessing it's kind of like a living document over that time, that just got bigger as you went? And also that it wasn't just you and Reed making this thing. It was others.

Patty - Absolutely.

Aaron - How did you get other people involved in your company building this thing.

Patty - You know, Reed and I had done another company together before Netflix and we were very, very deliberate about creating culture because the company worked at before, we grew through merger and acquisition, and the culture just sort of morphed right. And at the end, you know it was fine, But you just couldn't really define it, and we wanted to be deliberate about it. So, for example, still at Netflix, this still happens because I talked to them. I just saw Reed last week, but probably twice, sometimes three times a year at our executive, or our management  offsites We would spend a day or 1/2 a day or two days talking about the culture, right, And we would start with whatever chapter we had sort of collaboratively written at the executive staff. So whenever we'd come up with something, it was typically we would come up with something, he and I would talk about it. We take it to our executive staff. We'd argue it back and forth because a lot of times other members of the executive team were like, That's the craziest idea I've ever heard. You guys are nuts. I don't think this will work. And then we would take it to the rest of the team. You know, oftentimes groups of 50 100 people and then say what do you think about this? Would you modify it? How would you say this differently? Do we believe that to be true? And a lot of times we go back to the very beginning, which is the descriptors of the behaviors that we like, write that we expect from each other. And we would say, for example, go around the table and name one person in your organization that's demonstrated that last week, right? Or has not and what had happened. And we found that if we couldn't come up with an example like really quick, it either was aspirational and wasn't really true or we had to root out some bad behaviors in the organization. So that very first chapter, which is the behaviors that we we rewrote that six times. So, yes, it was very much a living document, a collaborative document, and part of the the impact of that was that everybody in the company believed that they had a part in it because they did right So that's, you know, if you look at the latest iteration, which Reed updated, I think a couple of years ago, there's a lot of talk in there about global diversity and inclusion because you know the company's international now, and it's a different. There's a lot of different challenges, and the company includes a lot of creatives that are, you know, making filmed entertainment, which is really different when I was there and it was a tech company. So you know, it is constant and and I think that's a message for your listeners. You know, a lot of times, CEOs are people early in, companies say we love our culture. It's perfect. How do we keep it? And the answer is, You don't You can't possibly do that right. Your culture is going to change. If it stays the same, you're not going anywhere right? The reason why culture changes is that you're successful, and so when you're successful and you're a different size organization or a different level of complexity then you're gonna operate differently with each other, that's that's healthy and good. So it's more about just that constant paying attention, attention. So the living thing that is your organizational culture?

Amy - And there's a lot of pieces, which I think. I mean, it's interesting you talk about the culture evolving because I think there are a lot of places you talk about in the book about which, outside of Netflix we think of as the  Netflix culture. So lots of kind of in the transparency and kind of those sorts of behaviors. Do you think those are the sort of things like that style of culture can only work in certain companies? Or are there things that could be applied to every company?

Patty - I think it can be applied to every company. It's takes practice, right? So that idea of openness and challenging each other and healthy debate. That's something that doesn't come natural to most humans. Because we're sort of taught to be polite and to debate in writing, right. It's like I it's interesting. I I talked to a lot of companies and they're like, Well, you know, we're really uncomfortable with this debate and then I read their Slack you know, incredibly like rough ride. So it's that you don't really practice doing it in person and doing it with respect, and so some of it is skills based. So it's much more difficult when I when I come into consult to a very large company and a very old company, because their ways of doing things are so baked, um, and that they can't It's much, much harder to undo it then to start doing it. So even then, when I come to a large company and they say, well, we want to change our entire culture because we need to be faster and more innovative and you know I'm like and you we don't know how to do it because we're stuck in our ways and I'm like, Okay, you know, if you're 100 years old, trust me, you know you're not riding horses anymore, either. You can learn new skills, but it's gonna take some time, so I think everybody can do it. I think it's just a matter of again paying attention to it and making it a priority. And here's I mean, it's like here's a very practical tip. Ah, you know, you're in a meeting and, um, there are people that are in that meeting every week, and they never say anything in the meeting, but they have lots to say after and before, right? You know those people? We all have them in all of our companies, right? And so, of a really practical tip is too in the meeting. Say, Hey, Aaron, we haven't heard from you. And we all know you have an opinion about this. How about if you let us know what's on your mind? Right? And so and I'm not calling you out to embarrass you. I'm calling you out because I need to know what's on your mind. It's not very helpful for you to tell me when the meeting's over, when we're here to discuss something that you clearly care about. And if you don't want to participate, then maybe you shouldn't come. Right?

Aaron - That point you made about  speaking up in a meeting, it really reminds me of another sort of theme in your book about people coming to you and giving you feedback about someone else. They're a complete pain. They're not doing this and that. And you say to them "What did they say when you told them?"

Patty - Yeah, right.

Aaron - They say, Well I haven't told them. Well I just love that.

Patty - The follow up is really important, which is well, I don't know how to tell them, and I say, but you just told me. I can't say that I'm like, No, I think you just said that. However, there may be a better way to tell her that. Then how you just told me. But what you just told me is really important. And people can't act on it if they don't know. You know, there's another part of my I don't know if I wrote this in my book, but I tell people, you know, when they get promoted, I'm like, congratulations. You have two things that you never had before. One. You have a business card with a new title printed on it. And to now you're psychic because you know how people are like well, he ought to know he's my manager, you didn't know 5 minutes before. But now all of a sudden you're supposed to know. Right.

Aaron - Amazing. I think back to that. What did they say when you spoke to them? And speaking up in meetings, I feel like there's, and one of my favorite bits of the book, is this running theme around building a culture of fully formed adults? Can you tell us what you mean by that?

Patty - I mean, work is something we only get to do really when we're grown up right and it's not school and it's not family. It's about creating something with other people. It's a really unique thing that we get to do when we grow up. And so I think if we just start with the premise that we're adults coming together to create something valuable, I mean, I know it sounds so simple, but you cannot believe how many people I talked to who can wax eloquently about, you know, participation and belonging. And I'm like, yeah, but you know, it's work. So, well like that. I want all of those things to matter, too. But it's the only thing you get to do with other grown ups where you can accomplish something. And it's just been my observation of people at work over all these many years is that literally everyone wants to go home at night proud of what they did right, and it's almost never that you can do it alone, right? It's almost always with other people, and so that ability to operate, you know, as an adult, it's the it's the only thing you have to be right, and so we have created these systems in our organizations that treat people like children. You know, you have to ask permission and you have to follow the policy and you have to get, you know, your manager's approval and all that kind of stuff. And then we complain that they act like children, right? It's like people respond to how you treat them. I mean I often say, You know, if you expect mediocrity, that's exactly what you'll get. And if you expect excellence, you'll be surprised what you get even from mediocre people, because everybody everybody wants you know that next rung. Everybody wants to go home and go and and here's another one. So when I left Netflix, it was out here in Silicon Valley. It was the time of the bartenders on duty and, you know, swings and hammocks. And it was beyond the pale of all the perks in every single company. And I remember talking to a group of HR people at one particular company, and this one person's job title was literally, you know, employee happiness specialist or something like that. I was like, Seriously, that is not a job, you know. And so I said, to her. Here's it. Here's your assignment. Go find five people in the organization that are incredibly successful. Regardless of title, everybody knows who it is that gets lots of stuff done right and who everybody kind of admires and asked them to tell you the story of the day they did something that mattered right, something that they were proud of. And I said, every single story I promise you will be about something hard. All right. It'll be it'll be when you're like God we didn't think we could do it on time, but we did. I mean, we all pulled together and we did it or like, thank god We had, you know, Susan on our team because she's so smart and none of the rest of us understood. You know, we couldn't see this thing underneath. And and people get all passionate and excited about those things, describing those really difficult things. It's very, very infrequent that someone goes, yeah, there were macadamia nuts in the cookies. That was a great day. We had extra beer. It was fun we got you know, I mean, that's what work is about. So it's a really wonderful opportunity that we have as adults.

Aaron - Very eloquent.

Amy - So that sounds like quite a difficult culture shift. So how do you actually go about like, at Netflix, what did you what did you do to actually wean people off all of the perks and actually get them focused back on the work and the things that really will give them that satisfaction?

Patty - Well, actually, at Netflix, we were pretty lucky at the beginning because we were poor. Um, so because our early business in the US was DVDs by mail, it was very, very capital intensive, so we couldn't do all of those perks because we had to buy DVDs and stamps and envelopes. I mean, I remember one of these things we said, you know, at our office in San Francisco, we all had Aeron chairs, and I'm like, yeah, those suckers cost $800. Do you know how many DVDs we could buy? I everything because it was the cost of the DVD at the time. So that really honestly was the big factor in our success with the culture was that we didn't have a lot of excess money to throw around, right? This is in the days before unicorns, and you've got, you know, $1,000,000,000 investments and stuff like that. So there was that. And the second thing was, you know, like I told you, we paid attention to it and we really took an oath as a leadership team. To, walk the talk, right. And we were very and we practice early on that honesty with each other where I could say, you know, to the CFO, you know, I don't think you really told the whole truth and nothing but the truth in that meeting you had with your stuff, right? Didn't you leave out the part about right? So it was a matter of people can't be what they can't see. So if you're part of the leadership team in the company and it makes you happy to write down a bunch of stuff, but it makes you uncomfortable to actually do it, then don't bother writing it. You know, the cynicism in organization is much more pronounced when the leaders take all this time to write some beautiful treatise and document or whatever it is, and then they don't do it. They don't act that way because people can see that. So that's that the most important thing you can do is pick a couple of things that you promise you're gonna be and be them.

Amy - So does that mean that in order to create the sort of these amazing cultures, do you have to be the sort of C level like. Does it have to come from the top first or are the things that everyone

Patty - No, no, but but the top has to be listening, right? So if if you don't ever listen, in fcat here's a great story. Um, this is way back when we were shipping DVDs, right? And we were having a celebration in our parking lot. We were that small and we were celebrating. I don't know that we had shipped a 1,000,000 DVDs out of our warehouse. You know, everybody’s. Yeah, clapping it was big, big deal. And somebody in the audience said, Look, don't get me wrong. That was an incredible accomplishment. Yea, for everybody in operations for doing that. But the truth is, it doesn't really matter how many left our warehouse. It matters how many people received in their mailboxes. It was so that incredible intense focus on our customer meant that, and I don't remember who this person was, it certainly wasn't a C level executive. But it was like we all went, Oh my God, you're so right. We're measuring the wrong thing right. We have to start with the customer and work backwards to what we're doing, not pat ourselves on the back for how good we're doing inside of the organization. And so that obsessive customer focus is everybody's business, right? So that doesn't have to come, you know, cultural stuff. What I'm saying is, if you say something and you don't do it, that creates cynicism, and you should be responsible for that. But great executives, half of their job is to listen. Right to have their ear to the ground, to hear the great ideas that come up. And that's the other part about when somebody has a great idea and everybody runs with it because it's obviously a great idea. Now you're demonstrating participation in the culture, right, because you want people that play right. You don't want anybody in the room that just works and doesn't pay attention. That's the the idea of innovation. People think it's creating, ah, you know, self driving vehicle that don't get me wrong, that's wonderful, but you can innovate in finance, right? That's my whole book is about innovation in my field, which is a field that's worked kind of this, you know, management leadership. We've come and done it the same way since the sixties, so I'm ready to, like, throw that out. You know what? What? What's say every 50 60 years We shake it up a little bit. What do you think?

Aaron - You mentioned there the idea of anyone could help, I guess, influence this culture and the importance is that execs and C level are listening to what people say on, I guess from the other side for the execs and the C levels. How can people know when they, when they're disempowering people or the teams?

Patty - Oh, it is. Some of it is just basic active listening, you know, instead of responding with an answer, repeating back what the person had to say, right. Here's another phrase that I'll give you, you're welcome to use, which is when so a) assume everybody you work with is smart and adult. I know that's a hard concept for some people, but let's just put that on the table. And when a smart adult says something that you either think is crazy or you don't agree with right, instead of immediately jumping to debating whether or not they're right, just try asking them. What leads you to believe that's true, right? Help me understand where you're coming from, and you may find out information that you didn't even know. Because if the person appears to be clueless assume that they just might be. They don't know, right? So I've often found that when I said that, you know, help me understand where you're coming from. I realize oh, my God. There's a whole volume of information you don't know, right? And so then you start when you demonstrate that then you know that people are gonna know that you're gonna ask them that, right? So you well, I heard that everybody in marketing is doing this thing that I think is incredibly dumb. And I can say, Oh, well, what leads you to believe that's true? Well, I don't know. I just heard right. Well, that's that's not very factual. So I can say, here's a couple of people in marketing I'd like you to talk to about what led them to that decision and send them off to figure it out. Right? So it's just this constant, um, pushing people to get more information that they have to be curious about. What other people are doing to understand the organization as a whole and not just what they're doing with it, what their particular team's doing with their particular departments doing, but realize that nobody does it alone and everybody matters.

Amy - Huh. Uh, that's so great, isn't it? It's like I think it's it sounds so obvious, but I don't know why, but you just don't think to just especially in Tech. We're really bad at doing it.

Patty - I did this talk with a group of, um, Young CEOs Tech CEOs and one of the guys it was in Miami. It was like a dinner. So I was very intimate, like 12 of us. And one of them said to me, Well, you know, I hear you say that you we should have an A-Player in every position, But you don't really mean that, do you? And I said, What. I mean, I usually don't say things I don't mean so, like, yes, I do mean that. And he said, Yeah, like you know you don't mean like every position. And I said name a position in your organization that you don't think you need an A-Player in. And he said, Oh, you know, like payroll. And I said, really, you don't thing being in charge of paying the other smart people to be smart enough to do it right. And he goes, Well, that's not what I said. I said yes,  it is and oh, by the way, just so you know, your finance are going to open, they hate you. And he said, You don't know anybody in my finance organization. I said, You just told me a perfect stranger, that you're okay with certain people in certain jobs being stupid. You think they don't know you think Oh, of course they know. By the way, you know, Then at a certain point, they're just gonna prove you right? But so I mean it at the respecting everybody on the team and every single job. And if you've got a job that you really don't respect that you don't, maybe shouldn't even have it.

Amy - Yeah, yeah. You have a lot in the book around hiring teams and building teams or certainly I I've read that section probably the most number of times. One thing I'm really, really fascinated by is, you're talking a lot about building the team you need for the future. So actually thinks taking the time to think about six months or further down the line, what skills and sort of experiences you'll need. You had some really great examples of hiring people who come from really different backgrounds or who maybe initially didn't you know, wow, you in the interview. But then you thought, Yes, What I'm really curious about is the, so hiring these days tends to have a lot of hiring panels, lots of different people involved, which could be ready good. But I think it can also make it really hard to try and hire someone that isn't just the normal culture fit. How do you overcome  that sort of, almost the bias for the same,

Patty - You have to start with the job that needs to get done in the future and what success looks like. You have to think about it a lot harder than we need five more engineers with, you know, Ruby on rails experience or something like that, right? It's that idea that if we just hire more people we'll get more done, which is, you know, your early stage solution. Like, we need five more engineers and six more marketing people and two sales guys. And we're golden, right? And then you know what you hire you know five more of the same people. And then you wonder why you can't get anything done right. The reason you can't get anything done is usually not volume. It's usually skills. So it's doing the hard work up front that says, You know, you've seen this in my book. I have a very distinct methodology that I've learned, I was a recruiter. So I mean, you know, and I was an internal recruiter so I could learn over time who was successful and who wasn't. And so the match wasn't about, you know, finding all the keyword matches on the resume. The match was about finding somebody who's really good at and really capable of solving the problem. But at first, the hard part is defining the problem. So it's looking six months out and saying in order to succeed, what does that look like? What? How do we measure it? How does it you know, if I walk around and see people doing things differently. What is what? What are they doing differently? Right? And really think about it. Are there more meetings? Are there less meetings? Is there somebody at the meeting who has the answer there? Or is it that stuff is just get being done in the background? Really? Really Think about that and then work backwards and say, wow, in order for that to get done next year next year. Time is very, very important because, especially in early stage companies, you tend to use words like someday. And I think someday means, you know, next Thursday. And you think someday means next year. So we have to be really clear, right? So I'm so in order to get that done by the you know, by the by summer, um, what would people need to know how to do? And then you can say, Well, they need to be able to operate at scale. That's 10 times bigger than what we are. For example, that's a typical early stage company problem, which is Oh, shit. We figured it out. Now we've got to do it at scale, right? Okay. So next year, 10 times more than what we're doing next year. Okay? Now you drop down and go. Wow. Okay. What? Would someone need to know how to do. What skills and experience would it take for them to do it? Well, they'd probably have to have already seen 10 times growth. Right then you say. Now, who do you have? And you realize everybody on the current team has only worked there, so they haven't seen 10 times. They haven't seen two times, right? And it's not that they're, not smart people. It's just that they don't have the skills and experience to be able to do what you need to do in the summer of this year, right? Because they won't, they're gonna have that experience someday, But they won't have it in six months. So that tells you who to hire right. So now you're looking at somebody to help you solve that problem that's unique to your organization. That's about scale with the rest of this team, by the end, right, But in a six month period of time and that's who you go look for the person to solve the problem. And it is not someone just like who you already have. Because if you already have the right person, that problem would be solved. Raises that thing, you know, then you really want to build your interview team around finding the answer to that question. And it may not be that you have panel interviews and everybody on the team interview this person to give their input. Since half of the people on the team don't know what to ask, because if they did, they'd already be asking it. So it may be that that conversation is with candidates who you sit down and say, Here's our situation. What would you do, right? And and by that kind of interviewing? Not only are you learning about that particular candidate, you get all kinds of good ideas and, you know, and I've found that when I do that, sometimes I'll be interviewing somebody I'd be like, you know, we never thought of that. Oh, wow. All right. I mean, we've never looked at it that way, huh? I might be really bad. Well, to look at it. I’m serious. I mean, I would say to people like, just bring him in and suck their brains. I mean, you know, this person is really let's find out what they know. And so then and, oh, by the way, those are, the really fun interviews to have for you and for the candidate. Now you're not finding out if they're good enough, you're finding out if they're interested and capable of solving the problem that you have to solve in the time frame, you have to solve it, right? So it's more fun for everybody and you're more like and then you're more likely to take a chance on somebody who's not like you because they're gonna approach the problem differently. And then and then the other thing is, sometimes when I prepare people for interviews, I say, Let's before we go look for somebody like you. Um, let's talk about who's been really successful that we've hired this year. What is it that lives that they brought to the table? That was especially valuable and you'll start to see that things have evolved and changed right? Well, remember the guy that we hired that like we were worried because he was meek as a mouse and never said a word. Now, when he opens his mouth, we all hold our breath because he doesn't say much, but what he says is really important. And so that a person that I talked about in the book, but it really leads you to be open to lots of different, you know, where was I last week? We were talking about I somebody was bemoaning they were in the Midwest and in the US And they were bemoaning that they didn't have enough great tech candidates. And they happen to be in a place that had a lot of financial institutions, insurance companies, you know, big firms there. I'm like, Are you kidding? You mean you haven't gone to the banks? You think they don't know math you know, you think they're not programming there? Are you crazy? Have you? Have you tried the government, right? You want to find someone whos just trapped in that horrible job with their brilliant mind, you know? So that's it. It's not just people that look different than you. It's people that really approach the problems very differently than you we hired in the early days. In fact, there's a couple of very, very successful executives there at Netflix that I hired out of, Um you know, a government lab that made missile systems or something. But the complex math that they used was unbelievable and the discipline that they had right? So they were like, crazy, different than the classic Silicon Valley hacky engineer types. Um, but they were really the people that really helped us scale because they worked on projects. So

Aaron - I think. One of questions for me. It's someone that has to trying inform who those roles are. We're hiring for you talked about for six months. Time less on the hiring, more on the strategy bit. But how do you actually know what you will need in six months time?

Patty - You have to define success, right? I mean, you have to be able to say, What if it was wildly amazing. I mean, you know, I'm whatever it is for your organization is it that you would triple your listenership, right? Or you would have five times the volume of content to play? Is that you know, I don't don't know your business exactly, But you know what it looks like. I mean, you have the fan take the fantasy all the way. I mean the story I used in Netflix was that, you know, we've grown 30% quarter over quarter, 3/4 in a row. Compound it. And so when we extrapolated that out into the future, it was shocking. Like Oh, my God, We could be at the time, the storytelling. The book is you know, we could be our CFO was looking at revenue growth, and he was just like, happy Slappy guy, right? Three times the revenue quarter over quarter, 30% compounded like, are you kidding? And then Ted Sarandos who's our head of content. At the time, we would say, Oh, someday we'll be as big as HBO. Someday. He looks at the revenue numbers and he goes, You guys, we could be HBO next year and we're like, What? What? And then our head of product said, Oh my God, you guys, this is 1/3 of the US Internet bandwidth and we just sat back and went ugh. Do you even do that? We couldn't think really big, right? Sometimes it's about not worrying about what could go wrong, but fantasizing what could go right. And then you realize, Oh my God, the people that know how to do that there's no one here who knows how to do that right. So we better at least start talking to people. Wrap our arms around it. So the here's another thing for you as a hiring manager, you should be interviewing all the time all the time, like 2-3 times a week. I'm serious and you know it can be that you have lunch with somebody or you meet somebody so that on the flip side, when I'm coaching people about their own careers, I tell them, Look, it's not what you know or who you know. It's who knows what you know, the okay, one more time. Not what you know who you know. But who knows what you know. Right so that you want to go out and meet with people all the time so that somebody can say, Hey, you can say, Hey, Aaron, remember that person you told me about that you talked to last month? I wonder if she might be the right.. can we bring her back in and talk to her, right? And that's and and you know, in the in the example of scale, right, it's perfectly reasonable for you to reach out like you reached out to me and say wow you're somebody who's done stuff at scale, can I pick your brain a little bit about how you got there? And people love talking about themselves. You got a little bit about what that person knows. That person knows you, right? So now you have that connection that human connection where you can call me like Patty. I'm stuck. Do you have five minutes, O r? Do you know anybody, right? So now you just start to develop those real networks, not just social media, but the real networks of knowing people that you can call up and go. I bet you know somebody. Yeah this morning, I did an email exchange with a guy who ran operations for us forever. And he was a guy, he was the CTO of a very large tech company I worked at. And when I went to Netflix we were tiny, tiny, tiny, tiny. And he called me up and he said, Hey, I understand you're looking for somebody to run operations. I said, Oh, God. Tell him I didn't even think about you. Of course you'll know somebody who has You have a right to use the questions I ask my and that he says Yeah, I thought of somebody I think would be really good for it. Like Let's go, baby, Who is it? And he said me, Are you Are you crazy? Don't you run an organization of like, 500 people? Don't you make like, $750,000 a year? You really sure. You want to come up? I mean, seriously, we got a warehouse like with things that the glue get stuck in. Why would you want to do this? And he said, I'm I'm a I'm a customer. That was we had no customers and he's like, I'm really interested in the technology. It's a passion of mine. I'd love to just come and meet you guys. And so he ran operations for us for like, eight years and course did very well, giving up things big salary. But he approached the situation as if we would be successful, right? He came into it and said, You know, when we're shipping a 1,000,000 DVDs a day, we should be thinking about what the system's gonna look like that

Patty - Awesome, so i've done a lot of talking about hiring hiring managers and how you get good people in the organization. But let's flip it around and think about the people that're  interviewing companies, you know, when at the start of this conversation we spoke about the Netflix Culture Deck as kind of up there as a prime example about how you determine what a company cares about, what their values are for those companies that don't have a culture deck like Netflixes. What kind of questions can you ask as an interviewee to understand the company's culture?

Patty - You want to ask how decisions get made? You wanna take a look at the sort of organizational structure you want to pay a lot of attention to the environment, right? So, hey, look, use your eyes. Use your ears. Use all your senses. Right, Um, are the women only sitting at desks in front of important people or reception? Or, you know, do you see them sprinkled around the technical team? You want to pay attention with all of your senses? You want to take a look at who's doing what, how people are talking to each other, what their body language is. I mean, there's a whole lot you can tell by waiting for somebody to pick you up. You want to pay attention to? Are they on time? Are they prepared? Do they know what they're talking about? Did you have the same interview six times, right? Did everybody take your resume and go? Let's start from the beginning. And by the time you've done that, eight times you realize they don't care who you are, right? They have. They have a mother to prepare to say you're going to talk about culture. You're gonna talk about technology you're gonna talk about. You know how this person likes to operate so again, Like I said, and And by the way, the other thing is I used to say to my recruiting staff, We want every single person that comes in here to want the job, even if we hate them, right, Because we want them to go back and say, Man, my interview and Netflix was great. It was hard, and I don't think I'm gonna get the job, but, you know, you might apply, right? So So it's just to to be curious of. The other thing is, you should be very very you know, these days you don't go into any company without finding something about them. So read all the stuff, you know, read Glassdoor, read their quarterly, whatever. They have its public read their who find out who you're interviewing with and look up, look up their profiles and find them on social media. I mean, go in really prepared and go in with as many questions as they're going to ask you. So if I was successful in this job, what would that look like? Right, so you're really finding out. Like I said, we're just reversing your reverse engineering what I told you about earlier, which is in six months, if I'm a star, what what's that gonna look like? And then so that I can walk out and think That's not the job I thought it was, you know, And I don't I don't know if I really want to do this for six months or a man. I could just kill this right and said, Oh, that's what you're looking for on the other end, because these are the people you're gonna go work with. So, for example, when I talk to women's groups, I say to them, Look, when your company talks about engagement they didn't put a ring on it, right? You're not married to your company and you should be interviewing all the time. And it's not cheating on your spouse. It's just finding out what you're worth and what's out there. People's careers are never and they haven't been in the last 20/30 years what we think they are that you're gonna join a firm and work for it for the rest of your life. It's just not true. Not true at all. I just had a good talk with a group of a 1000 CEOs and I said, Raise your hand if you're in the position that you had when you graduated from university you know how many hands with zero. Raise your hand If you think measuring retention is important in your company, 999 hands went up. I'm like, Seriously, you know, why are we telling this lie? So what you want to do is you know, a lot of people come in to interview and they want to ask, you know, what's my career gonna look like? What's my career progression? How long is it gonna take for me to be promoted? The answer is whoever tells you a distinctly clear answer to that doesn't know what they're talking about because you know what's gonna happen in five years. So you want to know how you're going to be successful in six months to a year, and then you want to know what else is important that's gonna happen around here, right? And and And you have to be really, really self aware. This is the thing. I wish I could teach everybody early in their career. And I'm not talking millennial, right, because I don't this age there's there's early in your career. There's a little more experience that I know a lot of really mature 20 somethings, and I know a lot of really immature 40 so it didn't have anything to do with age. But you wanna learn early to be self aware enough to know that you get hired to do something, and eventually you did it right. And so when you're done, you know that. So if you sit there passively waiting for management to find a better role for you, so that you can further your career and it's completely up to them, you could be waiting a really long time, right? That's when you want to go huh. That was fun. I accomplished that. What else? What do I want to do next? And is that available to me here? And if it's not available to you here, then go find it. No harm, no foul. All right, own it, Own your career.

Amy - So that ties in really nicely, I think with this idea that you have in the book about wanting to make a company that people are proud to graduate from, I love the idea like that. People, if people are proud to move on you'll be able to hire, but also people will move on, which is a healthy thing. Is it something you share internally? Like do you make that a kind of public part of their company culture? Or is it just something that you you're quietly trying to build up so that people you can have people moving out of the company happily?

Patty - It took time.  Yes, the answer, the correct answer to your question is, yes, but it took time and it took a lot of reflection of, um like Well, you know, I guess they kind of have to go because that's an opportunity we can't give them. And we don't want the person to be stifled because they're staying here. God knows we don't want a smart person to, like fail because they hung out with us on the other hand, and then the other part is, um, you have to stay in touch with your alumni and find out and talk about like Oh my God, did you hear that? So and so I went to Google and now they're running this that's that's really cool. A great example was, Ah, an early guy in our content organization. He's like the number two guy left us and went to YouTube, and now he's like running content for YouTube. He's been there probably 10 years, and is super super successful, and it was a great opportunity for him. I'm really proud of what he's done. The other thing that's happened in Netflix since I've been gone is quite a few people have left and come back and they're and they're much, much better, employees, you know, Reed tells me. It's like, Oh my God, the experience that they got it out of the company like you know, they left before we were international. And then they worked with all these people in India and China, and they came back and brought to us the gift of their new experience. So, you know, you really want people with a lot of varied experience, and and yes, I think we can talk about that. I think we should talk about that with people. That's like, Okay, so what are we gonna What are you gonna do here? That you're gonna be so proud? And I And when I coach managers, I'm like your job. Your only job is a manager is to create amazing teams that build incredible stuff on time with quality that is resume CV worthy. Right. So you want having been on this team be something that somebody's gonna put on their CV and go? Oh, yeah. Let me tell you about that. We really we really did something amazing.

Aaron - Yeah, that's also what a metric I wish you could measure it.

Patty - Well, but you can, But you can right you can, that's what I talk to HR people and they asked me what are the important human resources metrics? I'm like they're in the P&l. You already have the metrics that you need. Did you get stuff done when you said you're going to get it done and does it work? It's really not that hard. And you can measure that in every single part of the company. Right? Did you close the books on time? Did you hire the people that you thought you were gonna hire? Did they? Were they successful? Do customers love the product? does it work? You know, did that did that software update that you talked about last year ever get done, right? And so, you know, I learned all this, you guys were geeks so you understand this. I learned a ton of this from the engineers I worked with, you know, you know, in software, you know, you pause pretty regularly and do a postmortem, which is something I say. That was a funny term. It's like why we didn't let the patients. But anyway, you, you stop and you look back at what you've built and say. Did it work the way we thought it was going to? Did we get it done on time? If we did it again? What will we do differently next time? so it would be more successful. You can do that with any part of the organization, and you should just you have to set aside the time to say today instead of looking, you know, my look forward thing. We're going to reflect on what we just accomplish and say, you know, we're really proud of it. But could it have been better? And what did we learn, right? My mom says about Texas. Mama says the difference between a wise man and a fool is the wise man doesn't make the same mistake. You could make lots of new mistakes but make sure their new ones. The other fun fact about because I was at Netflix for so long I was there long enough to have the ideas that we bring somebody new in and they'd say, Hey, I've been thinking about it. I think we should do this. And we'd say, No, no, no, no. We tried that. We've tested that and it didn't work. Customers hate it. Does you? No, no, no, no, no, no. We tried. It didn't work. And they would say, Well, that was five years ago. And by the way, you know the customer then was an early adopter software engineer. And now it's your mother. So, like, Oh, wow, maybe we should go digging through all those bad ideas. Resurface them again. I mean, as you know, we knew back in those days that people would binge watch, for example, because of the way they watch DVDs. Right? If you if you wanted to watch a series, you would just keep putting the DVD in over and over again until you finished it. So back in those days, we didn't know that streaming was coming. But we knew that when you would,

Aaron - um, Patty, I think we could probably talk another hour easily and send questions your way. But got to be conscious of time we don't want to steal all your time today. But I did want to rap, we have three quick questions we like to ask all our guests. So just three quick questions?

Patty - Yep.

Aaron - Our first  one of you is what you reading right now?

Patty - I was just reading. Ah, well, I work for one of my clients is Laurene Powell Jobs, Steve Jobs' widow and she runs a thing called the Emerson Collective, which is a group of all the charities and businesses that she invests in. And so I was just looking at this. Is their? Ah, their book from last year of all the different investments they made, the accomplishments that they did in education and environment stuff. So that happens to be what's on my desk right now. So that's my current reading.

Aaron - Awesome. And what's your number one tip for keeping up with the industry?

Patty - You know, before I wrote the book, I was not a Twitter fan because I thought, this is just a ridiculous waste of time. And but, you know, I had my social media coach. Who would she'd say to me, You know, Patty, you haven't tweeted recently, and I would say to her, Look, if you're gonna be my coach, you've got to be a lot rougher than this. You gotta be Oh, I want five minutes today, four retweets and follow five more people before and give me that. Right. So But I've become really interested in finding out information through Twitter, right? I mean, so I get, like, something that piques my interest. And then I go deeper and like talking to people like you. Then I'll follow you and you'll follow me. And then we just It's been a really great way of discovering information.

Aaron - Well, it's nice to hear a positive twitter story.

Patty - Yeah. The other thing I'll say is that in my time since Netflix, I have learned a ton from sports coaches. I think there's huge value in talking to people who coach athletes to high performance to winning right, they're very disciplined about it. It's a great metaphor. I I did a talk where the coach of a famous basketball team was on and on stage, and someone in the audience is oh, doesn't it just break your heart at the end of the season. You know when you have to let these people go. When they played their hearts out, he goes, No, it's professional basketball like they get to have played for the San Antonio Spurs. I think it's gonna work out for them, right? You don't play professional basketball when you're 60 years old. I think we all know that right? And I'm thinking, how come they can say it? How come that seems like a perfectly reasonable answer, But for me to say to you, you know I'm seeing you here for a couple of years, then we'll figure it out is not a perfectly reasonable thing to say to you.

Aaron - It's true. Last question. Who inspires you?

Patty - Oh, well, because I have Laurene on my mind. She does. Laurene Powell Jobs inspires me with the work that she's doing, dedicating her life to making the world better. But, you know, I mean, I get inspired all the time by my my gardener. You know, that carries this wealth of information in his head, and he's got a family of four to support and just has this really positive, wonderful outlook. And I love having him being my business partner these days in my yard. right, so it's, I think, you know, I'm in a different chapter of my life now. That is not going to work every day like I have for the vast majority of my life. So I see inspiration all over.

Amy - So where can people find out more about you, Patty?

Patty - The easiest way is my website, which is PattyMcCord.com. All one word. And there you'll see the links to the book and to the talks that I'm doing and podcasts like this will show up there. And so there's lots of ways to find me.

Aaron - Awesome. It's been an absolute pleasure, Patty. As I say we could talk for hours. Thank you so much for taking the time today. Really appreciate it.

Patty - You're very welcome. I better take the dog out. Nice to meet you.

Aaron - We are massive fans of this book, So if you haven't had a chance to read it yet, go and grab yourself a copy. It's called Powerful by Patty McCord. I'm Aaron Randall. This is Amy Phillips, and you've been listening to the Humans+Tech podcast.

In this episode of the Humans+Tech podcast we spoke to the mighty Lara Hogan about her latest book, Resilient Management. Lara, previously VP of Engineering at Kickstarter, Engineering Director at Etsy, more recently founded Wherewithall, where she coaches managers and leaders across the tech industry.

Scroll down to read the full transcript of our chat with Lara.

Lara’s quick fire answers

• Lara is currently reading - The Art of Gathering.
• Lara’s number 1 tip for keeping up with the industry is Twitter.
• Lara is inspired by Paloma Medina.

We also cover

1. An intro to Lara’s new book, Resilient Management [01:02]
2. How Lara got into management [03:36]
3. How to get feedback from your team [06:04]
4. The advice Lara wishes she’d had when she started managing [07:16]
5. Manager READMEs and the manager one-liner [09:34]
6. Introducing yourself to your team [15:35]
7. Building your manager elevator pitch [19:26]
8. Introducing the BICEPS acronym to help us remember the six core needs that humans have at work [19:55]
9. Manager Voltrons [27:01]
10. Dealing with times of crisis [33:48]
11. The caterpillar cocoon metaphor [36:50]
12. Donuts. And sushi [39:32]

Find out more, and follow Lara

You can find Lara on Instagram and Twitter.

We were discussing her latest book, Resilient Management.

Full transcript

Aaron - Welcome to the humans plus tech podcast. I'm Aaron and this is Amy. Hi. And today we're talking to the mighty Lara Logan. Lara as previously VP of engineering Kickstarter ends being director at Etsy and more recently founded wherewithal where she coaches managers and leaders across the tech industry. Lara thank you so much for talking to us today.

Lara - Thank you. And honestly I've never been referred to as mighty before. I'm going to put that on business cards. Thank you.

Aaron - Hey, you're welcome. Very mighty.

Aaron - We first saw you speak back in 2017 when you presented at the LeadDev conference in London and I remember us looking each other after your presentation we were like that was so good. We went on to read all your books and your blog posts and so yeah to say we're a bit excited to talk to you today is an understatement!

Aaron - So to dive straight in congratulations on the release new book Resilient Management. For those who haven't had the chance to pick it up yet can you tell us what it's about.

Lara - Yes. So I wrote this based on all of the coaching conversations and workshops I've been giving for line managers of all kind. I found myself saying the same things to these poor new baby managers. Like just finding their way in the forest and I wanted to create this book for people like that. You know people who are either new to management or just want to like level up their skill at being managers and people who were just like feeling a little bit shaky but also really wanting to do a good job because as you all know like being a manager is both equal parts exciting and terrifying.

Lara - So Resilient Management is my hope is that it's going to help folks feel a little bit more grounded like have a little bit more solid footing while also acknowledging kind of all the challenges trials tribulations that we need to be resilient through.

Amy - Fantastic. And I have to say I was telling Aason that yesterday I was re-reading your book this week in preparation for this conversation and I missed my stop on the tube. I was like deep in there.

Lara - That's such good review. Thank you.

Amy - So your book has the M-word in the title. Is it only for managers?

Lara - It's funny. It's actually its cracking me up how often I get this question and I'm, I was, I shouldn't be surprised by that because of course you know people people who are not managers probably look at it and are like oh that's not for me. But that never really, never occurred to me while I was writing it was like No obviously it's for anybody who like has a manager, is a manager, or just wants to support other humans with the kinds of things that managers do.  Which you know frankly lots of senior individual contributors also are required to leverage a lot of the same skills about growing other people around them, giving feedback, you know those kinds of things. So it is absolutely a book for anybody who has to like work with other humans and be resilient through like people stuff not just managers. But it's, I upon retrospect I probably should have called it something else.

Aaron - I mean what it's what I have told, after I read it, I told one of our senior architects to also read it. So it's not just the managers.

Lara - Yes I'm hopeful it's helpful to a very broad group of people.

Amy - Yeah I'm sure it is. I'm sure it is. So you started out your technology career as a developer. Can you tell us a bit about how you got into management?

Lara - Yes. So I am a self-taught front end developer. And so I kind of found my way you know through a bunch of different tech companies like lots of us do. And I started to get more and more frustrated with how things were gonna be run. You know each of these companies and I was like I can help. I can add clarity and I can add it. We need all this more process and what people really need is a Jira board you know and just that way and they're not the right reasons necessarily that's the right goal. Right your goal can't be just to effect change it also has to be to support the people around you. And I found myself as a baby manager working with like one or two other people both of whom are super different than me meaning they had different needs, different things that excited them, different things that annoyed them and my style of management was like what I want as a manager which is like process and stand ups and look at all of this cool confluence pages I'm building you know like I could nerd out about Google calendars all day and that's not I say that's not exactly what they needed.

Aaron - So I guess that well my follow up question is maybe what do you find most difficult about management it sounds like you're sort of leading to some of those things already.

Lara - Yeah I just was so surprised when everybody didn't like it because like you know it was one of those things, I want this from my manager why don't you want this from your manager and they were like. One guy actually started giving me the silent treatment which is like a perfect introduction to how differently humans can behave even in childish ways. And for sure I was messing up but like silent treatment. Come on. I remember going to my manager who was actually a great manager and I was like this person is doing this. Look I don't know what to do here. This is so mind blowing to me. And he was like Lara here's the deal. You're gonna have to adapt. You're going to have to figure out what works for these people and also for you. And that was eye opening again the fact that I was I don't know how old I was maybe mid 20s. I could not believe that everybody wasn't like me. Which I feel is a very early to mid 20s perception of the world. Maybe not. I don't know. So it was a good hard first step into management.

Aaron - How did you go about. I. I need to hear more about how you got this feedback. Like how do you go about getting this feedback from a team that things weren't going great and you need to learn.

Lara - Yeah it was honestly it was the silent treatment cause nobody was saying it. No one was like here's what I need instead. And no one was like here's what you can do better because honestly we don't get that. We're not surrounded often by people who are phenomenal feedback givers or feel like even taking the time because it's so much work to give good concrete specific actionable feedback which is why I spend so much time on it in the book and in my workshops because like we're humans are so bad at it. I mean myself included but we're all often really bad at it. So no one was giving me the feedback. I just started to realize something was wrong and I'm the kind of person that really really really wants to support people and help them. And so when it's clear to me that there was a huge gap between what I was aiming for and what was actually what I was actually doing that's kind of when I started to go talk to my manager what else should I be doing what else should I be trying turns out asking lots of questions and doing lots of listening is the answer to most human's problems. I believe.

Amy - Yes definitely yeah. That's a really really great one. So maybe that ties in but like what advice do you wish you'd been given? Like right when you started managing?

Lara - I think right when I started managing, well I wish that every manager, new manager gets this. I wish every manager receives just a succinct little list of what they are responsible for or what they are expected to do or what their goals are. Any of those things that if it's it's too high of a bar to expect all of those things right. Yeah because management means so many different things to different people. Like for me I'm a person like would play school at home you know like I love some process I love some worksheets you know you can see this in my workshops these days but not everybody needs the same thing as a manager not every company positions the role of a manager in the same way. So it would have really helped me and I think it does help lots of folks is having clear expectations about what this role is for and then some support and help people build the skills they need to do that job effectively which by the way no one gets. If you have had manager training consider yourself so lucky because most of us did not get that at first

Amy - Well it was funny actually. I remember when I started managing and I got manager training, well it was called manager training and I was like you know I was like fantastic this is great. They're going to tell me what I need to know. And I went along and it was all about me. And I remember like now that makes total sense but at the time I was so confused.  I was like "I'm fine, I've got me. What about everyone else?" So yeah I mean I, years later I was able to connect that together.

Lara - Wow yeah. Man the state of manager training in the world right now is a little rough. We're just trying to help. I've also now at this stage been to a lot of like not just overarching manager training but also manager training modules and also the skill in like facilitation is so widely varied like I am right now taking a lot of courses on becoming a better instructional designer, better facilitator because I want to make sure that like my educational style will actually work for, again, people who aren't just like me. It's hard. It's really hard.

Aaron - On that, you talk about the expectations of manager being different in places it sounds like your, I mean you're kind of in the territory of manager READMEs which has been a fairly hot topic in our industry. Yeah. Discuss.

Lara - I even put, leave this, like touch on it a little bit in the book. So I used to be firmly in the pro manager README camp, the manager in me as a, as a, as a like a title for it I wasn't always super button you but like the idea of a manager writing down their general approach to this stuff. I have found this useful in my managers meaning like when my managers have told me here's my deal, here's what I think you should lean on me for here's where I'm like where I'm lacking and say look I can help you find other people to lean on for those skills. Here's what I'm expecting of you. Here's a reworked deal though. Those kinds of like the clarity like the brain dump of expectations. I have found really valuable especially when I have managers that are not like me you know I've had one manager that really well OK but let me take a step back what I want in a manager, and everybody's different, but I want in a manager is like someone to help me verbally process like I'm a I'm a person who thinks as I talk says I think race just like let me get this all out and work through it. I'm a person who wants stretch goals like I crave being thrown in the deep end being given challenges will actually stretch me. And I also want lots of autonomy that way I can go and like do my stuff and also bring it back and get feedback. The other last big thing is it give me some feedback some specific and actionable feedback on how I should be growing and I had this one manager that did none of those things except for the autonomy one he like left me high and dry which I was going through a particularly difficult time. I had a really really tough situation with a direct report and I needed I probably needed to fire them and I want my manager and try to lean on him for help. And he was not able to help whether that was because of time or skill or whatever you know unable. And it was helpful in that state for me to say to him hey what how do you perceive your role here. Like give me some to know what how we're supposed  to work together and he was like oh lean on me for like strategy and execution like forward thinking stuff that's it that's what I'm here for it's what managers are here for and I was like Oh what about this other list of things that I need. He was like Oh do not come to talk to me about those things, that kind of clarity was so so so useful to me. So what I think about manager README is the original idea, It's like people, one of our core human needs is predictability, we want to know what's expected of us what how it's all going to work and manager READMEs can help with that core need however. And I'm like super duper agree with a lot of the hot takes on this. There's also a failure mode wrapped up in right like if a manager is just like here's all my faults, deal with it or like by writing these down, it gives me an excuse to never have to address the things that I'm bad at. Or what's even, what's even worse failure mode is when people think that they're great and they write down all the things they believe about themselves but those things aren't true. So obviously lots of elements which is which is why I think this whole idea has evolved over time. So the way that I frame it now is in terms of setting expectations with what people can expect of you, as a manager, in this role and if any like cross-functional peer leads what's expected of a cross-functional peer leads. And also what's expected of the individual team members. So it's much less about like Hello this is the Lara Logan README, you know it is much more like here's what managers or here's what an engineering manager, here's what a product manager, here's what a design leader should be doing on the team. Here's what you can expect of us. So I like I like that. But the last thing I'll say about it is I think it's really useful for individual leaders to kind of self identify their their approach like a one liner philosophy about their approach to managing our leadership. Which is going to evolve over time but sometimes just that like elevator pitch that one line nugget is just enough for you to know what things you're going to be most helpful with and communicate that to your team that's going to help your teammates know why you do the things that you do. For example my my philosophy is like I believe humans already have the answers inside themselves. It's my job to help them find them which is such a coaching philosophy which also helps all my teammates. Now if they want to call me for advice they got to say it. I think that it has lots of open questions but actually what I need right now is some mentorship or some advice for me. And that's it's cool it's just having that one liner helps give us a foundation to begin working from.

Amy - That's great. So I guess one thing before I jump into something else I'm just really curious. How do you deliver that one liner? Cos that feel's like it could be very awkward, like a you know by the way..!

Lara - Right, like, like I bequeath to you my one liner, right? So I find it's useful when friction pops up, meaning I don't think I think you know when you've hired someone new it can be helpful to share it then like or even doing the interview process like hey fyi here's how I think about my role as a manager as leader which can help people kind of like figure out is this a kind of manager that I do want to work with or is do I want something else from a manager. So definitely hiring like early stages, but then as friction comes up like say a person came to me and was like Hey Lara in every one of our one to ones I come to you with challenges I'm working on and you just ask me lots of questions it doesn't seem like you're helping me that's when me sharing. Oh. Got it. Here is my default. Like my default is asking questions. Thank you so much for flagging this to me. Let's figure out a better way for us to work together on this. So it ends up like really helping in those sticky conversations. I am not advocating for you sitting down and in every on to one at the top saying Please repeat back to me what you remember about my management philosophy.

Aaron - That's great.

Amy - Yeah.

Aaron - So um, I guess well very related to this but you know you talk about in the book about the importance of getting to know your team and them you and maybe not having your self-serving one liner written about you. But as a manager what we like what ways we found the more interesting ways you introduce yourself to teams over the years.

Lara - Yeah. So it's funny the biggest transition I made was when I left Etsy and went to Kickstarter which meant that no one there knew me, every time I changed teams at Etsy you know I came in as a manager which meant that every time I worked with additional teams the kind of already knew me. So when I went to Kickstarter I realized like it's probably going to be helpful for me to have like a normal like Hello, Here's my deal to everybody like here's what I'm thinking about and looking for. So in a in like an all hands like an engineering all hands setting was helpful for me to be like Hello here's my deal here's where I've come from. Here's my plan for the next 30 days because again people crave that predictability. People want to know like who is this person. What are they here to do. What are they gonna change and really nervous about any kind of like unpredictability can feel really gross to folks. So I framed my first 30 days as just sponge mode and actually when I coach managers I always recommend don't change anything don't even hint about what you want to change in your first 30 days. Your job for the first 30 days is just to be in sponge mode right. Just ask lots of questions gather lots of information, figure out how people are feeling and then still don't feel obligated to change things in the next 30 days start to just like test the waters like ask people about potential changes you're thinking about get their buy in. So like when I sit down in a one on one as I did a Kickstarter with everybody who was in engineering. So for the first three days I had lots and lots of individual one on ones. I would ask does what shouldn't be changed and like what do you really really want to be different like both sides of the same coin. That way I could get a sense from them like OK what is it that they're worried is about to change with this new edition me. And like what did they think it's like time for. Like what might this be like a juicy cool opportunity for us to spice things up with the you know obviously like there's change already happening I've joined. How else what else can we like roll into this. So it feels like less change over time.

Aaron - Is there a risk, you know I love the idea of sponge mode and like being really clear about that, but is there a risk that you don't communicate it, that people are like what is this person doing? They've made no changes in 30 days maybe 90 days.

Lara - So I think it's also really important to be super like I'm an over communicator meaning like I try to respect the fact people don't want to hear from me all of the time but especially in those like big introduction. All hands meetings the things that you think are obvious about your approach and about what you're there to do are not obvious to everyone. Everybody's carrying their own baggage everybody's carrying their own desires , everybody's carrying their own like fears. It's so important to just say, I've started to use this phrase it's just like, say the thing that's happening. Just describe the basic to say the thing that's happening that's both true and a team dynamics conversation and a feedback conversation,  in your introductions, just with your mouth words. Just say the thing that's happening right now and people can, our poor little amygdalas, our fight or flight responses, can chill out knowing that we have a new certainty we have new predictability and clarity about what's happening.

Amy - Yeah that's fantastic. I really like that, like, it's really interesting isn't it getting that level of sharing right. You know I think well I guess from my experience it feels like I'm oversharing but I'm definitely not. I feel like I'm going to tell you to stuff again and again and again and still people come and they're like Why didn't I know about this thing and it's so hard.

Aaron - I think it comes back to that about because that so everything. It's the motive of the manager even it's where it's like you know what I like when you I think when you oversharing something you feel like you feel like the stuff that you're talking about is important or more important. So you gonna keep repeating it and I don't know how you get that balance right and actually this is the company's information not your's specifically.

Lara - Right. Well and I think that that's a great point Amy like people don't remember things the first time. So like that the seventh time you say something like they might remember it but that's also why one of the skills that I think managers should build is the elevator pitch like what is the one liner thing you want to say whether that's your approach at philosophy and management or whether that's what the team is here to do right now or whether that's this desk move that is happening here's why. Like no matter what the thing is developing your one liner that you can repeat that beat that same drum over and over and over again actually helps people hopefully remember this stuff a lot quicker.

Amy - Yeah that's great. And I love you mentioning that desk move because desk moves are like, you talk about this in the book, but they are the most hardest thing in the world and it's so surprising ins't it? You're like we're just gonna do a quick quick move and chaos.

Lara - So many emotions.

Amy - Yeah, I mean I have interviewed people in the past and we were like well you know why are you looking for a new job. And the answer was literally they had been moved to a desk they didn't like. We were like Wow OK. Like that's the level, you know, that a desk impacts. You talk about in your book and in the BICEPS model, do you want to talk us through the model. You probably do it way better than us.

Lara - Oh I love talking about the stuff because like desk moves is my perfect example. So the BICEPS model is an acronym BICEPS to help us remember the six core needs that humans have at work. So I mean when we don't have one or more of these core needs met our amygdala which I kind of hinted at before, our fight or flight response, it can wake up and if the threat feels significant enough it can go into overdrive which means our our lizard brain. Right. Like our the our emotional not rational part of our brain can go into overdrive. It's not helpful or productive for that to be the case. And desk moves is my favorite example of when this can come up because desk moves can trigger any of the six core needs feeling threatened. And so like that person can do an interview and was like it's because the desk moves it could have been so many different reasons. So the B stands for belonging. Like we don't feel like we belong to the group anymore we feel othered we're left behind. That sense of the core need for belonging to a group will feel threatened. The I stands for improvement or progress towards a goal. You know we want to feel a sense of progress in the things that matter to us whether that's us learning or our career developing or it could be for our team or for our company. Just we want to feel that movement towards a goal. The C stands for choice. Like we all want to have some level of autonomy over our work life. The E stands for equality and fairness. If we want to believe that everybody has equal access to what they need to succeed to do their work equal access to resources, to information. The P stands for predictability which is you know what we've been talking about this whole time like we want to have a sense of what's happening in the future. This is a funny one though. It's actually similar to choice and that too much predictability will actually feel terrible like demote de-energizing and like we can get bored from too much predictability and also too little. Same for the choice too much autonomy and we get stressed out and too little autonomy and we get stressed out. So those are two funny ones but then the last one is Significant which is effectively status like where do I sit in this you know informal or formal hierarchy. So desk moves that person, that poor person who came to you in the interview who is like I'm leaving because of these desk moves, who knows which of their core needs, maybe multiple of their core needs were like really feeling threatened by this.

Amy - Yeah that's really fantastic. And I mean I know when I read through this that like I was you know I've been managing people for a long time and I was like, even now reading of it. I was like Ooh yeah. For me it explains so much about the way I reacted to it. That was my main thing was I. Oh yeah. No that one's really important,  oh no that one's even more important.

Lara - That comes back to our thing at the beginning right. Like what's true for you. Like what's going on for you and your heart or your brain. It's gonna be super different in the people that you manage and so like you. Let's say you're going through a desk move with your whole team and your sense of significance is threatened, you didn't get to choose where your team gets to sit. Everybody else in the team might also be having emotions but for different BICEPS reasons like it's it's wild. And by the way we are really bad at guessing which core need is going on which person because we'll project our own. So this is yet again another reason to get curious. Ask lots of questions like help this person introspect and explore like what's going on for them to come to their own conclusion conclusions about what they need.

Aaron - It's interesting. I guess back to these BICEPS, have you, have you seen in your time, obviously we're all different and we switch between these different types at points in time. Have you seen a general pattern as an experience manager like do people tend to more of these than others?

Lara - No because it's is such a core from experience like this is our limbic system right. This is just like the way that we've been hardwired you know is this one of those universal truths. The way that they are expressed is different. Like there's five forms of resistance that that humans usually like portray to when they're being middle hijacked so like they'll avoid stuff they'll look for an escape route they'll fight they'll bond with each other you know they'll play devil's advocate, there's a bunch of different ways that this might manifest but again it's just such a core human experience.

Amy - Actually before we move on from there,  I'm really curious as to what are your techniques or great questions for helping work out where people are with their BICEPS?

Lara - Yeah totally. So the first thing I'll do is reflect back what I'm hearing them say and as I reflect back on them I literally say OK just to make sure I'm hearing this right. It sounds like what's going on is blah and I'll say like you know I'll repeat back again in my own words whatever they've just said and the act of doing that often makes people be like Yeah yeah that's exactly it. And that's what I'm looking for I'm looking for the like the feeling seen and heard. And just like I'm not just moving forward to solution mode I'm just like sitting in a moment and just saying like cool is this right. Is this what you're experiencing. So I make sure I have it right. People feel so reassured that someone's actually listening and cares enough to spend this time talking about. That's like step one, step two often is actually showing them the BICEPS model. This won't work for everybody like it feels it just feels too cheesy or weird for you. Don't do it. But like for many engineers they'd like a framework. I like a framework. I'm an engineer so showing them like OK. Here's the six core needs that humans have at work. Let's walk through them. As we walk through them I want you to think about like which one of these might be going on for you maybe multiple. And as I read them to you I'm sure you were thinking that one comes up for me all the time. Like for me it's right for some of us that's belonging or it could be any of them because they'll read that list and be like yeah, no it's this one. And maybe it's also this one. I had a coaching call the other day where they, they named five out of the six. It wasn't a desk move or something else but it was like I was like Yeah right. This is an awful situation that you're in. It's threatening so many things for you and just that act of like thinking through it. Sometimes what that does is it can help bring someone's prefrontal cortex back online so our prefrontal cortex is the thing that's doing like the rational logical thought. Like anytime we're involved in deep complex problem solving our prefrontal cortex is doing is doing that work it's online. So the act of sitting through and reading this list together and trying to almost we're not problem solving yet but we're like doing some critical thinking about which one of these core needs is happening. Sometimes that can bring that prefrontal cortex back online and bring us back to a more like logical rational place because when our amygdala is hijacked our prefrontal cortex is offline. We are no longer making rational and logical decisions. So yeah for me it's a nice little way to help people just chill out for a minute so we can figure out what next steps we need to take.

Amy - Amazing. Yeah. So moving into senior roles like I think probably everybody, as you progress it starts to feel quite lonely. You realize that you no longer have a great team around you so you introduce in the book the idea of the manager Voltron. Could you talk us through like what that is and how that can help?

Lara - Yes. I mean I like to usually ask other people to define Voltron just to see the answers, do any of you feel like defining Voltron?

Aaron - Oh I mean I can give it a go, I mean I've done it so. So I've got one that I actually printed out a copy from your book and then you have it on your website don't you?

Lara - Yes

Aaron - I printed that out and I got it and actually did it with my engineering management group at Songkick. So we had the five of us sit around and complete it together which is really fun. and uh.

Amy - Sorry, did you all feel like that you had to write each other? What was the peer pressure there?

Aaron - Well it was very much like these can be secret ones but the aim was to steal some time to actually complete them. It could be you that didn't share them with the group. But yeah everyone just wrote each other's names, no no they didn't. But essentially what it is I guess to answer your question its this matrix of kind of I guess skills and responsibilities that other people may have that you respect and you want to get better and you can fill in the names of people that can help your coach or mentor to level up in those skills. I hope that gives the gist of it.

Lara - Like there was no way that he was thinking about the other stuff I might need, so yeah building out that matrix of people that you can lean on you know manager crew doesn't need to be managers. Just people you can lean on as different pieces parts of an ideal manager as you learn and grow beautiful beautiful. I love that you did that with your Songkick crew. That's awesome.

Aaron - So I guess. Actually I had two things that I took away from that. Maybe I mean you're the perfect person to pick the brains up but the person was how many gaps there was like across all of us which I guess that's the whole point of this right is that if you've been set up correctly and it's all full then probably you're doing great anyway. So all with us there was some pretty big gaps. If you look at what subjects were. Their skills were they were definitely things that we needed support among big things just great things go through the process but the other follow up question was like Now what?

Lara - Yeah which is so weird right. It's like I have these gaps or sometimes you look for it in a name and way they have it the little bingo card you can circle. On like a print out version I have you can actually circle whether you already have this from a person, whether you have this person in your corner but you've never actually leaned on them for this skill before so you probably need to like ask them or if it's completely blank you need to find someone to fill that gap. So it's so weird to try to like introduce more people to your Voltron. First of all don't you don't need to tell them what you're doing. You don't need to say like here's what a manager Voltron is I'd like to add you to mine.

All - Laughter.

Lara - My favorite way of doing this. A friend of mine who used to be the CTO of Meetup, Yvette Pasqua. She added me to her Voltron without me even knowing about it. So the way that she did this was we had bumped into each other at some event you know. So we had met each other just briefly like we hadn't ever had a real conversation before. And at the time I was the director of Product Infrastructure at Etsy and she'd emailed me and said hey you know it's me again. I know that you are leading a bunch of infrastructure teams I'm thinking about reorganizing my infrastructure department. Do you have any like opinions about this or like you know war stories you want to share and kind of like talk to you about that over coffee and the beautiful part about this email was like she guessed correctly that boy did I ever have strong opinions on reorgs for infrastructure teams right. And she correctly accurately spiney sense like OK if Lara is the director of infrastructure probably she has some war stories about this process so she'll want, she'll be eager and this is it was true Yvette really was reorganizing her infrastructure teams so we got together for coffee and we ended up hanging out for like three or four hours and so it wasn't just us talking about that infrastructure team it was also just like sharing a bunch of other stories at the time I was dealing with something really stressful at work and so was amazing to get to lean on her for that too. And we guess we hung out for so long and it was the beginning of a Voltron edition. Like she correctly identified something I would be excited. We all love talking about ourselves. So Sheila correctly identified a thing that I was going to be eager to talk about with my experience and then I was able to lean on her too. And that's like the most easy beautiful way to add someone to your Voltron crew.

Amy - Wow that's fantastic. Yeah I mean I know I definitely when I did mine that were quite a lot of gaps and I was a bit like oh, oh, panic but there were also ones were I was like Oh no actually I have somebody but I'm not leaning on them as much as I can. And it was really great to realize actually you know I have someone I can ask about this stuff I just need to do it. I just need to ask.

Lara - Yeah it's so it's so rare for us to get that like little check in with ourselves like oh hey oh yeah I probably should just call that person like why haven't I just asked them. My favorite thing to do with my with members of my Voltron crew is to walk through my performance reviews with them. Like I'll pick three or four and then just be like hey here's my performance review. Can we sit down and chat through it together. I would love to hear your ideas and your thoughts and your feedback based on what was shared in here because everybody's going to bring different perspectives and you know maybe come up with even better ideas than you had.

Amy - That's really amazing. Yeah I think that's so powerful isn't it? like performance reviews are always treated as such a private thing. Actually I love that. I love the thought that getting someone else's perspective can just open up the other side.

Aaron - I was going to say exposed. I guess that's the be vulnerable piece. I guess

Lara - Yeah, exactly.  And like your Voltron crew wants to help you if they're actually members of your Voltron crew. They're there to support you. Right. And like help you figure it out. Also by the way you know being a lady in tech means like I've gotten some performance reviews that had some pretty biased feedback and it was so helpful to talk that through with members of my Voltron crew  where they could be like you know what I see why they wrote that thing you can discard it. You don't have to take that piece of feedback. And that was really really powerful for me.

Amy - Yeah that is fantastic. The bias that goes in a review is like, it's really, like even writing them. You know that you're like oh this is just one perspective. That's really powerful.

Lara - Totally

Amy - So you dedicate a section of this book to managing times of crisis.

Lara - Yeah.

Amy - Could you tell us about a time where it all went wrong. And maybe more importantly how you handled it?

Lara - Oh gosh so many crises. I mean look the reason I originally wrote this whole thing was because of external crises right like I'm in America. Y'all are in England. It is October of 2019. It feels a little bit like the world is coming to an end you know, like there is an external crisis that we do need to manage through but also of course like the hardest times of my management career. You know a lot of them were because of internal crises whether that was because of executive turnover or or layoffs or just something horrific happening. So for me probably the starkest experience that I had managing through times of crisis with an internal internal crisis was when at Etsy you know we had an executive team turnover and on the same day layoffs were announced and I found myself pretty ill equipped I'd never experienced something like that before. And because of a series of events I found myself up on stage at the end of the day talking to the engineers who had not been laid off and again being ill prepared ill equipped not really knowing what I was doing I just kind of went with intuition about how to answer questions from the crowd how to wrap it up and move forward. And I was joined by two or three other engineer leaders but like my my boyfriend at the time now husband was in the room staring at me like some of my closest dearest friends were staring like it was a hard just an awful awful awful day. And the way that I approached that was trying to both acknowledge how I as an individual was thinking about this event and also acknowledging the company party line. That way it wasn't just me regurgitating like top down messaging but also saying like here's how not not like here's how I'm feeling right now because I don't think it's fair for four people in positions of power to be trying to get people to care about how they're feeling like you're in a position of power. You need to get your emotional support elsewhere but just acknowledge like this is a super hard day and there's lots of questions that we don't have answered and like acknowledging that there's still more that we need to find out that there's no acknowledging where there was no transparency or no information yet and then saying like you know here's what I am personally I'm going to be doing to either follow up on this or here's the answers that I am eager for us to follow up on and get in the future. Here's when you can next hear from me is another thing I try to employ. So like here's what we know here's we don't know here's what you're next to hear from me about that stuff and in what medium can help again with that core BICEPS need of predictability that people are craving more information and they don't know when they're gonna get it they don't necessarily need it. You haven't earned their trust yet right. So it's really important to say when and where they can hear from you next. Even if you say I don't know today.

Aaron - Nice, that's pretty interesting. I think you know when you talk about working through a crisis and then back to the beginning of this chat when you were talking about mistakes you made as a new manager there's a line, actually it's kind of a spoiler to tell me if we can't talk about it but at the end of your book of you have this metaphor for growth which is probably like one of my favorite things I've ever read. And it really stays inside me. Can you talk about the caterpillar cocoon metaphor?

Lara - Yeah. You know no one's ever said that to me like no one talks to me about the conclusion. So thank you for bringing it up. I love the conculsion. This came to me from a coaching session I had. So I've had ever been working with my coach for a million years now all through my time at Etsy and since since I've left Etsy also. And she, I was going through like a really, this is gonna sound after talking about something as horrific as layoffs, it's going to sound a lot less serious but like I was going through a personally horrific time when I was trying to figure out what it was to be a director of engineering. I was a senior manager. I didn't really know the difference. I didn't know how to exercise those muscles I didn't know what it looked like with responsibility, like it's so unclear that there's difference between levels and I was going though this exercise of like trying to show up more as a director. And so we at the time we were talking about like you it feels growth is so gross. We talk about growth as is that just like beautiful thing we all want to aim for and like it's just exciting whatever and actually growth is painful and it's messy and we use this metaphor in coaching, my coach and I about this. I didn't know this but I listened to it I think it was a Radiolab about caterpillars and I had thought that when caterpillars go into their cocoon they like sprout wings and then bust out of their cocoon like what's up world of a butterfly now it's like happy and glorious actually what happens. You may know this, I didn't know this is that when they go in the cocoons they like dissolve into like a primordial goop state like it's gross and probably I don't know I assume it's painful you know like they reform as a butterfly and then they bust out and I love this as a metaphor for growth because totally growth is goopy and the growth is painful and like we all like we're all aspirational about it but actually it sucks when you're going through it. And so I included it as a conclusion to be like if this feels painful and hard right now probably that means you're growing and sometimes you know obviously like that kind of growth is not sustainable or worth it. But I call it out because like it's often an indicator that you're actually doing the right thing.

Amy - So donuts, Lara talk to us about eating right.

Lara - Yeah.

Amy - Did you like you celebrate your achievements with donuts, anyone who doesn't know this, I'm going to assume you're still doing this. But most important. How many donuts did you eat when Resilient Management was released?

Lara - So don't tell anyone. Slash This is a podcast.

Amy - We won't share, don't worry.

Lara - I totally got over donuts. Like for me donuts became like I got so many donuts. Oh and then. And that very very generous kind people started giving me donut related paraphernalia donuts pens and cards and whatever and like that's so so so sweet but also I was like oh I can't eat any more donuts so now it's sushi. So for me I ate so much sushi as I was finishing up and shipping Resilient Management. I had some of the best sushi of my life. Throughout that process.

Aaron - Is this just a way to ruin things that you really like?

Lara - Yes, exactly, I maintain that anybody can be any way to treat yourself like the way that I've now phrased it in the book and in places it's like when you are thinking about this for yourself. Like what's the way that you treat yourself like my when my friends it's a hot tub and a margarita, like he'll go find a hot tub and bring a margarita and like that's such a nice way of thinking about treating yourself so it doesn't have to be food related. It can be literally anything. So for me these days it is still food related and it's sushi and I love it.

Amy - Amazing. It's great. So you've written about web performance, public speaking and people management. So what's next for you?

Lara - I am itching to write another book but I don't have any topics yet. So if you have ideas I love the process of writing a book. I'm a weirdo that absolutely adores it. So if yeah, If anybody listening to this or if you two have any ideas on why I should write next please pass it along because I can't wait to figure it out.

Aaron - Great we'll get thinking.

Amy - Yeah we'll send you a load of ideas. Okay awesome. So super quick questions to just wrap things up. What are you reading right now?

Lara - Oh I'm reading The Art of Gathering. It's all about how to like gather people together in ways that are actually smart and useful not just like let's get together because we have to have a meeting right now.

Amy - Amazing. And what's your number one tip for keeping up with the industry

Lara - I am so sad to say this but it's Twitter. I hate it. And also it's so useful.

Amy - Yeah I totally agree. I sort of love it. You can find the stuff you need. You've just got to ignore everything else. And who inspires you?

Lara - The person who I dedicated Resilient Management to. Her name is Paulo Medina. She's the one who originated the BICEPS model. She is just brilliant. She is a better trainer than I'll ever be. She is absolutely credible she's, I look up to her immensely.

Amy - Amazing and where can people find out more about you?

Lara - Yeah I mean on Twitter (@lara_hogan) again I'm so sorry. Also I have a Instagram for wherewithall (https://www.instagram.com/_wherewithall_/) it has underscores in the beginning and the end of the word wherewithall and wherewithall spelled a little bit differently. So if you want to go on my Twitter you can probably find the link to the wherewithal Instagram. That's my current format these days for like putting out stuff that I hope it's gonna be useful to managers.

Amy - Amazing. And we'll put all these links in the show notes and show them out so people can find all the good stuff.

Amy - Thank you so much Lara. This has been amazing. I've, we've made loads of notes. We were like we were all prepped and now we're gonna go away like do like loads more homework.

Aaron - Great. I've got more work to do brilliant.

All - Laughter

Lara - Thank you.

Aaron - A massive thank you to Lara for talking with us. If anyone hasn’t read Lara’s book, Resilient Management, then go and check it out. I’m Aaron, this is Amy, and you’ve been listening to the Humans Plus Tech podcast.

Hi, we're Aaron & Amy! We’ve been managing tech teams for a combined 12 years, and over this time have learnt (often painfully) what does and doesn’t work. Of all the advice we’d give to first-time managers, giving constructive feedback (A.K.A having a difficult conversation) is the one that feels the most intimidating, least natural, and is often the easiest to put off. But like any other management skill, you can learn how to do this better – let’s talk about using the SIA model to give feedback.

Why give feedback?

Feedback is a gift – if you want to help someone improve, give them honest feedback & clear expectations

Successful management relies on good communication. As a manager it's your job to give feedback when things are going well, and even more importantly, to give useful feedback when things are proving difficult. Sometimes people approach a task in the wrong way, or fail to approach it at all, sometimes their work style offends, intimidates, or excludes others, or maybe they haven't quite mastered the timekeeping and hygiene factors. Whatever the issue, you need to have the difficult conversations, and you need to do it well.

Feedback is a gift – if you want to help someone improve, give them honest feedback & clear expectations.

Preparing to give feedback

Don’t freestyle! Preparing to deliver honest and clear feedback is your responsibility

So you have some feedback to deliver – great! Make it valued and welcomed by doing the required preparation. Don’t freestyle! Preparing to deliver honest and clear feedback is your responsibility. There are four things you need to do:

Preparing what to say can be the most difficult aspect of giving feedback. This is where a model like SIA can help.

The SIA model

The SIA model has 3 parts:

Here's how SIA can help with constructive feedback:

Why this works:
Situation: interrupting in a kick-off meeting
Impact: prevented opinions being heard
Action: let people finish before talking

And it also works for positive constructive feedback:

Why this works:
Situation: team presentation
Impact: clarity for the team, increased confidence
Action: find more opportunities to repeat this

Giving constructive feedback can be intimidating, but as a manager you need to have the difficult conversations, and you need to do them well. Framing your feedback using the SIA model helps you turn a vague piece of feedback into something that's considered, structured, and actionable.

Remember, feedback is a gift! If you want to help someone improve, give them honest feedback & clear expectations.

Shout out to The Geek People for coining SIA :)

Hi, we're Aaron & Amy! We’ve been managing tech teams for a combined 12 years, and over this time have learnt (often painfully) what does and doesn’t work. We recently spoke on the Programming Leadership podcast about our experiences making the transition from a software developer & tester into tech leadership roles. Take it for a spin below!

You can read the full transcript here.