Every so often, common sense turns out not to be quite so sensible. The assumptions that have guided us for years can, under the wrong circumstances, lead us confidently towards the wrong conclusion.
A simple example—one I have encountered more times than I can count—is the famous equation:
1 + 1 = 2.
Nothing could seem more obvious. If I have one apple and someone gives me another, I now have two apples. Even my four-year-old nephew could understand that.
If I had one.
The problem is not the principle itself. The problem is our tendency to apply it literally, even after leaving the context in which it makes sense.
This happens when we try to apply a mathematical formula to an organisational or logistical problem. For example, when we assume that adding more resources will automatically produce a result faster.
Imagine that, on the morning of Christmas dinner, Aunt Justine announces that she has invited her husband’s entire family and that we will now need to prepare a second turkey.
In that case, adding a second oven is a perfectly reasonable solution.
One oven plus one oven allows us to cook two turkeys.
Here, 1 + 1 really does equal 2.
Now change the situation slightly.
This time, Aunt Justine has not invited another twelve people. She has simply decided to arrive at lunchtime instead of in the evening.
Adding a second oven will not make the original turkey cook twice as fast.
Now, 1 + 1 equals a table full of hungry relatives and an empty oven sitting in the corner of the kitchen, occupying the counter space we could have used to prepare the starters.
It is a slightly ridiculous example, admittedly, but it illustrates a problem that professionals encounter constantly when dealing with logistical, strategic or organisational constraints.
I have lost count of the number of times a client at a digital agency suggested adding more developers to a project because the deadline was getting dangerously close.
The reasoning seems perfectly logical.
If three developers can finish the project in three months, six developers should be able to finish it in six weeks.
Simple. Obvious. Mathematical.
Except that we are no longer doing mathematics, and software development does not work like cooking two independent turkeys.
Adding someone to a project is not like plugging in a second oven.
It is more like inviting a new cook into the kitchen—one who does not know the recipe, does not know that Grandpa is allergic to cumin, has no idea that the good knives are hidden behind the pasta on the top shelf, and has yet to discover that switching on the third hob while the oven is running will trip the circuit breaker.
Before that person can help, someone has to explain what everyone is making.
And that someone has to stop making it in order to do so.
You can divide an amount of work.
You cannot always divide the time required to complete it.
The same principle applies to an organisation whose employees are drowning in five different Excel spreadsheets: one to track what was completed this week, another to record what remains to be done, another for the current project, and yet another for everyone’s working hours.
Adding three more spreadsheets so that every task can be documented down to the minute is unlikely to cause a sudden explosion in productivity.
These are the moments when an organisation needs to stop, take a breath and ask strategic questions.
Rather than throwing more resources at the problem, it needs to understand where the problem comes from and where intervention would actually make a difference.
Sometimes the right answer really is to allocate more resources.
But not blindly.
They need to be added deliberately, in the right place.
At other times, the answer is to replace a methodology that dates back to when the company was held together by duct tape, goodwill and three exhausted people, even though it now employs fifty people and reports to shareholders.
An additional tool does not repair a broken process.
It may simply give that process another place to break.
The same thing happens when a product is struggling to sell.
The instinctive response is often to add more features. But before doing that, it is worth asking whether the real issue is the product’s positioning, the user experience, or the unfortunate possibility that there simply are not enough customers who want it.
Adding a new feature to a badly positioned product does not necessarily make it more desirable.
It may have the opposite effect.
It can make the product harder to use, more expensive to maintain and even more difficult to understand.
The result is a product that still does not sell, but now includes calendar synchronisation, a badge system and a button for exporting to PDF information that nobody wanted to look at in the first place.
None of this means that businesses should never add features, recruit employees or invest in better tools.
The problem is not the addition of resources itself.
The problem is the belief that adding resources is a universal solution.
Before adding anything, you first need to understand what is actually slowing the system down.
In manufacturing, this would be called a bottleneck: the stage whose limited capacity restricts the performance of the entire process.
Every other part of the system may be capable of operating twice as fast, but the final output will still be limited by its slowest step.
Imagine a restaurant with room for a hundred guests.
The waiters take orders at remarkable speed. The payment system processes every bill in under ten seconds. Unfortunately, the kitchen is twelve square metres wide, and its four ancient burners can produce only fifteen meals per hour.
Hiring three more waiters will not allow the restaurant to serve more customers.
It will simply allow more people to place their orders sooner, giving them additional time to wait for their steak while watching the bubbles slowly disappear from their beer.
Worse still, the new waiters may send even more orders into the kitchen, interrupt the cooks more frequently to ask about table twelve, and reassure customers with increasingly strained smiles that their food is “being prepared”.
The additional resource has not solved the problem.
It has increased the pressure on the part of the system that was already struggling.
In a software project, the bottleneck is not always development.
It may be a poorly defined requirement, a decision that nobody wants to make, or a client approval that requires three meetings, two written summaries and the agreement of someone who is on holiday until next Tuesday.
You can add ten developers to the team.
They will not build a feature any faster if nobody knows how that feature is supposed to work.
They may, however, produce ten different interpretations of it.
This will give the project an impressive level of creative diversity, although it may not bring it any closer to completion.
The same phenomenon exists in almost every part of a business.
A sales team may genuinely lack leads. But it may also have enough leads and be wasting hours copying the same information into several different systems.
An administrative department may appear understaffed while much of its time is spent manually re-entering information that already exists in another document.
A team may schedule more meetings in an attempt to improve communication, only to discover that it no longer has enough time between meetings to complete the work it needs to discuss at the next meeting.
In situations like these, adding resources is sometimes like forcing more water into a blocked pipe.
The flow does not improve.
The pressure simply continues to rise until someone spends Monday morning cleaning up the floor.
The first step is therefore to stop confusing symptoms with causes.
Employees who are constantly overwhelmed are a symptom.
Repeated delays are a symptom.
Errors in documents, unhappy customers and teams that cannot clearly explain the status of a project are symptoms too.
The cause may genuinely be a lack of resources.
But it may also be poor allocation of work, an unnecessarily complicated process, scattered information, unclear responsibilities or dozens of small manual tasks that seem harmless individually but consume several working days every month when combined.
At that point, organisations need to ask questions that are slightly less comfortable than:
“How many more people can we add?”
What is actually preventing the work from moving forward?
Which stage takes the most time?
Where do errors occur?
Which information is entered more than once?
Which decisions always depend on the same person?
Are all the stages in the process still useful, or do they exist only because, eight years ago, someone created a spreadsheet called Final Project Tracking — Definitive Version 2, and nobody has dared to touch it since?
These questions have an inconvenient habit of not producing immediate answers.
They require observation, measurement and, occasionally, the willingness to challenge habits that appeared to work for a long time.
But they help prevent an organisation from solving the wrong problem with remarkable efficiency.
Because it is entirely possible to optimise a process that should not exist.
You can automate a task that should have been eliminated.
You can accelerate the transmission of information that nobody uses.
You can build an elegant real-time dashboard displaying metrics that do not help anyone make a decision.
The result will be faster, more modern and probably more colourful.
It will not necessarily be more useful.
Sometimes, the best way to improve a system is not to add something, but to remove something.
Remove an approval step that contributes nothing.
Eliminate duplicate data entry.
Bring information scattered across several files into one place.
Reduce the number of people invited to a meeting.
Abandon a feature that makes the product more complicated without solving its main problem.
This is less exciting than buying a new tool or announcing a major recruitment campaign.
Removing a step does not create the impression that money has been invested, and cancelling a meeting rarely produces an inspiring photograph for the company’s LinkedIn page.
And yet, eliminating one hour of unnecessary work every week may be more valuable than performing that hour of work more quickly.
Common sense is not necessarily wrong.
It is simply incomplete.
It works as long as the problem remains within the context that gave birth to it.
One apple plus one apple will always give you two apples.
Two ovens will always allow you to cook two turkeys at the same time.
Two developers can produce more work than one when the project is clear, the tasks can be separated and both developers know what they are supposed to do.
But two ovens will not cook the same turkey twice as fast.
Eight developers will not obtain a client decision eight times sooner.
And nine Excel spreadsheets will not transform a confused process into an efficient organisation.
Before asking what should be added, it is often more useful to understand what is blocked, what is genuinely missing and what could be removed entirely.
Otherwise, you may end up with a larger team, more tools, a higher budget and exactly the same problem you had before.
Along with a second empty oven in the middle of the kitchen.