
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 organisations is an invaluable skill. Here are a few ways to get to a shared understanding, and frame disagreement to find alignment.

Alignment across organisations


Beyond contextual reasons why this would be a timely read to me, [Julie Zhuo](http://juliezhuo.com/)'s [The Making of a Manager](http://juliezhuo.com/book/manager.html) is a great book. One reason to start with is Julie's story: she was Facebook's first intern grown into VP Product Design in her 13-year long tenure.

The book's chapter structure expresses the same progression than the title, as it starts with "what is management" and ends up in "nurturing culture". Surprisingly though, as the chapters have minimal dependencies between themselves, the book is easy to pick from where you left and to go to a chapter further and come back afterwards as you wish.

Furthermore, beyond going over foundational management themes in an unpretentious tone such as how to give feedback, how to run meetings and how to hire and build teams which work well together, the book also covers some concepts which were very interesting to think about.


### Concept #1: The multiplier factor

Very early on the book Julie talks about how **managers have the responsibility to be a multiplier factor to the team**. That is, **a manager's responsibility is to improve the outcomes of a team**. Through a metaphorical growing business story, a lemonade stand, she mentions how common it is for one transitioning into management roles to hesitate reducing or stopping their individual contribution as a response to the fact that it will reduce the team's pace, at least temporarily, and get it further away from its goals.

The trade-off on slowing short-term is a fair one: as the book mentions, there is much more to yield through finding opportunities that make the team more efficient as a whole. Regardless if it is by finding skill gaps, fixing process flaws or mentoring team members  – you will be able to add a multiplier factor to your team's outcomes if you focus on figuring out what is slowing you down, or in what could be better.

Even though the book attains itself to the context of individual contribution to line management progression in this chapter, there is clear applicability to progressions from line management to senior management roles too. Given the similar paradigm involving responsibility shifts and the counter-intuitive reality of the new position – less depth and further away from the craft, more breadth and larger context switch propensity – you will likely have to gradually step back and repurpose your contribution at a different level.

### Concept #2: The critique meeting

Another great concept Julie talks about is the critique meeting. Here is how it works:

- The team gets together and spends 90 minutes every week to share their progress for the week to each other;
- One team member starts the presentation and shows what they've achieved and then opens up for questions, concerns or suggestions;
- Every other team member raises their points, asks questions, proposes other approaches and expresses their point of view, regardless of whether the criticism is strategic or tactical;
- The presenter then takes notes from the feedback given, agrees on a list of next steps with their peers, and moves the conversation to the next person;
- The process then repeats until everyone had their turn.

I believe the main reason this concept caught my attention is that **every team has different dynamics, and collectively learning how to productively criticise each other's work can take considerable time**. With a structured session centered on criticism, you likely will learn how to give/receive feedback for the team setting much faster, while also reiterating the sense of trust between team members, which is invaluable to any team.

Differently from [agile retrospectives](https://www.agilealliance.org/glossary/heartbeatretro/), where the focus is usually behaviour, attention is sparse, and feedback can be less objective, and from [reviews and demos](https://www.scrum.org/resources/blog/sprint-review-much-more-just-demo), which the primary intention is usually gathering feedback from users or stakeholders making it is shallower from a technical standpoint and outcome-focused, **the critique meeting results in specific feedback by design**, has narrow focus with the intention of raising concerns, giving feedback, finding consensus of next steps, and then holding each other to account for progress and improvement.


### Concept #3: Peg your work back to the mission

Another very entertaining part of the book is Julie's story on how her team approached the extension of Facebook's iconic Like button. For context, Facebook's mission statement is "to give people the power to build community and bring the world closer together", which makes that specific capability – liking a post, a photo, etc. – an incredibly strategic feature.

When extending the design of one of the platform's most critical features, options were many, including a "dislike button". Even though it sounds like a good idea at first sight, additional insights guided the feature's extension in another direction.

Whilst diving deeper into the user's motivations, Julie's team found some interesting insights. Firstly, users were asking for a dislike button, although this was an oversimplification of how they felt. "Dislike" in fact means a range of emotions which are can be more specific such as sadness, anger, surprise. But most importantly, a dislike button doesn't get you any closer to _bringing the world closer together_. It actually sets people apart. With that said, the team decided to pick another route which made more sense.

In conclusion, it is easy to disconnect yourself from the company's mission, especially when you are trying to make a decision which can feel very practical, or when you feel under pressure to move on. With that said, **a great candidate [eigenquestion](https://coda.io/@shishir/eigenquestions-the-art-of-framing-problems/eigenquestions-3) for hard decisions is "how does this fit into the company's mission?"** as it can likely help you reframe the problem, as a consequence of that, pick a better solution instead, and also increase your cohesion to the overarching goals.

### Concept #4: Aim to put yourself out of your job

Lastly but certainly not least, as this is my favourite concept in the book, Julie talks about how her process for delegation is "aiming to put herself out of her job". Expanding on that, her work delegation strategy comes from working on the intersection of two factors:
- Most important things for the organisation;
- Things I can uniquely do better than anyone in/for the team.

If the task at hand isn't both, you should delegate. Here is her rationale on the subject:

1. **If anyone in your team can do one of the most important things either as good as you or better than you, delegate it.** This will allow them to increase their impact while freeing you up to pursue further support other opportunities for the team.

2. **For things you can do better and are not necessarily the most important ones, delegate to someone interested in the challenge and coach them to achieve it.** This will be a valuable learning experience for them and will help you reduce this capability gap in your team.

3. That leaves to you things that align with your skillset and are most impactful opportunities to work on within your remit. **These should be your priorities** – for the time being.

In due time, as you delegate enough lower risk opportunities, the team will be better positioned to do the most important things for the organisation which they initially couldn't. As that happens, firstly, you have fulfilled your role as a manager by improving the team's performance to achieve better outcomes. As a consequence to that, you are also taking care of succession planning, which as Julie says, puts yourself out of your job – but for your team's growth and your own progression's sake too.

Even though many management book authors talk about the motivations and mechanics of delegation such as growing people, managing risk, and the dynamics between full abdication at one side of the spectrum to being overly prescriptive/protective at the other side, what I particularly love about Julie's lens on this subject is her pragmatism on putting together an incredibly simple framework that is practical and has unambiguous criteria for putting it into practice.

---

In closing, [The Making of a Manager](https://www.amazon.com/dp/B079WNPRL2/) was a refresher to some extent, by bringing me back to my first management experience. It also reminded me of how it is fundamental to focus on building a strong foundation and gave me a pragmatic perspective to subjects which are often spoken about but very rarely fleshed out that simply and clearly.


My favourite concepts from "The Making of a Manager", a book written by Facebook's former VP Design, Julie Zhuo.

Review: The Making of a Manager


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 language.

Product Development

Alignment across organisations

Review: The Making of a Manager

Language as a tool for engineering teams