A 6 Steps Framework to Avoid Reactive Reorgs

If you’ve ever launched a reorg only to realize 3 months later that nothing’s really changed... you’re not alone.

👋🏻 Welcome to Lead and Scale, the newsletter for CTOs and leaders navigating the complexities of scale-ups.

If you’re not a subscriber yet, here’s what you missed this month:

• The deadly mistake every fast growing startup makes (that you’re going to make too)

• From pre-seed to IPO, which type of CTO does your company need?

---

Do you know what happens when you reorganize a team under pressure? By the time your new organization is adopted, you’ve already fallen behind.

Can you perform under pressure?

No, but I can sing Bohemian Rhapsody!

A few years ago, one of our engineering teams grew beyond sustainable limits. We were laser-focused on delivering our roadmap, and failed to notice how our small team of 3 had expanded to 40 engineers in no time.

Without intentional structure or clear leadership, everything began to feel wrong and inefficient. Daily standups stretched beyond an hour, with no one listening but the scrum master. Our senior engineers transformed into walking Q&A resources, working 15-hour days to keep critical projects on track. PRs remained unreviewed for weeks because no one cared. Despite these red flags, we kept hiring to support business growth and add more technical debt.

We finally acknowledged the problem and decided to reorganize. Not wanting to reinvent the wheel, we adopted the trendy Spotify model, a seemingly reassuring framework for dividing large teams into smaller, more manageable units while maintaining cross-functional communication and avoiding silos. At least, that was the promise on paper.

Several months later, everybody had forgotten the pre-reorganization chaos. That’s when I realized something troubling: our growth trajectory was encountering new roadblocks, and our organizational structure itself had become the bottleneck. In theory, we were supposed to have an agile, scalable model, but in practice, we were already falling behind.

When I raised my concerns during a retrospective, I received a sobering response:

You’re probably right, but we just revamped the whole team, and no one would understand another reorg so soon.

They were right, but we were trapped and spent the next year bending our new organizational model to create exceptions.

Why Did-it Happen?

The most common challenge when navigating hyper growth or a systemic crisis isn’t choosing the right framework; it’s uncertainty.

A perfectly rational decision taken on Friday afternoon can be completely invalidated by Monday morning, yet most companies manage organizational problems reactively instead of defining a clear strategy with enough freedom to adapt their tactics.

We fell into this exact trap: we weren't building a future-proof, scalable engineering organization; we were solving an immediate pain point. By the time we designed and implemented our new structure, the team had evolved—some people joined, others left—and we faced new structural problems our new system couldn't address.

How to Avoid Reorganizing Reactively?

Avoiding a reactive reorg isn't complicated, but it requires strategic thinking that extends beyond your initial pain points.

Instead of asking: "How can we fix the engineering team organization?", shift your perspective to: "How can the engineering team deliver our growth objectives?"

This reframing transforms reorganization from a technical problem-solving exercise into a strategic alignment opportunity that connects engineering capacity with business outcomes.

Here are 6 simple steps:

Start with business outcomes: Before drawing org charts, clearly articulate what business outcomes your engineering organization needs to deliver over the next 9-12 months.

Create evolution scenarios: Visualize how your organization can adapt to expected growth, accelerated scaling, talent shortages, necessary downscaling, or key attrition.

Identify capability gaps: Assess your current organization against those outcomes to identify capability gaps, not just capacity shortfalls.

Map organizational tensions: Document where communication breaks down, decisions stall, or execution suffers. These friction points often reveal deeper structural issues.

Design for evolution: Create structures with intentional flexibility points that can adapt without complete overhauls as conditions change.

Build feedback mechanisms: Implement regular organizational retrospectives separate from project retrospectives to maintain organizational health.

You don’t need a 100 pages McKinsey report to define your new organization. Despite navigating uncertainty, I like to visualize how my organization will evolve over time, according to upscale or downscale models. Connecting with the business stakeholders to understand the reality beyond the initial plan makes easier to build such models.

Thank you for reading. See you next Tuesday to talk about the critical role of the CTO in a sales team.