Bringing about Organizational Change from The Software Architect Elevator
This is a summary of how to bring about organizational change from The Software Architect Elevator by Gregor Hohpe:
Technical leaders are often brought in to organizations to fix technical problems, but technical problems often arise from organizational ones. You won’t progress fixing technical symptoms unless you address the management root causes.
Reporting should be project-based. Not functional, where all engineers report to a CTO. Functional reporting requires more cross-team synchronization, which slows down things down.
We think that bigger companies are more bureaucratic, but a legacy company 10 times smaller than Google in market cap can be more bureaucratic. Internal salespeople in these legacy companies can exploit management’s cluelessness, in one case making it to the board with a million-euro proposal to expose some functionality as an API. It’s easy to sell people in the stone age a wheel.
Beliefs
Organizations, like people, have beliefs. Our beliefs drive our behavior. Trying to change behavior without changing beliefs doesn’t work.
Sometimes organizational beliefs are captured in slogans like “move fast and break things”. But many times, beliefs are not written down. Asking people doesn’t help, because organizations are not aware of their own beliefs, just as a fish isn’t aware that it’s swimming in water. Water is all it knows! Organizations don’t think they have beliefs; they think that whatever they’re doing is right and natural and “of course; how else can it be?” So you need to reverse-engineer organizational beliefs.
To do this, first observe carefully, and look for unusual or unexpected decisions. Then keep asking people why they’d choose a particular option. When you do, consider which belief would make such a decision appear rational. For example, if a company launches only once a quarter, and you ask why not launch weekly, and they say it’s risky, you should be able to form the mental connection: Of course, if it’s risky, you’d do it less often! Nobody is irrational; they all act rationally given their beliefs. A person who believes encountering a black cat is inauspicious will return home and restart his trip. This is a logical reaction once you accept the premise that black cats are inauspicious.
Bringing change into an organization can stumble over existing strongly held beliefs. For example, if you try to put continuous deployment in place at a company that launches once a quarter, you may find resistance. You have to figure out the underlying belief, for example, that change is risky. Until then, your changes won’t be adopted.
Beliefs are learnt from painful experience. A kid who touches a hot stovetop learns not to do it again. When technology changes, beliefs need to change. Induction stovetops are safe to touch after cooking. But the kid would still hesitate to touch it, since he remembers his painful experience. Telling him that they’re wrong, or no longer right, won’t work. Telling him why, using terms like agile won’t help any more than telling the kid about Faraday’s law of electromagnetic induction.
Even if you convince legacy thinkers to switch to continuous deployment, the first or second time something goes wrong, they’ll take that as vindication of their wrong belief and switch back to quarterly deployment. In their mind, the wrong belief doesn’t require any evidence to convince them of it, while the new system is held to an unreasonably high burden of proof.
Unlearning is harder than learning, especially when the belief to be unlearnt has served them well in the past.
Wrong beliefs can also reinforce each other. An organization can have the following two wrong beliefs: first, that we should launch only once in a quarter. Second, an organization might work in two phases: first, the software is implemented without regard to quality. Then, a QA phase begins which adds quality to the software. The software enters the QA phase with low quality, and exits with high quality. This doesn’t work, but the organization might believe it, and insist that it even says so in the name Quality Assurance! Given these two beliefs, if you tell them to launch sooner, they’ll skip QA, and launch the crappy code written in the initial phases of the project. This won’t work. In this case, the two wrong beliefs need to be changed together.
Just as people who want to lose weight buy miracle exercise machines, managers insist on simple solutions to their complex problems.
Autonomy
People sometimes criticise agile saying it’s a lack of planning and everyone doing whatever they want. But the opposite of agile is not order, it’s slow chaos.
When companies try to over-control, the solution is autonomy. People sometimes object to autonomy saying you can’t have everyone doing whatever they want. But that’s anarchy, not autonomy. How do we create autonomy?
Stop dis-empowering people, such as by needless approvals and delays, or by preventing teams from hiring.
Give them feedback on what they’re doing that’s working or not working so that they can improve
Get goals that people can work towards.
Many organizations are managed by objectives and grant teams autonomy in achieving these objectives. This is a good approach, but people sometimes meet the letter but not the spirit of the objective: if they have a goal of setting up a server by May 31, they set up the server by May 31 and claim victory, even if it doesn’t work reliably. In other cases, people claim they’re following the policy while not. In other cases, people use the standard but for the wrong purpose: if the company policy is to drive BMWs, people will drive Mercedeses, but claim they’re using BMWs, which they are — as a four-seat meeting room.
Queueing
When a server receives requests faster than it can serve them, it queues them till they can be served. Queues also exist in organizations:
Busy calendars cause important decisions to be queued.
Monthly or quarterly steering meetings cause decisions or projects to be on hold till the next meeting.
Emails that go unreplied for days.
Features that are implemented but waiting for the next release.
Workflow tasks like a book can take a company weeks to deliver, as opposed to the next day by Amazon.
If you found this interesting, and want to continue exploring this topic, read Organizational Red Flags or Summary of the Software Architect Elevator.