"Do more reorgs" with Brian Guthrie

Instead of bringing you another analysis of a leadership topic laced through and through with my opinions, I thought it would be fun to share a new perspective. This time, from my old friend and former start-up colleague Brian Guthrie.

Brian recently started a company to help tech leaders visualize and execute smooth re-orgs, so we talked about that. What makes re-orgs hard? What would make them easier?

I strongly encourage you to listen to the podcast episode! The below transcript is accurate enough, but fails to capture the spirit of the conversation in many ways.

Brace yourselves; this is a longer one, but I really think you’ll take something away from it.

Enjoy!

Aaron
Hello, Brian.

Brian
Hey, Aaron. How’s it going?

Aaron
You are Brian Guthrie, CTO and co-founder of OrgSpace and former engineering leader at Meetup, SoundCloud, Slice, and ThoughtWorks. And you and I worked together a million years ago at a startup in Connecticut where we built data warehousing solutions for school districts.

Brian
That’s true, we did. On LinkedIn, I like to call that a “data ware-hut” company…

Brian
They weren’t very big.

Aaron
So you are the co-founder of OrgSpace. Tell me a little bit about what OrgSpace is all about.

Brian
Sure. So, OrgSpace is an organization planning and change management tool specifically geared towards software teams. So my experience prior to this was I was head of engineering at Meetup, which is a lovely company, I’m really fond of meetup. They’re all about encouraging people to get together in real life and make connections. But I entered the picture a little late in Meetup’s life, where they were purchased by WeWork. And as some of you might recall, WeWork collapsed rather spectacularly into a puddle of goo a few years ago, and meetup was part of the fallout of that event. They had acquired us, they immediately turned around and made the decision to sell us… Helpfully declining to give us any money as part of that. So we had to lay off something like 40% to 50% of our staff. I had to lay off 40% of our software and staff. For the first time in my career, I was the person picking names out of a spreadsheet.

Brian
Which is not a great experience and I don’t recommend it to anyone. And then subsequently, about six months later, COVID hit and Meetup is a company that encourages people to be together in real life, and again, as you might recall, there was not a whole heck of a lot of that going on during that time period. So unfortunately, we had more layoffs after that point. And I think it was necessary for the company because we had no resources to sustain the company at the size that we were at post-acquisition from WeWork. But it was really, really wrenching to everyone involved, to the people who left and to stayed. That’s actually my, to take a quick detour here, that’s my biggest problem in looking at sort of the Elon Musk thing and the Twitter layoffs and everything, is the utter contempt with which management there seems to have held the people who’ve left—as if it’s their fault for having accepted a job there in the first place. It’s always management’s responsibility, is my perspective on this. But at any rate, we became a lot smaller.

Brian
I found that as part of that, I could barely plan for organizational change in the next two weeks, let alone six months. The difficulty was that none of the HRIS systems, none of the sort of employee information systems that we were using, were sort of built to help manage and understand change for a number of reasons.

Brian
They couldn’t track team membership, which is not that interesting if you’re in conventional HR, but extremely interesting if you’re in software. Ours didn’t care about tracking contractors, which again, if you’re in the business of tracking employees, contractors are not employees and so therefore fall outside of the domain. But if what you’re interested in is tracking software team staffing, they’re critical. Contractors for us were an important part of how we were able to operate day to day, and other things. The keys to the kingdom were often withheld from folks on sort of the functional side.

Brian
So rather than me going in and planning a reorg in the in the tool, I was always told like, yeah, you make your choices and then for the love of God, like, just email someone in HR and we’ll do the change in the system, right? Like, don’t, don’t go in and try to muck with anything. And that got me really interested in this idea of the difficulty of managing through change. And OrgSpace was built to sort of act as an add-on to existing HR systems so that your sort of BPE person in that situation can really plan for organization change. Sorry I went all a little rambly there, but it’s a topic that interests me.

Aaron
Yeah, and I feel like organizational change is a topic that interests nearly all leaders. I think I’m mostly curious… I feel like reorgs are contentious in our industry. I don’t know if you listen to the “Decoder” podcast that’s produced by The Verge, the host, Nilay Patel, editor-in-chief of The Verge, he interviews a lot of CEOs, not all in tech, but mostly in tech. And he often opines that the thing a CEO has the most control over is the structure of the company. And certainly many executives, even below the C-suite level, see a reorg as one of their primary levers of control. But at the same time, the rank and file tend to revile a reorg. And that was certainly the atmosphere at Wayfair when I was there over the past tumultuous year, let’s say two years, most folks who would be affected by a reorg were just outright against reorganization. What’s going on there?

Brian
I think that’s a really good call out, and I agree strongly that one of the reasons why you see reorgs from sort of the C suite is that they see it as a lever that is relatively straightforward for them to control. They can’t necessarily control all of the staffing, although they can change how folks are evaluated as they come in, but they can restructure the organization to hopefully suit their beliefs about, um, their beliefs about the state of the market more effectively. But a lot of reorgs fail.

Brian
Reorgs are notoriously bad at accomplishing the thing that they set out to do. Leaders don’t really set healthy parameters around them, in my experience, right? If you’re executing a plan, ideally what I’d like to be able to see from that leader is, at a minimum, here are the goals, here’s what we’re trying to accomplish, here’s how we’ll know if it’s working. Here is the set of conditions under which, I don’t know, we’ll pull the rope and back out of this change because we think that it’s been destructive for the organization. There’s not a lot of the same kind of scrutiny and care that we apply to our strategic plans, often doesn’t get applied to reorgs. We don’t hold ourselves to the same standards of care in understanding the impacts of these changes and how the organization is affected by them.

Brian
And so I think that probably there are a couple of different issues that come into that and that make that super destructive, which is that a lot of reorgs involve switching managers, which is challenging for folks’ careers. You have to rebuild a set of relationships. You have to re-justify the work that you’ve been doing. There’s a huge amount of anxiety attached to them because it shifts your entire working relationship around and suddenly the environment you’re in is not necessarily the one you signed up for. And so because they are relatively easy for leadership to execute, because they don’t always hold themselves to the standards that they should from an efficacy standpoint, and because they are extremely impactful to the rank and file, people dislike them and not unreasonably.

Aaron
Yeah. That’s really interesting too, because something that was coming up for me as you were describing that is another thing that I was thinking about before we got together to chat today, which is something that both of our good friend Chris, who worked with us at that “data ware-hut,” he has been in some flavor of sales engineering or sales in sort of “enterprisey” companies from Dell to VARs. So he has opportunity to meet with C-suite or adjacent leaders in big tech companies all over the United States ranging in size, but as big as, like, Fidelity and CVS. And he has told me on multiple occasions that it’s common for these executives to come in, describe their predecessor’s work as totally inadequate, scuttle all of their plans, do a huge reorg, and then ultimately they leave and someone else comes in and does the exact same thing. They say, well, that person clearly didn’t know what they were doing and we need to reorganize everything because I know how to fix this.

Brian
What is that, bungee jump management, right? Like, you swing in, change everything, and swing back out again?

Aaron
I’ve described it as “seagull management,” where you swoop in, shit on everything, and then fly away. But I’m curious, as a founder of OrgSpace, have you seen a variety of real world scenarios or have you sort of chatted with leaders who are interested in or have purchased OrgSpace who have some notion of what is going on there?

Brian
Yeah, I don’t think that CTOs and VPEs sort of come in and use our product for all the same kinds of reasons that leaders do everywhere. And I won’t say that I think that we’ve been successful in changing the way the industry approaches the problem yet. But that sort of brings me a little bit to my thesis here, which I will freely admit is a little bit “trolly.” But my belief actually is that the problem with reorgs is that they’re too infrequent. That they are, I think, as you said, they’re tied to particular leadership who come in and imply that everything that happened before is terrible and we have to all change it and then they wander off. They’re done in secret; they’re probably not done with the collaboration of folks involved.

Aaron
And they happen on the order of once every two or three years, right? Well, I guess it’s different for different organizations, and depending on the scale. But they’re not happening every three months, typically. And five years is a little too infrequent, I think, for a lot of tech companies, although I might be wrong on that, but I think, when I talk to leaders, the cadence I hear is two to three years. And what that always brings me back to is I spent the bulk of my early career in professional services, in consulting. I worked for ThoughtWorks for many years. And the thing that I always find fascinating about ThoughtWorks—and there’s a lot of things I found super interesting about ThoughtWorks, even though I don’t work there anymore—but the thing that I find interesting as I look back on it is that my median time staffed at a team was six months. It was not two years. Like stability was not a thing that was promised there. And yet, ThoughtWorks is not a “body shop.” It’s not a marketing firm. These are not sort of fly-by-night engagements.

Aaron
The teams themselves tended to be quite long-term, but the staffing changed very frequently. Folks moved in, folks moved out. And not only that, but my geographical region changed frequently. They had me traveling quite a bit. The person to whom I reported in a nominal sense changed every time I changed teams. So different teams would have different project managers who were sort of engaged either on the client or on the ThoughtWorks side. And yet the thing about that, that I found so striking is that the teams that they built managed to be coherent, high-performing, at least in my perception or opinion; that they weren’t chaotic messes, that they weren’t disrupted because people were changing frequently. They were always pretty reliably high quality teams. And I think there’s something to the change motion there that’s really powerful: that because when you start exercising that muscle, the friction that we associate with change starts to decline. It’s the old sort of extreme programming adage, if it hurts, do it more often. Change hurts. Change can be really difficult, it can be really disruptive. But there are powerful things that you’re able to unlock if you become good at change.

Aaron
And there are also certain things that you can do to reduce the friction and the impact associated with that change. And you have to frame this as a leader, I think, in terms of this higher level goal of what am I trying to accomplish on behalf of my organization? Not what I think personally is best or what I’ve seen work at Company X or whatever. But if I’m trying to build an organization that’s more competitive and that’s more dynamic and that is responding to the market more effectively, change is actually a really powerful tool in your tool belt. Do you really want to bring in all the rest of the friction and misery and mess that reorgs apply along with that, if you’re trying to build a dynamic organization? Change is really impactful; why carry all of that baggage with you? And so I guess my position on this is that change can be really powerful if you do it wisely and well. One of the ways to get better at it is to do it more frequently. And in doing it more frequently you unlock a range of competitive options. But you can’t necessarily do all of the things that we associate with conventional reorgs when you’re engaging in the sort of continuous change process.

Aaron
In the same way that continuous delivery encourages us to think of change in sort of small concrete terms, right? Atomic changes that roll out to production rapidly and that can be reversed rapidly, but that require building up a number of muscles along that journey to get better at that change process, right? Where you start using feature flags and you start using hopefully a little bit more robust testing, you have more complex build pipelines and so forth. I would say that a continuous sort of organizational change motion carries some of those same characteristics.

Brian
I think that tracks. It sounds like there might be some contention between the notion that more frequent reorgs will build muscle and flexibility even at the individual level, like you probably experienced at ThoughtWorks as somebody who was shifted between teams frequently; and there’s sort of a contrary view that psychological safety and team gelling is something that happens at a team level in a collective way and that is the product of trust which is built over some period of time, probably greater than three months. So if your median time on a team is six, you maybe just reached that point when you leave. And I think I’m a little bit curious how does the ThoughtWorks model scale beyond ThoughtWorks and to what extent does the type of business have an effect on that?

Aaron
I think actually, to speak to that last point, the type of business has a big impact and a lot of people who leave professional services, I think wander into product companies and say, like, “Ah, if you did it more like the consulting firm, this would be so great!” And then it never works right? Because it’s a fundamentally different kind of beast. I shouldn’t say it never works, but some things work and some things don’t. So professional services companies are different; it’s difficult to apply those models, apples to apples into product firms. But even at product firms, change is always happening at the atomic level, right? Teams are always changing even if the as a whole isn’t. People join, people leave, the people themselves are changing, they gain skills, skills fade, the work is always changing in response to competitive pressures. And so to some degree, if you don’t change the org, you’re not reflecting the reality that’s on the ground. And so I think there’s an argument in there for manifesting and reflecting that change up. But one of the ways that you can de weaponize that a little bit is by making the organizational change reflect the reality on the ground rather than vice versa.

Aaron
Rather than it being sort of a mandate imposed by some Grand Poohba who claims they know better, you can build a change motion that is reflective of that continuous change within the organization. I’m thinking of a time at Meetup once where I executed like a small reorg of our platform engineering teams. But all I really did was reframed team names and team goals to more closely reflect the impact I thought they were already having. Because what I wanted to do was make the organization more legible to the rest of the broader enterprise. I wanted people to be able to look at those teams and say, “Oh, okay, I understand the value that you’re providing. I understand, based on the name and the mission, how my problems on the product side might relate to what you’re doing on the platform side and where I can go for help.” And I think that kind of a change motion is just an attempt to reflect more closely what’s already happening, but to do it in a way that rewards the people doing the work for engaging in it. And I don’t want to say that every reorg is that perfect or that neat.

Aaron
But I think it is important to remember that change is sort of a continuous process on both sides right. And that both management and folks who are sort of close to the work can come together to craft an improved change relationship. There are other things you can also do to kind of de-weaponize that. Another of the things that we did at Meetup that I was really happy with is that we made a good solid swing at attempting to decouple team membership from managerial relationship. This is something that you and I, I think, talked a little bit about a couple of years ago, but it’s also something that I thought ThoughtWorks did well, that it made it very easy for me to switch the work that I was doing without necessarily switching my managerial relationships or their understanding of my value and my role within the organization. This is something that Daniel Terhorst-North, who’s another sort of consultanty person who talks a lot about org design, he describes this as not a reorg, but as bringing people to the work. If you know that you have a need for the right kind of brain employed in the right kind of thing, then find ways to solve that problem in a humane way, without forcing people to drag all of their work, I should say, leave all their work relationships behind and reestablish new ones and also try to bring in a fresh perspective to the work.

Aaron
Because I think that makes it more challenging to get to the end goal. But the more you do it, the easier it becomes.

Brian
That’s super interesting. I really liked what you said about the meetup reorg that you undertook whose goal was to make the more legible. And that reminds me of minor reorganizations that I have done in my time at Wayfair, at least where the goal was. The way that I thought of it just now, as you were describing it, is like an organization exposes an API, in a sense, giving a team a name and a mission and having it appear in whatever sort of tracking thing the company uses to identify teams, in a way is like creating that legible, expressive, functional interface. And I like that idea.

Aaron
Yeah, I think that’s exactly right. And to me, I think it’s a particularly important thing to think about in platform engineering terms because platform engineering is nominally dedicated to the productivity of the rest of the engineering organization. It’s really important that people understand what those folks are up to and why they’re doing what they’re doing otherwise. Not to put too fine a point on it, but I think it tends to risk the relationship and the perception of success.

Brian
I’m curious while we were talking a moment ago about how executives or leaders execute reorganizations without the same standard that they hold themselves to for other activities. And I’m curious, I think of the retrospective meeting as one of the key tools that a local team can use to interrogate their own performance and decide how they’d like to change, and in a fashion that even reflects the philosophy that change is constant. Like we’re going to get together on a regular cadence and talk about what we’d like to do differently or not. What would a reorganization retrospective look like?

Aaron
Oh, gosh, that’s a super interesting question. I could spend an hour unpacking that. I have a whole thing on feedback loops. I’ve started to write a book a couple of times on getting, and I think the retrospective is a fascinating example of, like, one node on that feedback loop. It’s the point where you take a step back and examine the work that has been done and attempt to form a loop. You’re forming an iterative loop based on the inputs, right? The work that you’ve done and what you’ve learned about that work. You’re generating a bunch of outputs. Here’s what we’re going to try next. And I think of retrospectives and sort of planning meetings as actually two sides of the same coin, where the planning meeting is a retrospective focused on the work itself, and a retrospective is sort of a “meta loop” focused on the way the work is done. And so I think it’s in some ways sort of the same lens for a reorg. Part of my belief, I guess, about reorgs is that we should approach organization change iteratively. It shouldn’t be “we’re not changing.” And then all of a sudden “everything’s changing” and then “we’re not changing,” right?

Aaron
Change is part of the fabric of doing business in technology and it’s part of the way that we have to think about how we change as human beings and how the world changes around us. And so if we think of change as an iterative process, then all of a sudden we have all of these tools available to us to think about that change. Both the kind of conventional planning meeting: here’s, the mechanics of what we’re doing, here’s how we think the last set of changes operated, here’s how we think the next set of changes can operate. And then also sort of the meta side of that process, which is how I’d characterize sort of the retrospective piece: here’s how we went about it last time, maybe we did it all in secret because we didn’t feel comfortable exposing these plans to the rank-and-file. Is there any way to invert that relationship, right? Or vice-versa, we exposed plans to the rank-and-file and everyone blew up. What can we do to make folks feel safer? What can we do to sort of reduce the temperature around that stuff? Heidi Helfand, just to call it out, has a great book on this called “Dynamic Reteaming” where she talks a lot about this.

Aaron
She talks a lot about bringing the change process down into the sort of team level and encouraging teams to think about this process continually and engage in that conversation, right? And so I think she’s a great guide to thinking about how to make the change process more iterative and more responsive to the needs of the folks on the ground. But I love the idea of bringing a retrospective process into that. The only thing I’d say is that another one of my sort of strong beliefs about retrospectives is that teams probably don’t bring in data as mindfully as they could or they should when retrospecting on process. And most of the retrospectives I’ve been a part of—and ThoughtWorks used to be big into this stuff—is that everyone spends the first 15 minutes writing things down on stickies and you stick the stickies up on the wall and then you dot vote on everything. And I should say, you’re lucky if you get done with all that in 15 minutes, and then you have another, whatever, 30 minutes to maybe discuss a few of those issues and everyone leaves a little bit unsatisfied because not all the issues get discussed.

Aaron
And you don’t know why everyone voted for a particular topic or whatever. Right? And I think what I would say for a reexamination process around reorgs is the same challenge I would have for retrospectives more generally, which is bring some data into that process and pre-seed it rather than asking everyone to brainstorm on the spot what the friction points are. “This is what went well last time” can be a manifestation of the nature of the work, or whether or not it was successful in the market, or whether or not our latest employee NPS score was positive or negative. Really use that as an opportunity to interrogate those questions and don’t look out of there until you have a set of concrete changes, things you’re going to try differently that are informed by a thoughtful examination of the previous time around. But I love this idea of a retrospective as an anchor process in improving the change management process, perhaps because it sort of implies that change management must be an iterative process right. That in order to gain the benefit of a retrospective, you have to be doing it continuously.

Aaron
I wonder, Aaron, have you tried that before? Is that something that you’ve seen happen at the leadership level or that you’ve tried to bring in?

Brian
I never have. And now that I’ve thought about it, I would love to write more about it and ask more folks about it. I think one of the things that is intrinsic in a retrospective is that it admits that we don’t know all the answers. And I think that’s something that leaders and executives sometimes have trouble with. I think that it’s part of that loneliness of the job where you feel like the burden falls entirely upon your shoulders to plan and execute this with as much perfection as possible. And having a retrospective is a way of saying, hey, we’re fallible. We don’t even have all the information and we’re open to that. And I love the idea of bringing some degree of transparency into a reorganization process. I certainly tried to do that in the smaller ones. It can be tactically challenging to do that with larger reorgs. But I do think it’s important for folks to at least understand here’s the goal we’re trying to meet by doing this here’s how it benefits, whomever it benefits, and to admit that there are probably some downsides and there will be some friction from it and to just say we are aware of that.

Aaron
Yeah, I think it’s a really powerful way of thinking about it in terms of broadcasting that vulnerability and that openness to flaw. One thing that occurred to me as you were saying that is that one of the things I have certainly been there. I felt that very deeply, the notion that when you’re in leadership there is this kind of pressure to be perceived as being right and to not have been wrong. But sometimes my impression has always been that it’s less upward pressure from the team. I feel like I’m pretty good at broadcasting vulnerability and lack of perfect knowledge down. It’s with leaders in my peer group or upwards where I think the challenge comes from. And the higher you get in an organization, I think the less it becomes about managing systems, arguably, and more it becomes about managing the interpersonal dynamics of the individuals involved. Like when you’re on a team level, I think agile actually does a good job here of saying, like, look, we’re part of a system of work. That system of work implies certain constraints and certain advantages and sort of, what are we going to do to change the system of work?

Aaron
But when you’re operating within a leadership team, it’s a little bit less about the system of work, a, because everyone’s a little bit more senior and they already have their way of doing things and their egos and how dare you imply blah blah blah blah blah. But then also there are just sort of fewer moving pieces and the movement of those pieces is very reflective of the personalities and opinions of the people involved. I do think it would be healthy for a lot of folks at that level to be much less opinion driven, right. If people could get in the habit of saying, show me some data a little bit more often, you can’t be too overwhelmingly data driven because that strips out sort of the human side of the process. But you also can’t operate entirely on gut instinct, I think, because then that results in poor and unaccountable decision making.

Brian
That is super compelling. I could do another whole episode about that. But I want to thank you. I want to thank you for all your time today and this invigorating conversation about organization, structure, leadership and the cloud.

Aaron
Oh, the cloud. It has been an absolute pleasure. It’s always a joy to see you again, Aaron. Thank you so much for having me on. I really appreciate it.

Comments