Alignment across organisations

Especially in large companies, organisational design may not reflect the product you're building. As much as you try to align people to problems, there will eventually be distributed expertise across the company. As different teams may have different priorities, alignment across organisations becomes a very valuable skill to have.

What creates misalignment?

Misalignment, for most of the time, is unintentional. In a healthy culture, most people will want to support and enable you to ship your product. Although, there's only so much you can do when you are focused on things that you believe are the most important and have no additional bandwidth left. Some of the main reasons I've seen teams get stuck in misalignment include:

Diverging prioritisation. Teams should have the autonomy to set their priorities. Sometimes there will be disagreement in how high a shared project ranks in the roadmap of different teams.

Disproportionate or unilateral funding. It's not rare to have organisations working in similar domains being funded through different cost centres. What may happen is that funding happens for one side, but not for the other, or, on a lighter version and not necessarily less harmful, there are disproportional investments in both sides. In short, there's an asymmetry in the ability to execute against the original plan.

Increase in scope given iterative discovery. Even when planning cycles are perfectly aligned, discovering a larger opportunity due to research, data, or customer insight after planning deadlines may mean you have less flexibility to pivot.

While you likely can sort out this type of misalignment tactically, for instance, by persuading a partner team to bump a priority or trimming down the scope to fit the initiative in both teams' capacity, repeated behaviour can make both sides feel stuck with each other. I believe the root cause for this kind of situation is very frequently in either lack of shared understanding or disagreement in broader-level prioritisation.

Getting to a shared understanding

John Cutler has a very good take on what is shared understanding. Rather than "short-lived alignment", shared understanding is a state of alignment through direction rather than a destination. Some of the common traits I've observed in teams who have this type of long-lived alignment are:

1. Shared purpose. Even though it might sound obvious, it is easy to neglect whether or not you have a shared purpose for collaborating. Collaboration is not always the answer – you can probably name multiple companies which survived large-scale duplication for the sake of speed of execution or to avoid premature optimisation. If you choose to collaborate, though, the purpose should be clear. You can define a shared purpose by writing a joint vision statement, or even further, a joint product strategy. There are many great resources on how to do it (this article by Melissa Perri has a very useful canvas). If you lack ideas on where to start, a good starting point to find a common thread is facilitating a session where both teams abstract previous and future shared projects into themes together.

2. Clear outcomes. One level down is trying to understand what you're effectively trying to get from the collaboration. Do different teams contribute to different parts of the puzzle? Or maybe both teams play together a balancing act such as metric/counter-metric? The expected outcome should be specific, but not to a project (short-lived), but to the collaboration between the teams itself (long-lived). For tangibility purposes, consider two teams, one accountable for intake (customer acquisition) and another for quality (retention, user experience). Everyone will likely agree that low quality is irrelevant for a product without customers, and intake is irrelevant if every user churns because of low-quality experiences, but what means success for this group? In which proportion each role should be played? It could be, for example, meeting revenue goals without decreasing retention by more than 2%.

3. Collaboration model. Equally important, every collaboration needs well-defined ways of working. You want to avoid a situation where you need to rediscuss accountabilities, how to measure progress towards the outcome, and how to deal with eventual risks for every new project. The collaboration model is a set of expectations on how do you operate the two teams as a broader team. Some good practices I've seen include:

   • Formalising a "virtual team" with some representation of both teams and exclusive commitment or high priority for a longer timeframe than a planning cycle. Doing so helps not only with focus but also with effectiveness as people will gel over time;
   • Using RACI matrixes to align on who does what. They help to unveil misunderstandings on accountabilities and prevent communication gaps;
   • Defining how to measure progress together. It could be through metrics, a set of "ship" goals, or by untangling a big unknown into smaller unknowns. The end goal here is for the joint team to hold each other accountable for progress and have clear expectations of milestones over time.
   • Creating appropriate forums for decision-making, discussing risks or blockers, or any other unstructured subjects. Doing so prevents having to catch up with different people on why a decision was made, or which trade-offs were discussed, as the group is always part of these discussions.

Assuming that everyone agrees about purpose, outcomes and how to work together, and the ambiguity about priorities, funding and opportunities is likely to go away. When prioritising, different teams share a sense of the prioritisation criteria, funding dependencies are well known and can be flagged by both parties, and everyone will be happy to shift projects if new information comes in, as there's alignment on target outcomes. The overarching point is that alignment only lasts if it isn't made at the project or workstream level (short-lived) but at the team/organisational level (long-lived).

Sometimes, though, disagreement exists in principle.

Framing disagreement for alignment

More often than not, people are afraid of disagreement, and it can be uncomfortable, especially when you have two groups of people who are very convinced that they're right. Although, worse than disagreeing is not reaching to a conclusion. The best way I've seen people untangle this type of situation is to frame the disagreement together by agreeing on the fairest representation of reality and escalating it up the reporting chain in the form of a traffic light decision matrix. This is how it works:

1. Pick a list of criteria: describe what the dimensions you're trying to get a decision on are;
2. Have each team define one option, and define how it affects each criterion;
3. Represent the trade-offs you are making by colour-coding each cell of the Criteria × Options matrix.

The result should look like something like this:

Rather than spending weeks in convincing, which can be extremely painful, asking for help is usually the fastest way forward. By fairly representing the situation together, teams will help both reporting lines to be in a position to make the best decision. As a potential side-effect, there might be alignment on the suitable trade-off for other similar situations in the future.

While this is an oversimplification of the subject, finding alignment across organisations can be very useful. Organisational boundaries help to increase cohesion, but the most successful folks I've worked with do not "ship the org chart" and try to build cohesion beyond reporting lines.