Today's issue relates again to an inspiring conversation in a recent Sudo Make Me a CTO community call. One of the members shared that they were considering a significant reorganization of the engineering team, which led to a rich discussion with community members on the topic.

Reorganizations are common in the tech industry.

They're often brandished as the ultimate solution to productivity or efficiency problems in large and small organizations.

I'm confident that about half of the readers are just coming out of a significant organizational restructuring or are actively planning one.

There are situations when a reorganization is the most sensible solution. Still, I argue that this approach is used too lightly and often in situations where other methods are more effective.

Today, we will discuss why we have this reorg reflex and why it's often a bad idea. We'll dive into the real problems, explore better solutions, and maybe save you — and your team — one reorg too many.

We'll start by forgetting about your reorganization idea and taking you back a few steps.

Back to the basics of good leadership habits.

Do You Intimately Understand the Problem?

Before you start playing with boxes and lines on a Miro board, ask yourself: do you really know what's broken? Like, deeply know? It's tempting to jump to conclusions, but real problems hide in the details.

This part is hard. It takes time. It can be uncomfortable.

But it's the most important work you'll do.

We've all felt the lure of a "fresh start" that a reorg promises. However, that clean slate is sometimes more of a short-term fix for the leader's frustrations than a solution to the company's systemic problem.

Before you rush into such a decision, I recommend you roll up your sleeves and accept to go through the pains of understanding what might be going on in your team.

You'll likely hate yourself as you go through the process, but I guarantee you will come out much better equipped at the tail end of the investigative tunnel.

• Dig for Data: Forget gut feelings. Or rather, don't take them at face value; instead, put them into context. Where's the hard data? Product, operational, and development metrics. Look through them and try to pinpoint where the problem might be. We're often too quick to say, "We are not shipping fast enough," without qualifying and enriching such statements with actual data.

• Ask the Right Questions: Talk to your teams. Really listen. What are their pain points? Where are the bottlenecks? Consider running DevEx surveys with your teams to surface data that can be compared over time in a structured way. This will also provide a great way to measure the impact of the changes you'll introduce over time.

• Find the Root Cause: Don't treat symptoms. Find the underlying disease. Is it communication? Process? Skill gaps? You don't solve organizational issues with technology, and vice versa. You don't solve cultural issues with reorganization. You don't fix a sloppy strategy by shuffling around reporting lines.

Don't be fooled by the perceived simplicity of a reorg. It's simple for you, the decision maker, as it allows you to skip the pain of a lot of work trying to understand the situation while providing a comforting illusion of decisiveness and action.

Acting on assumptions is a dangerous game, with massive downstream costs in terms of lost productivity, team morale, and market opportunities.

Reorg as Your Last Option, Not Your First One

Reorgs are like pulling the emergency brake on a speeding train. Yes, it'll stop, but you'll also derail a few cars and seriously injure a few passengers. The price tag of a reorg is often underestimated. What we frequently dismiss as a reasonable "one-time expense" to make up new org chart slides, a couple of all-hands, and then a few more handover meetings, tends to have massive hidden costs.

• Productivity Loss: The loss of productivity as people figure out their new roles and responsibilities instead of doing their jobs can be massive. The bigger your organization, the longer it will usually take to recover normal productivity levels. This cost is hard to estimate and is rarely accounted for in the plan.

• The Morale Meltdown: Uncertainty, anxiety, and fear are always a byproduct of reorganizations. Your best people might walk out the door or become disengaged because they disagreed with the changes in the first place. Moreover, as reorg becomes the standard approach for addressing systemic issues in your organization, reorg fatigue will accumulate, and team members will lose trust in the company leadership.

• Hard to evaluate: When doing massive reorganizations, you're changing too many things simultaneously. As such, when things end up not working as expected — the most common scenario — but even when they do, you'll rarely understand what caused that. Think about this as the organizational equivalent of big-bang releases done once or twice a year. There are good reasons why the industry has moved away from them.

There are many other things you can likely try out before you hastily push the thermonuclear reorg button.

Remembering the Principles of Agile Software Development

Even though The Manifesto for Agile Software Development¹ was written more than 20 years ago, many companies and teams still fail to embody those key principles in how they operate. They might go through the performative dance of backlogs, iterations, and standups but still reason in ways opposite the key principles.

Similarly, big reorgs are performative. They can give the impression of boldness and moving fast. Of doing the right thing, even when it isn't.

One of the best definitions of Agility I have ever heard is beautiful in its simplicity and goes like this²:

• Find out where you are.

• Take a small step towards your goal

• Adjust your understanding based on what you learned

• Repeat

• When faced with two or more alternatives that deliver roughly the same value, take the path that makes future change easier.

The definition applies to any domain: code, organizational design, or even life itself.

When applied to organizational challenges, it can become a powerful means to deal with them.

Instead of a big-bang reorg, what if we tried small, focused changes?

We'd take fewer risks, learn faster, and contribute to building a culture of learning and experimentation across the entire organization. This could be a good way to practice the famous 1% improvement daily concept³.

So, when you're facing an organizational-related issue, which for 98% of you out there is likely an iteration on we aren't shipping fast enough, consider the following approach instead of complete reorg:

• Collect Insights: Look at the data, talk to people, and compare notes with peers in other companies.

• Formulate a Hypothesis: Based on your diagnosis, what's one small change you can test? Small is the keyword.

• Run a Small Experiment: Pilot the change with a single team or department or even across the whole organization if the change is small enough.

• Measure the Results: Did it work? If not, why? Use data, not feelings. Or use them in a structured way via surveys.

• Iterate: Adjust your approach and try again. Small, consistent improvements add up over time.

It's less dramatic than a reorganization but much more effective.

Instead of making large, often irreversible changes with a reorg, incremental experimentation allows for continuous learning and adjustments based on real-world feedback. This approach leads to more sustainable improvements in productivity and coordination. It provides plenty of opportunities to reassess and pivot and has lower negative repercussions on the team's morale.

You might have the impression that you are moving too slowly, but slowly and steadily moving in the right direction is better than moving very quickly in the wrong direction, especially when compounded with the high cost of reversing significant changes.

Think of it as another instance of the Festina lente⁴ principle that inspired many stoic philosophers and practitioners.

Stop the Reorg Reflex and Join the Conversation

The next time you feel the reorg itch, I recommend you resist it.

Take a deep breath, grab your data, and start diagnosing. Reorgs have their place, but they shouldn't be your default weapon. Let's embrace a more incremental, experimental approach to organizational change.

Want to dive deeper into these topics?

You are just one click away from joining the Sudo Make Me a CTO Community and start building better teams and more successful organizations with the support of all its members.

It can be another 1% improvement change that will have massive compound effects on your career.

Don't just take my word for it.

Here is what Mauro, one of our members, says about being part of the community:

Being part of Sergio Visinoni's tech community has been fantastic.

It's been so helpful to connect with others facing similar challenges – hearing their stories and learning from their experiences has been invaluable.

Sergio himself is a huge part of what makes the community so great. He's always willing to share his own insights and has put together some really practical presentations that have given me some great takeaways.

Plus, we've had some awesome guest speakers come in and talk about specific topics, which has been a real bonus. Honestly, it's been a great experience, and I'm looking forward to seeing what's next for the community!

If you like what you read in this newsletter, you'll love what we'll discuss with you in the community.

See you soon!