The ultimate guide to dependencies
How to effectively mitigate corporate complexity and streamline dependencies: A must-read deep dive for product leaders.
Recently Antoine Le Nel shared his growth playbook for Revolut.
As a side note, Revolut has reached a staggering valuation of 45b and is one of the fastest growing companies in the world. Clearly they know what they are doing.
Beyond their marketing and acquisition tactics, a few key practices stood out.
First, Revolut is cutting down dependencies for teams, empowering them to be as autonomous as possible.
Second, teams aren’t bogged down with meeting preparation. Instead of reporting, they solely focus on problem solving. This enables fast iteration.
These ideas are not entirely new.
Netflix’s CTO, for instance, has mentioned a similar approach, where meetings are kept intentionally under-prepared to prioritize discussion and problem-solving over presentation.
Amazon, nearly two decades ago, began experimenting with “single-threaded leadership” to reduce dependencies and increase team focus. Not to mention their cult-like “six-pager” practices, emphasizing deep thinking over slide decks.
Around the same time, Steve Jobs at Apple was notorious for banning slide decks, pushing for more direct and productive discussions instead. With the authority of the CEO, he removed blockers to foster collaboration and speed up execution.
Having worked in both flexible startup environments and more rigid corporate settings, I’ve seen many times how a project’s time to market can stretch from months to years due to unnecessary complexity.
There’s a clear pattern: companies across industries are grappling with the same challenges, decade after decade. So, what breeds complexity? How does it scale as a company grows? And most importantly, how can businesses mitigate it effectively?
Drawing from my personal experience and insights from over a dozen books and countless podcasts, I’ve decided to really get to the bottom of this.
Let’s dive in.
Today’s article
What breeds complexity. Nonlinearity, dependencies, command and control.
Stages of complexity. How it evolves from the startup to the evolved corporate stage.
Effective ways to battle complexity. Four powerful battle-tested strategies to reduce the complexity in your org.
TL;DR. Key take-aways from the article for people on the go (2 minute read)
+ A bonus → An AI podcast of the article for those who’d prefer listening instead of reading.
📝 Word count: 3161 words
⏱️ Reading time: ~23 minutes
🔊 AI Podcast Version of the Article
Powered by Google’s NotebookML
🌪️ Why complexity happens
Quoting Gen. Stanley McChrystal: “Complicated and complex are two different things.”
Complicated refers to a system made up of smaller, simpler elements that work predictably and efficiently. You can break down a complicated system into its components without much difficulty.
Complex, on the other hand, means that the number of elements and the connections between them create volatility and unpredictability in the system as a whole.
Complexity tends to develop organically. As teams grow, the number of connections between them increases. Some of these connections may break, silos form, egos emerge, and political kingdoms take root.
As team sizes increase, layers of processes are added.
In cases of past hypergrowth, the entire product may have ended up with a monolithic codebase, making any quick changes practically impossible.
On top of that, you may be operating under autocratic command-and-control leadership, which forces you to carry out their demands.
If management fails to act, the company can eventually become stuck, unable to move forward. The whole organization becomes focused on preservation rather than growth.
As a product manager or leader, you might feel like 80% of your work revolves around appeasing stakeholders, with only 20% devoted to building products. Not the most inspiring ratio - unless you thrive on managing expectations.
🧩 Complexity layers
1️⃣ Command and control leadership
The term “command and control” often evokes an image of an authoritarian leader.
However, in most modern-day tech companies, leadership dynamics are way more nuanced.
Many leaders today recognize that top-down command model isn’t effective. In many cases they won’t explicitly dictate the stuff for your roadmap.
That said, leadership almost always has a strong opinion. This often results in forceful communication, especially during touch points or sensitive reviews. Their strong opinion coupled with authority is often perceived as a “call to action”.
What amplifies the problem is that product managers rarely tend to be assertive enough to challenge the leadership’s opinion, assuming it is a status quo.
This can spiral into the “reporting instead of problem solving”. The team may start executing and at the extreme even sugarcoating their outputs. Ultimately, this erodes the unit’s ability to adapt newly arising connections and challenges.
2️⃣ Team connections
The bigger the team, the more there are connections between its members. When satellite teams arise (cross-functional), connections grow even further.
Let’s do a simple mental math exercise. You are a startup of two. Two co-founders. There’s just a single connection between you and this other guy (let’s say CTO). You vibe easily.
But when you hire 2 more people (Head of Marketing, Head of Finance), you suddenly end up with 6 connections.
You talk with CTO, all the new hires (3 connections), but then CTO talks with those two other folks (2 extra connections) and say Head of Marketing talks to Head of Finance (1 extra connection). There’s already a bit of formality that starts kicking in, but you still retain a startup-y environment.
But then you reach product market fit and scale to 10 new markets and your team grows to 100 people. That would already equal to 4,950 connections. The twist comes with further growth, a team of 300 people would result in 44,850 connections or a 9-fold increase.
So you grow the team 3 times, but get almost an x10 increase in possible connections 🤯.
Reid Hoffman in his book Blitzscaling draws a parallel of administrative units. A team of 10–100 people is a tribe, >100–1000 a village, 10,000+ a city. Growing scale requires a strong handle on operational management.
There are two problems here.
First, no person on earth has an empathetic capacity to manage that many. According to Robin Dunbar, a person can maintain stable relationships with as much as ~148 people max. This is a direct limit of the size of our neocortex part of the brain. But keep in mind that a part of this capacity is already dedicated to your family, friends, and loved ones.
Second, connections can slow down or break completely. Say, you have a toxic colleague or a silo building up, the flow of information in this part of the network will simply come to a halt. This is a surefire recipe for bottlenecks and reduced time to market.
3️⃣ Gatekeeping processes
The key reason why connections start slowing down is gatekeeping.
With the growth of the business, the error blast radius of decisions grows proportionally. Hence, you need protection against wrong decisions. It usually comes in the form of processes and protocols.
At the later stages, the company starts transitioning towards preservation and moving away from risks.
That’s why Google AB-tests a border color change in the interface. You can lose millions, if you pick the wrong one.
It’s a natural process, but not without it’s side effects.
One of such is premature gatekeeping. A political kingdom might arise based on an ego rather than the actual business need.
Alternatively, a cargo-cult obsession might kick in. I’ve seen companies introduce full-blown discovery sprints at the early-PMF stage. Instead of creating value, the formality of the process just slowed down the execution and the connections between teams.
4️⃣ Monolithic codebase
A common enemy of all hypergrowth companies is a monolithic codebase.
When a company kicks off everything needs to happen fast. Build, ship, test. No second guessing.
The whole service is contained in a single executable file of code and bulks up as more features are being added. There’s no time to think about tech debt, the company needs to blitzscale.
This euphoria suddenly comes to a halt when a simple feature takes a year to roll out.
The team needs to make many changes in a single giant codebase. Those changes need to be done carefully, not to disrupt the work of other teams or put the whole business to a halt.
This process is typically accompanied by gatekeepers, ensuring the team does everything just right.