Purpose

This playbook guides you through the design and execution of a team restructure. It covers when a restructure is genuinely warranted, how to design it well, how to sequence communications so people hear what they need to hear in the right order, how to run the individual and all-hands conversations, and how to stabilise the team in the weeks that follow.

A restructure is not just an org chart change. It is a change in the psychological contract with your team. People are asking: do I still belong here, do I still have a future here, and do I trust this organisation to make decisions that are good for me? Your communication and behaviour in the weeks around a restructure will shape the answers they form.

When to Use This Playbook

• You are planning a team restructure and need to sequence the design and communication
• You have been told a restructure is happening and need to manage the delivery
• You are part of a larger organisational change and need to translate it for your team
• You have recently completed a restructure and need a framework for the stabilisation period
• You are reviewing a restructure that went badly and trying to understand what happened

Before You Start

Be honest about why you are restructuring:

Before you design anything, be clear - honestly, not politically - about the reason. The most common genuine reasons for restructure:

• The team has grown and current structure creates bottlenecks or coordination cost
• The product or service has changed in a way that the current structure no longer reflects
• The technology has changed (e.g. moving to a platform model, breaking up a monolith)
• External change - a merger, an acquisition, a strategic pivot
• Performance is not where it needs to be and structure is a genuine contributor

The most common reasons a restructure is a bad idea:

• A new leader wants to put their stamp on things
• There is a performance problem with one or two people and restructuring feels easier than addressing it
• There is a relationship problem at the top and restructuring avoids the conversation
• The team is underperforming but the root cause is clarity and leadership, not structure

If the honest answer is one of the bad reasons, do not restructure. Address the real problem.

Check your assumptions:

The two most dangerous assumptions in restructuring are:

1. "The design is obvious." It rarely is to the people affected. What feels logical to the person who designed it may feel arbitrary or unfair to those living it.
2. "People will adapt." Some will. Some will leave. Some will stay and disengage. Do not assume resilience. Plan for it.

The Design Process

Step 1 - Define the problem you are solving

Write it in one paragraph. If you cannot, the design process is premature.

"Our current squad structure creates two problems. First, our platform team is a dependency for every squad and is constantly at capacity, which slows delivery across the board. Second, our data and analytics capability is spread across three squads, which means no squad has enough of it and we are duplicating work. We want to move to a platform model that reduces coupling and collocates data capability."

Step 2 - Define the design principles

Before you draw boxes and lines, agree the principles that should guide the design. Common principles in engineering team design:

• Minimise coordination overhead between teams
• Each team should be able to deliver end-to-end for their domain
• No team should be a blocking dependency for another
• Cognitive load per team should be manageable (Team Topologies: a team should be able to own what it maintains)
• Teams should have stable, long-lived membership where possible

Step 3 - Apply Team Topologies thinking

Team Topologies (Skelton and Pais) provides the most useful framework for engineering team design. The four team types:

The goal is maximum number of stream-aligned teams with platform and enabling teams that genuinely reduce their burden. If your "platform" team is a bottleneck rather than an enabler, it is designed wrong.

For each proposed team, ask:

• What does this team exist to deliver?
• Who are its customers (internal or external)?
• What are its dependencies? Can those dependencies be reduced?
• What is the cognitive load? Is it manageable for a single team?
• What capability does it need? Does it have it or can it acquire it?

Step 4 - Test the design with a small group

Before the design is final, test it with a trusted set of people - typically senior engineers or tech leads who will be in the restructured organisation. Not to get approval, but to stress-test the design and find the problems before they become communication problems.

Questions to ask in this session:

• "Where do you see this creating friction?"
• "What would this team spend most of its time doing? Does that feel right?"
• "What dependencies am I not seeing?"
• "Is there anything this design makes harder that is currently working well?"

Take the feedback seriously. Adjust the design where the feedback reveals a real problem. Do not adjust it where the feedback is "I don't want to move" - that is a communication challenge, not a design challenge.

Step 5 - Map people to the new structure

Once the structure is settled, map current team members to teams in the new model. Consider:

• Skills and capability fit
• Relationships and team chemistry
• Individual career interests where known
• Any constraints (part-time, location, contractual)

Where the mapping is not straightforward - where someone's role changes significantly, or where you are not sure where someone fits - that is your highest-risk communication.

The Communication Sequence

This is where most restructures fail. The sequence matters enormously.

The rule: no one should hear significant news about their own role from anyone other than you, in a direct conversation.

People finding out from a peer, from an all-hands, from a rumour, or from an org chart update before you have spoken to them is the single most damaging outcome of a restructure process. It signals that they are not valued enough to be told directly. Some people will not recover from it.

The sequence:

Stage 1 - Your manager and peers

Before you communicate to your team, your manager needs to know the design and have approved it. Your immediate peers (other managers at your level) need enough context to avoid creating confusion when their teams ask questions.

Stage 2 - Your HR partner

Involve HR early if any changes involve role elimination, significant role changes, or anything that might engage employment rights. Do not start communicating to individuals until HR has reviewed the plan.

Stage 3 - One-to-one conversations with each team member

Before the all-hands. Every single person. In the order of most to least impacted.

People whose roles change significantly go first. People whose roles are largely unchanged go later. The all-hands happens only after everyone has had their individual conversation.

Stage 4 - The all-hands

The all-hands is for the full picture, the why, and questions. It is not for breaking news.

Stage 5 - Broader communication

Stakeholders, adjacent teams, anyone who interacts with your team and will be affected by the change.

The Individual Conversations

Preparation

For each person, have clear answers to:

• What is changing for them specifically?
• What is staying the same?
• If their role changes - how does it change and what does the new role involve?
• If they move teams - who will their manager be?
• What can you say about the rationale for the decision as it relates to them?
• What questions are they likely to ask and what are your honest answers?

Questions you may not be able to answer yet

In any restructure, there are things you do not yet know. Be honest about this. Do not make up answers. Do not be vague in a way that sounds evasive.

"I don't have the answer to that yet. What I can tell you is [what you do know] and I will come back to you on [what you don't know] by [specific date]."

The structure of the individual conversation

Opening - set the context:

"I want to talk to you about some changes we are making to how the team is structured. I wanted you to hear this directly from me before we communicate more broadly."

Describe what is changing:

Be direct. Do not bury the key information in context. If someone's role is changing, say so early.

"We are restructuring into three teams aligned to product domain. You are going to be moving from [current team] to [new team], where you will be working on [area]. Your manager will be [person]."

Explain the rationale:

"The reason for this change is [genuine reason]. The current structure creates [specific problem]. The new structure addresses that by [how]."

Allow time for reaction:

Do not rush to reassurance. Give the person time to respond. Some people will ask questions immediately. Some will need a moment. Silence is okay.

Address impact specifically:

"I know this is a significant change. What are your initial reactions?"

Answer questions as fully as you can:

If you cannot answer something: "I don't know yet and I will find out. I will come back to you by [date]."

Close with next steps:

"I am going to speak to the rest of the team individually over the next [timeframe]. We will have an all-hands on [date] to share this with the full group. In the meantime, please feel free to come to me with anything."

Conversations where the news is harder

If someone is being made redundant, their role is significantly diminished, or they are being moved to a role they clearly do not want:

• Have HR involved or available
• Be compassionate but direct - do not soften the message to the point of ambiguity
• Do not make promises you cannot keep ("I am sure it will work out")
• Give them space and time
• Follow up the same day

The All-Hands Announcement

The all-hands is for the full picture, for the why, and for questions. By the time it happens, there should be no surprises in the room.

What to cover:

1. The context:

"We have been thinking about our team structure as the product and organisation have evolved. I want to share the changes we are making and the reasoning behind them."

2. The honest why:

"The current structure has created [specific problem]. As a result [specific impact]. The new structure addresses this by [how]."

Avoid corporate-speak. "To better align with our strategic objectives" tells people nothing. "The current split means that three squads all depend on the data team for every release, which is slowing everyone down" tells them something real.

3. The new structure:

Show the new org chart or team diagram. Walk through each team: what it does, who is in it, how it interacts with others.

4. What this means in practice:

"Most of you have already had a conversation with me about what this means for you specifically. For anyone with questions about their individual situation, please come and talk to me - or if you would prefer to do that in writing, I am happy to do that too."

5. What happens next and when:

"We are moving to the new structure on [date]. Between now and then, [what happens]. In the first 30 days, we will be [what]."

6. Questions:

Take live questions. Prepare for the hard ones. Do not dodge them.

Hard questions you are likely to get:

"Why was this decision made without involving us?" "We did involve a number of people in the design. I also want to be honest that some decisions are for the organisation to make, and those include how we structure the team."

"What if this does not work?" "We will be reviewing how the new structure is working after 90 days. If we find real problems, we will address them. We are not locked into this forever."

"Is anyone's job at risk?" Answer this directly and completely. If no one is at risk, say so clearly. If there are redundancies, do not imply there are not.

"Why is [person] going to [team]?" "I am not going to go into the individual decisions for other people in a group setting. If you have specific questions about your own situation, let's talk separately."

The First 30 Days After the Restructure

The restructure announcement is not the end. It is the beginning of the hardest part.

Stabilise before you optimise

The temptation after a restructure is to immediately start making the new structure work better - new processes, new ways of working, new tools. Resist this. The team needs to stabilise first.

In the first 30 days:

• Focus on relationships. New team members need to build working relationships.
• Keep delivery expectations realistic. Velocity will dip. This is normal and temporary.
• Increase your cadence of 1-1s. People have questions that did not surface in the all-hands.
• Resolve the open questions you committed to answering. Every unresolved question is a source of uncertainty.

What to watch for in the first 30 days

Flight risk signals:

• Reduced engagement in meetings or 1-1s
• Taking annual leave they had not mentioned previously
• LinkedIn activity increasing
• Asking about role definition, career path, or compensation with new urgency
• Giving minimal answers in 1-1s

If you see these signals in someone, have a direct conversation:

"I have noticed [observation]. I want to check in - how are you feeling about the changes and where things are going?"

Productivity dip:

Normal and expected. New team relationships take time to form. New ways of working take time to establish. Communicate this expectation to your stakeholders before the restructure so they are not surprised.

Informal leader reactions:

Every team has informal leaders - people whose opinion others form around. If an informal leader is sceptical about the restructure and you have not addressed their concerns, their scepticism will spread. Identify who these people are and invest disproportionate effort in understanding and addressing their concerns.

The person who is quieter than usual:

The people most likely to leave quietly after a restructure are not the loudest complainers - they tend to surface and work through their concerns. The risk is the person who goes quiet, processes their dissatisfaction privately, and then hands in their notice three months later. Go to them, not wait for them to come to you.

How to Declare Success

A restructure is successful when:

• The problem it was designed to solve is actually solved - teams are delivering more independently, dependencies are reduced, cognitive load is manageable
• The team is performing at or above pre-restructure levels within 90 days
• Attrition in the 12 months following the restructure is not above your baseline rate
• People understand their place in the new structure and can articulate what their team does
• The informal feedback you are getting from the team is net positive

Run a 90-day review:

• Have the design principles been met?
• What is not working as expected?
• What adjustments are needed?

Be willing to make adjustments. A restructure is a hypothesis about a better way to organise. Treat it as one.

What Good Looks Like

A manager who handles a restructure well:

• Is honest about why the change is being made - does not dress it up in strategy language
• Designs the structure around outcomes, not reporting lines or political considerations
• Speaks to every individual before the all-hands
• Does not let anyone find out significant news about their role from anyone other than their manager
• Prepares for hard questions and answers them directly
• Sets realistic expectations about the productivity dip
• Increases their presence and 1-1 frequency in the weeks following the change
• Watches for flight risk signals and acts on them
• Reviews the structure at 90 days with genuine curiosity, not confirmation bias

Common Failures

Restructuring to avoid a harder problem. A performance issue, a relationship problem, a leadership failure dressed up as a structural solution. This always becomes visible, and when it does, trust is destroyed.

Letting people find out from someone else. The most common and most damaging failure mode. You ran out of time, or you communicated to a group before you had spoken to everyone individually. Someone finds out in the all-hands. They disengage immediately and often permanently.

Being evasive in individual conversations. Softening the message to avoid discomfort creates confusion and then anger when reality becomes clear. Be compassionate and be direct.

Moving too fast. The design is not tested, the communications are not sequenced, the all-hands happens before the individual conversations. Speed here is a false economy.

Optimising before stabilising. Immediately implementing new processes, new metrics, and new expectations on top of a team that is still adjusting to who their team mates are. Give it 30 days.

Treating the all-hands as the hard part. The all-hands is visible and feels high-stakes. The real work is in the individual conversations and the 30 days that follow.

Not declaring success clearly. The restructure is never officially done, which means the team stays in uncertainty. Set a 90-day review date, run it, and communicate the outcome.

Checklist

Design Phase

• Problem being solved defined clearly in writing
• Design principles agreed
• Team Topologies (or equivalent) framework applied
• Each team's purpose, customers, and cognitive load assessed
• Design tested with a trusted group before finalisation
• People mapped to new teams
• Hard mapping decisions identified and prepared for
• HR involved where role changes or redundancies are involved

Communication Planning

• Communication sequence mapped (who hears what and in what order)
• Individual conversations planned for each team member
• Order confirmed - most impacted people first
• Open questions identified - what you cannot yet answer
• Answers prepared for likely hard questions
• All-hands date confirmed - after all individual conversations are complete
• HR available for conversations involving significant role changes

Individual Conversations

• Every team member spoken to before the all-hands
• Each person told what is changing for them specifically
• Rationale explained in plain language
• Open questions followed up by committed date
• Emotional reactions given space - not rushed to reassurance

All-Hands

• New structure presented clearly with visual
• Honest rationale given (not corporate-speak)
• Hard questions answered directly
• Next steps and timeline confirmed
• Individual follow-up offered for anyone with specific questions

First 30 Days

• 1-1 cadence increased
• Open questions resolved and communicated
• Productivity dip expectation set with stakeholders
• Informal leaders identified and engaged
• Flight risk signals monitored
• Stabilise-before-optimise principle applied

90-Day Review

• Review scheduled at the time of the restructure announcement
• Design principles reviewed - have they been met?
• What is not working identified with honesty
• Adjustments made where needed
• Outcome communicated to the team