This blog entry is mostly focusing on the topic of innovation. The words "process" and "policy" get involved as well.
When a company starts up, it does not have a documented process to follow, even less does it have a certain "policy". The employee needs to use, as his only tools, "common sense" and "domain knowledge" in order to get from A to B. If common sense and domain knowledge are correctly applied, the company makes profit. If the employee makes the wrong decisions all the time, the company tanks and goes bankrupt.
Enter the 5-year old company. Employees have routinely been taking decisions and have established a so-called "process", which is the way how things "are/estar" done. If circumstances do not change, the application and utility of that process can be very successful.
( "estar" comes from Portuguese, meaning a temporary "to be" )
Enter the 30-year old company, 20.000 employees later. Now things are established through "policy". This means, ensuring that "processes" and decisions conform to a certain "grand strategy". This is when things "are/ser" ( meaning the definitive "to be", the Portuguese "ser" ).
Policies can be hyper-destructive, because they are very difficult to change. It is as if they live their own lives, have no owner and no person within the organization generally feels powerful enough to change it. Changes in policy generates enormous quantities of confusion in an organization. Why?
It is funny and sour here that the word "policy" actually means: "A plan or course of action, as of a government, political party, or business, intended to influence and determine decisions, actions, and other matters" (Source:
The American Heritage® Dictionary of the English Language, Fourth Edition).
So, the description of policy does not carry the heavy sense of "mandatory", but the interpretation of employees is exactly that. Making a better decision for the sake of your project success may result in assuming the risk of being put in the spotlight for non-compliance. Policies are suitable and useful as a guideline, when assessing which option to favour if the alternatives are about equal.
The companies function differently, because there is a difference how (much) people use their mind. The startup company requires people to use their mind continuously, but the large corporation can live with a very large number of monkeys that apply a certain process, what they would call "best practice".
The world changes very quickly, so what was established as a process some time ago needs to be re-evaluated every so often. Communication about (requests for) changes in processes generates confusion and a barrage of "re-alignment and re-organization emails".
A process should be a helpful tool in order to define the responsibilities for the parties involved. In that sense, the "process" serves a very useful function. But it is also a potential hiding cover. It gives people the potential to stop thinking and use the process as a cover excuse for lazy-ness (or worse, blame the process as the point of failure, ignoring for now whether the process is actually wrong, incomplete or correct!).
Here we enter an interesting arena. The question is not whether we should dump processes altogether. The question is what we need to understand about each process in order to make it a useful tool in our collaboration. Understanding the process in this way goes much further than knowing how it actually works. People need to understand why it is there in the first place, what purpose the process serves outside the context of the routine or practice it is applied in. This is exactly the definition of responsibilities. Without the understanding of those definitions, nobody can use the process efficiently and elaborate on it (become contributing employees).
If employees do not have experience with alternatives, they will not understand additional reasons why the process is the way it is, simply because they cannot imagine how in practice things can go wrong. This "wisdom" only comes from exploration, which is forbidden in the context of the process because you are required to follow it. Thus, processes have the tendency to train monkeys that never think outside the box.
With this problem of never thinking outside-the-box, other people that do understand are inclined to try to prevent the failure by mounting another process, in an effort to help lesser experienced people. Such processes often formalize the responsibility that the employee should have assumed in the first place. Instead the process provides yet another cover for the employee to hide behind and it can make them even lazier than before, countering productivity.
When the environment or market the company operates in does not change, then the mounting of processes is not necessarily a problem. The process is basically the description of a routine that you must follow like a machine in order to be productive. Factories could do this for example and then you might get good results, everybody happy, no problem.
As in IT especially, markets, environments, tools and "insights!" rotate every three years or so, the process building blocks age very rapidly, which in turn very rapidly ages the organization. If you do not have the infrastructure available to create 'process change or adaptation', you will eventually age until you reach mortification.
People that do think in the organization would already have left by that time. So, losing your key employees is a good indication that your organization is aging too rapidly and not adjusting quick enough.