The divide between builders and bureaucrats is getting exposed more than ever today. Every organization system requires people who can build stuff and folks who administer the enterprise. When the balance skews heavily towards administration, the joy of developing drains out of the system.
How much time is spent creating value or solving problems? Vs. How much time is spent filling out reports and forms?
Effective administration is necessary but insufficient. The tension between creating value and managing the value generation system is always present. Effective administrators learn to strike a balance by being transparent about the needs. They get out of the way to make it easier for builders to innovate while maintaining sufficient control. Not too tight, not too lax, just right – in the goldilocks zone. For instance, when the work reports itself, the burden of preparing reports and updating meetings diminishes. Shared visualization via Kanban boards and explicit policies reduces the report-generating burden because the work items are visible as they flow through the system, and statuses are updated by their movement. This creates transparency in the organizational operating system by linking administrator and builder activities to converge on products and services for the customer.
Bureaucracies in disguise are in real danger. They think they are innovating, but they are not. Here is a short off-hand list of symptoms in enterprises where the builders are demotivated and the administrators debate the arrangement of deck chairs.
- Releases are fewer and farther between.
- Large multi-year projects consume most of the yearly budget.
- Colleagues are called customers.
- Demand for more dashboards, reports, and metrics keeps increasing.
Enterprises exist to serve their customers. Not colleagues. Customers are outside the organization’s boundary and trade on price for goods and services, whereas colleagues are inside the organization’s boundary and trade salaries for their contributions.
Builders aim to please their customers with their craftsmanship. Bureaucrats in disguise aim to please each other. The builder derives satisfaction from an external customer perspective, whereas the latter derives satisfaction from collegial approvals. Of course, people ought to get along and cultivate a psychologically and physically safe environment to work together. However, when the circularity of mutual appreciation fails to account for the impact on customers, the enterprise enters the vicious loop of becoming a bureaucracy in disguise.
The separation between a builder and a bureaucrat in disguise is not about organizational titles, roles, and responsibilities. The divide is in the approach that each takes. The builder favors reality, and the bureaucrat in disguise believes abstractions are reality.
The builder cannot build without acknowledging things for what they are and shaping them to become better. When a service API is broken, it must be acknowledged that it is not working before the builder can take the next steps to diagnose the problem and fix it. For the builder, the result of their actions is tangible. The API either works or it doesn’t.
Administrators who approach the work with empathy for the builder know that abstract reports and dashboards are not reality. They know that organizational challenges manifest differently for builders and administrators. They do not impose their perception on the builder. Instead, they improve their understanding by engaging with the builder to co-develop solutions to customer problems.

Bureaucrat in disguise
The administrator becomes a bureaucrat in disguise when they assume that the break-fix report is all there is to it. In the absence of hands-on knowledge about the problem, the bureaucrat in disguise assumes that the information in the report is all that there is to know.
An effective administrator engages with the builder directly—“individuals and interactions”—to develop a more nuanced understanding of the situation, even though they themselves may not know how to code. The “processes and tools” used to manage the situation are valuable only when they support collaboration between the builder and the administrator.
Agile approaches break the insular bureaucratic circularity through frequent delivery of working software. This requires responding to customer needs and feedback, not just collegial opinions. The outside-in customer perspective filters and refines internal narrative circularity. The more often the enterprise releases value to customers, the longer the organization avoids the vicious loop of becoming a gaggle of administrators patting each other on the backs in closed-door meetings—bureaucracy in disguise.
I leave you with the following exchange that I had with a bureaucrat in disguise.
Bureaucrat in disguise: We are 90% Agile.
Me: How come you are not at 100% yet?
Bureaucrat in disguise: We do all the ceremonies – PI planning, sprint planning, retro, review very well, but we have not released any software for over a year.
Join our Certified Agile Leader workshops to learn how organizations evolve with agility.
0 Comments