You’ve outgrown your current team setup but find it hard to figure out a better one that fits your reality.

When setting a new org structure it’s easy to pinpoint a few areas that are cleanly scoped and valuable, but then there is the rest. You still need to maintain the technology you built, there are domains that might be less clear on what value they bring and who their customers are, but you know they’re needed. And you need to figure out where to put your leaders (you probably lack some or have too much of a capability you don’t need anymore).

There is not one perfect setup, but if you start off with clarity on what you want to optimize you’ll find the most impactful way to organize your technology, teams and leaders.

Step 1: Define current state and future state

The crisper and clearer your trajectory is, the more likely you are to get there. On the other hand, it’s easy to underestimate the demands of the existing technology your teams have built. To get domains that push toward new impact without forgetting your existing commitments, you need to clarify where you’re heading (in metrics) together with a full inventory of what you own today and what competence you have.

Outcome: Blueprint of target domains with their KPIs and missions, plus a full inventory of your existing technology, team capabilities, and capacity constraints.

Product: Define your impact

What impact are you optimizing for? This will start to shape the different domains you’re looking for, what KPIs you’re pushing.

Start with these questions:

1. If you had one overarching metric you could push with the complete unit, what would it be?
2. How does that break down into the next level of metrics? These don’t need to be measurable yet, but get them down as “increase X” or “# of onboarded Y”.
3. Group these into boxes with key metrics and a mission. All of this can be iterated on later, but strive to be as clear as possible so you can stress test your thinking and understand what’s missing.

Now you have a blueprint for the new teams and the language to talk about trade-offs in the next phase. When two domains both need staffing, you can go back to which metric matters most and let that guide you instead of how things always have been or emotions.

Technology: Inventory your reality

Inventory all technology owned by the different teams. List everything and categorize it.

For each technology or system, capture:

• What part of the product lifecycle is it in? (emerging, stable, sunsetting)
• How much maintenance does it require?
• Level of complexity
• How many users does it have?
• Level of stakeholder management needed
• What business promise does it fulfill?
• Suggested actions (deprecate, automate, maintain)

This inventory shows you where your current commitments are. You might discover that 60% of your engineering capacity is maintaining systems or dealing with unnecessary complexity. That’s useful information for scoping what’s realistic AND pinpointing core work needed, like deprecating technology or lowering maintenance cost through automation to free up capacity going forward. Note all these ideas in the spreadsheet as well.

People: What skills do you have

Also do a quick inventory of skills and seniority across teams. You don’t need a full competency matrix, but you need to know what expertise exists and where it sits.

Step 2: Create your buckets

The reason some technical systems are harder to scope into clear product domains is simply because they have not gotten enough product love. There is work connected to understanding who users are, what metrics they push, how they link to value chains.

In this step you’ll do your best work to group technology into what impact you want them to drive. You’ll also identify what product work might be needed to mature the understanding and use of these systems.

Outcome: Draft domains with technology mapped to them, initial scope defined for each, and a decision point on what’s good enough to move forward with.

Map technology to impact

Group related work, technology, and impact goals into areas that make sense for roughly one team to own into “buckets” I call them this to signal that this is work in progress and not decided domains yet. This is collaborative work, best done with other leaders or senior people who understand the technology and product landscape.

• Put the different boxes with key metrics and missions on a board (physical or digital).
• Start to sort in the systems under these different boxes. These are now your buckets!
• For every bucket, note the top work they will face. For example: deprecate X and Y, get maintenance time down, get metrics in place, do product discovery for Z.

You’ll move things around several times. One technology might naturally sit under two domains, can you split it? Where does it provide most value (aka contribute most to the metrics) Talk through the dependencies, the user overlap, the strategic importance.

Always come back to what you want to optimize for and the metrics. It is ok to add and remove areas, but watch out for defaulting back to old thinking because of decision fatigue.

After a few iterations you’ll have something good enough to try.

Step 3: Determine team composition

This is where you become very concrete on what the new organisation will look like. We’ve deliberately held this off to let the future needs become well defined before starting to map people, ensuring we push for our vision over maintaining the status quo.

Outcome: Team size, competence requirements, and leadership needs identified for each domain, with decisions made on hiring, growing talent, or descoping.

Analyse team size and competence

For every bucket, analyse team size and competence needed.

You’ll probably notice you are short on people, but before cutting scope, challenge your thinking: can you sequence things smartly, can you free up capacity over time with any of the projects you identified in step 2 etc. I’ve never met a team who didn’t have work to do, it’s a story of making sure they are pushing as much impact as possible.

Analyse leadership needs

Next up use leadership. What type of leadership do you need for each bucket? Consider:

• Internal politics and stakeholder management needs
• Type of product work (greenfield vs. maintenance vs. transformation)
• Type of interactions with other parts of the business

Are you missing competence to achieve this?​
Look at each domain’s needs against the people available. If you’re missing a critical skill, you have three options: hire, grow someone into it, or descope the domain’s ambitions until you have the capability. Make decisions on that as well.

By now you have identified metrics, scope, ownership, team size, strategic projects. You can officially remove the Bucket label and replace it with “Teams”.

Step 4: Bring the organization in

Outcome: Team members and leadership assigned to the new teams with clear ownership of KPIs, technology, and expectations (including what to deprecate).

This step works very differently depending on your company culture. You could have team members choose where they want to go, or you could be top-down and decide who goes where.

Bottom-up can build the most agency in the organization. Actively choosing where you want to contribute sparks motivation and ownership. Top-down might be required by your labor laws or even preferred by your type of organization (some people see it as the leader’s job to make these decisions). Either way, make sure you motivate your team members to step into the new roles and spend time mapping out why this is a good fit and how they can grow.

Show the full thinking

As you introduce the new domains, be sure to show the overarching goal, how the different domains fit together, and WHY you’re doing this. Spending time upfront is needed to get the teams on board. Do this through slide decks, docs and presentations, Ask me anythings, 1:1s etc. Allow teams to digest the information and give them room for questions.

Get people’s perspective on the setup

This helps you understand where the new org will be strong vs. weak, what won’t work.

Create space for input, but make it clear which things are open for discussion and which are decided. You can ask “what concerns do you have about your domain’s scope?” but not “should we even do this restructure?” Stay open to learning while still moving forward.

Be prepared to guide different teams differently

Make sure to spend extra time in the beginning shepherding this transition.

Some teams will hit the ground running because they have clear scope and experienced leadership. Others will need more check-ins because the scope is new or the team is still forming. Spend time in the first month understanding which teams need more support and show up consistently for those. Watch for signs like unclear priorities, people stepping on each other’s toes, or decisions getting stuck.

Conclusion

With this framework you’ve organized your technology and people for the impact you want. You’ve identified what type of technical work and product work is ahead, and you’ve thoughtfully put the right leaders and teams in place with a realistic understanding of what their journey will look like.

Your work as a leader continues as the teams settle in and you learn what adjustments are needed, but you’re starting from a solid foundation. You’ve moved from a setup where pieces didn’t fit the puzzle into a clear story with momentum behind it.

I’d love to hear how this framework works for you and what you’d adapt for your context.