There is a particular kind of organizational shift that happens slowly and then all at once.
It starts with a new governance process. Then a reporting requirement. Then a capitalization framework that requires your time to be logged against specific project codes. Then a steering committee that needs to approve things that used to be decided at the team level. Then a program management layer that wants weekly status updates formatted a specific way.
None of these things are announced as a change to your job. They arrive as additions. Reasonable requests, each one. And then one day you look up from the spreadsheet you are filling out for the fourth time this week and you realize: this is the job now.
Not developing engineers. Not solving problems. Not building something worth building.
Filling out spreadsheets and playing politics.
What Leadership Actually Gets
The governance creep that produces this situation usually starts from a real concern. Leadership does not trust the delivery. Something went wrong — a project missed, a budget overran, a commitment that did not land — and the response is to add control. More oversight. More reporting. More approval gates. More visibility into what the teams are doing and when.
The logic is understandable. The outcome is the opposite of what they wanted.
Here is what actually happens when you layer governance and project thinking on top of a team that was functioning as a product team:
The engineers who were oriented toward outcomes start orienting toward process compliance. The sprint goal stops being about moving a number and starts being about satisfying the reporting requirements. The product owner who was defining problems starts defining deliverables — because deliverables are what the governance framework tracks. The manager who was coaching and developing starts reporting and shielding.
The delivery gets worse. Not because the people changed. Because the system changed what the people are rewarded for doing.
Leadership wanted control. What they got was the appearance of control and less actual delivery. The spreadsheets are full. The numbers are moving in the wrong direction.
The Manager Becomes a Reporter
When governance takes over, the engineering manager’s job transforms in a specific and demoralizing way.
You become a reporter. Your primary function is translating what the team is doing into the language the governance framework requires — project codes, capitalization percentages, milestone status, risk registers. You spend hours every week producing documentation that nobody reads carefully and that has no meaningful connection to whether the work is actually going well.
You also become a governance shield. Your job is to absorb the friction between the organization’s process requirements and the team’s ability to do actual work. You attend the meetings so the engineers do not have to. You fill out the forms so the team can keep moving. You manage upward so the people doing the work can keep doing it.
These are not nothing. In a heavily governed organization, protecting your team from process overhead is real and necessary work.
But it is not the job you signed up for. It is not the job that develops engineers or builds ownership or produces the kind of team that makes you proud to be a manager. It is the job of a human buffer between a broken system and the people trying to work inside it.
And it is exhausting in a specific way — not the exhaustion of hard work that produces something, but the exhaustion of hard work that produces nothing except the continuation of the process.
What Gets Lost
The thing that gets lost in governance creep is not efficiency. It is not velocity. It is not even delivery, though delivery suffers.
What gets lost is the human factor.
In the language of resource allocation and capitalization, engineers are line items. Their time is a cost to be managed. Their allocation is a variable to be optimized. The question is not “what does this engineer need to grow?” or “what problem is this engineer best positioned to solve?” The question is “what percentage of this resource’s time can be capitalized against this project code?”
That language is not accidental. It reflects a genuine belief — held by a lot of people in large organizations — that engineering is a production function. You put in requirements and time, you get out software. The quality of the output is a function of the specification, not the people.
This belief is wrong. But it is deeply embedded in the systems that governance frameworks are built on. And when it takes over, it teaches engineers the lesson that passive engineers have always been taught: you are not here to think. You are here to execute.
The hunters become cogs again. Not because they chose to. Because the environment stopped rewarding hunting.
The Only Defense
I am still in the middle of this. My organization is moving away from Agile and adding governance at every level. My time needs to be capitalized. My teams are being evaluated as resources to be allocated, not capabilities to be developed.
I have not figured out how to fix it. I am not sure it can be fixed from where I sit.
What I have figured out is the only thing that actually works as a defense: keep delivering.
Positive results are hard to argue with. A team that consistently moves the metrics that matter to the business — that reduces fraud, improves conversion, delivers measurable outcomes sprint after sprint — is a team that is difficult to dismantle even inside a heavily governed organization. The governance framework can add all the reporting requirements it wants. It cannot argue with the numbers.
Keep the bus moving forward. If people want to jump in front of it, they get run over.
That is not a satisfying answer. It is not a system change or a culture fix or a way to make the governance go away. It is just the thing that keeps the team intact and the work meaningful while the organization figures out what it actually wants.
Keep delivering. Keep the results visible. Keep the engineers oriented toward outcomes even when the system is trying to orient them toward compliance.
The fight is worth having. Even when you are not sure you are winning.
What This Means for You
If you are reading this and recognizing your own organization — the spreadsheets, the capitalization language, the governance layers multiplying — you are not alone. This is happening in large organizations everywhere. The pendulum that swings toward autonomy and product thinking eventually swings back toward control and project thinking. Sometimes it swings back hard.
The managers who survive it with their teams intact are the ones who kept their heads down and kept delivering. Not because delivery fixes the system. Because delivery is the only argument the system cannot dismiss.
Your engineers need you to protect their ability to do the work. Your stakeholders need you to keep showing them the results. Your leadership needs you to keep the bus moving even when they are adding obstacles to the road.
And you need to remember why you took this job — not to fill out spreadsheets, but to build something worth building. That purpose does not disappear because the governance framework arrived. It just gets harder to hold onto.
Hold onto it.
Getting Engineers to Give a Damn: A Manager’s Guide to Building Ownership Inside Broken Systems is available now. Get it here →
Use code AUGUST20 for 20% off the book or a paid subscription through August 31.
I publish every Tuesday at danielholt.substack.com
Top comments (0)