At the start of a new business or new project, everyone has clearly defined roles and responsibilities. But over time that changes. What started out as clean boundaries between people get fuzzy. You hire a developer who loves design systems. You hire a designer who loves data visualization. You hire a product manager who used to be a data architect.
Multi-disciplinary people often contribute in multi-disciplinary ways. Great! Not only are siloed, stay-in-your-own-lane work environments inefficient — they’re boring too.
But alongside the benefits of freewheeling collaboration is a hidden risk. Having people chip in on work beyond their normal responsibilities leads to situations where it’s not clear who owns what decisions.
Does the ex-designer product manager make UI decisions or does the data-viz-loving designer?
Does that change if we’re building a metrics dashboard instead of a pricing page?
When a product manager chips in on design work it builds a subtle link between product and design. Those connections are weak individually but as they accrue they become stronger and stronger. Over time, the connections start to act like organizational rubber bands — slowly making the roles overlap.
For example, imagine a developer chips in by designing and building a UI flow. When someone wants to make a change, they’ll likely pull in the developer to discuss the history and decisions that went into the design. Because they have all the history, they’ll likely join to discuss the next change too. And the next change. And the next.
After the tenth time, the developer gets pulled in to consult on a design, they might as well be a designer.
Situations like this happen all the time. And as the number and strength of the connections build, they start to pull the once well separated functional areas together. As the overlap grows, people start to lose track of who owns what decisions. When a decision could be anyone’s it becomes no ones. Decision making grinds to a halt.
If unaddressed, this always ends in one of two ways:
- No one feels empowered enough to make a decision because they’re afraid of stepping on someone else’s toes (and nothing gets done)
- Everyone tries to make the same decision but in opposite directions (and nothing gets done)
In either case, everything starts to feel really hard. Velocity drops to a crawl, the word “consensus” gets thrown around a bunch, and it feels like you’re spending more time talking about decisions than making them. The slowdown can be massively frustrating at big companies and can be a death sentence for small startups.
The root cause of this dynamic is what I call the Law of Organizational Entropy:
Roles and responsibilities drift towards sameness unless acted upon by an opposing force.
This law is universal. It takes a toll in every organization, both horizontally within teams and vertically between levels.
Luckily, fighting Organizational Entropy is simple (but not easy). There’s a two-part solution.
The first step is defining how things should work. The second step is finding ways to anchor those ideals to processes and tools.
Step one: define how you work
Helping your team understand where it’s going is leadership 101. But Product Visions and North Star Goals are only half of the equation. They show what the team is working towards, but not how they will get there.
Teams also need to understand how they should work.
In software development, version control brought us the concept of a master branch. That branch is a snapshot of the team’s latest working code.
It exists so that individuals and teams can go off and experiment. If things go well and the experiment is successful, they’ll merge their changes into the master branch and go on to the next experiment. If things go terribly awry they can reset to the master branch be back somewhere sane and healthy.
Publicly defining how a team should work is like having a master branch for a company’s practices. It lets them go off and try crazy experiments with the way they work. But it gives them a safety net to make sure that things don’t go too far off the rails. Declaring how teams should work keeps things sane.
If people know that the tech lead is responsible for producing bug free code in development but the product manager is responsible if bugs make it into production, that eliminates a whole host of ownership issues.
Defining and sharing the patterns your teams should use is an organizational superpower. But like any superpower, it can be dangerously misused. When deciding which ideals to define be very careful. If you pick the wrong parts of your process to standardize or standardize too much or too little then it can do more harm than good.
Standardizing bad practices hobbles growth. No structure is chaos. Too much structure is suffocating.
It can be hard to tell from afar if your guidelines are helpful or harmful. But the teams who live with them can absolutely tell you. Talk to your teams regularly about whether the ideals you’re aiming for feel right or if they need an update. “Right” is a moving target and we should build our systems with that in mind.
For a great example of how this looks in practice, take a look at Intercom’s Lessons learned from scaling a product team. (Notice how they make a special point to say how their process is always evolving --- yours should too!)
Step Two: Finding Anchors
On of my favorite examples of a leader finding elegant anchors comes from Facebook.
When Mark Zuckerberg got up on stage in front of the company and declared that they were going ‘mobile first’ he expected mountains to move. But weeks later nothing had happened. He was still in the same meetings listening to the same people talk about the same (desktop) things.
Saying you want something to change is almost never enough to actually make it happen — even for billionaire CEOs. Faced with that reality, Zuckerberg decided to make a drastic change.
He announced that from that day on he wouldn’t sit in another meeting, listen to a single idea, or look at a single prototype that wasn’t for mobile. He lived up to his promise and wiped his calendar clean. As you might imagine, chaos ensued.
It turns out the CEO refusing to take your meeting is a pretty strong motivator.
By the end of the week his calendar started filling back up. Miraculously, every meeting was about mobile.
Within a couple of months the company focus had totally shifted. He found a way to anchor the change he wanted into the routines of the company and got dramatic results.
Zuckerberg’s anchor point was his calendar but there are plenty of other options. Every organization has routines, cadences, and rhythms that govern how the company works. Maybe it’s a monthly meeting or a daily standup. Maybe it’s a weekly email update or a quarterly business review. Regardless of the specifics, finding a way to hook into those routines is a critical piece of making your ideals stick. Successful anchors make it easier to work in the “right” way than the “wrong” way.
Want to encourage teams to do more user research? Great! Schedule a recurring meeting with their boss’s boss to review the latest results. You’ll have user research happening left and right.
Want to change how your company discusses goals? Great! Add a Goals section to the budget request template. Reject any that don’t have it completed to your (public) standards. Everyone’s goals will be spotless.
Finding a way to build anchor points within an organization is incredibly important but it can be hard to find the right place to start.
As a first step, think about where functional areas or leadership levels overlap. Consider the times when managers talk to reports or when one group talks to another. Those places tend to have meetings, routines, and formalized pathways of communication. Intercepting and modifying those flows of information can be a great leverage point for change.
Fighting Organizational Entropy is tough. It’s a naturally occurring byproduct of every company and the faster you grow the more pronounced it’s effect becomes. But with some careful thought and precise action you can keep Organizational Entropy in check and keep your company moving forward.