To many cooks spoil the broth! (Image CC BY 2.0 kecko)

Fixing the “too many cooks in the kitchen” problem for large group strategy meetings

I spent the day yesterday in a “Hot House” at work. No, this didn’t have anything to do with horticulture. It’s corporate-speak for bringing a lot of people together in a room for at least a full day to promote “An environment conducive to vigorous growth or development”.

When working on a lot of enterprise programs, we often bemoan the fact that there seems to be “too many cooks in the kitchen” — and that is often the case for sure. However, I’d like to call out a difference between having too many cooks in the kitchen, and having all the right people “at the table” to tackle really, really complex challenges (or, to reframe in the positive, “rise up to the opportunity…”)

In our example, we were working on the planning for a new API product — in fact, we were trying to determine if the idea we had was even the right product to begin with. The Product Manager for that area of API ontology had convened this meeting with many participants: product & technical representatives from the area of the business that the API covers, experts on that area of the business itself, tech writers, tech strategists, developer marketing, and other subject matter experts that helped fill in gaps and advise us on the nuances of the very complex domain we were working in.

It would be easy to dismiss getting this many people in the room as too many cooks, or that we were doing “design by committee”, but the fact that we had a limited number of people from each area, and covered many areas with the group of people that had convened, made it actually work.

At the end of the day, we had a lot more clarity on what we needed to do next to rise up to the opportunity in front of us, and we all left (or at least I did) with a greater appreciation for the contribution of everyone present to the overall program — even though many of them are people we’d never encounter day-to-day.

What made this work?

I think there were three key things that helped make this large group work well together while sequestered in a conference room all day:

1. An agenda. The facilitator (the Product Manager for the API domain we were working in) did an excellent job of creating a detailed agenda for the entire day, with a good mix of structured activities for the group as a whole and break outs for smaller groups where we took on roles like “company”, “customer”, and “developer”. He did his best to hold us to the agenda despite our natural tendency to go down detailed rabbit holes. (Amazingly, there was no bike-shedding during the day!)
2. Little overlap, many specialities represented. I think this was key to preventing the “too many cooks” problem. The facilitator invited only one or two people from each specific area, rather than entire working teams. The most distilled viewpoints for each area were well-represented and it kept political debate to a minimum.
3. Mutual respect for expertise, regardless of title or level. There were at least seven or eight levels of management in the room (let that sink in for a moment, the enterprise I work in is indeed huge) but at that time, we all interacted as equals, and all of our ideas and opinions carried the same weight — or were at least judged on their face value merit, rather than who was speaking the idea.

All-in-all it was a very refreshing day and it showed me that there is a way to bring a big group of disparate people together and get them working effectively on important opportunities facing a business.

Chris Busse does digital strategy for a large financial institution with a focus on APIs and developer community. Check out his vocational info on LinkedIn and follow him on Twitter!

Have you had similar successes? Share your tips or questions in a response below!