I talk to a lot of CIOs and business leaders who feel a similar pain:
"We have smart people and plenty of tools, but everything still moves slowly. Maybe the problem is how we are structured?"
This article is my view as a CTO on when to shake up your team structure, how to do it without burning people out, and how to know it worked.
The audience here is business and product leaders, not just engineers. I will use a bit of tech language, but keep it practical.
1. The real signal: busy people, slow outcomes
For me, the leading sign is very simple:
Everyone is busy, yet important outcomes crawl.
You start seeing the same patterns:
- Every decision has to go through one or two "heroes"
- Teams cannot clearly answer a basic question: "What end to end result do you own?"
- Projects jump between three or four departments before anything useful reaches a customer
- Incidents require half the company on one Slack call
This is usually not a "people problem".
It is a structure problem.
Conway's law says that the systems you build are shaped by how your teams communicate. In practice it works the other way too: if your structure is fragmented, your products will feel fragmented.
When the org chart no longer matches how you want value to flow to customers, it is time to rethink it.
2. Start from value streams, not from boxes on a slide
Most restructuring fails because it starts from the wrong side.
Typical anti pattern: a small group of leaders draws a new org chart in PowerPoint, renames some roles and announces a "new operating model".
Nothing really changes.
A healthier way to plan:
2.1 Map how value should flow
Forget titles for a moment. Start with questions:
- What are our core products or services?
- For each one, what is the value stream from idea to revenue?
- Where does work get stuck? Which handoffs are always painful?
- Where do we see constant escalations because "no one really owns this"?
This gives you a picture of how work should flow and where your structure fights reality.
The "Team Topologies" approach by Matthew Skelton and Manuel Pais is very useful here. They suggest designing teams around clear streams of change and keeping each team's cognitive load at a sustainable level, instead of building huge "do everything" departments.
2.2 Design responsibilities first, structure second
Only after you understand value streams, move to responsibilities:
- Which end to end outcomes should each team own?
- Where do we need platform teams that provide internal services to others?
- Where do we need enabling teams that help others adopt new practices?
Then and only then turn this into:
- Teams and reporting lines
- Product owners or business leads
- Shared services (security, data, finance integration and so on)
If you go straight to "who reports to whom", you will rebuild your current problems with new labels.
3. What you actually need to make restructuring work
Restructuring is not free. It needs resources and some political courage.
3.1 Executive cover
Someone at the top (CEO, COO, board sponsor) must say clearly:
"This change will create noise for a few months. We support it and will not roll it back after the first conflict."
Without this, the first big escalation will kill the new structure.
McKinsey interviews with CIOs show the same pattern: operating model changes work only when there is explicit alignment in the whole leadership team, not just in IT.
3.2 Strong HR and people partners
You need HR and people managers who can:
- Explain the "why" of the change in simple language
- Work with managers on new roles and growth paths
- Support people who are anxious or unhappy with the new setup
Restructuring is emotional. Pretending it is a purely rational exercise is a good way to lose your best people.
3.3 Time and a transition plan
A realistic restructuring needs:
- 2–3 months of overlap between old and new structure
- Extra budget for training and sometimes for severance or new hires
- Clear "do not touch yet" areas to avoid changing everything at once
If you try to flip the whole company in one week, you will create more chaos than value.
4. When is the right time to shake up your teams?
There is no perfect moment, but some times are better than others.
Good time
- Перед запуском новой стратегии or a big product shift
- After you have seen repeated failures with the current structure and have data, not only feelings
- When there is a natural inflection point: new market, new line of business, merger
It is much easier to align structure with a fresh story:
"Here is our new direction. Here is how we change teams so this direction has a chance."
Bad time
- Right in the middle of a major incident or regulatory crisis
- As a reactive move after one or two people leave
- Only because a new leader wants "their own org"
In crisis, you usually want to change the process and ownership around the specific problem, not redraw the entire company.
5. The biggest mistakes CIOs make in restructuring
I keep seeing the same five mistakes.
5.1 Cosmetic change
Teams get new names and managers, but:
- Ownership does not change
- All decisions still go through the same "hero" leaders
- Old reporting lines continue informally
If after six months everyone still runs to the same three people for every decision, you did not restructure. You only added confusion.
5.2 No story for people
Big announcement in all hands:
"We have a new structure. Here are the boxes."
No explanation:
- What problem were we solving?
- What will be better for customers?
- What will be better for employees?
Without a clear story, people assume the worst: "this is just politics" or "this is a way to hide layoffs".
5.3 Ignoring cognitive load
Many org designs look nice on a slide but ignore a simple fact: a team has a limited mental bandwidth.
If one team has to:
- Own five unrelated systems,
- Support three business units,
- And learn three new technologies in a year,
it will burn out or slow down. That is why Team Topologies and many modern org design approaches talk a lot about limiting cognitive load and creating loosely coupled teams.
5.4 Forgetting about structure and architecture together
DORA research on high performing engineering organizations shows that loosely coupled teams plus loosely coupled architecture go hand in hand. Organizational structure cannot be fixed separately from systems structure.
If your architecture is one giant monolith, no team structure will fully save you. But the reverse is true as well: even with a modular architecture, if teams are organised around old department lines, you will see friction.
5.5 Treating restructuring as punishment
Sometimes restructuring is used as a way to "punish" underperformers or certain groups:
- Unpopular teams get broken and spread around
- Leaders are demoted without explanation
- Whole domains are moved around every few months
After this, any future change will be met with resistance. People learn that "new structure" means "someone will be hurt", not "we will work better".
6. How to measure if the new structure works
Pretty slides mean nothing. Look at the flow.
Some simple metrics that work well:
- Time from idea to first value in production Is it shorter than before?
- Number of cross team escalations Do we still need three VPs in a room to ship a small feature?
- Incident response How long does it take to detect and fix issues? How many teams are pulled in?
- Ownership clarity Ask random people: "What is your team responsible for end to end?" If they can answer in one clear sentence, you are moving in the right direction.
You can connect this with business metrics:
- Time to launch a new offer or pricing change
- Onboarding time for new customers or partners
- Satisfaction scores from internal "clients" of tech (marketing, ops, finance)
If both tech and business metrics improve, the structure is probably helping.
7. How we approach this at Pynest
At Pynest we work with clients that are often in the middle of this journey.
On our side we try to live the same principles:
- We structure teams around client value streams, not just technologies. For example, a team that owns onboarding for a fintech client end to end, instead of "one backend team for everything".
- We use a Team Topologies inspired model for internal platform teams (data platform, infrastructure, DevEx) and enabling teams that help product teams adopt new practices like observability or better testing.
- When we augment a client team, we ask blunt questions about ownership and flow first, and only then talk about specific roles or headcount.
Internally we also measure:
- How long it takes for a new developer to make a meaningful change in a client project
- How often work gets blocked on "waiting for another team"
- Whether each team can explain their mission in one clear sentence
This is not perfect, and we adjust the structure roughly once a year instead of waiting for a big crisis.
8. Final thoughts for CIOs
If you are a CIO or tech leader, here is my short version:
- Do not wait for a full blown crisis. If everyone is busy and outcomes are slow, start exploring structural issues.
- Do not start with boxes. Start with how value should flow and what outcomes teams should own.
- Do not ignore cognitive load and architecture. Team design, system design and leadership culture live together.
- Do not treat restructuring as a one time event. It is an ongoing process of adjusting how people, systems and goals fit together.
In 2026 and beyond, your technology stack will probably look modern enough.
Your real competitive advantage will be how you design the people side around it.
Top comments (0)