You come to work on a cold winter morning, and while you are pouring yourself a warm cup of coffee, you are suddenly hit by a million-dollar solution for a problem you have been working on. Your heart starts racing, coffee spills from the cup, and you wonder; how is it possible that no one thought about this until now? This is absolutely brilliant!
You race to your desk, and half-way there you meet your team’s engineering lead – perfect! You start passionately explaining your idea. Curiously enough, despite your enthusiasm, as fast as the words flow from your mouth the engineering lead’s face starts turning pale, and with a mixture of sadness and skepticism, she asks you: “How many teams would we depend on to deliver this?”. Bam.
Once you start to think about it, your solution will have to touch multiple domains and require the collaboration of several teams. Within minutes of your brilliant breakthrough, your dreams are crushed again.
If you ever talked to an agile person about this before, odds are you have heard the mantra “dependencies should be dissolved, not managed”. But how does one actually accomplish that, especially inside ever-growing tech platforms, with intricate webs of microservices and teams?
To kill dependencies, one hypothesis is that we need to improve how we share technical knowledge and accountability, plus establishing a single source of truth for prioritization.
And there is a third element that can help us achieve this, something we learned by running Dependency Standups at Consumer Tech.
When these were initiated almost one year ago, we had 9 squads and among several initiatives, two big projects requiring almost everyone’s collaboration. It looked like this: a standup with all product folk from different teams, held once a week and conducted by a different participant every week. The aim was to create visibility and transparency, and boost the collaboration among the teams, through this not-so-pretty board:
Sounds lovely. Then growth happened. All of a sudden there were over 20 squads, not 8. Dependencies grew and fragmented and grew again. The session became a boring reporting meeting, filled with touchpoints, not at all relevant for the majority in the room.
But we love to fail and learn. In our last stand-up, a meeting room packed with product managers and remote participants decided the forum couldn’t scale and should be dissolved; but one thing we learned was that having visibility and transparency of dependencies continued to be powerful.
Now imagine having a single prioritization scheme, easily visualized and digital, with each opportunity’s clear COD and ROI declared, where the teams could identify which collaboration is needed and which knowledge gap needs to be bridged in order to be successful?
Committing to the utmost value for the platform as a whole, to stop starting and start finishing stuff, together.
Well, maybe this is another million-dollar absurd solution over a spilled cup of coffee. Maybe not.
With collaboration rather than dependencies, we will get there.
And as always, if you’re interested in a becoming a part of the team, have a look at some of our following open positions:
