Bursting the Boiler: How not to speed up an organization
Gregor Hohpe
Retired from big tech. Not retired from riding the Architect Elevator to make IT and architecture a better place. Have opinions on EA, platforms, integration, cloud, serverless.
Economies of Speed
Companies threatened by digital disruption usually realize that one of their digital competitors' advantages is the speed at which they move. Speed is critical in the digital world to run effective Build-Measure-Learn cycles, which feed the innovation machine by releasing products, collecting usage data, and gaining insight from that data how to make the product better. Running these cycles in 18 month intervals won't cut it when digitals can do it in days or weeks. That's why often refer to the rules of the game as Economies of Speed as opposed to Economies of Scale. Large, established companies benefit from economies of scale because they are large. But they are usually also slow. That's why they become a target for disruption in the digital world that's governed by Economies of Speed.
Increasing Pressure
When a company realizes that they need to become faster, their natural instinct is to do what they know well: applying pressure to the organization. For example, pressure to become faster, more agile, more customer-centric, etc. In a command-and-control environment this is a fairly natural tendency: respond to change with the means that have proven to work before. The pressure will take the form of new task forces, agile training for employees, additional project initiatives, etc.
However, middle management is often stuck in the old way of working and attempts to achieve the new targets set by upper management within the existing structures and processes: assigning staff to multiple projects at once, demanding higher productivity without giving people better tools, tightening deadlines without taking the friction out of existing processes. This will put an enormous strain on the organization and is more likely to cause frustration than to meet management's ambitions. This way of applying pressure is often supported by misbeliefs that employees in "digital" organizations routinely work 11 hours a day and sleep under their desk.
Bursting the Boiler
I compare this situation to a crew running a steam engine, which is surpassed by a much faster electric train. In a feeble attempt to speed up, the operator may throw more coals onto the fire. More coals allow the operator to increase the boiler pressure and put more force on the pistons. Alas, we know where this will lead: the steam engine will initially move faster, but will ultimately burst the boiler rather than beat the electric train. Bursting the boiler in organizations takes the form of increased frustration, staff attrition, and everyone being crazy busy without achieving much, while upper management proclaims the organization has become "digital".
Looking back at history a bit, the lean concept of muri (ç„¡ç†) already warned that an organization cannot overcome friction in the system by overburdening people. Apparently, manufacturing had this figured out half a century ago.
Changing the Engine
What to do instead? I have a suggestion each for architects and management:
- It's the architect's job to devise a new engine that can keep up with the speed of innovation instead of simply turning up the dials on the existing systems. This can mean making systems horizontally scalable, migrating towards a public or private cloud infrastructure, or taking friction out of software delivery, e.g. with a fully automated continuous integration and delivery. All of these are major changes in technology and ways of working, and are necessary to complete with electric trains.
- It may seem counter-intuitive, but the best way for management to avoid bursting the boiler is to set goals that are so ambitious that it's crystal clear from the start that they cannot be achieved by doing more of the same. Instead of cutting error rates or speeding up delivery by 10%, we must aim to cut errors by 90% and cut delivery time in half. Ideally both at the same time! Amazingly, this can be achieved as demonstrated by digital organizations, but not by putting more coals in the old boiler! To achieve a change in the way of working, management usually has to inject at least a few people who have seen an electric train zip by, so they can give support and direction to existing staff.
So stop increasing pressure and start working differently!
Learn 37 more things that one chief architect knows about IT transformation:
Lead developer, IT Architect at Ritense
8 å¹´Great analogy. I do agree architects should take the lead in devising new ways to optimize for innovation. It is important to see the complete picture to be able to optimize the whole (Lean principle #7). Large companies usually have specialized departments which leads to sub-optimization of the whole process. Architects are guarders of the complete system and should signal a different design is needed.
Great summary, Gregor. I think another mandatory ingredient is shift from micromanagement to management of tech