Reducing dependencies

When your company gets large enough, you’ll start having problems with dependencies. Here’s how to address it.

What do I mean by dependencies?

• Teams not able to deliver their work without other teams doing work for them.
• Projects that can’t be successful unless a lot of teams do work.

Signs you have a problem

• Big projects are always challenging and problematic.
• Lots of efforts to solve this through project management and better tracking.
• Lots of efforts to solve this through heroism.
• Lots of efforts to solve this through process.

The problem is that you have a structural problem, so none of these will work consistently. I write more about how people try to work around these structural problems.

All the things you can do

• Reorganize the teams to reduce dependencies. Generally favor cross-functional organization. Team Topology style structures. Or FaST approaches if you have a higher tolerance for experimental but promising approaches. There is a lot of nuance in this — it’s a fairly advanced leadership topic. You might have different models in different parts of your org, for example.
• Make your projects smaller and more incremental. It’s easier to ship smaller things.
• Focus on fewer things. If you halve the number of projects, that means each projects gets that much more attention, project management, attention to detail, etc. If a manager is project managing four things, they’re dramatically less effective that project managing one thing. Consider constraints on the number of projects per team.
• Define engagement models for your teams. I write about a lot of these in Coordination models. Be very explicit about the way teams work with each other. You might have a team page in the wiki, with a section on the engagement model for each team. Examples of engagement models: self-service, independent executor, objective expert. Moving all your platform teams to self-service is an example of a very good improvement.
• Define how to work across team boundaries. Away teams, open source model, etc. I haven’t completed some of those posts yet, but have some detail in the independent executor post.
• Look at your bottlenecks. You always will have bottleneck teams. Not only are these usually the most problematic places in engineering, they also are often where a fix can have outsized impact throughout the whole organization.
• Have someone who explicitly looks at dependencies and org structure. If you don’t have enough systems thinkers in the organization, it might be useful to make this more explicitly something that the right person is thinking about a lot. Dependencies are one of the main decelerants for your org — make someone responsible for taking care of the org structure.
• Bring in consultants or advisors. This can go very well, or very poorly. But it can be a good idea to bring in outside expertise. Be wary of SAFe or other one size fits all approaches. I can help, or refer you to others.

Thank you

Image by Trond Giæver Myhre from Pixabay