Collaboration with our colleagues at work is a good thing, right? As product managers, we facilitate collaboration across the entire organization to create successful products. In Agile environments, collaboration across developers, designers, and testers is the norm. A client who adopted true cross-functional teams during their SAFe adoption reported positive outcomes from understanding the different perspectives and work involved. Even though they believed they already had a collaborative culture!
- There’s collaboration when doing the work. That’s what Agile is focused on; and that’s the focus of product managers when they’re leading cross-functional product teams.
- But then there’s collaboration when making decisions. This, it turns out, is an entirely different and often frustrating aspect of “collaborative cultures”.
Now, I’m all for getting buy-in from the right folks. But sometimes we take collaborative decision-making too far, and it really slows down time to market.
Flash quiz: Do you recognize any of these symptoms in your organization?
- Too many people have to be consulted when a decision is needed. Often results from high growth or re-orgs, where the experience moves elsewhere in the organization but the influence remains. Newer folks don’t even realize how broad the stakeholder group can be, because it makes no sense when you compare it to the org chart.
- Decisions take too long. Either too many people have to be consulted, or the people who can make decisions are unavailable – or both.
- Decisions are only clear in hind-sight. There is no clear ceremony around the decision. You keep moving forward and if no one stops you, then the decision went in your favor. This often slows forward progress just due to the uncertainty factor.
And all of these issues interfere with accountability for results.
So what can you do?
Go back to “command and control”? Nope, don’t like that idea! These three suggestions will help you improve collaborative decision making:
1 DACI. Similar to RACI, but aimed squarely at decision-making. The letters stand for Driver, Approver, Contributor, and Informed.The key to DACI is to have a single, named Approver. If you use the RACI model already, then you might note that the “A”s and RACI and DACI help you align accountability with authority. And you might consider making “A” into “AA”: Available Approver! In highly collaborative organizations, be careful with assigning “C”s. Get the right expertise, but too many influencers can slow and muddy the process. Be liberal with “I”. Make sure you share the information broadly. Product Managers are often the Drivers, and sometimes the Approvers.
Applying DACI successfully takes two forms. First, there are typical decisions that are made on a regular basis. Product Portfolio Reviews, Quarterly Business Reviews, Gate Reviews are some examples of regular, defined decision points. Implement DACI once and you’re good to go for some period of time. The second form is dynamic: think of all the smaller, day-to-day decisions that are in play. When teams are faced with a decision that can’t (or shouldn’t) be made on the spot, it’s time to pull out DACI and get specific about who will Drive, who will Approve, who needs to Contribute, and who should be Informed. And add a time-frame for resolution! Being explicit about DACI enables organizations to be dynamic and move quickly!
2 Push decision-making downward on the org chart. Lean thinking teaches that strategic decisions (those with long-term impact) should be centralized. Tactical decisions should be moved as close as possible to the point of the work affected. One way to structure this is to think of the dollars at stake with each decision and see if that aligns with spending authority. If you have no “tree” of spending levels, then maybe you don’t have a good decisions structure either. And if most decisions require director or above approval, then maybe you need to work on the third suggestion, below.
3 Build trust, and a “safe to fail” culture. Yes, mistakes will be made. Harvest those moments of learning with quick retrospectives!
And to keep your organization moving quickly, publish the “Plan B” you’ll use if problems are detected. When everyone sees that good alternatives were considered, its easier to move forward, and easier to recover quickly from any issues that arise.
And a bonus suggestion, for when you’re trying to make technical decisions and find that lots of other groups are affected (see question 1 above), you may have to look carefully at the architecture of the system(s) in question. Applications grow over time, and so do organizations. You might be experiencing some side-effects of Conway’s Law. Over time, as the systems and organization diverge, you’ll see issues with technical decision-making.
What other techniques have you used to improve collaborative decision making?