
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.

<Image src="/assets/uploads/2021-10-29/boats.webp" alt="Boats in alignment" caption="Picture by Simon Micheler on <a href='https://unsplash.com/photos/kALqjIawiv0'>Unsplash</a>" placement="default" width="450" height="300" />

### 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](https://www.productplan.com/blog/build-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](https://melissaperri.com/blog/2016/07/14/what-is-good-product-strategy) 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](https://lethain.com/goals-and-baselines/)? 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](https://www.cio.com/article/2395825/project-management-how-to-design-a-successful-raci-project-plan.html) 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](https://www.linkedin.com/pulse/decision-making-101-traffic-lights-puppy-case-study-valerio-magliulo/). 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:

<Image src="/assets/uploads/2021-10-29/traffic-light-matrix-en.png" alt="Example of a traffic light decision matrix" caption="Example of a traffic light decision matrix" placement="default" width="710" height="400" />

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"](https://twitter.com/stevesi/status/1275311075508936704) and try to build cohesion beyond reporting lines.


Finding alignment across orgs with different priorities can be hard. It's also an invaluable skill for senior leaders. Here are a few ways to get to a shared understanding, and frame disagreement clearly to ship your product.

Alignment across organisations


I've been a lot more interested in language lately. That's likely due to the fact that I spent some time with other people who talk about the subject often. As a consequence of this, I have paid more attention to how powerful it can be for multiple purposes.

Take the video below as an example. Jacob Collier explains harmony in music to a variety of audiences, starting with a 7-year old and ending with legendary jazz musician Herbie Hancock:

<Video id="eRkgK4jfi6M"/>

I love how in just a few seconds, Jacob can explain harmony in an appropriate language to many audiences, ranging from no technical expertise in music (see 00:00 to 1:05) up to meta-language (see 11:00-12:00). At the final stage, the interactions are wordless – yet, communication is still very much there. That is language's primary purpose, [communication](https://en.wikipedia.org/wiki/Language).

I can't help but draw a parallel to technology, especially when we live immersed in terms, concepts, abstractions which are non-trivial to be understood, such as harmony in music. With this said, there are some areas where language can help engineering teams to be more effective and communicate better.

### Cohesion between team and stakeholders

I think the best example I had in my career so far when it comes to language impacting a relationship with stakeholders and business outcomes was when I was exposed to payments systems for the first time. Trying to make sense of all the domain-specific terminology was terrifying. I remember trying to make sense of card authorisation, capturing funds,  clearing funds, settlement, reversals vs refunds vs voiding, chargebacks... it was even harder trying to understand how these are connected when my stakeholders would articulate the same concepts in multiple different or interchangeable ways.

My main takeaway from this experience was that **learning something new can be challenging, but when language is loose between business and technical folks, it makes everything much harder.**

My favourite approach to this problem is [Eric Evans' on Domain Driven Design](https://www.amazon.com/exec/obidos/ASIN/0321125215/domainlanguag-20). Here's a summary, in my words, of how he describes this problem in the book:

- When stakeholders and technical teams do not share language you have serious issues, as each group builds its understanding in a siloed manner;
- Because each party has its language, translation is expensive at best, or incompatibilities are unnoticed at worst;
- This situation ends up bleeding into system design and code, which may render technical jargon or domain-specific concepts incomplete or wrong;
- And to the same degree, language used by stakeholders doesn't serve the technical team's needs, leaving both in further isolation from each other.

The proposed way to solve it is what Eric coined as _Ubiquitous Language_: having a shared language which articulates a [domain model](https://en.wikipedia.org/wiki/Domain_model) in a simple, concise manner, without leaking implementation details or excessive domain-specific jargon. Everyone uses and plays a part in building this shared language. **The outcome is a language which you can use everywhere as it is representative of the domain at the right level of granularity and abstraction** for any context, hence useful for both technical teams and domain specialists.

Even though not related to a stakeholder/engineering team relationship, _Ubiquitous Language_ can reduce the learning curve for onboarding, support internal talent mobility, facilitate inter-domain knowledge sharing, and lower the bar for engineers to have a broader impact within a domain.

### Goal setting and accountability

When it comes to setting goals, it is common to use a combination of expected impact and measurable outcomes to achieve that impact. [OKRs](https://www.whatmatters.com/faqs/okr-meaning-definition-example/) are a great example of how to do that. Here are some ideas on how to improve a goal through language.

Firstly, **the benefits of achieving a goal should be obvious.** If it is hard to articulate the value yielded by achieving a goal, this could potentially be solving for the wrong problem, or just be masking the symptoms of a problem. It is even harder as part of a team, as there is a natural inclination towards confirmation bias and herd behaviour and the other team members can easily empathise. When challenging whether or not this is the right problem to be solved, one technique that can help is [five whys](https://en.wikipedia.org/wiki/Five_whys).

**To make the goal itself obvious, language should be simple.** To achieve that, avoiding overly technical terms, acronyms, component names, nicknames/aliases, business/domain-specific language, or lingo someone outside of your team wouldn't understand can help. Using such terminology in the context of extremely technical teams is fine as long as that's a conscious trade-off, as if someone new joins or there is a need to articulate the goal outside of that team, it will be harder to make the goal informative to them.

Moreover, **a goal should be opinionated and outcome-focused instead of output-focused.** An excellent read about this subject is [Phil Calçado's article on how he approaches OKRs](https://philcalcado.com/2020/01/31/how_i_like_to_use_okrs.html). Drawing the parallel of using KRs as the test to the Objective is very interesting from a language standpoint as there is an inherent opinion of what achieving the desired impact is through the choice of measurable results.

Finally, **goals shouldn't be bendable.** As a result of ambiguous language, I have seen goals be relativised unintentionally. Language should support accountability and keep the team honest about what success looks like. Ways to remove ambiguity include the choice of words for an objective and key results as previously described, but also the options on how to grade key results on review sessions. Common ways to do it are through a boolean outcome ("yes"/"no") which has less inclination to ambiguity, and percentages (x% completed) or statuses (completed, pending, in progress) which have more tendency to ambiguity.

In short, **a well-written goal has an obvious upside and is written in simple language**, has an obvious why, one or a set of obvious "how much"s, and should communicate what success looks like very clearly.

### Metrics and baselines definition

Metrics are a fundamental part of goal setting, but goals also implicitly call for focus. **It is hard to articulate a metric concisely while capturing all the nuances of that measure** such as supporting metrics, baselines for competing metrics, or upstream or downstream consequences of optimising for a specific goal.

Nevertheless, it doesn't mean that a metric that isn't driving a goal isn't relevant. Not paying enough attention to supporting metrics or competing baselines might set you off course by meeting the target which you expected in a goal, yet not delivering the value which you expected. As [Goodhart's law](https://en.wikipedia.org/wiki/Goodhart%27s_law) explains well:

<Quote quote="When a measure becomes a target, it ceases to be a good measure." author="Charles Goodhart" />

To exemplify, imagine a hypothetical situation of a set of teams responsible for onboarding new users to a product, with the goal of "increasing the number of registered users by 20% within the first half of the year". When over-indexing on lead quality, there is increasing friction through identity checks, which will increase churn and turn into additional cost upstream, on advertising for lead acquisition. On the other side of the spectrum, there is over-indexing on intake, which then will incur into fraud costs downstream for misuse of the product, or additional operational overhead for terminations for fraud reasons.

**A way that language can help is creating a new metric**, let's call it for the above example "genuine registration" **which takes into consideration both baselines** – keeps identity check churns at \<5% and identity fraud declines at \<0.1%. The new goal would be "increasing the number of genuine registrations by 20% within the first half of the year". That's a much more transparent metric: adding sign-ups while maintaining quality and intake at the same levels. As a complementary effect new metric is now attainable to the domain that set of teams owns and can help with focus with what must be done:

- What could be done to improve the user experience when signing up?
- What can we do to reduce friction or churn when signing up?
- Which other ML fraud model features we can use for predicting fraudulent behaviour when signing up?

This technique turns out to be helpful not only when you have associated baselines, but also when you have implicit supporting metrics or a complex definition where value comes from. A great example of this is [monthly active users (MAU) and daily active users (DAU)](https://en.wikipedia.org/wiki/Active_users). Every product will have its  definition of what "active" means, such as product usage or engagement time. You can dive in if you want, or just get the information that you need from the word "active" itself.

An interesting read about baselines is [Will Larson's article on Goals and Baselines](https://lethain.com/goals-and-baselines/) where he explains similar dynamics to the above and a different approach to goal setting which I found very interesting.

___

In closing, as Jacob Collier shows incredibly well in the video at the beginning of this article, language is most effective when it is considerate of the audience. It will take different forms and shapes in different settings. The most exciting part of this journey is being open to trying and figuring what works out together.


A take on how to overcome problems engineering and product development teams face with stakeholders, goals and metrics through an universal, yet very powerful tool: language.

Product Development

Alignment across organisations

Language as a tool for engineering teams