On Misalignment

Being aligned is one of the most important parts of working together – that is, having consensus about what you’re doing and how you’re trying to do it. This can be surprisingly difficult! Most teams and organizations have some level of misalignment.

In many cases it is unspoken and unknown: the people involved never stopped to talk about the thing in question, and everyone assumed they were all on the same page. Misalignment can also be intentional, like when stubborn people insist on doing their part differently. Either way, you wind up with different people or groups working against each other when they should be working together.

Types of Misalignment

Misalignment can have a variety of shapes and sizes:

• Horizontal Misalignment: poor consensus between teams or within teams
• Vertical Misalignment: bad communication along the management chain, common when managers don’t trust their team and vice versa
• Temporal Misalignment: corporate amnesia (build a system, refuse to elaborate, leave)
• New-Hire Misalignment: where new employees aren’t given enough context and wind up doing things differently.
• Splintering:, where different groups have consensus internally but not with one another.
• Self Misalignment: where an individual has multiple conflicting goals, or no goals at all. (“What am I even trying to accomplish?”)

Misalignment can happen at any level of an organization:

• Big-Picture: business model, target audience, overall tech stack, etc.
• Mid-Level: conventions, technologies, processes, and how to organize things.
• Low-Level: what individual parts of a system are supposed to do, especially when it comes to edge cases and error handling.

Consequences

In general, misalignment can cause a number of issues:

• Tech Fragmentation, if there’s no consensus on which tools or platforms to use.
• Security problems, if there’s no consensus on what’s supposed to be allowed.
• Poor morale, if different groups of people are working against each other.

The exact consequences depend largely on the type of misalignment. Big-picture misalignment is usually pretty noticeable – the whole company feels like it has no direction – while lower-level misalignment can take longer to manifest. Questions like “What does this piece of code do in this obscure situation?” don’t matter until the obscure situation actually happens. And if the author made the code do one thing, but the larger system assumes the code does another thing, you can wind up with some pretty major bugs.

New-hire misalignment is another one that can take a while to become noticeable. Even once the new hires are up and running, and it’s clear they’re doing things wrong, it may take further time to identify the onboarding process as the root cause.

Getting Aligned

The first step is wanting to be aligned. You have to be willing to put your ideologies aside for the sake of group coherency. Leadership has the toughest job here: they have to take input from the stakeholders and find a viable direction which everyone will be willing to work toward.

Regular meetings are useful for getting aligned. Documentation is invaluable for getting and staying aligned. Both force people to put their mental models into words and try to coalesce around a single one.

For low-level alignment, code reviews and comments are important in the same way. The ideal code review focuses not just on technical correctness, but on what the author’s intentions are. This is why comments are so important: they describe what the author thinks the code does, which helps identify bugs vs features.

Speak the Same Language

All the documentation and meetings in the world won’t help if you’re talking past each other. Software engineering is a fractal of specialization, and sometimes it can ruin your vocabulary. When creating documentation or speaking in cross-team meetings, it’s often worth the extra effort to find language that can reach across sub-disciplines.

Be Flexible

Part of getting aligned is that you might not like the resulting consensus. You can’t win every debate, after all. But in most cases a lousy consensus is better than no consensus. If you like Platform A but your team decides on Platform B, resist any temptation to build your part in Platform A on your own. Your choice is no longer A vs B, it’s B vs Frankenstein.

In a Nutshell

Alignment is deceptively difficult, and there’s no silver bullet. It requires good communication skills, a willingness to consider viewpoints you disagree with, and a genuine desire to be part of a team. It requires non-managers to consider the big picture, and managers to dive into technical details. But it’s absolutely worth it.