How to Refactor a Legacy Team

You’re staring at your org chart after reading yet another LinkedIn post touting AI. Yet your org isn’t moving. It’s like jogging with weights strapped on. Is your legacy team doomed just because you got started before the AI revolution?

Right now, the median tech organization is naturally pre-AI (by which I mainly mean what happened with Claude Code in late 2025/early 2026). Nevertheless, many of these seem to feel doomed. CTOs and VPEs I talk with look around them and feel like they’re the only ones who haven’t unlocked 10x productivity yet.

First, it’s very natural to have that impression when the echo chamber on our socials seems to float up all the AI progress, both real and hyped up. I imagine there aren’t a lot of buyers for posts bemoaning things being difficult and requiring actual work, experimentation, and some luck.

That’s aggravated by the fact that newer organizations usually are moving blazingly fast. I see the contrast among companies I work with. We were always told that being new means you get to move with agility; we just didn’t expect “new” to cut off at around 8–12 months, right?

Being in charge of a team that was formed while we were all still typing actual code character by character, like peasants, can feel very outdated. A bigger ship is slower to turn around. It’s more difficult to change the behavior of more people. Many just looked at their headcount, compared it to what new startups use, and felt hopeless.

Are you doomed? No. You can start refactoring your legacy team. But you better get to it.

It’s never fun admitting it, but the thought of laying off people has passed through the heads of nearly all tech executives with these legacy teams. Perhaps it was openly suggested by the board, or maybe just something they mulled over with a friend.

Yet virtually no one told me they were considering this because things were moving so much faster now that they don’t need the engineers. Therefore, the work is definitely there, and letting people go won’t necessarily make things better. In fact, it just might make it worse.

If your company is genuinely in trouble and cuts are required, that’s one thing. But I’m in general against downsizing just as a “precaution.” Instead, if you’re afraid you’ve got too many people to justify, the first refactoring possibility is to reshape the team around making the pie larger.

That’s the abundance mindset that startups are actually supposed to be based on. You probably have so many things on your backlog that you never got to because it was too complicated. Setting up squads that go after these new directions could be precisely what your company has to gain from embracing AI.

This, in turn, also tends to make the actual AI shift easier. That’s because spawning new areas allows your org to execute AI on a greenfield project. Those working on that have better odds of success, while having fewer people on the legacy part could be the needed change to allow you to turn the ship around in time.

Now more than ever, we’re in need of people who actually know what management is as a profession. Having so many balls in the air requires proper leadership. This translates, in many cases, into merging nano-teams into larger teams. That means you’ll be able to have fewer managers, hopefully those who are actually leaders and not just engineers who lead “on the side.” I highly recommend moving the others into technical leadership roles, not showing them the door.

Like in the previous case, it will make it easier for you to coach them and work with them, because there will be fewer people involved. Reduced managerial overhead simplifies communication and change efforts. And your team becomes leaner, not just due to AI, but as it ought to have been years ago to become a profitable R&D org.

I’m sure you know that delegation was always a good idea. However, if you never felt like your team could be given enough autonomy without wreaking havoc, I can guarantee it won’t get any better with AI. In fact, seeing as AI is just an intensifier of whatever input you feed it, teams that suffered from bottlenecks, constant back-and-forth, and missing context are going to ram against those same walls just more often.

Thus, another refactoring step you should consider is rapidly injecting your team with autonomy. Frequently, that means supplying the team with more context to understand what they’re doing, clear metrics of success and progress, and coaching. Armed with product mastery and autonomy, your bloated legacy team could turn into an organization delivering at a speed to be reckoned with.

You can’t expect your team to start embracing all these changes in how they operate and yet try to manage them the same. To genuinely refactor your organization, it’s time to change how you manage.

Daily meetings, sprint planning, code and design reviews, all need to be overhauled. I’ve covered this at length in this video:

Embracing experimentation is another refactoring I’m betting many organizations could’ve found very useful even years ago. Making space for innovation and creativity. No matter what you’re being sold, no one has yet unlocked the “perfect” way to utilize AI today (and even if they were to do so, it would quickly become outdated).

What that practically means for your team is that you ought to get accustomed to tinkering, tweaking, and trying things out. It provides people with more autonomy (see above) and takes some of the pressure off your shoulders. After all, who said you are supposed to have all the answers? If you’ve got a capable team, why not give them the opportunity to experiment and come up with some approaches by themselves?

Have collective experimentation days, share learnings, and encourage people to try things, not just read about them. More on habitual innovation is available in the free sample chapter of The Tech Executive Operating System.

A legacy team isn’t doomed. You can actually turn it into a team that is your legacy, jogging swiftly. Pick one of the refactorings listed here and get started this week. If you need help doing that, reach out.