[ghostinit]

His first week he sat in on a discussion about Kafka consumer group rebalancing causing production issues. Engineers were deep in partition strategies and offset management. Forty five minutes in he asked "have we tried breaking this into smaller stories?"

That set the pattern for two years. Every technical problem got redirected to a process conversation because process was the only thing he understood.

Database migration from Oracle to Postgres? "Let's timebox this and take it offline." Microservice boundaries for payment processing? "What's the user story?" Deployment pipeline failing intermittently? "Sounds like we need a retro."

His retrospectives were textbook perfect. Clean facilitation, sticky notes, dot voting, action items in Confluence within the hour. But six months of action items and every single one was a process change. Not once did we commit to fixing the service causing 60% of our production incidents. He couldn't evaluate whether a refactoring proposal was valid so he defaulted to what he could judge: process.

The moment that crystallized everything was a 14 hour production incident. Connection pool exhaustion in a payment service that had been patched without proper refactoring for years. Team knew it was a ticking bomb. Had been raising it in retros for months.

Next day he facilitates a blameless postmortem. Engineers explain the root cause in detail. He nods, then steers toward "how can we improve our incident response process" and summarizes the tech debt as "legacy system challenges." Six weeks later same service, different symptom, same root cause.

For $150k we could have hired a senior engineer who could actually look at the code, unblock developers, pair with juniors on real problems, and catch architectural mistakes in pull requests instead of process deviations in sprint boards.

He had every certification. CSM, SAFe SPC, ICF-ACC, ICP-ATF. None required writing a single line of code. Two day courses and multiple choice exams that qualified him to coach teams of senior engineers on effectiveness.

He was a good person genuinely trying to help. The role itself is broken when it puts non-technical people in charge of making technical teams effective. How do you coach a team when you can't evaluate their technical decisions? You default to process. Every time.

Anyone else seen this pattern? Curious whether anyone has found a version of this role that actually works.