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

 [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?

 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.

 . 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.

 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. 

 my first job involved actually racking the hardware and building it out of OEM parts. 

 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?

 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.

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

 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.

 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. 

 I gotta, I gotta ask you, so if engineers in between, what do you see at the ends of the spectrums? 

 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?

 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. 

 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. 

 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?

 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. 

 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. 

 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.

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

 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. 

 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?

 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. 

 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

 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 

 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?

 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. 

 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?

 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. 

 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? 

 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. 

 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.

 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. 

 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?

 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.

 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?

 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.

 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? 

 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.

 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?

 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.

5f822a83f7c537cf0d9b06a0

Kellan Elliott-McCrea is a Head of Engineering at Adobe. He discusses how software engineering has changed in the last 10-15 years, the importance of alignment and tactics for achieving it, how to think about and enable engineering productivity, and lessons on culture from Adobe, Dropbox and Flickr.