Office Politics and the ML Project
Technical people locate power in the ability to build things: develop new solutions, explore technologies, refine processes. In most organisations, the ability to deliver a product and the ability to prevent one from shipping carry considerably more weight, and neither requires technical understanding. The structures of large organisations distribute and hold authority – reporting lines, budget authority, approval processes, integration dependencies, and so on.
Technical teams often struggle here: requirements, decisions, and the fate of projects all live outside their domain. This is the oft-maligned political side, or, to be more sanguine: the business.
One of the more confusing situations for a technical person is a project that continues without shipping. These projects may not even be failing, there is simply no obvious technical progress. Even more confusingly, all the measures are good: sprints, bugs, tasks completed, backlog reduction all going the right way. This project continues to employ people, and headcount is budget; budget is resource, and justifies a role. The stated deliverable and the actual function diverge while still appearing to make progress.
The technical team and the organisational actors around a project are reading different landscapes. The technical team relies on communicated abstractions – the data, the code, the process. The organisational actors depend on shared assumptions: resource allocation and usage, risks and rewards of continuation and failure – structures which describe the efficiency of the organisation. A pilot that produces a technical lesson (a metric, a capability boundary, a constraint) simultaneously produces a political outcome: knowledge of contestable resources. Two different readings of the same event. The gap between them is where the zombie project lives.
The weaknesses which creates this gap tends not to be discussed openly. They are held privately, circulated carefully, and deployed when organisational conditions make them useful. Raising issues without the ability to act costs more than staying silent and signals more than is intended. The period between problems becoming visible and public acknowledgement is when positioning happens. It cannot be resolved by a technical breakthrough.
People with standing are either acquiring authority over the block, or building a case to remove it. Those without standing – usually technical people – leave or absorb the situation. Leaving is the more legible choice: without production impact there is no basis for career progression, and staying signals an absence of options. As capable people leave, the project loses institutional knowledge, the abstractions fail to support reasoning, and the project becomes harder to manage.
Resolution to this impasse requires a leader to read both landscapes and act on what they see. The effective leader understands which blockers are structural (requiring time or resource) and which are political (requiring decisions). A manager who is comfortable blocking does not have this capability: for them, the blockers offer support and are constructed with purpose. Organisations which ship consistently clear these structures as a byproduct of execution. The ratio of running projects to the number of shipped products measures organisation health; who has priority: friction builders or friction removers?
New technology disrupts these arrangements because it shifts what counts as useful authority. The established blockers, the conventions around what gets discussed and what does not, the distribution of credit for delivery: all depend on a stable technical landscape. When that landscape shifts quickly, the people who move first to understand the new capabilities gain understanding over incumbents. The current consolidation in AI is a visible example of this at industry scale. The initial disruptors have shipped relentlessly, while organisations watching from outside ponder which existing structures survive the shift.
In summary, for an organisation to be healthy it must ship. A product in production generates feedback; a bug has a surface to work against. A product that never reaches the customer generates nothing and teaches nobody anything, leaving space for other structures to develop. If the path to production is blocked, clearing it is the project’s first task. If it cannot be cleared, the project must be terminated.
The obvious question is why friction builders are tolerated. The answer is that externally, the same structures that slow internal delivery are how organisations negotiate with markets, competitors, and regulators. A business is not a pure delivery machine, and the people who manage its relationships, politics, and positioning serve a real function – even when that function is visibly expensive from the inside.
If your company is struggling to deliver product and ship due to internal structures, we cannot help, we’re not that type of consultancy!