How to supercharge your engineering org | Kellan Elliott-McCrea (Adobe, Dropbox)

Brett Berson: [00:00:00] So we have a lot of different fun stuff to talk about. Maybe one place is, given you've been building engineering teams for a while across a lot of different companies and a number of different market cycles. When you think about the underpinnings of what it means to run an excellent engineering organization, say 10 or 15 years ago. What have you become more certain about? And maybe what are things that you once believed that maybe you updated your thinking or you changed the way that you um, you think about those things?

Kellan Elliott-McCrea: Sure. That's a really interesting question. Hit me with the having to remember something from 10 to 15 years ago. You know, I, I will say that I've always approached the work with curiosity, so it's, it's constantly changing. So there's not sort of a bifurcation, I like to think that that means that it's always been uh, relatively correct 'cause it was based on data. But no, that's a really interesting question. I mean, So I would say that the things that haven't changed are, I mean, the things that make software [00:01:00] possible are like small teams, high degrees of clarity, lots of trust, good communication, iteration, customer focus, like these are the things that we kind of already knew 10 to 15 years ago. They're still true, they're still hard. And I think that's kind of a reoccurring theme of a lot of this stuff is just 'cause you know, the answer doesn't mean it gets easier to do. But as of what's changed, I mean certainly we are embracing larger teams these days and having to think more creatively about how we handle the complications and concurrency that brings to our teams. And I think that's a thing where my thinking has evolved over the years to sort of see some of the value as well as the downsides. Flickr was very famously a team of 20 people, and we never wanted to get larger than 20, which meant that, once people started leaving, we didn't have a lot of resilience and very quickly, That organization got unhealthy.

I, I really appreciate the SmugMug [00:02:00] people picking it up and reviving it. I think that some of the other things that have, have really changed is a real focus just on the quality of management. I really have come to believe that high quality management is one of the keys if you're going to scale your organizations.

And so the degree to which I invest in that versus invest in architectural principles or code reviews or other things has grown. And then there's the fun things where we were out on an island 10 to 15 years ago and sort of the industry is kind of. come around and some of that is things like continuous deployment or blameless postmortems, generally learning culture stuff.

And like, that's been kind of fun , So that's, that's a few. Hiring has changed dramatically during that time period. That's probably the place where the practices have changed the most.

Brett Berson: . Let's talk about larger teams and what you've observed there, and maybe go a few clicks deeper. I think that's certainly true. The other interesting thing is that [00:03:00] at the same time, the teams have gotten larger. The layers of abstraction have improved dramatically. And so in some ways, certainly in the context of building a small new product, I feel like you can get more done now than in the history of the world.

Kellan Elliott-McCrea: Absolutely.

Brett Berson: to your point, at the same time, it feels like the average engineering team of a medium-sized product has grown dramatically.

Sort of, how do you reconcile that? I mean, You could even go back 20 years when a team was managing all their own infrastructure from day one. 

Kellan Elliott-McCrea: my first job involved actually racking the hardware and building it out of OEM parts. 

Brett Berson: maybe you could share kind of what, what you've noticed in why that is the case. Pros and cons. How do you even know how large a team should be to do anything?

Kellan Elliott-McCrea: So many questions in there. Let's see if we can pull them apart. Um, But I think you've hit on kinda one of the fundamental contradictions or tensions right now in software teams, which is this idea of the tools are better, we have better abstractions, like you said, [00:04:00] you know, even relatively modern and maybe Flickr doesn't feel modern to other people, but it, you know, to me, you know, we were having to build up storage as a service and that was a huge part of what our critical skill was as a team.

It's like we knew how to store lots of photos. The lots of photos that we stored at that time fit in a single S3 bucket today. Like this is not a hard problem. This is a problem, which has just been removed as a consideration, for an entire class of software for the last almost 20 years now.

And so there's a few things going on. And the first is that not all of the abstractions are good. And so while you said it is easier than ever to build something small, there are a bunch of challenges. Some of those abstractions are great at small scale, but you, when you have to pierce the abstraction, they get challenging, but some of them are actually never great.

They are things that are telling you about ways to build software and ideas about what the right way to build software are, which are just misleading and others are things that play [00:05:00] into. I, I don't know if I would write this, but this is a podcast so no one listens to anything we say here, right?

So I would say that they almost play on our, our insecurities or weaknesses. Like, I actually feel like a lot of the data products that are available today are really like targeting people's, need to prove that their work is actually working or validate their existence within a team rather than actually driving the software development forward.

And so there's a lot of different ways that the sets of tools. Have raised the cost from raising the complexity of implementation to raising the complexity of when it doesn't do the thing you want to, just raising expectations about kind of what is normal, you know, and we've let ourselves get, this idea that, you know, it is normal to have an infinite amount of data and be able to answer all of the questions, or sometimes you just gotta, you gotta go without the answers.

So I think that's a little bit of that, that conundrum with there being better and better tools, and we can definitely dig into that. You'll also ask the, like, how do you know the right size of the team? Fundamentally, the rule of thumb I use here is your team is your unit of concurrency.

And [00:06:00] so the number of work streams you want to be solving at the same time is how many teams you need. And so the more things you're trying to do at the same time, The more teams you need, but each of those teams has to interact with all the other teams. And so the complexity of this growing is actually geometric, not linear.

And so as we constrain the number of things we work on, the coordination, communication costs go down, but in an environment where we didn't have to constrain it 'cause we could afford to grow or we didn't constrain it because the market pressures were really competitive, we saw exploding teams and then we saw the cost of operating, those teams go up faster than anybody expected because they didn't grow linearly.

Brett Berson: What's your guess of what team sizes look like in three, five or 10 years?

Kellan Elliott-McCrea: It's a really interesting question. I think that there are a bunch of unknowns there. you know, if you look at the last 10 years, half of everybody working as a software engineer joined the industry in the last 10 years. And I think that has also been a, had a [00:07:00] profound shaping effect on what teams look like.

And the question is, do we think that that growth, that demand continues? And if that demand continues, then that number of people will enter the industry and that will shape the teams. There is a very good chance that AI, not that it writes software, but that it actually just removes the class of software from needing to be written full stop.

and That there's a huge drop in demand and that teams actually become more experienced, smaller teams, more focused, also in a world where you can bring software to market without a UI. Very different dynamics around teams. So I think there's a bunch of different things there. I think that. Over the next 18 months to three years, I actually don't think we'll see substantially different changes, but over the next five years, I could see teams actually getting smaller again.

I think that there's a bunch of work right now that doesn't have to be happening.

Brett Berson: So going back to the question of, team sizes and maybe org structure, you kind of laid out your kind of simplistic way of thinking about it, which is concurrency, or how many [00:08:00] separate things do you want to be doing at the same time? How does that fit into levels of productivity?

And I think there's kind of the age old question of, of how do you know how productive an engineering team is? And there's a lot of different religious points of view, I would say, on this potentially. but the thing I'm always curious about in companies, Is, how do you think about input and output mapping?

 And in certain parts of the business, we'd all agree that input and output mapping is relatively easy and relatively coupled.

 And what I've noticed is in any organization when, when that gets decoupled where it's harder or squishier, lots of weird, oftentimes unhealthy things generally happen. I'd say in engineering it's probably somewhere in between. 

Kellan Elliott-McCrea: I gotta, I gotta ask you, so if engineers in between, what do you see at the ends of the spectrums? 

Brett Berson: An example of something at one end of the spectrum of, of tightly coupled is, is sales motions or sales organizations the more transactional the sale is, the more measurable it is in terms of inputs and outputs. I think in [00:09:00] terms of things that, that are, are less easily tied. One thing that comes to mind is brand and brand marketing. That feels kind of like an artistic pursuit to a certain degree. 

But I'd be interested in like how you think about input and output mapping and then maybe kind of sitting on top of that how you think about productivity?

Kellan Elliott-McCrea: Yeah, there's a few different pieces there, and I think the first thing to understand is that there are different types of teams and different shapes of engineering. Squads within a larger engineering team, but also it changes a lot at the phase of the company and the age of the company and a variety of other things. When you're advising or when you're coaching, a standard question from an engineering leader is something like, or not an engineering leader, a CEO is. My engineering team is going too slow and they're working on the wrong thing. 

Brett Berson: You very rarely hear it in the inverse.

Kellan Elliott-McCrea: yeah you're like, well, wait a minute. Do you want them to go faster or to work on the right thing? And there's a few things going on there, but fundamentally, and I think that this is what makes these conversations challenging and breaks our brain a little bit, but is [00:10:00] just true.

And is more true today 'cause of the sophistication of the tools. we say the abstraction layer has gotten better, but in many ways we are using more sophisticated tools. They have not gotten simpler. They have merely gotten higher level and more productive, but they're not simpler to use. And software today is more of a collaborative team output than it has ever been. The stereotype when I got into software was the engineer puts their headphones on for six months and like types away and then checks the code in at the end of the six months. And like that is almost unbelievable. You know, you, you can't imagine that happening in this day and age. I mean, I've gotta get branch and I'm pushing to it continuously and I'm getting PRs.

I'm like, the work just looks different. It was always collaborative, but it's more collaborative today, which means that you don't see linear input from an individual's effort to output. And that's really tricky because you're right, there are a bunch of tasks and a bunch of disciplines where you actually do see [00:11:00] that and where you can bare knuckle your way through it, you can hero your way through it. I mean, and you would know better than I do, but my sense is that actually startup founders one of those jobs where at least in the early stage you can hero your way through it a little bit, and it, it ends up in this really odd tension with the engineering ward where they have to first build a healthy team before they can get any outputs. So it's a little bit tricky. So your unit of measurement for health is at the team level versus the individual level, especially as you scale. And to be clear, Below 12 people. Anything works. Everything is easy. I mean, that would probably be my message to anyone listening is it's never gonna be easier than it is today.

It's just getting harder as the number of people involved grows. and so then as you start thinking about, the health of teams as a unit, then you have to ask yourself, do they have clear goals? And that sounds trite. But the lack of clarity around goals is the number one reason that teams are actually moving slow. And then the second reason is of course, 'cause they're trying to coordinate with somebody else. And so the [00:12:00] health of a team is very much measured on, like, it sounds simplistic as you described it is, do they know what their goal is and can they execute with low dependencies? Where there is dependencies, do they have a trusting relationship with that team?

And that's where we start to get in the fuzzy things. can these teams solve on a, on a point by point basis to solve their problem? Or do they have to route up? And so as you're starting to evaluate the teams, you're looking for things like they are delivering independently. the escalations are relatively low. there's a variety of things that you can be looking at that says these teams are. Self-contained and also have the relationships within the org to go solve their problems without routing up 'cause that's what modern software looks like. 

And then you can break in and look at the individuals. But that's kind of more, because we have to compensate people as an individual. We can't compensate them as teams just 'cause that's not how our society works. But the unit of health is the team versus the individual. 

Brett Berson: Have you thought about economic models that are oriented around the sub-team as opposed to the individual or tinkered with them in any way?

Kellan Elliott-McCrea: I haven't [00:13:00] tinkered with them in any way. it just is so at odds with everything our society does right now that it, it's very much of an uphill battle and probably the closest is team level bonuses. But even there, It just, it goes against the grain. It goes against the grain, at least in America, of like what we are socialized to people.

It goes against HR practices, it goes against people's own senses of self-worth, because we all showed up and worked hard and we kind of need to be individually acknowledged for that. But it's not actually how the software is being built. 

Brett Berson: It's also interesting because obviously you know what has made technology companies, or when I use the term Silicon Valley, I mean this way of, you know, the types of companies that you and I have spent time with, the idea of giving equity so that the whole company, the team level is the entire company is obviously the norm.

 And maybe it's just norms outside of that that kind of break people in a certain way, or maybe there just haven't been enough people that are willing to try it and break things and whatnot. 

Kellan Elliott-McCrea: I mean, I also think I think I have a couple of hopes [00:14:00] for sort of this downturn right now, and one of the hopes, one of the things that made it really hard to run these kind of experiments, you were asking like what is the difference, and I should have thought of this earlier, but at Etsy, I mean, a lot of the people I hired at Etsy are still at Etsy, but certainly when we were there we had a long continuity, which means that we could do multi-year culture changes for the last decade. You know, average tenure has been about 18 months in these kind of companies that we're talking about, which means it's very hard to actually build and experiment with culture in the way that we were for a while. And I think that's one of the other contributors too. Maybe less creativity around some of this stuff. I do think our equity model though, has changed a lot as well. I mean, we still, equity is still pretty core, going back to like with semiconductor equity model or I think that, I think that that's too old for most people to know about, but even like when Microsoft was making people millionaires in the nineties, like that's where our narratives and, and, and sort of stories as an industry are based, but, you know, sarbanes Oxley came, pricing has changed. You know, black-Scholes has like [00:15:00] fundamentally changed how valuable equity is these days and a lot of people have moved to RSUs and it's just a very different, like, I think we tell ourselves that equity is still the same kind of, we're all in this together, but I actually think it's pretty different. I think that one of the things that we've seen is that leadership and, uh, you know, the staff are actually less aligned around the equity models today than they once were.

Brett Berson: What was the general concept of how it worked in the semi days?

Kellan Elliott-McCrea: The semi days, there were very few rules about fair market value. And so there was just a much, larger chance for a high outcome with very little, tax sort of implications. that was, you know, Something we see relatively explicitly as, um, I mean, the DOD was the person buying all the semiconductors in the early businesses anyways.

And so you know, they were a finger on the scale there in terms of regulation. 

Brett Berson: You mentioned that you know, you can kind of do whatever you want until 12 people. How'd you come up with 12 people versus 11, 13, 18, 20, whatever?

Kellan Elliott-McCrea: Partially a observation, know, partially like that is the scale where. You can kind of have a [00:16:00] conversation as a group of people. You don't need to actually start having leadership structures. You know, you can have managers, not have managers, but that's a group that can have a meeting. After about 12, it starts breaking down. Also, 12 people is sort of the upward limit of where most people can manage effectively. You know, six to 12 with eight kind of being the sweet spot is just kind of how much most people can sort of. Juggle the amount of context you need for each individual in order to be an effective manager.

So twelve's kind of your upward limit there and then I think you start to see it break down, by the way, at every doubling the way that you get to 25, you know, and the way you get to 50 and the way you get to a hundred and the way you get to 200. It's kind of different techniques, different organizational structures, different players. 

Brett Berson: You mentioned this conversation that you and many engineering leads have had with, with CEOs and general managers, which is like the, I think our engineering team should be moving faster and or focusing on the right stuff. What's your side of the conversation end up being like, I'm sure you've had it so many [00:17:00] times

Kellan Elliott-McCrea: It's a little bit, the conversation we've been having here you say, well, you've gotta understand, you know, modern software is a collaborative effort, and so communication and coordination are your number one costs. And so the number one thing that, is creating confusion is that not everybody has the same goal. you know You think you've communicated a goal and that everyone's moving the same direction. And I can tell you right now, I'm gonna go talk to people and you haven't. So that's where we're gonna start and we're gonna create clarity. One of the things that's really different about software engineering than other types of engineering, Is the fungibility. problems can take two days or they can take two years. And the fundamental difference is the excitement and clarity you have around the solution. You know, I'm gonna solve this problem for these customers and I can spend two years researching it and building a data infrastructure and deploying it. Or I can go hard code something 'cause I actually understand what I'm trying to do. You know, those kinds of trade-offs come up all the time and not all of them are that extreme, but I've absolutely seen ones that extreme. And so when I'm going and having [00:18:00] these conversations with leaders, and this is, I think the standard conversation most people have is, it starts with leadership if we're moving too slow, it always does, and we've always believed that we've been more clear, we've created more clarity, we've aligned people better than we have, and we just haven't 

Brett Berson: Why is that? Because I, I, it's funny how often so many things in, in building come down to this, but it's also odd because a lot of times, not always, but a lot of times the people at the top were once at the bottom so they were often the recipient of ambiguity or lack of clarity. And then they become kind of the perpetrator or they perpetuate it.

So why is it kind of this evergreen, tricky thing?

Kellan Elliott-McCrea: That's a good question I think there are a few reasons. I think communication is hard and I think people don't prioritize it and prioritize developing skills around it and getting better. No one says, I went into a an MFA in creative writing to become a startup founder. Just no one's saying [00:19:00] that. And I think that there's, uh, I, I got a communications degree so I can become a startup founder, and so I think that that's part of it. You know, we're undervaluing the skills. I think that that's key. I also think that a key piece of it is, again, those inflection points. The way you communicate keeps changing as you grow, and what did work doesn't work anymore. And also, like one of the things about technology companies, it's shared between a lot of different companies, but it's certainly very true in technology companies, is we bring up a lot of different skills together very quickly. You know, sales, marketing, engineering, design, data support, they all come from different cultural backgrounds, even if they've all been in working in tech. And we try to communicate to them as a unified whole without necessarily figuring out how you break it down. I think that that's key. I also think there's a downward cycle here. I communicated I'm not getting what I want, so I'm gonna get more detailed in my communication and I'm still not getting what I want.

So I'm gonna get more prescriptive and more detailed in my [00:20:00] communication. And that's actually counterproductive. 'cause that's actually not what people need. people need the foundations and the strategy and the system and the goal. they don't need sort of the, the work divided down into smaller and smaller pieces. 

And that's actually a thing that, that is uniquely bad in engineering. because so much of our practices are based in consulting. You know, so much of the writing that has been done about how to software engineer actually comes out of folks with a consulting background. And in those cases, predictability is what matters. that's how you get paid. I'm gonna ship it on this date and I'm gonna be able to give you consistent updates all along the way. But when you're building a company, fuck predictability, like we're swinging for the fences. And so that's the other, the other challenge. And so you go into a tool like Jira.

Jira's not built for building greatness. You can use it that way. But fundamentally, it's about someone who's trying to create a sense of control and a sense of predictability over it, while at the same time actually asking to be surprised. And I think that people just don't reconcile with that tension when they think about the goals they're giving people. 

Brett Berson: So you're sort of getting at [00:21:00] this, but is creating clarity and setting goals in the context of an engineering team look like when done well?

Kellan Elliott-McCrea: I mean The first, it has to be simple, and the second is, You have to be willing to sit with people while they poke holes in it and ask why. 'cause that's what engineers do. And so it's a simple message. It looks measurable. People are gonna wanna poke holes in it and ask questions. I have a nine year old, so it's a little bit like, you know, she keeps finding, keeps taking what I tell her literally and wants to like turn that around on me. It's a little bit like that. and so that's the work. you go out and there's the things that come up every time. okay, but what do you want me to do if the site's in danger?

Or, what do you want me to do about tech debt? And we can talk about that. How do I find time to do these other things? And so you just gotta layer that in there and layer that in there starting again at the cultural level. Look at, we should be making things better every day. You know, we care about developer experience. We care about the customers, you know, the customer [00:22:00] experience every day. and you start laying those things in there over something like predictability over something, like doing what you committed to, and you get to the end of that sort of all those other things that you're putting in your budget. And you may not have a lot left. That's the other piece about engineering leadership is, if you're trying to build a new product, you need to start farther back and make sure that you have paid down all those other costs so you actually have enough in your budget left to do the work to build a new product where you're not fighting fires and you're not responding to customer requests and you're not doing KTLO or tech debt. And so that's the other piece of these goals is kind of knowing that piece and having that lived experience. You can know it. You can be in the trenches. You can be curious and have people ask quest– answer the questions, but I hate to say this, but at the fun- fundamental level, it looks a lot like OKRs, which have a bad rep, but are kind of great, so I don't know. 

Brett Berson: Maybe on that point, is there an example that you can give from recent memory or in the past to show what this kind of looks like? 

Kellan Elliott-McCrea: Yeah. Yeah. [00:23:00] So I, I just started a new job a few months ago, you know, and we're working on putting out a brand new product. You know, there's a product in market, but there's a brand new version of it, which is a complete rethink. It's a multi-year effort and lot of different features, very complicated space.

This is Frame.io, they're acquired by Adobe. It's video collaboration, yada, yada. And so, you know, a goal for a quarter will be something like, here's a customer and we identified a particular customer, and everyone for this quarter is going to make it so this one customer will be able to use the product at the end of this quarter. So is a feature in and out? Do I have to optimize for 10,000 videos? Do I have to do HDR? You know, all those things. We can answer those questions. I can't answer those questions over the next 18 months, but I can give you enough clarity where you can answer that question for yourself for the next three months. You know, the, the next piece of it is, can we find 10 customers who won't want to go back to the old product after one month of using it? Alright, let's identify those and figure out kind of what it is. Ooh. Turns out [00:24:00] performance is the number one thing, you know, or one of the things. And so like that's an example of a goal.

And then we can get into like the sub things, but that's how you align. And I have a smaller team now than I've had in the past. The goals have to be at the right resolution. I've only got about a hundred folks at the moment and so the goals can be pretty specific and pretty product oriented. But that's an example of a goal and a goal that speaks in the language of a, of a product development organization. 

Brett Berson: What's sort of the metadata or context that you like to set? Let's use, this is a great example, a very specific goal. What else is being delivered to the org around that sort of one-liner.

Kellan Elliott-McCrea: Now we're getting into process. and you always wanna be careful on process, but you know, the, it, it doesn't have to be hard, but it does have to be a conversation. So I can tell you this is the goal, and I can ask you what do you think needs to be in it. And so we can do it as a bottom up, but.

What we find over and over again is that you need to set more context than that. So for this goal, I can say things like, it's this customer, and here's what I know about them. 'cause we went out and we did just the smallest amount of research [00:25:00] about kind of what their needs are. And also there's some things that we just know about how people use our product.

Look at, you know, the, the commenting feature needs to be there because, you know, you can't do review and approval without people leaving comments. So you sort of set that, so like that was the initial brief was this customer, here's two or three sentences about what they use. Here's a couple of features that have to be in there, details TBD about what, how well those features are going to work.

And then ask people to come back and in those conversations the question is very simple. Like, do you believe you know, this customer, is gonna have everything they need by the end of this period. . And by the way, nobody moves on until the goal is finished. You know, we, we took on this goal as an organization or as a sub-organization and like, we're all gonna keep working in this area until we're done with this goal and move on to the next one.

So it doesn't matter if we get to the end of the quarter or the end of the whatever, we're gonna try real hard to be done by the end of the quarter. 'cause we have work we want to be doing. But that's the other piece by the way, of having a, a simple shared goal is we can be like, , we can look at this thing that we [00:26:00] signed up for and know we're not there, so let's figure out how we do this together to actually get a little bit further down the road.

And so in this case, you know, so new practice for this team and we missed it by a few weeks. And so we had a few weeks of kind of, mob programming to get a few things over the line. 

Brett Berson: On the topic of coordination. Do you think more about how to get teams working better together or how to require teams to not need to work together?

Kellan Elliott-McCrea: I think more about how to get teams working better together. I think that we see over and over again. Technical solutions proposed around the idea of, I don't want to talk to my coworkers. I think microservices is like the canonical example of this, but we see it in all different ways, and I think you should wanna talk to your coworkers.

And I think part of my job is to create a culture and a and a team where you're excited to talk to your coworkers and that you can actually solve problems. I think the way that you do that, but through solving problems is you have some shared culture and you have some shared goals and some shared culture and [00:27:00] some shared values that allow you to actually solve those problems.

You know, one of the things that was pretty core at, at Etsy, for example, is it was a fair fundamental skepticism about technology. You know, we built sort of one of the hot shot, fast growing. You know, tech companies in New York, so you know, small pond comparatively, especially at the time by being like, look it, we're gonna take great engineers and break their spirit by making them write PHP, where elegance just like isn't an option. And you know, when you come with a brand new technology, the stance is, I have this crazy idea, talk me out of it. that's not a culture that's appropriate for every company. That was a culture that was appropriate for that, that company, that team sort of very like a customer focus, human centered. You know, right now the current team I have is really focused on winning through product quality and winning through product quality in these days in the web actually requires being very in tune with the cutting edge, very deep into like what is landing in the chromium repo.

It's a totally different orientation to [00:28:00] technology, but you know, we, we are starting to build some of those same shared values where teams can, can resolve the conflict. So, Short answer. People should want to talk to each other, but shouldn't have to coordinate with each other. And one of the places where we see this really becoming a problem right now, and I think this is downstream of us all having so much success using Amazon, is that we really see the rise again of internal platforms and teams taking dependencies on, on these internal platforms.

I think we've just fundamentally underestimated how hard it is to build these internal platforms, and we're gonna see another wave of sort of disappointing outcomes, that we're, we're not prepared for because we were all like, Hey, this was, this was great and this was easy, and it's not.

Brett Berson: So in the case of improving coordination through this idea of shared values is kind of one of the tenets of, of improving coordination. What do you mean by that? What does like the before and after look like?

Kellan Elliott-McCrea: Again, this is gonna feel simplistic and that is unfortunately one of the [00:29:00] reoccurring elements of this work just 'cause you know, the answer is it doesn't get that much easier. And so the standard problem that you see over and over again, and this got worse during the pandemic, and distributed teams who don't see each other in person, it's really common to go and ask a team what's going on.

And they're like, I don't know what's going on with that team over there. And you're like, there's 20 people in this engineering organization. How do you not know? But like, strike that. I'm not gonna ask you how you don't know. That's, that's a judgmental counterfactual. I'm just gonna ask you what's stopping you from asking them and we can dig into what's stopping you from asking.

So like that's what you see. It's a fundamental is is skepticism about they're like me, they share my values, they're here for the same reasons I'm here for. There's some concrete things that you'll see sort of spontaneously. Emerging groups of senior engineers across technology disciplines is one of those things that you see when the values are starting to be well aligned.

Sometimes you just force them into a, into a meeting room periodically and there's nothing quite as satisfying as [00:30:00] as forcing engineers to sit around staring at each other and you're like, right, if you were gonna coordinate and run meetings, you would've gone into management. So it's not the best use of your time.

But spontaneously, people sort of building, you know, different sort of working groups and other things across disciplines is one of those things that you're like, oh, the values are aligned here. , but also just like fundamentally like, Shared talking points, shared understanding, a lot of empathy for other teams.

All of those things suggest that we're actually building on a shared set of culture or values.

Brett Berson: Can you potentially bring it to life by explaining what shared values looked like in the context of maybe Dropbox? and what does shared values look like in the context of Frame? 

Kellan Elliott-McCrea: Yeah. So I can talk about in Dropbox,, a, a shared value and a value that wasn't shared. So in Dropbox, there were a couple of shared engineering values. I mean, there's sort of the, the values that Dropbox talks about, but like the engineering culture at Dropbox is one fundamentally built around scale, you know, and, and being at a, a really large scale with a relatively small [00:31:00] team.

And, trust and privacy like Dropbox, like takes data retention and data privacy incredibly seriously. And you never speculate about some other team's doing this. Like there's no other team that's gonna be like, sneaking looks at the data or, you know, doing a creep, creepily trained AI model, or it, it just doesn't come up.

You never ask, is this person doing this for, for sort of, Reasons that aren't aligned with that values around trust and privacy. A value that wasn't shared at all was the idea that you could build products and that would change the direction of the company. You know, Dropbox had built one product once.

It had been very successful. It had gotten more successful by keeping that product, scaling up with demand, and there was a real skepticism that a second product could ever emerge from the company. When you showed up and said, Hey, I'm gonna build something new. They're like, you're just trying to build an empire, aren't you?

Which didn't come up at all when you said, Hey, I need to access this data. They're like, okay, you and I have a shared value around trust and privacy. I can work with you on this. [00:32:00] You know, at Frame, I, I'm still new, you know, and, and Frame is also going through its own cultural transformation having been acquired 18 months ago, but you know, I'd say that, that the shared value is around product quality. The shared value is like you win by building the thing, which is the most beautiful, the most performant, the most delightful. And that's where everybody orients. And then people have different ways of getting there and different sets of trade-offs that they make on that way.

But like those are, those are examples.

Brett Berson: I want to just go down a, a little bit of a left turn here and come back to sort of the thread that we were following. 'cause it's an, it's an area of personal interest, which was the. Sort of non-shared value of basically being a successful multi-product company.

it is generally true that every single large software business has to do this empirically, and very few are able to do it. But if you want to get to a certain size, every single one, and you can acquire your way into it, you can build it from scratch, you can do some hybrid. But if you look at atlassian [00:33:00] Salesforce, I mean, you just go down the list of every single one, what's going on there?

What do you make of that?

Kellan Elliott-McCrea: I mean, I don't know that I have deep insights. But I mean, I think at some fundamental level, first we're talking about an innovator's dilemma, which is you've got a thing that's working and you're asking to spend a bunch of resources on a thing that may not work. And like, that's just, that's just always a hard pitch.

So that's one. And a lot of them do fail. You know, I think a another thing that we see, you would have more data points on this than I do. A thing that we saw in the culture at Dropbox, and it was fascinating that stayed in the culture even as people left, is, you know, Dropbox hit a home run basically out of the gate, and there was kind of an expectation that that's how you built products.

And like people came from different places and very different experiences, but pretty deep in the culture was this idea that you build it. And then, you know, coin a phrase, they come and, and that was, you know, just not a replicable, uh, model. And so the combination of like, it's hard for it to matter. It's a really different experience than the [00:34:00] first time we did it.

There's always more money to be made, you know, in the lemonade stand as it were, than, than in the new product it just goes against kind of all the most basic incentives., You know, and Dropbox. It's not like Dropbox wasn't trying, I mean, we were constantly trying different approaches to build a new product.

Um, but it, it went against a lot of culture and a lot of history and a lot of culture and history and practices and technology that grew up to serve the first product. And so I think that when I look at Adobe versus Dropbox for right now, it's just two points of comparison. Dropbox was a very unified, engineering culture.

Unified practices, unified technology stack, unified hiring, all of those things. And Adobe is not like, it's just a little bit of a wild west in a way that's kind of crazy. , and that's just the history of its, uh, of its acquisitions. They're like, look at, it's a big tent. There are a lot of ways to be successful at Adobe, and that's kind of how we run multi product. Now, I don't know if that's how everybody does it. You know, I haven't really dug deep into Atlassian's multi-product [00:35:00] strategy, for example. It feels like maybe they're somewhere on that spectrum between those two ends.

Brett Berson: One of the things that that comes to mind as you were sort of sharing that is, I think we all like to simplify company building, org building, engineering team building into a set of this is the right way to do it, or this is the wrong way to do it. And the longer I have the opportunity to work in technology, the more I've come around to it might not be that there's right and wrong. But sort of the idea that the most important thing is that everything fits together 

 and that most of the time everything needs to be in service of the system, but there's not necessarily a right way to set up a go-to market org or a right way to do pricing and packaging or.

It, it all has to fit together and that's why Adobe and Salesforce are both successful companies. My sense is the systems are very different. Atlassian and Salesforce are successful companies. The systems are different. Anything come to mind now that you've had the [00:36:00] chance to work in multiple successful systems?

Kellan Elliott-McCrea: I mean, I think it's true. And I think it's also one of the things that makes it, again, challenging to replicate advice. Because it is about the system. It's sort of going back to the idea of the team is the unit of health, the system is the unit of, of advice in some ways. You know, I think that there are things that you can do to be better or worse at reasoning about systems and talking about systems and talking about breakdowns in systems.

that can actually transfer. You know, I think that, again, going back to communication. You know, really taking sort of, principled approaches to communication can really help you reason about those systems, especially when you get surprised by them. And so I think that that's pretty key. but yeah, I do think that there are a lot of different ways to, to do this.

And I think that's actually one of the things that makes software particularly hard is the space of possible ways is so large. There are a bunch of right answers or a bunch of answers, which are good enough. it [00:37:00] was actually kind of one of the things I think that was, you know, it was almost an existential angst for, I think, experienced engineering leaders during, you know, 2010 to 2020 where you sort of looked around and you looked at success and you're like, success is not correlating.

Teams that I feel are well run from an engineering leader standpoint, what exactly am I doing here? , and I think that that's fine. You know, I think that one of the things we've realized is there are actually multiple paths to success and multiple high quality ways to run a team. And that also that some companies path to success doesn't actually run through a high quality engineering org, and that's also okay.

It is one of the things that I think I am cautiously optimistic about at the moment is the idea that that actually. There may be more need for high quality leadership, uh, in this particular moment. But yeah, I absolutely agree with that, that it is about the pieces holding together and it's one of the reasons that we, we find it so hard to move.

I think the canonical example of this is Google, by the way. I mean, I think that sort of in industry now, we've kind of learned you hire people outta Google and they show up and they don't know how to operate. ' cause they've been[00:38:00] such a determined, high functioning thing where all of the tools were in place and they had a very narrow role.

and that's a great example of a system that is very effective and very unique and hasn't really replicated

Brett Berson: yeah. I'd also argue that a lot of people trying to model their orgs and culture after Google has probably created more damage to our ecosystem than, than sort of positive outcomes.

Kellan Elliott-McCrea: I think that that's probably true. Yeah. certainly certainly in the scale chasing aspects of it and some of the other pieces as well.

Brett Berson: yeah, again, like you look at a simple thing, and this is the a really stupid example from forever ago, but the way that they had all of these perks, there, there were a bunch of companies that did this, but they took it to a new level and again, If you understand their system, you understand how that works really elegantly in the system.

If you don't, you start to do all these perks at your company and, and it doesn't have the desired impact because you don't have the cash geyser that Google has and all sorts of other things. But I I, I'm really interested sort of your idea about these [00:39:00] separate systems.

How does that influence the way you approach coming into a new company, a new system?

Kellan Elliott-McCrea: there's an interesting tension coming into a new company because on one hand you want to be respectful of what's currently working. You want to not mess it up. , you want to go on a listening tour , there's always things that are broken and people are nervous that you're gonna think they're morons rather than just like, yeah, it was hard and you did what you needed to do to get to, to now.

 But there's always a lot of fear around that when you come into new organizations that you're gonna judge them by the current state rather than the state they wish it was. On the flip side, there's sort of this interesting window where you get about six months, And then it's your fault. I mean, that's my standard deal with anyone's senior is you get about six months and then it's your fault.

And that's just as true when you're coming in. And it is easier to change some things when you're not, when you're not implicated in it. and so, you know, I'm always trying to find the balance on that. And again, it helps that we see these reoccurring issues with pretty much every engineering org [00:40:00] ever.

Where they're struggling from a lack of clarity. They're struggling from an underinvestment in developer experience. You know, there's, there's sort of these other challenges , where you can sort of reuse some of the tricks in the trade to, uh, kind of rebuild those while you're thinking about how the larger system works.

But absolutely, you should expect to need different practices. Different leaders, like different things in different organizations. You know, one of the things that people ask me is, you look like you've worked with a bunch of great people. Like, do you just like bring them with you to every organization?

And, and the answer is of course not. Like every organization is different. And partially I need the people who grew up in this organization to translate it for me, but also like a lot of those people would fucking hate this system right now. Maybe someday we'll be in the system they would like, but. It's not the same set of people, gonna be successful in different systems.

And so, you know, some of the things you want to change about the system and some of the things are constant, like the need for clarity. But, uh, a lot of them are, are very different. And so that, that does shape a lot of [00:41:00] how I think about coming into a, a role. And I'll just say that probably the other piece of this is,

I mean, you're speaking my language. I am a systems thinker. That is my approach. There is a a equally valid approach, which used to be a details first person, and to sort of say, look it. I'm gonna find the one thing that we are doing here, which is just crazy, and I'm gonna fix that. And that's gonna be a symbolic of a culture and people are gonna see that change.

I'm gonna fix another one. And, and that's another way to create change. It's not my way to create change. And I think the systems approach is more common in leadership, but they're, they're both equally valid approaches.

Brett Berson: So what do you make of, of your ability to. To operate in the different systems relative to the point that you made about, there's a bunch of amazing people that I've worked with that I wouldn't bring to this system, but it seems like there's enough malleability in you or, or how you think about your job getting engineering teams that works in some way.

Kellan Elliott-McCrea: I think there's a few different things. I mean, one, is just me. Two, I have a couple of things I'm trying [00:42:00] to do in any org that I find that I can do in, in almost any org. Not any org. You know, I did a start up in between, Etsy and Dropbox. and you know, I found there was a set of values I couldn't actually be successful in, and I, and I left.

but in most orgs, my, my needs are pretty basic. You know, I'm. Trying to increase the capacity of the engineering work. You know, I want this as an organization to be a place where people are growing and learning, and we are better at building software than we were last week and last month and last year.

And that's a thing that you can kind of do most places. And I get a lot of satisfaction out of that. So I think maybe I just have pretty basic needs. And the other thing is I wanna feel like we're winning. And I feel like that's a, you know, both of those needs are pretty basic and pretty solvable most places.

And so I don't know that anyone else can generalize that. But for me, that I, I find that I can get the needs that I have outta the organization met and, and therefore I can meet other people's needs.

Brett Berson: So on the point about growing the capacity at the engineering organization, I think we've touched on a number of, inputs to doing that, creating clarity, coordination, number of other [00:43:00] things. What haven't we touched on that if I were to watch you work. Is part of your set of tools or the ingredients that grows the capacity of an engineering team?

Kellan Elliott-McCrea: Yeah, I mean, uh, the, the thing that you would probably, that we haven't touched on, that you would notice almost immediately how I work is I invest a huge amount of time into, making sure that people, you know, have information. So that's the clarity, but at all the different levels. So I meet with ICs, I meet with, you know, managers.

I meet with sales, I meet with marketing , I'm trying to create really high bandwidth exchanges there. So like that is just a thing about how I work, because I'm trying to build a, a shared worldview and a shared set of language and vocabulary. And then the others, I just do a ton of coaching again, in all of those communications, not just with my managers.

And that coaching really comes in the form of wanting to hear their opinion. Asking them how they developed that opinion, being curious about their opinions and encouraging them to go try it. Some days I feel like I don't really do [00:44:00] anything 'cause I'm just like, oh, what should we do today, Brett? Oh, great.

Go do it. And it's not that simple, you know, there is more detail to it, but I fundamentally can't, I mean, like I said, this is a smaller org these days, but even at this scale, like I can't understand everything that's going on. you know, I'm simplifying things and creating clarity, partially just for my own limited ability to understand what's going on.

I cannot be smarter than a team of eight, much less a team of a hundred. And so that's pretty fundamental to my practice. Again, it sounds basic, but it's a lot of asking people their opinion and, and leaning into supporting them on that. I find that most people have a lot of context 

and what they're missing is my job to create, which is either the context they don't have or the experience of having tried it.

Brett Berson: Can you talk more about when you use the word coaching, what you mean by it?

Kellan Elliott-McCrea: , so I, I don't mean what you might be taught to do as sort of part of like a formal coaching education, which I feel like the heart of that is not giving people answers. It's asking questions and not giving them answers. So I don't do that. [00:45:00] Get curious is my single most commonly repeated piece of advice to people, but I spend a lot of time being really curious.

And asking people a lot of questions and then asking them how they're going to deal with the problems that they've identified, and then talking about a couple of different approaches that might work and asking them to maybe try it. Like that's, that's the simplicity of the practice. You know, I had an uh, one-on-one with an EM today.

Where they're like, look at, I'm thinking about, assigning ownership areas to everyone on my squad so that, you know, we know how to route bugs. And I'm like, cool, you know, this is a thing that's been tried about a million times before in an engineering org. Some things are gonna work well, some things are not gonna work well, you know, what are you concerned about with doing that?

And what's the problem you're trying to solve? What are you gonna do when JP goes on vacation? You know, it's just that, that's coaching. Um, and I tend to do it both at work and also outside of work. I mean, I do a fair amount of advising and I do coaching when I'm in between gigs and I'd say it's probably just my fundamental professional practice.

What I do is ask people questions.

Brett Berson: When you were talking about just before [00:46:00] this, one of the core tenets is, these conversations that you have to improve communication with all sorts of different folks inside of the org. Is there anything else, you're doing in those conversations other than , your sort of concept of coaching?

Kellan Elliott-McCrea: Yeah, so there's a couple things I'm doing. I mean, one it only works if you're actually genuinely curious. Like, I don't know how to do their jobs. I don't know what their day-to-day job looks like.

So you have to actually be curious. You have to actually wanna learn from them. And then the other piece is, I, I'm doing a lot of explaining what else I've heard. Hey, look at, this is what's going on with engineering. This is what's going on with sales right now. This is what's going on with support. So some of that synthesis is just happening as you wander around, but absolutely there's a couple of other ways the synthesis manifests.

 And partially people are watching the way you communicate after you've talked to them to see if you were listening. So in leadership forums, in all hands in written communication, oh, I should probably say that's the other thing is I do a ton of written communication. I've got an end of the week [00:47:00] status update that I used to do an email and now I do a slack and all this other stuff.

And so in your public communications, people are looking to see if you adopted their language, their ideas. That's sort stuff 'cause that's how you build trust. You actually were listening. You trusted, you updated your ideas, you incorporated the information I gave you, and that, that, that is part of the synthesis work that people are looking for.

Not everybody knows that, that that conversation came from this person, but the person who I had the conversation with knows where that came from and is looking for it. And sometimes you're calling them out explicitly to give credit and to elevate profiles. And then the other piece of synthesis you're doing is you're saying, Hey, you know, You and you have similar problems and are approaching it different ways.

So you should talk, because again, one of the things we're trying to do is we're trying to solve the problems horizontally rather than having them come up vertically. ' cause if everything comes up vertically, that's where we start to get into that geometric product around communication, coordination, challenges, where people can solve it one off our, our network actually gets smaller. So that's a little bit of it, but I'd say probably the most important. [00:48:00] Just thinking about this, and I've never, I've never ranked them before, but based on your question, the most important is that people actually see that you listened in other forums.

Brett Berson: Any thoughts on how you approach disagreeing with people?

Kellan Elliott-McCrea: One of the things about my practice that is very different than when I started is I'm a lot more detached than I used to be. And I think that that's a survival skill. , I disagree with people about things all the time. that's okay.

there are only a few things that are really important for me to go push them on. And so I'll push once, maybe I'll push twice, but if it's, if it's their thing, that's fine. Um,, if it's important. And you know, the things I find are important, the things where I end up getting into it with people is about things like motivations or, or statements around values.

That team is lazy. These people are doing this 'cause they don't care. You know, any of that sort of stuff. Like that's the stuff where I'm gonna go to the mat ' cause that's the stuff that actually shuts down that communication we're trying to create. You wanna talk about what the pricing change is? I'm gonna tell you a little bit about the experiences I've had in the past. It's this [00:49:00] one-way door, two-way door to bring in a cliche. Then, then we'll go through it and I'm okay with losing those, those arguments as it were. And I actually do think that a certain amount of detachment, is actually pretty critical as you become a senior leader and the people who don't learn that detachment are the ones who either fry or or end up trying to micromanage a system that's too complex for them to understand.

Brett Berson: How does that fit together with caring is detachment the opposite of caring or it sits alongside it in some way? the best way to care is through detachment?

Kellan Elliott-McCrea: I don't know if I'm that zen or Buddhist yet to have seen the best way to care is through detachment. I think caring is an action, and detachment is a, is a feeling. Caring is what I'm doing. Detaching is, you know what I'm taking on again. Maybe, maybe that is getting a little zen there. But people have to know you care about them. I mean, that, that's just, that's just fundamentally your job as an engineering leader. That's how you get great teams, is that they believe you care about them, and the only way to do that is to actually care about them.

Brett Berson: Yeah, no one ever said, I dislike my manager. They care too much about me.

Kellan Elliott-McCrea: [00:50:00] No one's ever said it, but boy, is it true. This is actually probably worth calling out. One of the other things that has changed over the last 10 to 15 years is we saw a rise of things like servant leadership and managers who were just focused on making their teams happy. And that's not the job either.

you know, I, uh, I was, I was writing this blog series that I think, you know, we sort of touched on briefly, , and I was gonna write the fourth entry and I kind of didn't wanna write it 'cause it's about labor relations and that felt like a difficult year for labor relations. Like one of the pieces in there is like doing hard things is uncomfortable, and we are in the business of doing hard things and they will be uncomfortable to do that.

And one of the things that we lost over the last 10 years and some of the engineering practices and some of the, what we expected as managers is the idea that this work can be uncomfortable. It can be uncomfortable, we wanna do hard things. And so there is a balance. You can care about people, but. There actually are lots of people whose managers care about them too much.

Actually, one of the, the early [00:51:00] stereotypes about engineering managers in our industry is as the shit umbrella. You know, just gonna keep people from being distracted by all the crazy. And what that is, is those teams end up just drifting off. You know, you talk about like, Coordination and alignment and shared values and cultures.

If people are never getting the feedback about what's actually important as a company and what we're all the rest of us are talking about, they end up misaligned. You know, those managers are actually under optimizing their teams and their effectiveness because they're caring about them or rather taking care of them too much.

Brett Berson:  this sort of nicely dovetails with one of the things I wanted to come back to, which at the very beginning of our conversation, One of the things you mentioned is sort of this idea on high quality management as being a primary focus of yours. And maybe in the context of what you just shared, what is your view on what high quality management or engineering management actually is?

Kellan Elliott-McCrea: Yeah, I don't know that it's a soundbite. I mean, I think it's a set of skills that people practice and work on and get better at. there's a set of ways you evaluate it and at the most [00:52:00] basic level, you're evaluating a manager based on the output of their team and their team health and the team health you know, you can look at things like, you know, retention, the repeatability of the outcome. You know, there's a, there's a few other things that you can look at there in terms of the, the health, but really it's just outcome and repeatability of the outcome and everything else ends up being a secondary metric so that's the most fundamental way that you're measuring a manager, you know, high quality management is creating the conditions for that. I think I said earlier, you know, I, I don't actually think the conditions have changed.

You know, it is really small teams with lots of trust and lots of autonomy that tend to build software. You know, this is what's sort of found in the, the Google psychological safety work and, and just kind of, Two pizza teams. Like we keep coming back to this as an industry.

And so then, you know, the manager's job is to create those conditions, you know, and that's the manager's job. And then we start talking about managers and directors and the work gets a little bit more complicated, but high quality management are people who have the skills to do that and have the experience to do that. So that's not a [00:53:00] satisfying sound bite. I'm sorry.

Brett Berson: so a second ago you talked about output of the team and team health, and then you said there's some other stuff. I, I wanna, I have a couple other questions that just came to mind, but what's the other stuff?

Kellan Elliott-McCrea: yeah. Okay. So the fundamental measurements are, are output and the repeatability of the output. 'cause anyone can get output once. And so, you know, you're measuring the team's ability to consistently deliver. But there are a few other things, which is their ability to hire a diverse group of people.

That is one of our cultural indicators about whether or not the team is, is healthy and their ability to interface with other teams within the organization. And so one of the ways that you see teams create output and even reproducible output is to create strong us versus them. One of the easiest hacks for creating strong identity as a team is to put the team in a combative situation.

And so that's, that's really your other, your other health metric is, you know, is this team being led in such a way that they're getting output, they're getting repeatable output, and they're doing it in a way that doesn't create hostility with the rest of the organization or hostility with whoever the out members of the organization are.

Brett Berson: In your mind, [00:54:00] is output the same as as results or different?

Kellan Elliott-McCrea: Uh, sorry. Yes. Outcomes are generally the things that you should, you should care about. Output is very uninteresting. Results are absolutely what is interesting, and that's really important because, you know, it's not a production line, , it is R&D, at some fundamental level, and so the path to results is non-linear.

Showing up and writing. Writing, uh, a hundred lines of code every day does not get you a product. There's no amount of doing that that will get you a product.

Brett Berson: So if great management is creating the conditions for these things are there things we haven't yet touched on? When you think about the actions that a great manager tends to take to create these conditions? 

Kellan Elliott-McCrea: The other piece that we've only touched on briefly when you're thinking about how do you create these conditions is, You were creating the space for growth, which again is a little bit of a cliche, and so what growth means for each person is, is a little bit different, but sort of fundamentally you are celebrating people's.

Growing, developing new skills, [00:55:00] and then as they get a little bit more senior, passing those skills on to other people becomes kind of a core way you evaluate people in their roles. I think that you are creating space for the job to be fun. This is a fundamentally fun job. We do look at, it's gonna be uncomfortable at times as well, but you know, writing software's fun. , like, this is a great job, and like if people are hating it, you're failing on multiple levels. And so there, I mean, there's, there's a bunch of stuff there.

but fundamentally as a senior leader, you know, the, the outcomes, the results are, are the non-negotiables. And I think that, you know, That's gotten harder as I think building new businesses has gotten harder, even while software has gotten easier.

Brett Berson: Can you talk a little bit more about capacity building?

Kellan Elliott-McCrea: Sure. I mean, you know, you think about the capacity of your organization to produce a thing, to have a, have a result, and so what are the ways that you increase capacity, you increase the skills of the people. , you improve the system under which they operate. So the tools and practices they operate, you grow the team, and those are kind of your [00:56:00] tools.

Like those are kind of your levers. And so you can either skill up the individuals, you can improve the environment in which they're operating, or you can hire additional people and that's how you grow capacity. And ideally you're doing. Some mix of all of those and different parts of your organization probably need different ones.

But you know, at the end of the day, you have an organization which is highly effective. And then for me, now that I've been doing this now, I mean my first engineering management job was almost 25 years ago. I kind of think of myself as like increasing the capacity for the industry. 

Brett Berson: Why didn't you say replacing people as a way to grow capacity?

Kellan Elliott-McCrea: Probably didn't think about it. Um, generally, I think that replacing people, I mean, replacing people or not replacing people, You know, one of the fundamental lessons you learn in management pretty early on is, uh, you almost never regret letting somebody go. It was always, always too late. , but it, it generally tends to be, I, I don't know, I guess I don't have a systemic way of approaching it, you know, if I had, uh, so there's my systems brain kicking in, you know, there are some ways to make sure that you're having [00:57:00] performance conversations.

But, you know, I'm not doing a sort of a, a, a, a stack rank and cutting the bottom 10% ever. ' cause I think it has other problems with the, the culture that it creates. And so, particularly that's probably why I wasn't saying, uh, the replacing is it's more of an individual process, less of a systemic one.

Brett Berson: If it didn't have the, the cultural issues, do you think it 

would be an effective systems level concept or it's still flawed.

Kellan Elliott-McCrea: Here's the piece, and I think it would be tricky to do. One of my fundamental beliefs around talent is that everybody is going to be successful at every company for a given individual we can evaluate, can we make the company someplace where they can be successful? Can they become someone who can be successful at our company or should we part ways?

And I think that that framing. A) makes it a lot easier for managers to have performance conversations. 'cause now it's not about a moral failing where you failed to be good. It's just like, I can't make this company a place where you're gonna be successful. And I don't think you can make [00:58:00] yourself a place that can be successful at this weird, unique, one-off system that we've created here.

And so I think if you could somehow be evaluating that and having. Those conversations, and I think probably the closest thing we've ever seen to companies doing this systemically is probably like Zappos with the, I'll pay you to quit style stuff. Um, I have never run a process like that. partially because I find that a lot of people can be successful in a lot of places.

I'm not the only person who is malleable in what they're looking for and what they're excited about, and that hiring is expensive. I mean, people say, you know, bad hiring is expensive. Hiring is expensive, and I think that a lot of people can be very successful and that as you grow and mature as an organization, expanding the window of who can be successful in your company is one of your maturity capabilities.

And so, you know, as a startup, I think you need to be. Very persnickety about how much energy you're spending making this work for everybody involved. ' cause you have very limited capital [00:59:00] and very limited time. But in a maturing organization, I think a wide variety of people should be able to be successful.

And so maybe that's the other reason you know, you have to cut your losses. Not everybody's gonna succeed, but it does fundamentally represent a failure as the organization to have adapted. And I think that, you know, in practice, the way you view that, Is the more junior somebody is, the more it's your responsibility to make it work for them.

And the more senior they are, the more it is their responsibility to figure out how to adapt and to to identify that they're in the wrong place. And so that's a little bit of how I think about it.

Brett Berson: Yeah, it, it seems hard to be in equilibrium. I think I've noticed in small companies, there's probably, on average the company's trying to overly contort itself. To either create opportunities for the person or to change in some way, as opposed to being very clear, as you were saying at the very beginning and then saying, is this a system for you or not?

Is this a role for you or not? And you know, somebody wants to do X, , we have a specific thing we need to do here [01:00:00] and we need somebody to do it.

Um, 

Kellan Elliott-McCrea: And we may need X someday, but that's not today. We need Y today. Yeah. I said a lot. And again, I feel like people don't have those conversations. ' cause they're avoiding the confrontation and because it comes with a, a moral judgment. And once you simply say it's not a moral judgment or if it is moral judgment, you know, I'll take that on.

I failed to create the system where you can be successful. But let's be clear, you can't be successful.

Brett Berson: so a, a couple minutes ago you mentioned sort of in, in, in this area of creating conditions that enabled the team to deliver on, on results. There were some different tactics that came to mind. I'm curious, what are some of the tactics or rituals or things that you've seen tend to be quite useful in this area?

Kellan Elliott-McCrea: , the first is getting obsessed with the business outcomes, with the product outcomes and the customers. You know, that's, that's really key. And so you start to build literacy around that, and there's a variety of ways you build literacy around that. But you make that a, a core touch point constantly.

And, you know, that doesn't sound like an engineering thing, but we as engineers tend to be a little cynical, [01:01:00] and so the way you build that literacy looks a little different. And the second is teaching people to reason about the business. So you know, if you're really understanding the business outcomes and the product and the customers.

The next one is to understand the numbers of the business. You know, I think the most common failure I see, Is people failing to teach their engineering teams or their product and engineering teams how to think about the business they are in. You know, what is our path to success? Who are our comparables?

What does success look like? Um, and so, you know, building that literacy is really key. And then the next one is, encouraging people to surprise you and to pleasantly surprise you. You know, it is the whole reason you are hiring large groups of people is because they are better and smarter and can focus on a thing that you can only spend a little bit of time thinking on.

And so you encourage people to surprise you through all the things, including telling people, Hey, I wanna be pleasantly surprised. Creating opportunities for demo, talking in the language of surprise, creating hacks, putting Slack explicitly in the system. So there's a [01:02:00] variety of things there. After that, you're really asking people to like focus on their core goal, really starting to create a culture of the most important thing.

why are you doing the thing you're doing this week? Is it the most important thing? How do you know? Starting to ask those questions. And by this point we're already starting to get pretty far up the Maslow's hierarchy of sort of–, getting close to self-actualization. And then the other piece of this is removing the barriers to rapid change.

You know, this is the place where I feel like the, the literature at least, has really converged even while we've seen the experience move away, you know, the, the, the Dora metrics and, you know, Nicole Ferguson's work and all of this Parkinson's, I never say her last name, right. About, look at like the one secret is

cycle time. and so that's the other piece of this is, you know, you are creating in people, the desire, the conditions, the information, and the permission. And then you need to make sure that the system doesn't resist it. So you can deploy easily, you know, you know, if your deploys were successful. It is easy to make a [01:03:00] small change it is linear on how hard it is to make a small change versus a large change.

You know, all of those things, you, you don't have gatekeeping.

Brett Berson: Can you explain more about how you build literacy? You kind of gave, gave a a few little anecdotes, but. If somebody's trying to build business literacy within their org, what do they actually go about doing? Or how do they go about doing that?

Kellan Elliott-McCrea: Yeah, there's a few different things. First you don't lock it away, like that's the first step is like, so often you see people have locked this entirely down and that people can't build the literacy because one of the tools that people have around literacy is look some people wanna be taught and some people want to go out and explore and teach themselves.

And guess what, most engineers fall in that second bucket. So making sure the autodidacts have the tools necessary to, to answer their questions So that's first. You know, one of my favorite tactics, one of my favorite icebreakers, that I use in a lot of meetings is bring a graph to the next meeting. I don't care what graph, just bring a graph.

You know, there's a few things that you [01:04:00] get outta that people learn how to use the data we have available and you start to learn about the systems and you start to learn about all the different systems. because data is a mess, literally everywhere. And so, like, that's a really simple tactic. And then you also go over the core numbers and the core basics of the business.

, at every, at every opportunity. You know, go over how the business is doing at the all hands. Like that should be a core piece of it. And so there's a few different things like that. I. Then the last one is, is just that, it's just teaching classes. It can be brown bags, it can be people coming into your staff meetings.

It can be, you know, an after school, as it were, you know, class that we teach, uh, in the afternoons about, you know, statistical relevance. Like, it kind of depends on what's relevant for your organization. You know, at Etsy it was about understanding experimentation beyond just AB like, We were a very experiment heavy company, but we did a lot of bad experiments because our statistical understanding was poor.

Um, at Dropbox, Dropbox didn't ever care, talk about money. And so understanding like, let's go with the basic [01:05:00] unit economics. How much does a gigabyte of storage cost? I'm not gonna answer that question because that's you know, a secret for Dropbox and it's one of their core values. But every engineer at Dropbox should know the answer to that question.

And so just starting to build up kind of some of those basics. and you know, I think , we just asked questions like that at the start of a, a series of meetings. Like who knows, you know, doing a little bit of trivia games and some of that other stuff. It's also a great way, I mean, I was coming into a company at that point that was 14, 15 years old and I had to learn the business.

And so having some of those questions and some of that play be a way that I learned the business.

Brett Berson: An interesting place to end would be, I'm really curious, given what you shared in our conversation, what are the things that have influenced your thinking on these topics the most? And maybe that are potentially unrelated to engineering management, if there are specific things that you found a lot of inspiration in.

Kellan Elliott-McCrea: I mean, I would say that the first inspiration is not engineering management, but just software engineering, you know, and just going [01:06:00] back to. That feeling of being a software engineer at the start of my career and what it felt like and the agency that came with that work. 'cause you know, I was doing it at a time when the web was brand new and I was dropping outta college to do my own startup and just the discovery and joy and fun of that work.

And so that, that, that is a, that is a bedrock is, is that experience of what this can be like at a very different time and phase and maturity of the organization. The other piece, uh, you know, part of my secret weapon is both my parents manage, you know, both my parents are executive directors of nonprofits and seeing the way they worked and the way they worked with volunteers and the way they worked with boards and, you know, talking about that with them over the years is just, I think, brought a set of management practices from a industry that's been around longer.

And has a different set of challenges and constraints. But I will say, particularly when the, when the industry is on an upswing, there is something similar to [01:07:00] managing volunteers and managing engineers, even though you're paying the engineers a lot of money to do it. , Um, so that was pretty key. And you know, 

I think that the, the other piece is just, Being in a community of engineering leaders for a long time now, and just a lot of different inputs, you know, everybody is, is trying to get better. And so some days it's a psychological paper and other days it is a management technique and other days, you know, it's just a lot of those inputs. 

Brett Berson: Are there specific engineering leaders that you've come up with that have had an outsized impact on how you think about this stuff and 

kind of any little anecdotes or stories that they shared with you that, that you've hung onto? I.

Kellan Elliott-McCrea: sure. You know, I'd say that you know and, and I haven't talked recently, but there was about 10 years there when john Allspaw 

and I were working together first at Flickr and then at Etsy. A lot of the work that he did around popularizing ideas like, you know, blameless postmortems, human systems, all of that was, was pretty key.

You know, we are at the, uh, the one year anniversary of Richard Cook dying, and so I would just say [01:08:00] everybody should go read how complex systems fail as sort of a a way to celebrate that. And so that was pretty key. , you know, camille Fournier was another person, who, you know, was part of my sort of monthly dinner club when we were all getting started as CTOs and then she left her job at the same time I left my job.

Our kids were similar ages. We taught engineering leadership classes together. You know, she's, uh, comes from a much stronger technical background than I do. You know, I'm a startup hacker and she's got a degree in this shit. And so that was a useful tension as well as we thought about system designs and how, how things work.

And I would say that, you know, my idea that this is both , a human-centric job and a technology-centric job is something that really got clarified when we were co co-teaching engineering leadership courses. , You know, there were, a couple of people in Learning and Development, both at Etsy and at Dropbox, who, who really pushed, I think my level of tolerance and, and interest in kind of group dynamic theory.

You know, I just find it is a thing that was, it was very hard to take on as a, as a young engineer and young [01:09:00] engineering manager. And I've come to accept that psychology has actually figured out a few things. So Paloma, who ran LND at Etsy, and I'm Reese, uh, running LND work at at Dropbox. Um, I can't remember either of their last names right now, which I feel terrible about. Um, you know, those were a few of the few of the key folks over the years.

Brett Berson: Great place to end. Thank you so much for spending the time with us.

Kellan Elliott-McCrea: Thank you so much. This was fun.