Dependencies are like running a race where other people decide the route as you go. You never know when a detour will crater in and send you the long way around. Well-done planning removes dependencies. It's easier to create systems to manage dependencies, so everyone usually does that. Dependencies are barnacles on your company's velocity. Scrap them off now and again. You can learn how to identify when a dependency has a negative value.
We’re talking about dependencies between teams. If you need someone else, somewhere else, to do something so you can do your job, you depend on them. If they don’t move, you can’t move. There are good reasons to add dependencies: safety, security, quality, and consistency. None of those words invoke a feeling of speed, but maintaining speed is the most critical factor in a company [1].
Teams that can independently execute make more decisions and are nimble to change. Fast and distributed decision-making is a core tenet of successful companies [2][3]. Leaders have to cultivate an organization with these values.
Plan to Change
I’m a proponent of regular planning cycles. They provide forward-looking context and allow for identifying problems before execution. However, they can become a rigid structure in an attempt to fix a cultural problem with process.
Companies plan longer timeframes based on their maturity. There are diminishing returns when you get into details beyond a quarter. When projects take over three months to build and release, you have a velocity problem. If you have more than three months of dependency work to start, you have a coupling problem.
Use regular planning as a signal of how well your internal structure maps to your customer’s needs. There are two ways to deal with the evolution of customer needs over time. Some people adopt process-heavy “Big Room Planning” such as SAFe to help surface dependencies [4]. You need to change how you work to have fewer dependencies at all.
Mapping out a dependency plan in advance requires two things. Neither are usually knowable upfront:
What steps depend on each other?
How long does each step take?
Big Room Planning surfaces dependencies by everyone learning what everyone else does. There is always a multi-hour “office hours” block to encourage discovering dependencies. Assuming you even know who to talk to about your unknown dependencies. It's like speed-dating your features to discover Unknown-Unknowns. Lots of movement and not much time for depth.
I’ve spent several planning sessions at empty tables and Zoom calls, waiting for other teams to come talk to me. There was no question people depended on me. But there were too many teams for me to talk with everyone to find out who was who. With so many groups and so many initiatives, it wasn’t possible to provide enough context to everyone. I unfondly remember our CPO at one gitty that we had 152 initiatives, double the last number. That quarter was a mess; it's an O(n^2) context problem that we couldn’t handle anymore [5]. It wasn’t possible to know what depended on what anymore.
Time estimates include uncertainties by definition. When you stack estimates to sequence them, you multiply, not sum, the total risk. For quarterly planning, there are ~six two-week sprints. If one team takes an extra sprint to finish, the team next pushes the work. The last one isn’t finished with their previous project and has yet to start. Suddenly, you are a month and a half late yet haven't even started.
The other option is to record the team dependencies over time. Who blocks you and why? Next time, see if the same teams block you for the same reasons. It might be time to discuss how to avoid the coordination going forward.
Causes of Dependencies
Dependencies exist when the scope of work for a feature is beyond what a single team manages. They manifest in three ways:
Team Ownership
Product Architecture
Feature Scope
Everything requires coordination when teams each own minor aspects of the feature. Technical architecture usually maps to the org structure. Changing multiple components for one feature means touching code for various teams. When a feature is so significant that no team can hold its full context in their head, can a user?
Changing a team’s ownership, reorganizing, or scoping down can break a dependency. Those all hurt to do, too. You can’t whip people around and only allow tiny changes all the time. Every defined ownership, architectural change, and organizational structure was correct at one point. The assumptions you had when you made those decisions are what changed. Reality diverged, and it started to add friction. Slowly. As you learn you were wrong.
Team and technical architecture are always coupled because of Conway’s Law [6]. In practice, they always have to be done together.
I used to work at a logistics company. We moved goods (think shipping containers) from A to B, usually internationally. There was a single feature there that showed us how poorly our structure mapped to a customer's need. Shipment Visibility was a project to provide consistent progress information about a shipment. Regardless of whether it was on a boat, truck, plane, or in a customs warehouse.
It took years and didn’t work. We were in teams based on transport types and processes: Ocean, Trucking, Air, Customs, etcg. This feature needed everyone to do something, and no one was the obvious owner of it. Almost everything customers asked of us used multiple transports. They just wanted to know where their stuff was and when it was going to arrive. No group or person was responsible for what the customer actually wanted.
It took a reorg to fix. There were groups focusing on enterprise customers, SMBs, and other specific subsets of what customers thought about. Not how we handled the backend.
It’s critical to remember that our organizational structure wasn’t always wrong. When the company was founded, tech had to be mode-specific. That was the size of the problem we could afford to solve and the customer was internal. As we matured we offered our customers a wider breadth of features. That's when the misalignment appeared. Our product evolved. So then did our customers. Then we had to as well.
Required Dependencies
It's common to see dependencies with teams focusing on a product's common attributes: security, identity, or infrastructure. These teams can block like a linebacker. As give-me-a-ticket-and-I’ll-do-the-work teams do. Others can be subtle. Infra teams may not support you if you customize what they provide. Others require you to adopt their workflow or tooling. Even when it's insufficient or not designed for your use case.
The only way to break the dependency with these teams is for them to treat the consumers of their tooling or requirements as customers. While simple to say, incentives almost never align with this.
A security team owns security. It is a “single mistake makes the news” domain. The “customer” is the company’s customer, not internal developers or other groups. The team's incentive is to add more requirements, slow down, and not get paged in the middle of the night.
To break the dependency, these teams need metrics based on their internal consumers. Doing so pushes their mindset into a product-centric one, where UX plays a role.
It’s not possible to remove all dependencies. Specialization allows more focus on a subset of a problem. The problem occurs when the way dependent groups interact requires unnecessary coordination.
Conclusion
Don’t make planning a process everyone follows, and no one trusts. Use it as a signal when your customer’s needs no longer match your internal structure.
Changing ownership or doing a reorganization is best contextualized with how it maps to customer needs. Provide context so teams understand why things are changing. Convince them it reduces overhead and clarifies their mission. If you can't, it might be the wrong change to do.
Your customers evolve, so you must, too. It's better to grow your understanding and adapt than to exist in a stagnant space.
[1] https://paulgraham.com/startuplessons.html
[2] “High-Velocity Decision Making. Day 2 companies make high-quality decisions, but they make high-quality decisions slowly. To keep the energy and dynamism of Day 1, you have to somehow make high-quality, high-velocity decisions.” https://www.sec.gov/Archives/edgar/data/1018724/000119312517120198/d373368dex991.htm
[3] https://www.norulesrules.com/
[4] I’m not linking to SAFe because you shouldn’t use it.
[5] It’s O(n^2) for initiatives, but dependencies aren’t evenly distributed. There are usually team to team as well. So its sub exponential, but not linear. It still sucks.
[6] Conway’s Law is actually about the communication of organizations, not the organizational structures themselves. These tend to map closely. https://en.wikipedia.org/wiki/Conway%27s_law