Reorganising teams through experimentation

Similarly to systems, as engineering teams grow, you get to points where you need to iterate the design and optimise for different characteristics. You also don't want to over-engineer, as optimising for future cases can lead to undesirable consequences. That's a point in time where you might want to consider a team redesign or reorg.

Reorganisations are rarely the only way to solve a problem. In fact, they generally are the most expensive and disruptive way. Although, sometimes, reorganising or redesigning is the right call. Some of the symptoms that might indicate this is something to consider are recurring complex dependency management, an overwhelming cognitive load needed to maintain systems owned by a group of people, increased amount of processes to compensate for poor communication, and so on.

A way to reduce the risks of reorganising to solve a problem and end up creating a few more is clarifying the problem, coming up with a hypothesis, approaching change as an experiment and then sharing your findings, which informs the final decision.

Before making the decision

First and foremost clarify what the problem you are trying to solve through reorganising people is. I believe the default inclination should usually be to not go for reorganising. Most of the times alignment at a higher organisational level, reevaluating ownership of systems or responsibilities and introducing better communication practices or processes can help to avoid this decision.

If you are convinced that you need to do it clarify which groups of people are affected by the problem. A way to start is by asking people individually and paying attention to the nuances each person brings. These nuances will serve as input to hypothesis generation.

Once you know who's affected by the problem, collaboratively generate a set of hypotheses for the problem's existence. Understanding people's frustrations is usually a good starting point and then asking why this frustrates them can lead you to a good hypothesis. Liberating Structures are useful for getting everyone's input free of judgement.

Next up draw different ways you could organise people to validate your hypothesis and understand capability gaps each candidate change would generate. Reorganising might introduce risks, and for teams, a large factor is team composition. A change like this can make you lose essential characteristics in a team such as specialised knowledge about a set of components, on-call coverage for operating the footprint the team owns, diluted throughput from a delivery standpoint, and so on.

Then, once you collaboratively find some of the best options, listen to people who are the most hesitant and most excited about each potential change. This will help you gauge whether the split would be healthy for the new teams and people individually too. Ideally, you want to solve for everyone – the organisation, the team and also each individual. Some people might be unhappy with the proposed change, and strong opposers usually have their reasons which can be insightful and cover blindspots from the group.

Experimenting with change

Framing change as experimentation takes some of the pressure of succeeding off and is easier to revert from an administrative standpoint, but also morale and expectation management perspectives. Commit to one hypothesis and approach it as experimentation. As any experimentation, you need to give it enough time to get accurate feedback as there will be a considerable lag between implementing the change and being able to evaluate its effectiveness.

At the beginning you will likely have more crossed wires, people will be more uncomfortable, quality can decrease, and pace might get slower. Let it last long enough to build a fair judgement before making a definitive decision either way to keep or revert. A good starting point is six months to re-evaluate. This time interval will likely match your goal-setting schedule, performance reviews, staffing planning, so giving it enough time will help you understand the consequences of this decision from multiple perspectives.

Set up a feedback loop with team and external parties. Getting feedback from the team is fundamental, but it is usually more straightforward, as you might have established communication channels such as 1:1s and team health surveys. It is also essential to understand what are the external impacts, so spending time with stakeholders and peer teams can help to gauge both internal and external satisfaction and act upon it accordingly.

It can be insightful to re-evaluate if the problems you assumed reorganising would solve are getting solved. You might feel that, anecdotally, the teams are healthier and performing better, but it is essential to understand why. Looking back and understanding what you thought the motivations for doing it were in the first place can help to validate if you are solving the problems from the initial hypothesis itself or something else.

Considering the experiment is being successful, and the new teams are doing incredibly well, you still need to be aware of external factors. One of them is demand: understanding the future needs and how demand and supply evolve over the experiment can be a strong signal to justify either to grow a team further or to be proactively prepared for another plan. The least disruptive way I know of doing this is watching both supply and demand closely and being open about your observations to all parties.

Making the decision

As you feel like the new experiment has reached maturity, share your findings internally and open up for discussion. Will Larson's model, document and share can work well for starting the conversation with an informed perspective rather than an authoritative one, especially if you are the person accountable for the team's success where it can be easy to go top-down unnecessarily.

It is also important to recap what you were collectively trying to achieve and how successful you were on doing it. Set up a retrospective-style meeting to reflect on what went well, what went wrong, what should change and summarise lessons learned. At this stage, you have the opportunity again to build shared understanding and decide how you want to move forward. Use the outcome of this retrospective as input to what you will communicate publicly.

Next up, you probably have a decision made. If you have any folks who are concerned about the change, take your time to listen and understand people's individual needs. Sometimes not everyone will be happy with the change. Unsatisfied people have all the right to want to figure out what future will look like for them, and it is your role and accountability to support them on finding something they will be happy with, preferably within the team or the organisation.

As the next step, regardless of the outcome of the experiment, make your findings public. Go back to the context which generated the experiment, how was it approached, what you have learned during the process and share the change with the audience affected by it. If you think the experiment succeeded, Uma Chingunde has a great post on communicating organisational changes, which is excellent for this purpose.

Change is never easy but is usually for good. I believe the most important aspects for successful team reorgs are finding clarity on why, having people's input on the process, and listening to individuals thoughtfully. Again, rarely it is the only answer to a problem, but if you think it is to yours, experimenting before making a final decision can help you manage risks more conservatively.