‘Design by committee’ is a punchline for many jokes, but it’s still seeing a comeback, and that’s scary.

Google “design by committee,” and you won’t see anything good. The phrase is a pejorative term for a project that has many designers and no unifying plan or vision.

That said, I see this approach more frequently now when it comes to cloud architecture, which is disturbing. I’m not sure if it’s due to our Work from Home (WFH) environments and the need to get people engaged remotely, or our lack of skills that is pushing important decisions to groups of people.

If you’re as old as me, you remember architecture steering committees. These were groups of IT leaders, typically from different departments, such as security, infrastructure, app dev, etc., who came together to decide on a holistic architecture made up of technologies that everyone could agree on.

The approach seemed logical. If you’re going to get people to follow a plan, you want them to be involved in creating it. However, what was set up to motivate the team created a hodgepodge of technological gobbledygook that cost millions to fix later.

How did this occur? Different agendas, with different technology bias regarding those agendas.

Typically, a group didn’t consider the holistic objectives of the architecture (such as business requirements) but focused on tactical issues or tools around their pet requirements. To appease the group, each member was allowed to make a call, and while the technology may not be a bad choice unto itself, the architecture did not work well together and cost the business millions more to build and to fix when it failed.

I was in the middle of several of these, and the memories are still painful. While I stopped short of needing treatment for PTSD, I did learn that design by committee was a bad idea and I avoided it passionately, even by threat of resignation.

Today it’s pretty much understood that too many people making technology decisions and plans just does not have a positive outcome. I see the most success when a small, tightly coupled team is led by a master architect or CTO. They consider all business requirements and select an optimized cloud technology stack based on nothing but the business requirements.

Centralizing these decisions, while not completely democratic, typically leads to stronger outcomes, faster decisions, and better deployments. Decisions are still politically charged, but you only need to say, “Do you want to design this by committee?” and everyone pretty much backs away slowly. Most of the time.

As I mentioned, there seems to be a return to architecture steering committees to select and deploy cloud computing technology, largely because of more remote work, fewer skills in the organization, or an advisor who is completely asleep at the wheel. Companies are moving to a brain trust model where many of the technologies will be chosen by a vote.

I’m here to warn you before you get in trouble and must fix some huge mistakes: This is still a bad idea. And trust me, I will say “I told you so.”