Project Controllers and Project Trolls

A Descent Into the Human Abyss

This story unveils the true villains of the IT world: controllers with a penchant for numbers and project trolls who specialize in sowing confusion. As developers try to keep their code clean, these trolls crawl out of their caves, armed with Excel sheets and Gantt charts, ready to turn every meeting into a battle for sanity. The real challenge? Surviving the people, not the project.

You think you know people. You think you’ve seen the worst of office politics, the petty arguments over code style, the endless debates about whether to use tabs or spaces. But nothing—nothing—can prepare you for the dark, twisted world of Controllers and Project Trolls. These aren’t just office nuisances; these are the shadowy forces lurking in every project, waiting to drag you into the depths of bureaucratic hell.

Act 1: The Project Controllers’ Grand Plan

Let’s start with the Project Controller —those champions of process, lords of spreadsheets, and eternal enemies of flexibility. On the surface, they look harmless enough. Armed with their Excel sheets and Gantt charts, they present themselves as the sensible adults in the room. But beneath that calm exterior lies something much darker: an insatiable need for control.

It begins innocently enough. “We just need to track a few metrics,” they say. “Let’s make sure we’re sticking to the timeline.” But before you know it, they’re questioning every single decision. “Why didn’t you report this task at 9:02 a.m.? What do you mean the client changed the requirements? That’s not in the plan.”

Suddenly, the project that once had potential—real creative potential—is suffocated under layers of oversight. Every line of code, every coffee break is monitored, logged, and dissected. The Developers, who once dreamed of freedom, are now shackled to the almighty spreadsheet, their creativity drowned by endless KPIs and performance metrics.

But it’s not just about control. The Controllers are on a mission—a mission to make sure that no one, and I mean no one, strays from the path of project conformity. It’s all about the numbers, the deadlines, the charts. God help you if you miss an arbitrary milestone.

Act 2: The Rise of the Project Trolls

And just when you think it can’t get any worse, Project Trolls emerge. They proudly declare themselves as emissaries of the "Major Stakeholder," sent to derail progress with vague requests and unnecessary revisions. You’ve seen them before—those shadowy figures who lurk at the edges of every project meeting, waiting for the perfect moment to strike. They don’t contribute, they don’t code, and they sure as hell don’t help. But oh, do they love to criticize.

“Why is this taking so long?” they ask, despite having zero understanding of the technical complexities. “Shouldn’t this be done by now?” they question, while contributing nothing but confusion. They specialize in adding fuel to the fire, turning every minor delay into a catastrophic disaster.

Their favorite trick? Asking the most soul-crushing question of all: “Did we really need to build it that way?” It’s never an honest inquiry. No, it’s a rhetorical dagger, designed to make the Developers second-guess every decision they’ve made. Suddenly, what was once a clear path forward is now a maze of doubt and frustration.

But the Trolls don’t stop there. Oh no. They feed off chaos. They’ll go directly to the Project Controllers, whispering in their ears, planting seeds of doubt. “Did you notice that task was marked as complete a full hour after the deadline?” they’ll say. “Maybe we should add more oversight.”

And just like that, the Trolls and Controllers unite—a monstrous force of bureaucracy and obstruction.

Act 3: The Human Abyss

What happens next is the stuff of nightmares. The Developers find themselves trapped in a Kafkaesque nightmare, where every sprint review feels like an interrogation. The Product Owner (PO), who once believed in the project’s vision, now spends their days justifying every change to the Controllers and defending every decision from the Trolls.

But the worst part? The project stalls. It doesn’t move forward, it doesn’t move backward—it just sits there, suspended in a void of endless analysis and critique. Fakers and Bench Warmers? They thrive in this environment. While the Developers are buried under a mountain of unnecessary processes, the Fakers quietly coast, doing the bare minimum while escaping all scrutiny. Why? Because the Controllers are too busy tracking the real work.

It’s a slow, painful descent into the human abyss. The Developers lose their motivation. The Stakeholders, once optimistic about Agile and creative problem-solving, watches as his vision is slowly strangled by a thousand bureaucratic paper cuts.

Act 4: Controlling runs the show - The Return of the Old Structures

For a long time, we followed the YouBuildItYouRunIt principle – every developer could deploy their own code directly to production. It was the pinnacle of agility and responsibility. But then, Security stepped in, as it always does, and made sure deployments had to go through a special client, sealing everything off from the outside world. The catch? This client costs money – per user. The feeling of a tightening noose was impossible to ignore.

Our corporation needs to save money, that’s no secret. And when the pressure is on to cut costs, everything gets cut. Even the client. You know what’s coming next: not every developer gets access anymore. Instead, a few chosen ones per team are selected to have the privilege of deploying. The rest? They have to wait. The result? We’re suddenly dependent on these few people. And what happens when they go on vacation or fall ill?

With the introduction of user-based billing for the client, the system has turned back, and we’re falling into the same old structures. Controlling now runs the show, and the once agile YouBuildItYouRunIt principle is slowly but surely being eroded. Flexibility and ownership have given way to financial control, and we find ourselves back in the same dependency – the end of agile freedom is looming.

Act 5: The Confrontation

But then, something happens. Maybe it’s the PO who snaps first. “Enough!” they shout in a meeting. “We can't manage every second of this project and make them wait for tools at the same time - we have to make people work! It's like you're stuck in a traffic jam with an ambulance and no one is clearing the way!”
The room goes silent. The Developers, now hunched over like broken soldiers, look up with a glimmer of hope.

The Major Stakeholder steps in. “This isn’t why I started this project,” she says. “We’re here to build great things, not to drown in process.” The tension is thick as she turns to the Controllers and Trolls. “We need to trust our people. We need to give them space and the tools to do what they do best.”

And then the major stakeholder spoke the magic words: "This project is for a critical service to all our customers. We cannot afford to damage the company’s image any further. There will be no budget cuts to this project, and the team will have full access to all the tools it needs!"

The Controllers, clutching their spreadsheets, hesitate. But something in the Stakeholder’s words hits home. Slowly, reluctantly, they agree to loosen the reins. The Project Trolls retreat, muttering something about “lost productivity,” but for the first time, they’re ignored.

Act 6: The Breakthrough

The next sprint is different. With the chains of bureaucracy lifted, the Developers are free to code again, using tools they need to create, to problem-solve. The PO is back to focusing on delivering value, instead of justifying every minor deviation to the project controller. The Stakeholder? She smiles as the team moves forward with purpose.

The project controller still track metrics, of course—that’s in their DNA. But they’re no longer suffocating the project. The Trolls? They’ll always be there, lurking. But now the team knows how to handle them.

And so, the project that once teetered on the edge of collapse is back on track. It’s not perfect, but it’s moving forward. And in the end, that’s all that matters.

Because sometimes, to escape the human abyss, all you need is a little trust, a lot of patience, and the courage to tell the Trolls to get lost.

Conclusion

The problem with Project Controllers is that they’re often brought in when things appear to be going off track—typically when top-down dictated budget cuts push projects out of the cooperative agile mode and straight into emperor mode. In these moments, the Project Controllers seize control, and their authority becomes absolute. Their job? To trust the very people they find difficult to trust - because things don't go according to plan. But what plan, has it already changed again?

The problem with Project Trolls is that they actually have a legitimate project role, but due to a lack of competence or time, they often delegate their tasks to so-called proxy roles. Then, from the shadows, they swoop in with management by helicopter and a series of helpless interventions that only serve to further deepen the confusion.

Got thoughts? Share them at ifeel@lostindigital.blog