Too many cooks spoil the broth

Article#: 00123

Date: 2026-08-25

Author: Radim

"Two heads are better than one..."
In most cases, that's true.
When dealing with a complex technical problem, it makes sense to ask several people for their input. Everyone has different experience, a different perspective, and may come up with a solution we would never have considered ourselves. The more experienced people we ask, the better our chances of finding the right solution.

But there is another saying:

"Too many cooks spoil the broth."
And there is some truth to that as well.

First of all, it is important that the experts we ask understand the bigger picture. Bringing someone in to answer one specific question without knowing the broader context can be dangerous. Their solution may be perfect for that particular detail but wrong for the system as a whole. Before asking someone for a solution, we should give them the opportunity to understand the big picture.

Another problem arises when all these heads want to go in different directions and it is not clear who ultimately makes the decision.

It is good to ask many people. It is good to listen to their arguments and consider different options. But in the end, there must be one person who says: 'This is the option we will choose.' And that person must not only have the authority to make the decision, but also take responsibility for it.

1. Authority without responsibility:

It is easy to give advice when we don't have to bear the consequences.
'I would program it differently.'
'I would add another sensor.'
'Why are you doing it this way at all?'
'I would change the entire concept.'

Such opinions can be very valuable. They may reveal something we have overlooked or open the door to a better solution. That's why we should listen to them. But advice is not a decision.
Someone who makes a suggestion during a half-hour discussion will usually not be the person dealing with the consequences several months later. They don't have to implement the solution, commission it, justify its costs, or explain to the customer why it doesn't work as expected. Their opinion should carry weight - but it should not automatically give them the right to make the decision.

2. Responsibility without authority:

The opposite extreme is just as bad.
Someone is responsible for the result but has no real authority to decide on the solution. Others tell them what to do, how to do it, and which option to choose. But when the solution doesn't work, the question is: 'Who is responsible for this?'
And suddenly, none of the advisers raise their hands. When it comes to responsibility, all eyes turn to one person. That is not real ownership.

If we expect someone to take responsibility for the result, we must also give them the corresponding authority to make decisions. And if we give someone the authority to make decisions, we must expect them to take responsibility for those decisions. Authority and responsibility must go hand in hand.
So, in my opinion, a simple rule should apply: Those who make the decisions must take responsibility. Those who take responsibility must have the authority to make decisions.

The point is not to limit discussion or stop listening to others. Quite the opposite. Ask experienced people. Look for alternatives. Discuss their advantages, disadvantages, and risks. But at some point, someone has to weigh the available information, choose a direction, and take responsibility for it.

Ask many. Listen carefully. Let one decide. And let the one who decides own the result.

© Radim-Automation, 2020–2026. All rights reserved.
Sharing of this article is permitted with proper attribution (link to the original page).

Related previous articles:

• The false illusion of rapid progress
• Dedicated employees
• Keep the documentation up to date throughout the project
• My boss was a hero
• Documentation issues
• Knowledge gained from a completed project is priceless
• A good concept = Complete set of suitable solutions
• Are there also any disadvantages?
• Think critically!
• Design machines with a focus on user's abilities and needs
• Learn from your journey!
• Project leader
• Why do automation projects fail?
• Collect all the requirements and sort them!
• Who knows it?
• Appoint a representative!
• Write down your best practices and processes!
• Prepare a good project plan and keep it up to date!
• Is the way really the goal?
• Do you really want to start with this?
• I can see what you can not see
• Do the right things and do them right!
• Define test scenarios and test cases continuously!
• Don't make it worse!
• Write a project diary!
• Keep the answers to the question "Why"
• Realize every good idea ASAP!
• Get and stay in the flow!
• Industrial evolution - Listen to your customers and follow new trends!
• Stay alert!
• Have an expert on hand!
• What does the customer need?
• Don't disappoint your customer!
• Ask questions!
• Assign tasks efficiently!
• Request bottom-up input!
• Communication skills are extremely important
• Don't replace employees in the middle of the project!
• Develop a sense of responsibility!
• Recruit and retain the best employees!
• Get the things done with a small, motivated team!
• Focus on target!
• Avoid overly optimistic estimates!
• 9 women can't make a baby in a month
• Sharpen your axe before you start felling!
• Understand - Agree - Be Identified - Believe
• Don't hide any problem!
• Keep it simple!
• Success is not a matter of coincidence
• Good communication is important
• Development is evolution

Related next articles:

• Don't let your employees wait

Comment#: 00001

Date: 2026-08-27

User: Radim

Many years ago, early in my career, I was working as a software developer on one of my first larger projects. I was developing a central SCADA system for a machine controlled by multiple PLCs.

The project was very well managed. A good concept, good documentation, clear specifications, and a realistic project plan.

The SCADA system also included PDA - Process Data Acquisition. We collected production data in a database, aggregated it, and created statistics: the number of produced parts, the number of machine stops per shift, the shortest and longest stops, and similar information.

This part had also been thought through in advance and was well specified.

But when I started programming it, I encountered a problem. The specification considered only the optimal state, in which all parts of the machine were running and all PLCs were providing data. But what if one part of the machine was intentionally switched off? What if one of the PLCs had a fault and was not providing any data? What if communication with the SCADA system was interrupted exactly when the shift changed? While programming all those IF - THEN - ELSE statements, I began to realize that in such situations, the statistics might not produce correct results.

I pointed this out. But because of the promised deadlines, I essentially received a simple answer: "The function is specified. Program it according to the specification." So I did.

The machine was being successfully sold and delivered to many customers around the world. For several months, nothing happened.

Then one day, a senior manager called me into his office. I stood in front of his desk, and he told me that a customer was refusing final acceptance because the PDA statistical functions did not work correctly when some parts of the machine were left out of operation.

"What do you have to say about that?"

"Ah... I know," I replied.

He suddenly stood up from his chair.

"What? You know?"

"Yes. I had to program it according to the specification. Situations in which the entire machine is not in operation were not taken into account when evaluating the statistical data."

He thought for a moment and then said: "Fine. Then you will fix it. And then you will go to the customer and prove that the solution is correct. You will stay there until they confirm that the system works and give their final acceptance. How much time do you need?"

If I remember correctly, I asked for approximately six weeks to rework it and one week for installation and testing at the customer site.

In the end, I stayed with the customer for two weeks. We fine-tuned the last details, and the customer was satisfied and gave their final acceptance.

I still remember this experience years later. As a junior, I did exactly what I was told to do. I implemented the approved specification. And yet, during the implementation, I could already see a problem that the people making the decisions about the solution could not see. Not because they were doing their job badly. With a complex system, it is very difficult to anticipate every possible combination of states in advance. Sometimes a problem only becomes visible to the person who gets deep into the implementation.

And that is why having a good specification, good experts, and clearly assigned tasks is not enough. There must also be a way to bring new insights from the implementation back to the person who has the authority to make the decision. And that person must be willing to reopen the decision when new information emerges.