Organizational Red Flags from The Software Architect Elevator
When an architect is brought into an organization to fix technical problems, he should be aware of the following red flags. This is a summary from The Software Architect Elevator by Gregor Hohpe:
Applying too much pressure: When legacy companies are overtaken by digital-first companies, management puts pressure on the organization to deliver faster. But this won’t work. This is like a steam engine that is surpassed by a fast electric one. If the driver is forced to throw more coal into the fire to increase the boiler pressure, it will speed up the train, but soon cause the boiler to explode. Similarly, management demanding “I want it faster! Faster!! Faster!!!” will damage the organization.
Being solely top-down: A closed loop system is like a heater that first heats the room. Then it uses a sensor to determine how much impact its action had, and based on that feedback, increases or decreases the heating. Open loop is a system without this feedback — it doesn’t work. Likewise, in a company, management steers the team in a certain direction, which is top-down. After that, management should get feedback bottom-up from the team on the impact their actions have had, and consequently adjust their actions. Management that operates solely in a top-down, command-and-control way is a red flag. They’re as ineffective as a heater with a broken thermostat.
Cargo culting: Companies sometimes try to copy superficial aspects of successful digital companies, like having stand-up meetings or giving everyone Macbook Pros with stickers for open-source products. This doesn’t work, and is like tribals building a wooden plane in the hope that that will cause white men to arrive:
Overuse of buzzwords: If you’re hearing every day about agile or cloud, it’s a red flag. If they have to keep saying they’re agile, they’re not. Googlers did not talk about “big data”, “cloud” or “infrastructure as code” because that’s how Google worked; there wasn’t a need for a specific term to describe what they’re doing anyway.
Excessive meetings: In poorly run organizations, people don’t have autonomy, and have to align or get approval from others for everything. Work stops until a meeting can be scheduled, which can take months for senior people. Synchronizing two computers kills the throughput of both. To increase throughput, you want each computer running at full speed without waiting for the other. Similarly, a meeting kills the productivity of everyone who has to wait for its outcome. When there are too many meetings on their calendar, people resort to blocking time for individual work. This makes the calendar even fuller, making the problem worse, not better. Instead, give people more autonomy.
Over-planning: Planning a project extensively before it starts, with the goal of eliminating surprises, is a red flag. It would be like trying to calculate how long your heater should run and programming it that way, rather than sensing the room temperature and adjusting dynamically. Cheap thermostats are better than some project managers.
Over-control: Sometimes, organizations try to exert too much control on their engineers. Sometimes it’s obvious, like not giving engineers admin access on their laptops. In other cases, it’s more subtle, but no less severe a problem. One red flag is hearing about governance too often.
Watermelon status updates: People want to look good to their bosses, so they give status reports that are like watermelons: green on the outside (everything’s going well!), but red on the inside (the project is facing serious problems). This is like giving a status update after the Titanic’s sinking that “700 happy passengers have reached New York”. To prevent this, management should look at dashboards showing objective data rather than subjective thumbs up / thumbs down, green/yellow/red indicators or PowerPoints.
Black market: Bureaucratic organizations have a flourishing black market where people who know who to talk to can get something done quickly. Another type of black market is allowing executives to bypass the rules they’re imposing on others. Black markets break the feedback cycle: if people have to live with it, it will create pressure to ease the bureaucracy. Black markets are inefficient — people have to spend time learning to navigate the black market, which is time that could’ve instead been spent creating business value. This knowledge is undocumented, which is bad. Newcomers have to take time to learn it. Black markets also create haves and have-nots, rather than democratizing access to resources. Finally, black markets erode the authority of the organization in people’s eyes. These are all the problems of black markets. To fix the black market, control freak leaders should realize that trying to over-control is what created the black market in the first place.
Rubberstamping in architecture review meetings, with the excuse that “we didn’t have time to do it properly”. This defeats the point of an architecture review. If there was no time, skip the architecture review.
If you found this interesting and want to continue exploring this topic, read about Bringing about Organizational Change or Summary of the Software Architect Elevator.