A couple of years ago, I used to blog and tweet a lot about #NoEstimates, before I decided to completely quit this discussion. In one of the latest articles I wrote about estimation, I insisted on estimations as being only a tool. Even though I won’t discuss much about estimations in the post, I think there is still room for talking about tools, and how they can catalyze, or, on the contrary, inhibit, a business or an organization cooperation and improvement.
Before going any further, I’ll share with you my own definition of what I call “a tool”. A tool is any object, or a process, or a word, anything really, that you hire for solving a problem.
For example, a hammer is obviously a tool, but money is also a tool : it was invented to ease exchanging goods between people. An important thing to understand is that a tool is not essential. It is something that people use to achieve a goal, but a tool is not a goal. You don’t want to own a hammer, you want to own a hammer because you often need to nail stuff to your wall. I suppose that money is only useful in a context of private property, but I can’t remember buying anything from my wife, or from my children. At a wider scale, some anarchist communities from the past removed money as well. It’s just a tool.
control and uncertainty
Human beings don’t like when things go out of control. They are scared of unpredictable behaviors. And, this is true for individuals, but this is also true in a team or any kind of organization, of any size. That is why we, Human, like process. A process is a tool, or a set of tools, for keeping things from happening in an unpredictable manner. A process can be heavy and constraining, but it is reassuring. It becomes kind of meta when we think that management, in its own way, is a tool created for dealing with creating and improving process, which are tools !
It is very important to understand how much effort Human can put in making sure that everything stays in control. In a business organization, predicting the future is vital, hence the invention of tools like budget, gantt charts, and estimations
blaming the people
When people are used to working with a defined set of tools, they tend to forget that those tools do not define the organization, but it’s the organization which defines the tools. There was a problem to be solved, the organization invented, or hired, a tool to get rid of the so-called problem, and now we keep using the tool because we don’t want the problem to come back. But when we live in a process, or let’s call it a system, for a while, we are inclined to believing that the system rules the organization.
In this context, when someone misuses a tool, we naturally blame him/her. The system is good, the person who misused it is evil. When a worker, in a factory, causes an accident with a machine, the company accuses him/her to be inattentive, or worse. Sabotage ! (you may not know it, but the word “sabotage” comes from the French word “sabot”, a clog, which strikers used to throw into their machine to break it).
Any system, any tool, has caveats, and as the Murphy’s Law teaches, there will be someone to misuse it. But, where most organizations see an occasion to blame someone, you must see a place to improve the system.
improve… or remove
In France, in the second half of XVIIIth century, King Louis XVI realized that the monarchy was not doing its job well enough. Monarchy is definitely a tool, so he tried to improve it so that the problem to be solved, which was basically keeping him on the throne, could be dealt with. But the system was too heavy and flawed. Privileges, unbalanced taxes and laws, huge inequalities between the people, nobility and the cloth : the gap was too important and every try was another failure. The solution : remove the tool. Long story short, Louis XVI is beheaded.
When a system goes wrong, an organization will often, after blaming some people of course, try to improve it so that the misuse situation never happens again. This is when new tools are created. In the introductory example, many tools were added to monarchy : new local parliaments, new laws, new taxes, abolishing corvée, the estates general, etc. But, most of the time, it just makes the system more complex. That is why you should always consider removing the failing tool completely as an option. Remember : it is the tools which is primarily failing, not the people who use it.
more practical examples
- In my house, in a room that used to be a bedroom, we store washed laundry that needs to be ironed. We used to put it on a table. Unfortunately, the table was quite big, allowing us to store an impressive amount of clothes on it. My wife, realizing that we were not using the table as a simple buffer anymore, decided, instead of blaming us two for being lazy, to remove the table.
- In France, the presidential election campaign was horrible. Day after day, a new scandal arose, and people were just disgusted to realize that all of those politicians who lead the country were so corrupted, and selfish, and misusing their position so much for their own benefit. But maybe the problem is in the system itself. Révolution !
Two cases/trolls from software development now :
- In Object Oriented Software development, every problem has its design pattern. A common improvement strategy is to stack them up : “Oh! In this situation you should add a factory to build the various strategies to be injected by the dependency injection container into the front controller, so that the facade abstracting away the service is …” or maybe plain old functional programming would do the trick
conclusion and takeaways
- Tools are just tools, they should not define your organization.
- When a tool works that’s great. When it doesn’t work, or allows people to do bad things with it, change it
- Instead of blaming the people for misusing a tool, blame the tool for allowing people to misuse it.
- Sometimes it is better to throw the old tool away completely. Maybe the original problem does not even exist anymore