Too Many Cooks in the Kitchen

I’m currently on a project at work where there are too, many, cooks. We are effectively building a landing page, and while doing so, need to manage the expectations of the 20 people involved (in some capacity) on the project. What a headache 🤦

Problem 1: Those most distant from the work, are the most vocal 🔈

This manifests when reviewing the design artefacts for the page. A stakeholders subjective opinion is weighed highlighy due to status - whether that is seniority, or politicking - and the feedback they share is expected to be implemented. Such stakeholders often lack the context of why decisions were made as they weren’t involved in user interviews. Unfortunately, even sharing recordings and feeding this information lands on deaf ears. Breaking a stakeholder out of their world view to accept reality is a problem many face in organisations across different industries. As a side note, if you could solve this, you could make millions writing a book. “Gurus” pretend to have all the answers to this, and I acknowledge there are techniques available to help, but anyone who has spent significant time in people heavy roles will understand the complexities of applying these techniques and getting repeatable results.

Repetition and being the voice of your users may help to slowly drill an opening inside that stakeholders thick skull. Effort better spent trusting a small team to build the best solution in collaboration with their users.

Problem 2: Nobody wins. 👎

In an attempt to appease all 20 people involved in the project, compromises and trade-offs must be made. That’s reality. In doing so, the soup we are cooking becomes watered down, diluted and our users are ready to throw up after taking that first mouthful 😋

Internally, everyone leaves the project thinking “Thank God it’s over”, rather than “I can’t wait to hear what our users say.” or “I can’t wait to build v2”.

Problem 3: Collaboration is not a silver bullet. 🔫

I used the word “project” above which is telling… Instead of building something small to learn quickly, and iterating based on user feedback, as soon as a large group gets involved we devolve towards a waterfall project. We quickly lose sight of our goal. At the beginning, our goal was to understand x, but now we are building y or adding one more feature because stakeholder z thought it would be “cool”.

There is rarely an acknowledgement that collaboration is a trade-off. The default position is that it’s to be strived for, and that anything less is a problem of teams not communicating with one another. It probably resonates a lot more with software engineers as a discipline in that there are no free lunches, and that everything is a matter of trade-offs between competing solutions and setups.

In the case of excessive collaboration, you:

  • Lose quick decision making
  • Dilute the accountability and responsibility for everyone involved (ownership becomes split)
  • Lose momentum to delivery
  • Lose the opportunity to learn and course correct early. As mentioned above, the more people involve, the quicker we transition back towards a “project” first mentality, and scope begins to creep in. “We really need feature x just in case!”. What’s worse, is that software design indecision also begins to rear its ugly head.

How to address the “too many cooks” problems? 🧑‍🍳

This is a leadership challenge. Leaders need to give small focused teams the reigns to execute on a customer problem to the best of their ability. They need to accept that these individuals will execute differently - they hired independent thinkers afterall - and have different subjective options. They need to trust what the small focused team is telling the broader org based on user interviews and any other data collected. Collaboration needs to be saved for when it’s truly required, rather than thinking we live in la la land.

A more cynical and ranty post, but the essence of this idea is:

  • Hire great individuals. Build small teams. Give them a problem, and let them execute.
  • DO NOT allow a large group of stakeholders to get involved in this problem. You delegated that to the small team.
  • DO provide feedback. DO NOT expect it to be applied. Trust the small team to consider the feedback and decide on the action to take (to apply or discard)