Prioritize cohesion, then uncouple
How to increase autonomy in your org
Welcome to The Overlap, a biweekly newsletter somewhere between product and org design. This one’s on alignment and autonomy.
A note before we get into the essay.
Reader, I ask you at this moment to offer patience and support to your colleagues who identify as Asian.
Last week, eight people were shot to death in Atlanta. Six of the eight were Asian women. This, on top of other recent anti-Asian hate crimes, has left me and many others I know feeling angry, tired, and scared.
Recognize that. Offer your time to listen. Learn. Be for your colleagues. Small gestures of compassion and support during fucked up times go a long way.
You (generally) want both alignment and autonomy
I’m sure we’ve all seen this 2x2 from Henrik Kniberg, a consultant who formerly worked with Spotify.
If you haven’t, here’s a quick refresher.
Your team, your department, and your organization can fall under one of four categories:
Tightly aligned, but not that autonomous
Not that aligned, but highly autonomous
Not that aligned, not that autonomous
Tightly aligned and highly autonomous
One (1.) benefits organizations where the risk is high. I’ve never worked in a hospital, but I imagine that some degree of risk-aversion and process to prevent error is good here. Being wrong means risking human life.
Two (2.) benefits organizations that don’t need to be aligned. GE’s kitchen appliances division doesn’t need to be aligned with GE’s aircraft division. But if GE’s kitchen appliances division is trying to get new products out to market, while GE Power is focused on reducing GE’s overall carbon footprint, then 4) is the goal.
If you work in software or business, you want (4.). High alignment and high autonomy grant you the speed of a startup with the resources and talent of a large company. Agility and impact.
Here’s what each modality might look like in a software org:
Tightly aligned, but not that autonomous
Your leaders debate tactics more than strategy. Instead of “What problem are you trying to solve?”, you hear a lot of “Design it like this.”
Your senior managers are involved in many small decisions.
You’re in tons of cross-departmental meetings to get buy-in on tactics.
You’re frustrated by (or used to) how slow things move.
Not that aliged, but highly autonomous
You’re not clear on what your colleagues are currently working on.
Your managers don’t/can’t communicate the bigger picture.
You’re never sure of the goals of the meetings you’re in.
You notice that anyone can make changes to the system, but it’s not clear who owns what parts of it.
You feel like you have too much freedom, and aren’t sure how to best spend your time.
Not that autonomous, not that aligned
You’re not a company. You’re just a Twitter feed of endless debate, wondering the point of it all.
Tightly aligned, highly autonomous
Your leaders debate strategy/outcomes more than they debate tactics.
You get coached on outcomes (“You want to walk out of a kickoff meeting with these outputs”) rather than your style (“Your kickoff agenda should have X, Y, and Z”).
Your colleagues, who are more junior than you, openly disagree with senior members. Senior members listen to them because they know junior members have more context on their projects than they do.
Your team has the support to make good decisions on their own.
Everyone on your team respects each others’ skillsets and perspective.
You know your business’s goals.
You feel like your colleagues know your business’s goals.
You feel clear on how to best spend your time.
You feel trusted.
You get shit done.
Highly aligned, loosely coupled
I think it was Netflix who coined the saying “highly aligned, loosely coupled.” From Netflix’s 2009 culture deck:
In software engineering, coupling is the extent to which modules are dependent on each other. In org design, coupling is the extent to which roles, teams, and processes are dependent on each other.
Software engineering contrasts coupling with cohesion: the extent to which the elements inside a module belong together. In org design, cohesion is the extent to which our roles, teams, and processes serve the org’s purpose. I go back to Spencer’s definition:
I define cohesion for organizational design as the extent to which given nodes [roles, teams, or processes] work together in service of a greater value than can be achieved from the node alone.
In software, low coupling is usually a sign of a well-structured system. Key word: usually. A microservices approach can backfire if you’re not clear on how it meets your app’s needs. Low coupling can lead to low cohesion.
In org design, low coupling is usually a sign of a well-designed organization. Key word: usually. Highly autonomous teams backfire when the org’s strategy is not cohesive. Again, low coupling can lead to low cohesion.
Our goal is to limit coupling as much as possible between roles, teams, and processes. And standardize coupling, to keep it easy to edit, add to, or delete.
Here’s Spencer again:
To be clear, we don’t want to eliminate coupling. Coupling is what makes the system networked and useful. We just want to 1) limit it as much as possible for a given node and 2) control/standardize it as much as possible to keep it easy to modify, extend, or delete.
How do you avoid the potential backfire that happens from uncoupling? Prioritize cohesion. Then uncouple. Why? So that you solve the right problem (and avoid solving the wrong one).
Of course, you can do this the other way around. Prioritizing uncoupling can create a shared awareness that there is no cohesion, which can lead to increasing cohesion. “We went back to creating our apps in a monolithic way when we learned that microservices isn’t always the best approach.” Sometimes you need to go backwards to go forwards.
But at some point, you’ll need to increase cohesion.
How? Define your org’s strategy, and then define roles, teams, and processes that serve that strategy. Once you’ve defined your strategy and the “nodes” that serve it, autonomy will unleash.
Alignment and autonomy can vary by team and department
Some teams can be high alignment-low autonomy, while other teams can be low alignment-high autonomy. This is normal! Remember, organizations can be simultaneously underbounded and overbounded:
Organizations are complex systems. So they aren’t solely overbounded or underbounded. They’re both. Here’s more from Clayton’s Psychology Wiki bio:
Systems can behave in both underbound and overbounded ways in reaction to different groups and situations; they are rarely one or the other in all instances. In addition, overbounded suprasystems often create underbound subsystems, and vice versa. Systems display these characteristic behaviors as a way of balancing the two extremes in order to achieve optimal boundaries; they react in relation to one extreme or the other and as such, are shaped by the embeddedness of multilayered systems.
Roles, teams, and processes need to balance each other out in order to realize optimal boundaries.
In huge software organizations, it’s common for the design org to have low alignment-high autonomy, while the engineering org to have high alignment-low autonomy.
Some signs of a low alignment-high autonomy design org:
The design org is thought of as a “shared” service.
Resourcing decisions are one-off.
The team feels under-resourced.
Designers are spread thin, overworked, and burnt out.
There’s not much org-wide visibility on how full their plates are.
Some signs of a high alignment-low autonomy engineering org:
There’s a perception that we’re wasting money when developers aren’t coding.
Engineering managers struggle to support more junior engineers in writing their own code and making their own architectural decisions. They end up micromanaging since they have yet to hone their leadership skills.
Senior engineers are celebrated when putting out a fire. It’s viewed as heroic.
Individual contributor engineers are left out of platforming/architectural decisions. When thrown into a codebase, they have little/no familiarity with the intricacies of the platform/architecture.
Individual contributor engineers don’t have the freedom to explore different frameworks, architectural decisions, and/or code styles.
If the above is a little too real, you’re not alone! Most software organizations experience this. I feel like theory and frameworks creates an anxiety of having to become the perfect org when there is no such thing as a perfect org. Only an org that’s constantly getting better. I also acknowledge that not all design orgs are low alignment-high autonomy and not all engineering orgs are high alignment-low autonomy.
Just consider when high alignment-low autonomy / high autonomy-low alignment gets in the way of your organization’s goals. Be honest! The earlier we name what’s in the way, the earlier we can adapt.
Three ways to create awareness:
Have regular retros across teams (not just within teams)
Frame org changes as experiments and invite your org to propose experiments
Foster psychological safety so that it’s possible to openly disagree
Aligned autonomy starts with cohesion
The main takeaway: prioritize cohesion. Then reduce dependencies. Alignment and autonomy will follow.
Which of the four quadrants best describes your team?
Where does your team want to be?
What’s in the way of them getting there?
What I’m Reading
On process and culture: Avoid mono-process (but embrace shared language) by John Cutler.
On accessibility and shared agreements between designers & developers: Taking a no-motion-first approach to animations by Tatiana Mac.
On stepping into a lead role: How to scale yourself: do less, lead more by Ed Batista.
What I’m Sending
I worked Jones’n for four straight weekends and finally finished it over the weekend. In the spirit of learn in public: here are three failed attempts, one rehearsal of the frightening top out, and my full send.
See you in two weeks,
–tim