The Double-Edged Sword of Collaboration: How to Avoid the Pitfalls of Decision Paralysis

I’ve been thrilled to see more and more organizations adopt Design Thinking and collaborative elements into their processes. As a Delivery Lead and former Designer, I’m all for collaboration, and I’ve written about it at least a few times already, here and here.

However, like most good things, there is such a thing as “too much.” Although I love to see collaboration become more mainstream, I have also seen the spirit of collaboration serve as a scapegoat for a lack of decision-making and accountability. Let’s talk about the limits of collaboration and how to avoid decision paralysis.

First, what is collaboration?

In its most basic form, collaboration is simply working with others. That’s it. Can it include whiteboards and meticulously planned group activities? Sure! However, it does not need to.

What is NOT collaboration?

Collaboration does not mean everyone needs to agree 100% of the time. It also does not mean every person needs to be involved in every step of the process. “Divide and conquer” is a valid (and often effective) form of collaboration.

Who should have a seat at the collaboration table?

Who is involved might vary based on the phase of a product or project and what you are trying to achieve.

For example, in the discovery stages, it’s important to have ample input from various people with diverse backgrounds. Include the following:

• Business stakeholders
• Product folks
• Subject matter experts
• Engineers
• Designers
• A variety of users

Notice that all of those were plural. In the discovery stages, you’re more focused on quantity than quality. You could be gathering input from 5-100+ people, depending on how much time you are able and willing to invest.

As the project continues, this will change. As you hone in on the vision and move into execution work, you might cull down who is included and/or the frequency in which they are included. This might look like a core team of Technical Lead, Delivery Lead, Design Lead, Product Owner, and key Subject Matter Experts.

This doesn’t mean you’ve forgotten about users, business stakeholders, and the rest of the development team. However, at this stage, you might choose to pull them in for feedback at specific milestones, rather than spending time on the minutia of iteration.

Pro-tip: If you find that your group is often spiraling on decision making, evaluate what stage of the project you are in, and if the key collaborators at this stage are still serving the goals of the project.

How long should we iterate for?

As an art student, I used to stay up until the wee hours of the morning making endless tiny adjustments to my pieces. I never knew when to call it “done.” I’d often just work until I was overly exhausted and needed to step away for sleep’s sake.

Software isn’t much different. What I mean by that is that it’s never really “done.” However, that doesn’t mean we should lose sleep over it.

I’ve often found setting calendar constraints is the best way to avoid getting lost in endless iterations and decision paralysis. For example, give yourself a month to iterate on the design of a feature. Work backward from that timeline to schedule working sessions, interviews, etc. Communicate with all parties that the goal is to decide by your specified date.

Pro-tip: Remind folks of your timebox before each working session, as well as when you are asking for feedback. Keeping the date in the forefront will help folks know how to prioritize their responses. Clear expectations lead to better results.

What if we cannot reach a consensus?

Sometimes a natural consensus isn’t reached. That’s okay! However, to move the product forward, it’s important to not get too hung up on everyone agreeing about every little detail. This mindset will quickly lead to designing/planning by committee.

There should be a final decision-maker. This final decision-maker doesn’t necessarily need to make all the decisions. But, when there’s no clear consensus or if you risk decision paralysis, this person can serve as a tie-breaker.

It is important to designate this person at the start of a project before you get too into the collaboration weeds. This might even be more than one person. For example, you might have a different tie-breaker designated for each area of an application or product.

Pro-tip: Don’t just talk about a final decision-maker. Document it! Building out a RACI chart as a team is a great way to do this.

Don’t stop collaborating.

Sometimes it might feel like collaborating extensively on a product slows down the process. While this may be true to some extent, it’s hard to deny that collaboration leads to better outcomes. Working collaboratively is worth it, but it might take a bit of finesse and calibration to dial it into a balance that serves your product the way you need it to.

Don’t stop collaborating, just be smarter about it!