Here's the truth. Hiring remote engineers doesn't have to be expensive and time-consuming. Our friends at Revello can help you find and hire top engineers based in Latin America in a matter of days. Just tell them what skills and experience you're looking for. They'll come through their network of over 400,000 pre-vetted engineers and give you a short list of curated candidates that meet your specific hiring requirements. You interview
and hire on your terms and only pay for as long as you keep the engineer. To learn more, visit revello.com forward slash ELC today and save $2,500 off your first hire. As managers, when we've gone through re-orgs, they tend to be so painful and difficult to pull off that by the time we finish the re-org, all we want to do is wipe our hands of it and be like, all right, I'm going to move on to the next thing. Re-orgs over. How
do you know it's successful? The changes are made in work day. We sent the email. The re-org therefore is successful. No, it is not. You have inserted an organ into the patient. We do not know if the organ will be accepted. Hello and welcome to the Engineering Leadership Podcast brought to you by ELC, the Engineering Leadership Community. I'm Jerry Lee, founder
of ELC, and I'm Patrick Gallagher and we're your host. Our show shares the most critical perspectives, habits and examples of great software engineering leaders to help evolve leadership in the tech industry. Hey, everyone. Welcome back to the show. We hope you had a chance to enjoy the winter holidays and spend some quality time with your family and loved ones. The next few weeks we're sharing a couple different sessions from ELC annual
2022. This is our big conference for engineering leaders that happened back in October. This episode features a session with Aaron Erickson and Mike Tria on how to do an effective re-org. With the environment that many of us are operating in right now, they cover some incredibly timely and relevant topics like frameworks and strategies for implementing a successful
re-org. Why you should probably be involved throughout the entire re-org process, who is accountable when a re-org goes poorly and how to improve communication channels throughout a re-org and implement a smooth transition. Aaron is co-founder and CEO at org space, helping leaders tackle complex staffing challenges, model change and plan your organization's future. Before org space, he spent 30 years working in leadership roles, most recently as VP of
engineering at New Relic. He spent a decade at ThoughtWorks where he drove digital transformation via application of Agile and continuous delivery. Mike Tria is head of engineering at Atlassian. In overseas Atlassian's global cloud infrastructure, identity and front end platforms, enterprise offerings and third party developer ecosystem. As a former comedian, Mike also brings some high energy and a sense of humor to the tough challenges that he faces. One quick note,
you'll notice the volume is a little bit strange in this conversation. It's because we recorded this live at our conference and we had three sessions going on at the same time. So there may be a little bit of background noise and some distortion, but I promise you the content is incredible. Enjoy this conversation with Aaron Erickson and Mike Tria.
Thanks everyone for coming here. By the way, whenever they say he's 30 years in the industry, I feel like my retired yet, like you know, this is that, yeah, maybe I've been here too long. But I'm excited to be here to talk about this topic. Right now, I think crystal hearts. I don't know if anybody's been watching the news or anything, but there's changes in economy, there's changes in the world. And that is leading another robust,
right, suffer leaders and joining leaders to have to think about rewards. And so Mike, I want to give you a chance to introduce yourself. But thanks for the aircombed session day. Yeah, thanks. This has been a very topical this topic of reords. I can speak for myself. I've gone through a ton of reords personally. I've done a bunch myself and I've gone through many. Asham Currice in the audience, if you has ever been through a reord before raise your hand, okay, some of you raised
your hand twice. That's good. Okay. How many of you have done a reord? How many of you have actually raised it? Oh my lord. Okay. How many of you have done more than three reords raise your hands? All right. Great. Just curious. Has anyone ever been involved in like a bad reord like one that didn't work great? Okay. How did you raise three hands? I don't know how that's possible. Very topical. Also, our industry has been changing a lot recently.
Like you probably like wash the news and you see every company out there going through like reord this reord that how do the reason that you know Aaron and I are here to talk with you is he and I have both done a bunch of these and there's not a lot of great info out there on how to do these things right. Most of it out there is sort of you know, here's how to think about
an organizational structure. Here's how to think about grace for a team. But the reorg, which feels like it's the most obvious thing to do in a lot of situations like just do a reorg, solve your problem. Most of them don't work great. And so we wanted to just talk with a bunch of you and share some learnings that we've had through our time in the industry all 58 years of it. 58 years of my god. Yes, we're old war stories. Say we're going to play a game.
I like it. We're going to try to make a topic that is not very fun, slightly more fun. So we're going to do a game called reorg improv. Oh my god, you didn't know you're coming for this today. I'm going to name a kind of reorg. And then my friend Mike here is going to say what's bad about it or maybe what's good about it if you like that kind. We'll see. We'll see how this goes. So reorg in plan. Topic number one. All right. Clapeley org. The quota reorg. Okay, we'll see.
A quota reorg is when you've got some target in your organization about either the number of direct reports you need to have or span of control in a team. And so you're quite simply changing the organization to be able to fit some balance like so and so can't have more than eight direct reports or fewer than four or you have to have a product manager and you have to have like a designer
on there. These are pretty bad. These are up there in terms of pretty bad ones. A good signal you've been in a quota reorg is especially if you are one of those directs of the VP that did the reorg is you know nothing about what your peers do and you have no reason to care about what they do because you're just a bunch of people that have been gathered to do a thing and nobody really loves that one. Imagine explaining it, right? So you're an engineer or a manager on that team
and suddenly you're trying to ask why you this reorg? Well, you're going to often hear some made up nonsense reason about why this reorg was done. I'm like, well, we're trying to increase shareholder value. We're trying to do so. So really it's because someone was just trying to hit some quota in the end. Never, never good. They often do not end well. But hey, you need 70 indirect reports of your VP. So yay that. Okay, we got another one. It's called the trend chaser.
Oh, I love these. Okay, the trend chaser. There's some trend out there. Two pizza teams makes a good organization or we have to go to tribes. And so the organization just decides that trend so and so company out there seems to be pretty successful. They have this model. We're going to copy them. We're going to cargo cult that trend and make an or change. Also, this I put this in the realms up there of some of the worst ones I've seen in terms of works. So we here watched YouTube about
the reorg rag, who's you haven't seen that there's a song called the reorg rag as anyone see it? Yeah, well, we'll share it afterwards. Yeah, it'll be a link basically it ends up with you being your own VP by accident, which I think might have happened to me once not just saying one of the other things that happens with trend chaser, too. It's like it's like the two pizza team thing. I've had to do that thing where oh, we have to have the end up with just a lot of kind of badly aligned teams.
And sometimes these are good ideas, right? It's usually assigned to maybe a consultant was in there and said that maybe you need to do a thing not as fun. Let's go to the other one. Let's talk about the zombie reorg zombie reorg. Okay, so you probably have a product that's not performing so well and this is an or change that's done to sort of take something that's not performing well and
quietly sunset it without actually doing the hard work of shutting it down. You've got a business unit, some product, whatever, and you've now created a zombie in your organization with the express purpose because you know as a manager, you're not really doing your job of just either performance management or shutting nothing down. Also pretty bad. This one ends up in a really bad spot for a lot
of folks. Yeah, one of the things I certainly think we both noticed is that sometimes reorgs are a thing you do when you have organizational debt or decision debt or you have meant to make certain decisions over time, but they were politically hard to make for all sorts of might be good, maybe not so good reasons. And so that reorg is that opportunity to say, okay, well, let's just get a bunch of
decisions we needed to make before into the system now. It gives us a pretext to do it. And so that's why you suddenly see these kinds of things like, hey, I know we're going to start a product, but why don't we do these other things as well? It's a sad fact of life. I understand why they happen, but yeah, it's not a wonderful pattern. Yeah, and you're probably noticing from a bunch of these, while these are a lot of like bad reasons to reorg. There's mostly bad reorgs out there.
Aaron, I've talked about there's this data there. McKinsey did this study in 2016 where they went and measured for companies that have done reorgs, what percentage of them actually achieve the results they were meant to do? What percent actually achieved the results? And the answer is 20%. 20% of reorgs actually achieved the outcome for the business that's intended and 10% of them actually cause material damage to the company. So the vast, so it's not just anecdotes that,
you know, most folks here, I felt like you've experienced a bad reorg. Most of the ones actually out there do not achieve the results that they meant to do. The last of the improv, the management by rumor. Oh, this one's really tough. So let's say you've got a situation where you've heard there's some stat in your business, some particular piece of information. I don't know, you've got lower user count than you think you might have or your conversion rate isn't good. Let's say on
a product. So because you have a bad conversion rate, we're going to reorg and build a team whose whole job it is to solve the conversion rate. But then later on you find out it wasn't actually a conversion rate problem. You did your entire org change based on bad data. You did it based on a rumor. Good luck explaining that one. Like we say, sometimes they do damage to the company. When you reorg for no good reason, who here loves having just a poll, we love polls, who here wakes up
in the morning and say, you know what, I want four bosses in five years. Does everybody want that? Is that like what you aspire to do? Let's build a new relationship with our boss every time we had January? Like that's that sounds kind of a terrible way to go through your career. It's hard to build trust with your boss when you get a new one every six months, right? So a lot of these, this is an a lecture from us. This is confessions because we've all done them. We've all made these mistakes.
And so one of the reasons we talk about bad reorgs first is we would love for people not to make the same mistakes sometimes. So we've covered all the bad ones, at least that we know about here. And I'm sure people in the audience have shared bad ones. Tell us about them. We'd love to hear your stories because it helps us talk. But Mike, what are some of the virtuous reasons to reorg? Who here is sort of con ways law? We've heard of con ways law. Yeah, that's right. So I would say
the best reason to do a reorg is what's called a reverse con way maneuver, right? So ultimately, Aaron and I just talked about a whole bunch of purely organizational reasons to do a reorg, right? They're looking inside the business. They have to do with like spans of control or products that aren't working or some weird trend. None of them. None of those reasons have anything to do with enabling some outcome for the business. You want to enable something in the
business. You either have something that isn't performing well and you want to improve it, or you see some opportunity out there that you want to chase. Those are the reasons to do a reorg. But a reorg should still be one of your last resorts. So think about it this way. The virtuous reorg, the idea, you've got something out there you want to do like an IKVW specific example at Atlassian where I am. We wanted to start to serve enterprise better in our cloud, right?
Historically, the Atlassian products, if you're familiar with them, enterprise companies like the largest like, you know, your fortune 500s, they would run our on-premise products. They would go and download and install the products and then would run them on-premise themselves. Our cloud offering was just not suited. It was just not set up to be able to support enterprise customers.
We couldn't do it for years. We have tried. But to do that meant a whole bunch of subteams of a bunch of departments all working together to achieve something like this sub team here has to change their build system. This sub team here is to focus on performance. This sub team here is to focus on scale compliance, etc. Maybe we could have pulled it off, but you're asking for a vertical outcome from a horizontal set of teams to be able to solve the problem. A reorg is a really
good solution to this particular problem. You say you have this outcome you want to achieve for the business and you want to take all the horizontals and turn it into a vertical. Let's make a team whose job it is to achieve this particular outcome. So essentially the best reorgs have some very clear business charter business mandate that ties into the actual exchange. So what you're saying Mike is the best reorgs aren't called the reorg. The reorg is a side effect
of the business outcome you're trying to achieve. And it just happens that you have to change some reporting structures or build new teams or maybe shut down one thing to make a new thing in order to achieve that outcome. You wouldn't even know it was a reorg if it's one of those virtuous kinds of reorgs. Yeah. And note, no we're in there. Did I say anything about spans of control, organization, or people? Right. So I think a really important thing with reorgs, the ones that the ones that work
well follow this formula, they go strategy, er, people in that order. Often when we think reorgs, we think about it in the reverse. We think about, oh, I've got so and so strong leader. How can I put more stuff under that person? They're not thinking about it in the inverse, right? Which is how do I achieve this outcome for the business? Figure that out first. Then go through and think about what's
the org shape that makes sense? After that, start putting people's names and boxes because what you'll probably find is that you might have some great people. You might be missing great people because you may have a box without an evening in that situation. So the reorg, you know, very much as Aaron said, it happens to be just the means to the end to achieve the business goal, which also will get to later, which is how you know if the thing worked in the first place. You know, it's funny. That's
my next question. Oh, look at that. My gosh. It's like we shared notes beforehand. How do you know it's effective? That's a good user acceptance test. What's a good Selenium test? I guess maybe not that, but for your reorg. Yeah, that's a great question. I'll give you, I'll give you, I think probably too. So the first one we've just been talking about, right? You had some hypothesis for the business, right? So you had driving user adoption. In the example of Atlassian, we wanted to
drive more enterprise paid seats in our system. Did you actually do that? Ultimately, you know, as managers, when we've gone through reorgs, they tend to be so painful and difficult to pull off that by the time we finish the reorg, all we want to do is wipe our hands of it and be like, all right, I'm going to move on to the next thing reorgs over. How do you know it's successful? The changes are made in work day. The changes are made in work day. We sent the email. The reorg, therefore,
is successful. No, it is not. You have inserted an organ into the patient. You do not know if the organ will be accepted. You do not know. And so there are really, I'd say two things to look at to know if you did it right. One, validate your business hypothesis. That is going to take time. That is not something you will know in a week. It's probably not something you'll know in a month, but it is something you must, and I say must here, go back to and look at on a pretty continual basis. I
probably start looking within a few months after you've done it. You have to. The second is the whether the patient has accepted the organ is the one I would use to say, right? So do folks actually accept the reorg? How do you know that if you just sent an email and you accept folks, expect folks to just do their work? The very important thing to do when you do a reorg is to enable
a two-way communication, right? So the question you want to ask folks after a reorg is how do you know that the work you're doing ties into the strategy of the business that you're in now, that the team you're in now? How does the work that you're doing tie into that team? And if they don't have the answer, you haven't done your reorg effectively, you're not done. It means you still have communication to do.
So what we've done at least at the last scene and the second one is we do two-way communication. When we do a reorg, yes, there's an announcement often that we'll go out to folks to be like, hey, here's the change that's happened, but also inviting questions. Q&A, town halls, ask me anything, things like that to just make sure that folks understand this. If you don't do this, and I know folks out there because I've been a part of them where people skip this step, you end
up with fatalism in your organization. You end up with folks that say, it's just another reorg. What does it matter? My boss is boss's boss's boss now reports to their former boss's boss's boss's peer. All right, has our roadmap changed? No, I don't care. It's just another reorg. What is it matter? But what you haven't done is you haven't tapped into the potential of your team. Ultimately, when it comes right down to it, there will come a time when that person's roadmap
changes. At that point, they'll want to understand why it has changed. What are the new things that they need to do? If you didn't spend the energy on communicating why the reorg in the first place, then you haven't enabled them. And I'll give you a corollary to this one, right? You don't have to
get the reorg perfect at the start if you've got the communication right. I think a lot of managers, and this is something like I have fallen into this trap personally of spending way, way too long on the reorg to try and get it perfect such that when it lands, no one's upset and all the communications perfect and we figured out every little box across hundreds or thousands of people spent too long on it. That's often a mistake. What you actually want to do is get the shell right,
get the communication really, really good. And then enable your managers, your directors, your VPs, your managers to be able to do habal autonomy on their own team, to do their own little reorg if they need to. You might not get it all right at the start and don't expect that you will, but they will. And now that you've armed them with good information about the org change and why you did it in the first place, they can now do their own reorg on the team that makes sense for
them armed with that information. At that point now, you've done it's sort of like determining the right sprint length to determine for your reorg. You probably want to do it faster than you think. So what you're telling us is that as the CTO, as the VPE, I may not have all the context to say what in teams four levels down are going to be properly structured to do. And in fact, maybe give the people that are closest to the data and the reality of their work, the ability to kind of self-reorg
to meet these objectives. I kind of feel like that's treating your engineering leadership like the adults and grownups they are rather than having to have some VP kind of tell them what to do. Oh, you are so right. In fact, I would say this, this is up there with one of those like greatest reorg myths, which is if let's say you're doing an or change and you have someone under you, who's let's say you're going to cut their team in half as a result of the or change.
That person, they're going to lose half their team. When do you bring them into the change? When do you start to involve them? Our instinct as people is often, oh, that's going to be a tough conversation. They're not going to like that. In fact, they might not play ball when it comes time to figuring out this reorg. Let's wait till the end. Let's wait till we're really far along in this to really involve that person to, you know, shorten the time. They're not going to really have a say
in this anyway. That's the exact opposite of what you want to do. They are adults. And in fact, if you wait till the end, if you've gone for weeks and then you drop that on them at the end, what does that tell that person? It says, my manager has known for weeks, months, maybe, that they're going to reduce half my team and they didn't tell me. They don't trust me. How incentivized am I going to be to sort of put my best in on the team? You want to bring the
key people that are involved in a reorg early in the reorg. Share the fact that things leak again, like you want reorgs to go as fast as possible because once three or four people outside of the circle know it, everybody knows it. However, your key folks bring them in as early as possible. You will actually get a better quality outcome on your reorg because as you mentioned, you as the manager, you probably have the actual least context about what works in the organization.
You know the business outcome, right? So you know, we're trying to tackle this market. This thing isn't going so well. You might know that better than them, but your people know that actual communication pathways on your team better than you do. It's not in the org chart. The org chart doesn't say this is how work happens. Only your managers, your people under you will actually know how work really happens. And they might be able to tell you things that really save you
from making a huge mistake in your reorg. As a U.S. company, hiring remote engineers can be time consuming, expensive and frustrating. You could hire freelancers, but you don't know how much they'll focus on your business. Out sourcing to dev shops, risks, control over who works on your projects, and expensive long-term contracts. Or you could look overseas, but working across lots of time
zones can really slow things down. Enter Revello. Your gateway to a talent network of over 400,000 pre-betted engineers in Latin America who are proficient in English, work in your time zone, and are dedicated exclusively to your business. Revello simplifies the hiring process, enables quick payroll in local currencies, and provides expert staffing support. There are no big up front contracts. You only pay for each month that you decide to keep your
developers employed. With Revello, you're in complete control. You get to decide who to hire, what to offer, and you get to decide how long to keep them on your team. To learn more, visit revello.com forward slash ELC today and save $2,500 off your first hire. One of the things I like to think about is that there are differences when you think about peacetime and wartime. And the reality of our industry right now is a lot of us are in wartime.
A lot of us are being given mandates by our executive leadership to do what it takes to survive this downturn, to do what it takes to get back to growth before not doing that right now. How do we always differ in peacetime and wartime in your experience? Yeah, that's a great question. I'd say a lot of the fundamentals are still the same. So you need a strong business outcome, you need to communicate the well for a re-work to be
successful. You need those two things. What happens in wartime is the time pressure is much more dramatic, right? So you don't have a few months to think about seizing some opportunity. It's crap. We've got runway that's only going to take us, you know, another six months. We've got to make some big changes. We've got to often wartime is focus. Often the difference is when you have a re-org that happens during wartime, it's all about focus. How can we focus on fewer things?
Making that very, very clear to folks, if you find as a result that you're taking too long to think through your re-org, you are doing it wrong because the goal is focused. Therefore, you need to be putting things to the side that just simply don't matter and you need to tell folks that. Again, we underestimate, I think, just quite how adult and mature people can be in a business when you explain things to them in very clear terms about what's happening. They will understand,
they'll see the business, they'll see it going on from talking other folks around them. They'll understand it. The time pressure and focus, I would say, would be the the two biggest things that are the difference. Yeah, I mean, I think there's something in this idea that it doesn't matter what kind of company stands you're in. A couple of the key points are exactly that. Engineering leaders,
I mean, I think we understand the financials of the organization. We understand the financial reasons why maybe a product is being invested in or another and just being very clear with people about what those priorities are really, really important. Yeah, I'll actually add one more thing to that, right? To that. When we mentioned, like, not getting a re-org perfect, you can have really, really great people. How many of you are in an organization right now that is, would you say,
like, you know, ideal org structure to make you effective? Raise your hand if you're in the idea of the ideal org structure right now to make you effective. How many of you feel that you're effective in your organization today? Okay, look at this. You're effective, even though you're not in the ideal organization and for folks that are watching their recording, nobody raised their hand at the start and then pretty much everybody raised their hand in the second one, which means
either all of you are lying or you're all telling the truth. So good smart people will do good work even in an org that might not make sense. Right? So I'll put that out there, which almost all be it's the need for this entire talk. I'm like, well, that doesn't matter. What does it matter? Um, if you're really, really good, it has to do with communication. You can have the perfect
org structure. If you haven't communicated it right, folks won't be effective. However, you tell folks essentially you communicate with them well about what the goal of the organization is meant to be, they will still continue to be effective. Your job as a manager, you're iterating through that org structure to try and make con ways law work for you. That is essentially what you're doing. So one of the con ways law thing, who here knows what con ways lies? Okay, most of us who here knows
the reverse con way maneuver. Mike, do you want to describe what that is because not everybody raised their hand? So con ways law, right, the whatever you build is going to mirror the organization or the communication path of your organization. Reverse Conway is quite simply changing your org structure to get the architecture you want. Right? So let's say you have two teams and actually let's say you have
one team and they're building like three different services, right? You're probably finding that those three services are all pretty coupled. If you make them three different teams, you will get more interfaces between those components because those teams are now not in the same organization, not incentivized on the same thing. You've done what's called a reverse con way maneuver. You have used the org structure to change your architecture, which often means you might want to consider
having an architect in your discussions as well when you think through these things. This is one of these reorg side effects that folks often don't consider when they're doing their organization, when they're doing their org shape. We often think about org structures when we do a reorg from the engineering lens or the product lens, right? So we talked a ton about the product lens here today. Like there's a business outcome we want to achieve. This is why we want to do it.
There's also the engineering side, right? Which is we've got a bunch of teams that might be building similar services should they be on the same team or should there be barriers between these things? Have we not built clean interfaces? That means you actually want to change your org shape to actually make them different teams. And Conway's law, I would say in my experience is ironclad. It is not something that you can just paper around. It is something that's going to hold over time no
matter what you do. So a reverse con way maneuver is having Conway work for you not against you. It's one of my favorite anecdotes. Last question before we go to Q&A. It's a tough one. Might be a little provocative. Who gets fired when the reorg goes bad? I do. So ultimately, because I all gave you advice on how to do this. So therefore you can just point to me if it doesn't work out. The way I think about this as a manager, ultimately it's your accountability for the org.
Therefore it's your ultimate accountability for the reorg, right? So in the end, I don't know if there's enough accountability, accountability out there with regards to how we do these org changes. Often it's oh so and so made some change and it went above, you know, sort of was about my pay grade. So therefore it wasn't my responsibility. As a manager, if you are the one doing the reorg, it is on you. It is your responsibility to get it right. And we try to give you a few tips to
try and make it easier. But ultimately, yeah, I feel like the responsibility whoever owns the accountability for the org also owns accountability for the reorg. One way you can think about this is when you are doing that, when you're changing the organizational software, one of the things that we have as leaders is reorgs are probably the most leader like things we can do. They're one of the most impactful things we can do. And oftentimes it's the first thing we reach for it because it is
that thing that nobody else can do. If you're the CTO or the Apex power, that is the one thing that you can solely do that might fix something. It looks bold. It is a high reward thing that you'll do, right? If it works out really well, you are the hero. But if it works out badly too often, you don't have the downside of that. But a lot of people get the side effects. A lot of people have their jobs changed. A lot of products get thrown off their roadmap. Sometimes these do damage
to companies like we talked about 10% of reorgs literally do damage. And that's just what they admit to. And it's probably higher than that. You think about all the lost productivity when you change teens and all the new co-bases you learn and all that stuff. And so that's what they really want to reiterate as leaders in this room. We're all engineering leaders have to think about this. I want us to be, I have the gravity to this that is appropriate. Yeah, I would add to that, like,
reorgs are hard. So they should feel hard. It should be the last tool you reach to when you're talking. If things are working like, you know, a bunch of you just raised your hands when you said, you're not unnecessarily and super effective shaped organizations, but you are effective, you might not have to do a reorg. In fact, you should ideally goal not to. Reorgs cause tons of disruption in your organization. It should feel like something that you need to spend a lot of
time in. There are priors. There are things you need to do one well. You need to understand your business charter. You need to have buy in from your boss that you can even do it, right? Like, who here has ever started to go down the road of a reorg halfway and found out that they actually didn't have permission to really work with that team or move that thing around. That's very, very painful. You need to have those things in place. It should feel challenging. It should feel
like something you, you really want to spend your time in to do it right. Because when you do it right, Zaren said, you really have changed the organization. You have wielded the most powerful tool that you have as a manager. We wielded poorly. You can cause real damage. All right. So with that, we're ready to take some questions. We're going to have a mic moving around and we'll go from there. Thanks so much. Questions. So you mentioned reorgs are often a means to an adder. They must be a
means to an adder done well. Do you enter a reorg with sort of like a KPI thesis? If done well, this number will go up. This number will go down. And that's how we measure success. Yes. Yes. Broadly. Usually it's the case that you probably already have that KPI in your business, right? So you've already got some goal in your target. And it's often reorgs are the result of either, huh, we're not hitting that number. Why is that? We're not hitting it. Or it's,
we really materially want to move that thing. So yes, broadly, you'd have a number. But reorgs are more long lasting than right. They have an impact that goes beyond the movement of a single KPI. They often change the way that you do your business in that particular regard. So yes, you should have as much metrics and stuff that back your reorg as possible. And ultimately, that number, right? That KPI, you give to that organization that you've just set up. You tell them,
you'd be very clear. The reason we did this reorg is because this is the thing we want to move. And we want to enable you to do that. Thus, you can continue to shape your organ out basically in the way that makes the most sense for you to achieve that. So yes, I love metrics. I think as engineers, it's something that we can often reach to and use in a particular situation like that. So yes, broadly, I agree. I would add, it's going to be more than one. You're going to have your
top line metric. If it's a product based reorg, it's going to be about product metrics about, you know, increasing our MAUs, that kind of thing. If it's an engineering reorg, it might be about reliability numbers. It might be about execution and delivery and those kinds of things. But you're going to have secondary things around attrition. You don't want to cause additional attrition more than your minimal amount. If you're doing this, if you're doing it well, people accept the reorg,
and they're not just funding it in for a year while they find another job. And I'll add, even one more to that, which is if you find you don't have one at all, look harder. Often it's the case of we want to go and tackle this market. Therefore, we're going to do an org change. It's like, well, how do we want to tackle that market? Do we want to go for land as many users as possible? Do we want to get profitability as quickly as possible? Like, what is the thing
we actually want to do? Because that's going to alter the kind of engineer that you might put in that organization, other teams that you might bring in. If you don't have that KPI or a metric, ask for it push harder. You will always be able to find one. My question is around communication. You mentioned bringing people along for the journey and making sure that you're doing communication. It just went through a huge reward. There was posts, there was emails, there was Q&A, and then about a
months later, we're doing road mapping. And this is the only time when I saw people actually engage. Packed managers, impacted ICs, and I went was each team that is impacted, and I sat with them, we have any questions to collect. And then once you're actually looking at your road map and it's changing, that's the moment where they're engaged. Is there anything you would do to change that? I feel like it's a human nature's only embrace the change once it's actually impacting them.
Would you do anything different? I would say that's actually in the realm of re-or communication, that's pretty good. To end up in a spot where folks are like, all right, I guess it's fine. That's pretty good. I'd say that's your bar. You know, you want to end up there. The highest praise I think I could possibly hear after a re-org is that made sense. That's the highest possible praises. Oh yeah, that made sense. Why didn't we do that earlier? That's the highest you can get.
I think it is human nature, especially for engineers. If they're not immediately impacted by the org change, right, you know, they're managed it didn't change, their immediate roadmap didn't change. It's our nature not to disrupt them. Of like, hey, you know, there's this thing that happened, leave it alone. That's why I like the question of on a regular basis being asking folks, how does the work that you're doing tie into the strategy of the team? That question alone will
unearth so many things. It will one on earth, whether they actually have a comprehension of how what they're doing ties into the business period, whether what they actually even understand as what the business is doing is correct or not is a material. Do they even understand that? You get very jaded engineers if they don't know the answer to that. And then two, understanding the actual
strategy of the business. If they can answer that in a decently good fashion, then I wouldn't worry too much because then as it comes to changes to their roadmap or new things that will come in from the side they'll understand it. I would just reiterate, you know, the best re-orgs is they made sense. And they're not even called a re-org. They're, hey, we're going to do this new product. Everybody's excited about the new thing that's happening and trying to figure out a way that can contribute to
that. And the re-org is just, you know, a way to do that. So you're thinking about a re-org. You want to improve communication in an area, but you realize it's too disruptive. So what's the alternative? Don't do it. Again, get down to if you have some goal for the business that you are not achieving. Then if you are exhausting all of your other options that are not a re-org, and you know, as Aaron mentioned, like a re-org is just one tool in the toolkit. It's kind of the side effect.
Maybe you have the wrong leader. This is actually something I've seen the most, which is you have an underperforming leader, and we say we're going to do a re-org to solve this problem of an underperforming leader. We're going to like maybe move things out from that leader to another leader to make things work. Horrible, horrible outcome. All you've done is you've stacked your cards in the wrong particular situation, and you haven't done your jobs a manager, a performance management. And I'll
tell you all of the engineers in the organization, the managers, they will see this. They will figure it out. They are not dumb. So I would say if you've exhausted your other options, then you get to the re-org. But ultimately, if you're holding back from doing a re-org because it's too disruptive, that's when I would say communication is your friend here. Actually investing your time in communicating, bringing the right folks into the tent early on, and then spending the energy on the
back and forth communication will reduce the disruption. Promise you, because you've given an avenue for folks to vent their frustration. That's not unblind or on whisper or another place. They're venting it to you. They're asking questions to you in an open forum where you can have a discussion with them about it. Oftentimes, when a re-org is being seen as too disruptive, it's the equivalent to, I've not been releasing software continuously. I've not been doing small changes over time, and now
it's going to be a big, disruptive change. Now, I'm not going to say we should coin the term continuous re-org. Nobody wants continuous re-org, but maybe you should think about making adjustments over time, even if you don't call it continuous re-org, so that it's not disruptive in the first place. Usually, if you really need one and it's too disruptive, it's usually means you haven't been doing changes a long way. Don't ever say continuous re-org. You didn't hear it here.
Yeah, we didn't say that. This is like a time when a lot of companies are being forced to frequently like pivot and adjust their strategy, and given that you see looking to strategy to guide re-orgs, like how do you set up your teams for success if you have an intuition that you're going to be pivoting
quite often, your strategy in a single year? One of the ways I like to think about that is to prepare people for it, and to bring them into that conversation, hey, we're not just doing pivot-suppivot. We're going to do this series of experiments, and you're going to actually start to think about, okay, well, if this works out this way, here are two or three different ways we think it will go. Bring them into your strategic thinking. They understand the basis for how you got there.
One of the things I like about some companies like Stripe and Amazon and others are very document-based cultures, is you can lay out in detail the principles under which you're thinking about not just this change in the organization, but the next three or four you might be considering, and laying out that
strategy. I think if you bring people into that and allow them to critique it, then they will have kind of a stake in the outcome, and you'll get a lot more buy-in for that thing that you're doing over time. Let's assume that everybody in your organization has enough context, or that you're doing a good job of giving them that context to be able to think about those changes in a holistic way. I'll add one more to that, which is often it's the case that if in a business setting,
you're pivoting a lot, right? So you're constantly finding like, I don't know, you've got competitive threats or you've got constraints in your business that is forcing you to constantly change in pivot. You can do a reorg, you certainly can. What I would try and do in that situation, preserve the leaf
nodes, right? So the actual scrum teams try not to move them around too much. Folks will find safety in that group, and the more you mess around with the like the lowest level in your organization, like the scrum teams, you're actually killing your ability to do pivots, because what you want is you want the actual leaf nodes in your organization to be able to have essentially like an emotional support group, right? During these situations where they can go and then they can all work together
to solve it. Feel free to move around mental management, all that stuff. That makes sense. Frankly, that's our jobs. That's we're meant to do that. We're meant to be comfortable with the amount of that amount of change. Try in in a mode of where you have a lot of instability in your organization from a business perspective, try to increase stability at the leaf nodes. It will benefit you. We need to execute better. I know. Let's make everybody on board on new teams and spend
two months looming their co-workers. That's going to be totally awesome for execution, right? I'd like to hear both rear views on functional versus mission oriented team structures. Would you place management at the scrum team level or at a functional level, so like skill set, right? Back in engineering, data engineering, things like that.
I think the answer is both. But I think if you can choose one or the other, I'm going to put it into the team because that most aligns with the idea that and a lot of more advanced organizations are doing this where you have an autonomous team with all the different functions it would take to build a company. So you have a product function in the team. You have a
data function in the team. QAs embedded in the team. If for no other reason what that's going to do is it's going to shorten the feedback cycles from some of those other functions so that if I need design help, I'm not working through multiple organizations to do it. So on average, that's what I prefer. It's probably why I run a tiny startup and my friend Mike here runs a giant organization. He might have a perspective, but I can also see the ideas around having a community of practice
so that you have somebody that's your boss that also understands your function. And there's a lot of merit to that too. And I think the more an organization or organization scales, the more they might need that kind of structure as well. And so that's my non-answer to your answer if you're looking for one or the other. I love that answer. I'll say I work at a company whose stock symbol is team. That's the stock symbol. So we think about this quite a bit. I would say think about like
what actually is a team in that situation? It's not necessarily about reporting lines. So if you ask people in your organization like what team are you on? You might be surprised about the answers that you get. Often it's the case that you may have, as Aaron just said, you have a team with like embedded QA design product management program management. They may either report up to different people, but they're all on the same team together. If you have that, then almost the
reporting line is immaterial. Like you can have it. That's the second order effect. First order is absolutely get to the model that Aaron said, get to a point where you have an autonomous group of folks that are cross-functional that can just knock things down. Like get there. Then when you get into reporting structure, different answer, I would say from like startups versus like large organizations,
it tends to be the case. The bigger you go in a company, you tend to have it more functional because you know, as Aaron mentioned, like it's about understanding skillset and folks start getting really passionate about like their growth, their career, things like that. If you have a non, if you don't have like, you know, engineers reporting into engineering managers product into product management, you have a really hard time solving that problem. It's solvable, but it's really
challenging. But I would say avoid it if you can. Like the smaller you are, go for the cross-functional. It works better. If you're an engineering manager in the middle of Ruyorg, and your heat of engineering has decided on a Ruyorg, can you recommendations for how to support that? Or what would you expect to, I guess you're like, middle managers or engineering managers? Great question. So I'd say the very
first I've been on the receiving end of dozens and dozens and dozens of Ruyorgs. Often the first question I ask is, yep, okay, we're doing this. Why? Understanding the why? Because your job in the end, as a person that is the on the receiving end of a Ruyorg, is going to be explaining it to your engineering team. That's going to be your primary value ad. If you do not have the information to be
able to explain to them, then you are just going to be simply a pass-through to management. And it's going to make the engineers look to you and they're going to think, oh, so and so really do have any say here, then have any power. You get into that fatalism that you want to avoid. The number one question is understanding why. So that's the very first thing. And I would explain to your boss that that's the value you're going to be providing. Like I am going to be the person that's going to
make this really easy for you by handling the explanation in the back and forth. And if there are questions that come from the team that I am unprepared to answer, that's okay. I will bring them to you, but I will do my best to try and get as many of them solves as possible. Here's a good question. When you're on the receiving end, you're the director of the VP said we're doing this.
From the director I'm asking, hey, help me become an enthusiastic supporter of this so I can yell it from the rooftops and believe in my heart and my soul that this is the right thing to do. And if you can get to that point where you actually believe in what this thing is, and I'm not everyone's going to get there, you might not believe in which case they have some other decisions to make, but you want to be in that place where when somebody asks you what this is,
there is conviction in your voice. You're doing this for good reasons and that will translate to how others will support this. And they can sense if you yourself are tepid about this, you're going to have a hell of a time trying to make this thing actually work. Can you talk a little bit more about how to make the transition period of a rework more smooth?
So for example, a lot of teams might absorb different scopes or change ownership areas and there might be ICs, critical ICs that previously had a lot of legacy context on certain scopes that your team is absorbing that remain on other teams. So yeah, in terms of like onboarding the ICs and when to do the actual transition, can you talk about how to make that more smooth? I'll give you two different time periods to think through. One is the actual time you're spending
on figuring out the reorg prior to announcement. Then the second is post announcement till you actually get to the end state of the goal for which you wanted in the first place. The first one, the fastest way to get that done is to actually involve the most number of people as possible. You know, I'm trying to dispel them if you want as most people as possible that are involved in it earlier with time blocked off with target dates to get it done. Then when you actually
land the thing, let folks know you're going to be in a transition period. Yes, you're on some new team, but you're still working on the thing you were doing yesterday, which isn't aligned. Let folks know that's okay. That is okay. I would actually say the fastest way to shrink that time window is to put that on those teams. Now that they understand the reason for the reorg, ideally, they're going to get excited about the reason that the target state that you want to get to.
To shrink that as much as possible often involves talking with other cross-functional partners and peers to get there. But having them be on the journey with you will make it go faster. You as the ultimate manager in that situation can push and push and hard as hard as you want. Teams are still going to feel like they own the stuff that they owned yesterday. The fastest way to get them to the end state is to make them feel like they want to get to the end state as fast as
possible. One of the biggest hidden drivers of attrition is when you move around teams, but you still are a shadow member of your old team. You're still being called onto on call, because you happen to be the person that knows some old part of the code base. And so we talk about onboarding. I'm betting means getting those new folks that are coming into that team that supports that old thing to a position where you can truly break. You can have your critical IC truly
break and not be on call at all. Not be just called into the slack room when something goes bad. Because oh yeah, Joe from this thing from three years ago still knows how the service mesh works on whatever service. Like actually do a good job of breaking that. Otherwise, you're going to end up with people that just tire from having to support too many things. And those are usually really critical people that are really good. Awesome. Thank you so much. Let's get around to applause.
If you enjoyed the episode, make sure that you click subscribe if you're listening on Apple podcasts or follow if you're listening on Spotify. And if you love the show, we also have a ton of other ways to stay involved with the engineering leadership community. To stay up to date and learn more about all of our upcoming events, our peer groups and other programs that are going on, head to sfelc.com. See you next time on the engineering leadership podcast.