2-03 Org Design Kevin: [00:00:00] Hello everybody and welcome back to the It Depends Lessons in Technology Leadership podcast. I, as always, am your host Kevin Goldsmith, and I am absolutely delighted to be back. I've been really excited about the episodes that I've been doing since coming back from that summer break. It's really nice to talk about new topics and not just the topics from the book. And I really appreciate the suggestions that I've been receiving from all of you of topics you'd like me to cover. Today's podcast is, from a suggestion that Yulian, on LinkedIn made , I didn't ask his permission, so I'm not gonna include his last name, but, he suggested I talk about Conway's Law. For those of you who don't know, which would be most of you, I have given a talk about Conway's Law. Called organization and architecture for many years and at many conferences in the US and in Europe. Last week, I [00:01:00] revisited an old talk and sort of updated it. I didn't want to do that again. I also think that talk is still just fine. I would give it again tomorrow if somebody asked. , So I didn't wanna just redo that talk. But I did wanna talk a little bit about the larger topic, which is organizational design. Because if you are in my role as a senior engineering manager, senior engineering leader, this is part of the tools that are available to you and they're important tools. And if you listen to the last episode, which I hope you did in that episode, I talk about how your company's values. Create your culture and from your culture comes everything else. And one of those things that is everything else, our artifacts, processes, things like that. Your organizational structure is an artifact and to an extent, it also reinforces processes by its very nature. [00:02:00] So just like in the last episode, I talked a lot about how career ladders were very much influenced by your culture and should be organizational structure absolutely will reinforce or conflict with the culture you're trying to build in your organization. Now, I understand that a lot of you might be leads or engineering managers, or you're managing one team and you don't necessarily have a lot of direct ability to change organizational structures, but you might have an opportunity to participate in a organizational kind of rethink. From your leader, and hopefully as you advance in your career, you'll get an opportunity and it's worth having understanding of, and also having thought about as you continue to build your skills as a more and more senior engineering manager. So that's what we're talking about today is organizational structure. Now, most [00:03:00] engineering leaders inherit structures rather than design them. I have only a couple times been at a super early stage or been a co-founder of a startup where we are designing an organizational structure from scratch. But of course, in those situations it's, there's not a lot of organizational structure when you're a very small team. More often. In fact, most of the time. I am inheriting an organizational structure that had somewhere between zero. And in the case of like Spotify, a tremendous amount of thought put into it. So you inherit almost always as a manager or more senior leader, you inherit an organizational structure, but that structure dictates how communication, accountability and technical things I mentioned Conway's law it dictates those outcomes. I also think a lot of engineering leaders and HR leaders as well, and [00:04:00] CEOs don't think about this in that way of it being a way to reinforce culture. Instead, they think about, well. How is the company I was at last, how were they structured? That seems like a reasonable way to do it. It worked fine there. Or more aspirational. How does Amazon structure, we need two pizza teams because that works great for Amazon. Even though, as we talked about in the last episode, different cultures. Do you wanna build more of that culture into your company? Copying those things will create that conflict. Is that really what you want? Because you're not Amazon, and Amazon is, no matter what size your company is, I can promise you it's bigger than yours. You have to think about what is the right thing for your company, not just what am I used to, what have I seen? All those places, how it works. Everybody does command and control hierarchies. Old industrial style things. Managers, managing managers, managing [00:05:00] managers, functional teams, whatever. It's just easy 'cause everyone else does it. So you just do it. That's not the best way to do it. And that's what we'll talk about today. I'm just gonna try and give you some tools, some hands on way to spot issues in your organizational structure. We're not just gonna talk about theory, we're gonna talk about some practical stuff as well. So let's say we're gonna start from the position that something's not working in your organization. Because that's a reason why you would restructure. You don't restructure just to restructure. 'cause there's a lot of work that's involved, there's a lot of pain that's involved for the teams. You need to restructure your organization when you have a problem and it's a problem that is manifested by your current team structure. When you've made that decision, our current org structure isn't working. And I'm gonna talk in a little bit about ways to figure that out. What are the problems with our organizational structure? [00:06:00] What are our goals? What's the entire point of doing a reorg? We always want clear ownership and accountability. Lack of clear ownership creates a lot of friction between teams, fighting between teams. And sometimes maybe that's what you want, but you have to choose it. You don't want to inherit or just back into it. A good organizational design would include communication bandwidth, high communication bandwidth, where needed. The closer teams are together in the organization, the more interaction they're gonna have. This is a central tenet of Conway's law. Understanding where you want those high bandwidth communication and low bandwidth communication. The distance between two teams in this organizational design will influence the communication bandwidth. How much coordination overhead do you require or do you need in high governance kinds of situations or industries you may [00:07:00] actually want a lot of coordination and a lot of oversight. You may, I personally don't like having lots of coordination, having worked a lot in very command and control things which required tons of coordination between teams. To me that was always a massive bottleneck, massive slowdown in our systems. So I always try and avoid that. But I haven't been in government, I've been in FinTech, but I haven't been at like a bank or something like that. So maybe that is appropriate. But again, you want it to be a choice, not just something you don't think about and you end up with, and you want space in your organizational design for autonomy and focus in your teams. Especially if you're a scaling organization, the more coordination, the more kind of back and forth you have to do with teams or leaders have to do across the teams, the slower you [00:08:00] get. That's how big organizations get slow. The way to avoid that is build more autonomy into your teams. There is no one perfect organizational design just like, there's no one perfect career ladder, it's gotta match your company. It's gotta match your company's values. It's gotta be fit for purpose, and it's gonna depend very much on size and maturity and priorities. And by the way, if your company's changing size, that means it will change and it should, it shouldn't be fixed forever. You have to keep that in mind and. You might think you can optimize the heck outta your organization. Good design aligns incentives, goals and interfaces. You want alignment over optimization. So these are things to think about as you're thinking about how do I design my organization? I'm gonna talk about team topologies in a bit. I also wanna reflect on a book that was exceptionally influential to [00:09:00] me, Frederick Laloux's reinventing organizations. That is what I might call sort of advanced organizational design because really it's mixing organizational design and advocating for building an exceptionally dynamic and self-governing organizations and highly autonomous organizations. It's a good book to be influenced by and to use. It puts together different levels of organizational maturity. I would say a lot of tech. We would be what Lou might call, I think an orange or a green organization. It's very sort of command and control. Green is maybe where you're starting to build autonomy into the organizational structure. Depending on where you are, you might be in that orange or maybe a little bit green in, in tech. But what he's advocating for is very much an emerging teal or teal organization. And teal organizations start to approach, if you heard about [00:10:00] Holacracy as an organizational model where you have these kind of little circles and teams working together, and forming and reforming and people having a lot of autonomy within their organization. Think also Valve, as a company approaching something more like that. Not a lot of companies are doing that. Not a lot of companies honestly could, without a lot of culture change. But it's worth thinking about those things and having those as a reference. So I wanted to give a shout out to that book. Let's get into Conway's Law, conway's Law is something that comes from Melvin Conway, who is a computer scientist. He wrote an article for Datamation Magazine in 1968, so over 50 years ago now called How Do Committees Invent? And the actual text of Conway's Law is "organizations which design systems are constrained to produce designs, which are copies of the communication structures of these [00:11:00] organizations." Another way of saying this is you ship your org chart or I've also heard it, looking at an application and you can, if you look at the early versions of the Spotify application for example, not current 'cause a lot of work's been done, but the earlier versions you had these autonomous squad models and you could look at the app and see that, that on one screen, different parts of that screen were designed by different teams. We used to call it shipping your organizational underwear. So the sort of meta version of that is any piece of software reflects the organizational structure that produced it. A quote I like is, "if you have four groups working on a compiler, you'll get a four pass compiler" that's from Eric Raymond. That gives you a bit of an idea. Of what Conley's Law, hopefully. From my own experience, it's true. I've seen it repeated over and over again. I, again, I'm not gonna go massively into this 'cause I have on my website, che m goldsmith.com/talks, you can find architecture and organization there. And [00:12:00] there's multiple recordings of me giving that talk, so I'll refer you to that rather than give that whole talk again. But it is important to think about as you're thinking about what organizational structure you're trying to design, for example, the architecture often reflects how the communication happens. So we just talked about sort of high bandwidth and low bandwidth communication within your organizational design teams closer together in the org, high bandwidth teams further apart, reporting up through different management hierarchies, lower bandwidth, for example. Are these low bandwidth organizations, are they gonna build architecture that works very closely together? No, they're not. And sometimes that's exactly what you want. And if you're actually thinking about an architecture you're trying to design, thinking about the organizational structure that would produce that architecture is not a bad way to go. And in fact, there's a name for that, that's called the Inverse Conway Maneuver, [00:13:00] which is, by the way, one of my favorite things to say in all of sort of management. It's fun to say. Your structure should follow your strategy and not the other way around. My favorite examples of this, obviously the Spotify model, which I've talked about a ton on this podcast, and obviously because I lived it, that model, autonomous teams, lots and lots of autonomous teams working independently of each other. That's great for producing microservices architectures, which is what Spotify had. And Spotify was very much influenced by Netflix, who also had a very strong structure like that. And Amazon. Who that two pizza team model is all about. Small teams working independently from each other. Not a ton of coordination, not a ton of synchronization. Another microservice architecture. So if that's something you need or your [00:14:00] platform needs or your product needs, that's a good way to do it, right? That organizational structure will reinforce that architecture, and if you try and build that architecture with a command and control structure or with non cross-functional teams, Amazon, Netflix, Spotify, cross-functional teams, you try and do it with non cross-functional teams, like the teams I led at Adobe, where we were very functionally structured. We could have never built that architecture because there would have been so many problems. Of coordination and all those kinds of things. What did my command and control structure and, and by the way, like I was already thinking about autonomous teams but that was a long time ago, I didn't have that knowledge of what an autonomous team could be like. That was really before that kind of real cross-functional autonomous team model was really kind of well known. I was starting [00:15:00] to approach it because I was seeing the problems of not having it, but I didn't have it. So what did that command and control functionally organized team organization structure produce? A monolith. Which was fine, but. We weren't gonna produce anything other than a monolith because we had one team, owning the backend and the web platform and a bunch of teams doing clients. That organizational structure produced the optimum software architecture that mapped to that organizational structure. Worked okay, but created a lot of struggles around coordination and things like that, which slowed us way down, which is why I was starting to think about how could we break this up a little bit. I didn't solve it. And then Spotify called me and I found out what they were doing. I said, this is what I was hoping to do at some point. I gotta go see how it works in the real world. And so that's one of the reasons why I left to go to [00:16:00] Spotify because I was seeing the problems the way we'd, we were organizing and I was trying to figure out new ways to do it, and Spotify was already way down that road and I had to go see it. So keeping in mind , your software architecture, either that you have or software architecture that you want, the organizational structure that you have, the organizational structure that you want, these things are intimately related. There is a homomorphic mapping that will develop between your organizational structure and your architecture by virtue of the way communication works in your organization. Keep that in mind as you're designing or thinking about how you wanna structure your organization. How do you start thinking about those things? How do you identify these communication challenges? How do you identify what's not working in your organization? The way I like to do this, you've heard also in a prior episode, me talking about systems thinking and understanding systems thinking [00:17:00] and how critical that is for any leader or any manager. It's understanding the system that you're working within. So mapping the current system will help you understand the challenges that you have. I think about it like this when somebody's telling me the teams aren't working well together, or something's much slower than it used to be, or much slower. Then we want it to be, I start telling them, let's track tickets through the system. And so if you think about your epics or your stories in your tracking system, Jira, linear, whatever, how many teams does it touch? How many different functions does it touch? How are those organized? What you'll start to find often is from your source, product management, backlog, whatever, to your sync, which is shipping in the product available to customers. [00:18:00] How many nodes does it go through? Let's say it goes from backlog. So it starts with the product manager. Product manager, designer. Developer tester does it then go to a different team developer? 'cause the first team can't finish the work on their own because they don't own the right systems or whatever. They don't have access to the things they need or they don't have the skill sets within the team. Does it then go to another team and go through product manager, developer, tester? How many teams does it go through? How many different functions does it go through? Are those functions in the same team? Are those functions in different teams? All that kind of stuff. You'll start to map out as you follow work through the system where things are getting blocked and where things are sitting. And sometimes that's a resourcing issue. You just don't have enough capability in the test team or in the development team. Or you're missing a crucial skillset in the development team. And sometimes that can be solved by [00:19:00] staffing and sometimes it's actually an organizational structure problem. So going back to my last organization at Adobe, I mentioned we are functionally structured. We are building a product. That product had mobile web desktop applications going through an API, talking to backend services, running on infrastructure. So for any new feature, that feature would go through four teams minimum before the feature was live. So if you can imagine each of those teams working on two week sprints, team one finishes it, sends it to the next team, they pick it up in their next sprint planning, even if there's high priority, right? They'll pick it up in their next sprint planning, then they'll finish it, they'll hand it off, goes down, goes down, comes back up, back to the clients. That can be three months. To build one feature, a simple feature, but a feature that needs backend support. That was the problem. That [00:20:00] was the thing I was struggling with. The tool I didn't have at that time was to say maybe instead of having these teams be functionally structured instead, how about we just actually make cross-functional teams so a single team can handle all the work and that becomes one, two week sprint instead of four teams, a two week sprint each. And I could do that by mapping the bottlenecks, mapping the work, going through the system. So if you're wondering what the challenges you're having within your system, why things are slow, why things aren't working, why quality is not where you need it to be, why innovation isn't happening in the right way, why r and d is suffering. Mapping the work through your teams and understanding how work flows through your teams and where it gets caught and where it gets diverted. That's a great technique I've found for really understanding the challenges in my own organizations. And you're mapping not only teams, but you're also mapping [00:21:00] roles and functions. And seeing, maybe there's a role missing, maybe there's a role involved that doesn't need to be, or two roles that could be collapsed into one because the handoffs are slowing us down. Things like that. I mentioned earlier, team topologies. Team Topologies is a book from Matthew Skelton and Manuel Pais they talk to a bunch of organizations and tried to build a framework for a way of thinking about organizational structure that I very much like. They don't prescribe specific organizational designs. What they're doing instead is trying to classify organizational structure. In a way that gives you one, a way to think about it, two words to talk about it. Just like Lou has organizational maturity levels from teal on down. This is a very similar thing. So it gives you words that you can use that if other people on your team or in your [00:22:00] organization have read the book, you can refer to these and everyone knows what you're talking about, which is always helpful. I'll do a little brief, discussion of TE team topologies, but again, I'm gonna recommend you just read the book. I'm just gonna do a very quick synopsis of it. Organizations deliver software faster and more safely when they deliberately design team structures and interaction modes around flow of change. This is from the book, not around hierarchy projects or technology. So flow of change. Another way of talking about that, the flow of work through teams, what I was just talking about. So they came up with four fundamental team types. A stream aligned team, which is a team that owns a specific flow of work, a product, service or customer journey that team would have end-to-end responsibility for delivery and operation. And their goal is to maximize the speed of value delivery. The second team type is enabling teams, which helps those stream aligned teams adopt new practices, tools or skills. [00:23:00] They're temporary, very coaching oriented, and their goal is to reduce learning friction and promote autonomy. You have complicated subsystem teams, um, which handle analyzes specialized areas that require deep expertise. For example, video codex, machine learning models. That goal of that team is to encapsulate complexity so that other teams don't need to internalize it. And the last of the four team types is platform teams. They build and maintain internal platforms that simplify work for the streamlined teams. They treat internal teams as customers, and their goal is to enable self-service and reduce the cognitive load. I like those four types of teams. Unsurprisingly, they spend a lot of time at Spotify. Spotify very much had teams very much like that. They talked to lots of other companies as well. Because I spend that time at Spotify, that model feels very comfortable to me. It makes a lot of sense. It works pretty well in that thinking of teams, i've been in lots of other companies as well. I think it, it still maps even to [00:24:00] very different organizational structures. You can map the different teams to these things. Once you understand these four different team types, you can think about how they interact. So there's three interaction modes. Collaboration, which is two teams work closely for a limited time on a share goal. Building X as a service, one team provides a well-defined service or API to another. Again, think of Amazon, it happens all over the place. Facilitating is the third type of interaction mode where one team mentors or guides another to improve capabilities. Another important part. So what are the teams roles, and then how do the teams interact? And then the final piece is their design principles. Cognitive load is constraint. Team should be small enough and scope narrowly enough to keep the system comprehensible. Evolve structures with the architecture as teams modularize or scale team boundaries should shift accordingly. That's referring back to Conway's [00:25:00] law and prioritizing fast flow. Every design decision should increase the speed and safety of delivering change . Team Topologies again, I like that it gives you a vocabulary and a playbook for intentional org design. If you've ever been in a reorg where the end result makes no sense whatsoever. That's folks not really thinking this through, especially if they can't explain it to you. You see these common patterns and like all the time. Recurring patterns I've seen is like functional silos, as I mentioned. That was my last org at Adobe, and that was the way Adobe worked. Functional silos, they're efficient early. It is great, right? Early, they become really brittle later. A very common thing and still when you have cross-functional teams and my current company, this is true now, we have a mobile app team. We have the same thing at avo. What happens when you have a mobile web team and you have a bunch [00:26:00] of other cross-functional teams? The mobile team is always chasing all the other teams. But the alternative, which is what we had at Spotify, fully cross-functional teams, meant that you need mobile developers on every team. So now you have way more mobile developers. It's way more expensive. I am 99.99% certain that, by the time I left Spotify, I had more mobile developers in my team at Spotify than any other company in Europe because we just had so many different teams and each of those teams. One or two, usually two mobile developers on it. Most companies that were more functionally structured, they would've never had that many mobile developers. Even if they were a mobile only product, probably didn't have as many mobile developers as we did. But that was what we needed in order to build truly cross-functional teams. Another very common silo is data engineering or data science. 'cause those folks are [00:27:00] hard to hire and you want build capability for the company. You wanna start to build best practices and those kinds of things. So it's really important to centralize it at the beginning. Eventually that centralization becomes its own, as I said, brittleness and it becomes its own bottleneck. And at that point you have to start thinking about distributing that skillset within the organization. Another organizational pattern that I've just referenced lots and lots. , So I'm not gonna spend a lot of time about right now is just cross-functional teams. So I didn't define it, and I will a cross-functional team , the way I think about it is really trying to achieve a level of team autonomy, which means that the skill sets that the team needs to execute against whatever their goals are, whatever their mission is, those skill sets are represented within the team. So the way we tend to think about it is developers plus testers, plus UX design, plus product management in a single team that is absolutely a cross-functional [00:28:00] team. So the way I would've done it at Spotify, where I was really focusing on having teams be fully autonomous, as I just talked about, you would have mobile developers, web developers, desktop developers, backend developers, testers, design product, data engineering if needed, data science if needed. So you'd end up with much bigger teams than a lot of companies have. But that team had every skill set represented within it, so it had no dependencies on other teams, and that was by design. That team could move as fast as it possibly could because it had no constraints on it, it had no dependencies. That's important if that's your goal. It's also very expensive, so it's not something I would just recommend everybody go do. You have to have that the kind of money to make that work. But Spotify did, because Spotify's goal was to go as fast as possible. We talked about platform and infrastructure [00:29:00] teams as part of talking about team topologies, one thing I will say, having worked with different system architectures and different platform teams, the more complicated your infrastructure is, the bigger the platform team needs to be. Because the idea is that in a mature company, developers shouldn't be focusing as much on the infrastructure that their code runs on. They should just be focusing on the features they're building and the code they're writing in earlier stage companies. Now, it's a lot more tied together because the developers tend to also be doing the infrastructure simultaneously. So for example, in a microservice company, microservices, each of them are really small. But in a company like Spotify, you got thousands and thousands of those things running. Certainly in Amazon, certainly in Netflix. Well, how do you monitor all those? How do you manage all those? A [00:30:00] team of a few developers, how they may be managing a hundred microservices. How does that work in practice? It works because you have a massive platform. That they work on that gives them all the tools to let them do that. And we built that at Spotify. Of course at Amazon they use AWS and they have that whole thing. That's an important piece of this. The more complicated your architecture is, the bigger the platform is. 'cause what you're trying to do is let the developers focus on the things that they're supposed to be doing, which is building features and just have a platform that supports them and lets them go as fast as possible. So that's an important part of, how you think about this and how big your platform team needs to be. I get asked a lot like, what's the right ratio of infrastructure team to the rest of the organization. I think at Spotify for a lot of time I was there, the infrastructure team was bigger than the features team by a lot. But, and if you took sort of infrastructure and platform versus everyone [00:31:00] else. So I was doing all the features on mobile, desktop and web and all the music stuff. The infrastructure team was bigger than my team. Plus the growth team plus the sort of third party facing teams. The platform team was as big as all the other teams combined. But that was absolutely appropriate 'cause I had developers on my team managing 20 microservices by themselves and generating new ones. And they could do that and they could do it really fast. They could get their work done super fast. And that was because we had an amazing platform that we got to leverage. And so that was absolutely appropriate. That platform team was needed in order to make the rest of the organization go as fast as possible. Every L organization I've been since. In a more complicated architecture, that team might be like a quarter of the organization. In a simpler architecture, it may be just a few people. So it really depends. Uhhuh, see, it depends [00:32:00] on what you're building and the architecture you have. There is no one size fits all for platform versus application and r and d. Another important pattern is matrix models. I could be wrong, but as far as I'm aware, IBM really is the source of matrix organizational models. When I say matrix organizational models, what I mean is managers mapping to multiple teams. Now that's not a director with multiple engineering managers reporting to them. That's command and control. That's hierarchy. Managers have people that are in multiple teams maybe the manager has accountability across those teams. Maybe they don't. At Spotify, a single team might have three different managers or four for the different functions. The management was functional, but the team structure was not. So what you ended up with was multiple managers supporting people in a single team. That's, I think, the extreme of matrix management the thing I learned from that, that I still [00:33:00] apply. And has operated in almost every company I've been at since Spotify. The thing I don't like is having a really high overhead of managers, more managers than you need in an organization. And that's because I want the management role to be a role. I want people to take the job seriously. I want them to be on the management ladder. And that's hard if a manager's managing a very, very small team and you have lots of managers, manager managing small teams, if you have almost as many managers as people on teams, that to me is a massive red flag. So how do you handle that? You look for what is the right number of people for a manager to support. I'll talk about that in a second. And then you say, okay, the managers are gonna manage X number of people and however many teams they map to, that's how many teams they map to. The other part of that, which I [00:34:00] liked, and this is something I learned at Spotify, people hopefully, generally like their managers. And if you like your manager but you wanna move to a different team 'cause you wanna work on something else, well you don't wanna lose your manager. So having a matrix org lets you keep the manager you like, even as you move between different teams which is really nice. And the other thing I like about this is having managers have visibility across multiple teams, lets them actually help me as a leader or the directors or VPs that report to me helps debug the organization because they'll see how teams are performing relative to each other and it helps surface problems within the organization a lot faster. So I am a big fan of matrix organizations. I think Spotify is one end of the continuum there. I haven't come close to that since I left Spotify, 'cause I haven't been in a company where that would be appropriate. But pretty much every company I've been at, we've endorsed [00:35:00] some part of this. And really what it is, is about making the people who are responsible for managing other people, make sure that they want to be managers and that they have appropriate work as managers and taking that management role seriously. Because I think that's important for the people that report to them. And I think it's important for the organization. Usually when I join a company, let's. There's lots of teams, lots of smaller teams, and each of those has a lead. And that lead is the manager of the team. And the way this is all worked almost every time, when I join the company, I talk to all those leads and I ask them, do you want to be a manager? Do you like managing the team? Why do you like it? What makes you happy about being a manager? Do you want to continue in the management path? And what I find is about half, usually half of those folks tell me, no, I just wanna be [00:36:00] a developer. I have no interest in managing people. I ended up managing people because I'm the senior developer on the team. When I give them the option to just really focus on being better developers, they about half the time will take me up on it and all of a sudden I have half as many managers, but I have the same number of teams, which means I end up with managers managing multiple people in multiple teams. And that's worked out pretty well. I can't promise that everyone in the company loved it, but I never fell on its face and I've done it multiple times. Just be very clear and deliberate about why you're doing it and how it works. So these patterns will evolve over time and they'll change as new leaders come in, new managers come in with external ideas. That's good. You want your organizational structure, you want your patterns to evolve as the organization evolves. Fixing it in [00:37:00] time you're just gonna be compounding management debt there. One pitfall I see often in organizations that, especially those I inherit, and they're hard to untangle, but organizations that are designed around personalities. So there's a person with a specific skillset or a person who has historically held a role and the organization kind of got designed around them. Maybe it grew up that way and now that's not working anymore. But no one knows how to change it or everyone's afraid to change it because so much is riding on this one node in the system. That to me, is always a mistake. Doesn't mean it doesn't happen, doesn't mean I haven't had to deal with it and lived with it because it was too hard to change. But if you find yourself saying, well, after looking at how the system operates we really need to change this, but we can't [00:38:00] 'cause this one person, we can't move them 'cause they've owned this stuff for too long and no one else knows how to do it. So we kind of have to leave them in place, which means we can't do this change that we know we need to do. If you find yourself doing that, you're in a really bad place and you need to really debug it. And you may need to make some very difficult decisions, but you are adding more and more debt that you're gonna have to pay off eventually. Let's talk a little bit about evolving design and when and how to change. Some signs that you may see too many cross team dependencies, stuff's really slowing down. That's a sign that there's maybe some organizational structure problems. It could be that decision latency is increasing. It's taking more and more time to make a decision and move forward because too many different teams with [00:39:00] low bandwidth communication between them have to align and they aren't because they don't have high bandwidth communication. You have ownership disputes over different parts of the systems or over different. Missions, we are responsible for this. No, we are responsible for this. That's a clear indication that something got missed in the current organizational structure, or honestly, that your architecture is now becoming a problem and is slowing you down. And by the way, some of these solutions may not require an organizational redesign. If you see them all, probably you need an organizational restructure or reorg. But if these individually, sometimes there are other ways to work around it. Think about your reorg. If you do it in a deliberate way, if you do it in a very transparent way, when you're very open about the goals, you involve the organization as much as is [00:40:00] reasonable. So it's not something that's just continually being done to them. Management is reorging us. Again, we don't understand why and we don't understand this new structure. If instead, you are in front of the team, if you're the senior leader or your senior leader is in front of the team saying, these are the problems that we're seeing, this is the way we wanna address them, we want your input into this, and then we're going to move forward. People will understand that you're trying to solve specific problems. And the next thing you have to say is, and this is how we'll know if it's working, and this is how we'll know if it's not working. And if it's not working, we may have to change it again and think about it that way. This is more like a refactor and not like a revolution. So the problem when org structures feel like revolutions, [00:41:00] again, something done to you that you have no input or no understanding of, you don't understand the new structure or why it's better, that really messes with your brain. When you do that reorg, and the reason you don't wanna do it too often, you don't wanna be afraid of doing a ever, but you don't wanna do 'em so often that you mess with people's heads is because there's a sociotechnical cost. To a reorg, reorgs change relationships. They change where you have that high bandwidth communication and low bandwidth communication and they change your identity. Who am I? Who am I in this organization I'm in? So be careful, handle it with care, handle it with clarity. Let me leave you with some practical tools. Just remind you of what we've been talking about. Map your current system, the communication patterns, design flow, the ownership boundaries. Align your organizational structure to your strategy. It should serve where you're going, not where you've [00:42:00] been. Don't change it every time. Strategy changes, but you should be going in a direction with your strategy as it evolves. Make sure your organization is supporting that strategy and supporting your culture. Designed for interfaces between teams, between systems, between managers and ics. Iterate. Don't be afraid to iterate, but iterate very deliberately and very transparently. The org design, it's a living system. Small changes, frequent feedback. If you can do this in a transparent way, if you can explain the why, if you can explain the, this is how long we're gonna live with it and this is how we're gonna know if it's successful and if it's not successful we're gonna change it, but we'll change it again in a transparent way that will help you build trust within the organization and that will help you build cultural resilience in making design changes to make the organization work, which is good. You want people not to be afraid of change. 'cause companies change all the time. Just closing out organizational [00:43:00] design is a continuous tool for engineering leaders. It's a great. A tool that we, in our tool belt as leaders and as managers. And so don't be afraid to use it, use it sparingly, but don't be afraid to use it. Try the bottleneck mapping exercise. Try mapping the system of your organization and how work flows. Think about it. In terms of team topologies as well, what are your teams of those four team types, how do they partner? How do they collaborate? Are teams not mapping cleanly? Is that okay? What does it mean? Should they be? Look at your current state of the world. If you drew your org as a flow of information or a flow of work instead of just, a directed a cyclical graph of management and reporting structure. If you did it instead by how does information [00:44:00] flow, how does workflow through your system, what would that look like? If you're doing something interesting in your company, I'm always fascinated to hear about new org structures or people experimenting around organizational design, trying new things. I would absolutely love to talk to you about it. So if that is you, please send me an email contact at, it depends book.net. And I would love to chat to you about it. I hope you found this helpful. I hope you found this informative. I love talking about this stuff. There's probably a billion things I could have said that I just. Didn't. But I love geeking out about this stuff. I would love to hear about your organizational journey. I would love to hear your suggestions For topics, there's a survey, it's included in the show notes, or you can find it from the website. You can reach me to tell me on Blue Sky, on Threads, [00:45:00] wherever. I'm kind of my name in all places. You can go to chem goldsmith.com. There's links to a lot of my socials there, but I'm pretty much everywhere. It's just I pay attention to some more than others and I'm really interested to hear your thoughts on organizational designs, things you've tried, things you're struggling with, and also other ideas you have that you'd love for me to talk about. I really appreciated getting this one. I hope your org's working pretty well. I hope if it isn't, you're not afraid to make some changes or at least talk to your leadership about making changes. I will see you next week in the newsletter and I'll see you back here on the podcast in two weeks. Have a great week!