DEV Community: Ghostinit0x

When Your Team Becomes the Unofficial Support Group for Every Unqualified Tech Lead

Ghostinit0x — Sat, 14 Mar 2026 04:32:58 +0000

There's a pattern I keep running into and every senior engineer I've talked to recognizes it immediately but nobody writes about it because writing about it means questioning decisions made by people who control your career.

A company hires a tech lead from leadership's personal network. No real technical vetting, no input from the team that's going to work under this person. Just a relationship. And suddenly there's a new name on the org chart that everyone has to accommodate.

For the first few weeks it looks fine because asking questions is expected when you're new. But then the questions don't stop. And then you realize the tech lead isn't learning, they genuinely don't understand the technology they're supposed to be leading. They can't review a PR with any real depth. They can't help their developers debug anything. They can't make architectural decisions because they don't understand the architecture well enough to evaluate tradeoffs.

I've been building software for 25 years and I've seen this play out at multiple companies. What happens next is always the same.

Your team starts doing two jobs

The senior engineers quietly start compensating. Not because anyone asked but because the work needs to get done and the person who should be directing it can't. They answer questions the tech lead should be answering. They make decisions the tech lead should be making. They do code reviews the tech lead should be doing. Their workload doesn't shrink, it just gets a second layer of invisible work on top.

Leadership can't see this because the dashboards look normal. Tickets move, code ships, nothing is on fire. The reason things work is because three people are doing four jobs but that doesn't show up in any metric anyone is tracking.

The blame starts flowing downhill

When something breaks and something always breaks the tech lead needs to explain what happened. But they can't explain it technically because they don't understand it technically. So the explanation becomes "we were blocked by the infrastructure team" or "the pipeline had issues" or "requirements were unclear." Always pointing away from their own team and toward someone else.

Leadership accepts this because the tech lead is their friend. Questioning the explanation means questioning their own hiring decision. Nobody does that voluntarily. So the team that was actually keeping things running absorbs the blame for problems they didn't create.

The quiet exodus

Here's where it gets expensive. The senior engineers who've been doing double work while watching someone less capable get the title and the trust don't explode. They don't send angry emails. They just decide quietly that they're done.

First one leaves, leadership calls it normal turnover. Second one leaves, someone starts to worry. Third one leaves and suddenly the team's institutional knowledge is gone. The tech lead who couldn't do a code review is now leading a team of people too junior to compensate for them. Everything gets slower, buggier, more fragile. And nobody connects it to the hiring decision from eighteen months ago because the narrative has been rewritten to "the market is tough" and "good people are hard to retain."

No. Good people are easy to retain. You just have to stop putting unqualified people in charge of them.

What I call Risk Management Theater

The organization has a tech lead on the org chart. The role is filled. Architecture reviews happen on schedule. The structure looks right from above. But nobody qualified is actually leading anything technical. The title exists to fill a box on an org chart. The actual work is done by people whose names leadership doesn't know because the person bridging that gap is too busy managing up to manage down.

I've been writing about this pattern and others like it. I call it Risk Management Theater: the appearance of governance without the substance of it. Organizations that look managed from above while being completely unmanaged underneath.

If you've ever been the person quietly holding things together while someone less qualified took the credit, you're not alone and you're not imagining it. The system works exactly this way on purpose. Not because someone designed it to be unfair but because the people who benefit from it have no incentive to fix it.

If any of this resonates, I wrote a free chapter about a related pattern: how the daily standup went from a collaboration tool to a daily performance where developers rehearse what they'll say every morning to avoid sounding behind. Same dynamic, different ceremony.

Read Chapter 2: When Communication Became Surveillance

Agile Certification Economy

Ghostinit0x — Tue, 17 Feb 2026 03:15:22 +0000

Last week two things happened on LinkedIn that made me open a spreadsheet instead of writing my usual post.

The CEO of PMI — the Project Management Institute, the biggest certification body in the industry — published a post celebrating Agile's 25th anniversary. In it, he cited a stat from PMI's own research: 85% of organizations say agility is critical, but only 32% are satisfied. A 53-point gap.

I asked one question: what does the new manifesto offer that the previous ones didn't?

He edited his response. Accused a four-follower account of self-promotion. Deleted my comment.

Same week, Jeff Sutherland — the co-creator of Scrum — posted about Scrum at Tesla. I engaged. He told me that 65% of Scrum teams are late, over budget, with unhappy customers. His explanation: they haven't implemented the protocol correctly.

Not "maybe there's a design flaw." Just: two out of three users are wrong.

So I followed the money. And everything started making sense.

The Numbers

Nobody publishes these together. I wonder why.

Scrum.org: 1.17 million certifications issued. PSM I exam: $200. Most people also pay $1,000-$1,500 for a course.
Scrum Alliance: 1.5 million certified members. Training mandatory. CSM courses: $250 to $2,495. Expires every 2 years.
Scaled Agile (SAFe): 2 million+ trained. Courses: $500-$1,500. Cert expires every year. Renewal: $295 per cert.
PMI: 1 million+ PMP holders. Exam: $555 (non-member). Revenue: $200M+/year. They're a nonprofit.

That's over 5 million certifications from four organizations.

The enterprise agile transformation market — training, coaching, consulting, tooling — is valued at $49 billion. Growing 18.5% annually. Projected to hit $96 billion by 2029.

For a methodology that its own inventor says fails 65% of the time.

The Renewal Machine

This is the part that radicalized me.

Your CS degree doesn't expire in 12 months. Your bar exam doesn't require attending bar-branded webinars. But in Agile world:

SAFe certs die every year. $295 to renew. You don't retake any exam. You don't prove new competence. You pay. The badge stays. You don't pay. The badge greys out on LinkedIn. That's the entire mechanism.

Scrum Alliance certs die every two years. Renewed through "Scrum Education Units" — earned by consuming Scrum Alliance content, attending Scrum Alliance events, taking Scrum Alliance courses.

PMI certs die every three years. Renewed through "Professional Development Units" — earned through PMI courses, PMI events, PMI publications.

Create credential → expire it → require your ecosystem for renewal → extract forever.

It's not education. It's SaaS with a lanyard.

The CSM Reality Check

The Certified ScrumMaster — the most popular entry cert in the industry, over a million holders — works like this:

16 hours of training (two days)
50-question exam, 74% to pass
Open book
The book is The Scrum Guide. It's 14 pages.

I've written incident reports longer than the source material for this certification. The README for some open-source libraries has more substance.

Price: up to $2,495.

Compare: CompTIA Security+. Months of study. Six domains. Hundreds of topics. Closed-book. Proctored. About $404.

One certifies you can protect infrastructure from real threats. The other certifies you didn't fall asleep during a two-day workshop about a pamphlet.

The market prices them similarly because the market isn't buying competence. It's buying a checkbox on a job posting.

Why It Never Gets Simpler

When revenue depends on certification volume, simplification is a financial threat.

SAFe went from one framework in 2011 to 20+ certification tracks today. Scrum Alliance launched "AI for Scrum Masters" microcredentials. PMI acquired Disciplined Agile in 2019 for its cert potential — DA adoption promptly dropped from 7% to 4% and existing cert holders got burned.

The answer to a 65% failure rate is never "simplify." It's always "sell more."

What Actually Ships

I watched a six-person team at a payments company ship a regulatory compliance module in eleven weeks. No SAFe. No Agile coach. No release train engineer at $400/hour. One senior engineer who could say no, a product manager with customers' phone numbers saved in his personal phone, and a CI/CD pipeline that caught problems at 2am.

The team running SAFe in the same building didn't ship on time.

None of what worked required a $1,500 course. None of it expires annually. None of it needs Scrum Education Units to remain valid.

There's no recurring revenue in "hire experienced people and let them work." But there's $49 billion in "your people need our badge to be effective."

The Gap Is The Product

The question I asked the CEO of PMI was simple: if 85% say agility is critical and only 32% are satisfied, what does the new manifesto fix?

He deleted it because the honest answer kills the business model.

The 53-point gap isn't a problem. It's the market. If satisfaction ever reached 85%, there'd be nothing left to sell. PMI needs the gap. Scrum Alliance needs the gap. SAFe needs the gap.

Closing the gap would bankrupt the industry that claims to be working on closing it.

When you follow the money, the deleted comments and the blamed users stop being confusing. They're just good business.

Full data breakdown and the complete PMI CEO exchange: agilelie.com/blog/certification-economy

Curious if anyone else has done this math. Or if you've seen the renewal machine up close.

Benjamin Castell is diving into the gap between what the Agile industry sells and what engineering teams actually need. Follow at agilelie.com.

Happy 25th Birthday, Agile!

Ghostinit0x — Sat, 14 Feb 2026 14:22:47 +0000

This month is the 25th anniversary of the Agile Manifesto, my LinkedIn feed is full of birthday posts from the people who built the certification industry around it. The pattern is remarkable: everyone acknowledges what went wrong, nobody stops doing it.

So here's the version nobody asked for. From someone who spent 25 years building banking systems while Agile happened around me.

The manifesto was never the problem

Four values. 68 words. Written at a ski lodge in Utah by people who actually built software.

Individuals and interactions over processes and tools.
Working software over comprehensive documentation.
Customer collaboration over contract negotiation.
Responding to change over following a plan.

That was it. And for about 18 months, it gave teams permission to do what they already knew was right: stop pretending that documentation was more important than shipping.

Then the industry arrived.

How 68 words became a billion-dollar machine

If "interactions" mattered, you needed someone to facilitate them. Enter the Scrum Master — a role that didn't exist before, created by a framework that was supposed to reduce overhead.

If teams needed to "respond to change," they needed a process for responding. Enter sprint planning, backlog refinement, sprint review, retrospective, daily standup. Five ceremonies minimum, every two weeks, forever.

If collaboration mattered, you needed artifacts. Enter backlog, burndown charts, velocity metrics, story points, Definition of Done.

Each addition made sense alone. Together they built exactly what the manifesto warned against: a process-heavy system that valued tools and documentation over people and working software.

The manifesto said "individuals and interactions over processes and tools."

The industry heard "here's a new process with new tools."

The numbers

Scrum Alliance: 1.4 million certified Scrum Masters at ~$1,000 each = $1.4 billion in cert revenue alone
SAFe documentation: 800+ pages
Original manifesto: 68 words
PMI stat shared this week: 85% of executives say agility is critical, only 32% are satisfied with implementation

That's a 53-point gap between "we need this" and "this works." PMI's proposed solution? Another manifesto. The Manifesto for Enterprise Agility, launching March 3rd. Built from 700 CEO voices.

More words to solve a problem created by too many words.

The apology loop

Here's what I found remarkable today. The people who built this industry are publicly apologizing for what it became:

"We turned agile into a certification ladder"
"Ceremony without intent"
"Packaged mediocrity"

These aren't quotes from critics. These are from people with CSM, SAFe SPC, PMP, and RTE in their titles. They see the problem. They name it. And tomorrow they'll run another sprint planning workshop and sell another certification.

The apology is genuine. The business model isn't apologizing.

It's a retrospective with no action items. Which is exactly the dysfunction they're describing.

What the manifesto actually killed

The manifesto didn't fail because the ideas were wrong. It failed because it succeeded.

It succeeded so completely that it created a market. And markets don't optimize for the original intent. They optimize for revenue.

Today most teams practicing "Agile" have never read the manifesto. They know Scrum. They know Jira. They know story points and velocity. They don't know the 68 words that started it all. And if they read them, they'd notice the manifesto describes the opposite of what they do every day.

What actually works

25 years. Banking systems. The best teams I've worked with shared these traits:

Technical leadership that understood the work. Not facilitators. Not coaches. People who could evaluate an architecture decision, debug production, and tell stakeholders why a shortcut would cost more than it saved.

Clear ownership. One person who could say "we're doing this" without scheduling a meeting to discuss it.

Short feedback loops. Not because a framework required them. Because the team wanted to know if what they built worked.

Minimal overhead. Meetings that served a purpose. When a meeting stopped being useful, it died. No ceremony survived on tradition.

None of this required a certification or a framework or a manifesto.

The uncomfortable truth

The ideas were always good. Simple, honest, human.

But the industry spent 25 years proving that you can take any good idea, package it, certify it, scale it, and sell it until the original intent is unrecognizable.

Happy birthday, Agile. The manifesto was 68 words. The industry turned it into 800 pages, 1.4 million certifications, and a 53-point gap between intent and reality.

The words were never the problem. We were.

If you're wondering how much of your team's process is real agility vs. framework theater, I built a diagnostic that measures exactly that: Risk Management Theater Self-Check

What's your experience? Have you seen Agile work as intended, or did the framework get in the way? Drop your stories below.

Your Definition of Done Is a Political Document, Not a Quality Standard

Ghostinit0x — Tue, 10 Feb 2026 12:31:27 +0000

Somewhere in your company's Confluence instance, there's a page called "Definition of Done." Last edited fourteen months ago. Eight to fifteen bullet points. At least three reference Jira. Every one designed to be verifiable by someone who doesn't understand what the software actually does.

That's not a quality standard. It's a treaty—a liability shield negotiated between engineering, product, and management that says: when things go wrong, here's how we prove it wasn't our fault.

What Your DoD Items Actually Mean

What the DoD Says	What Actually Happens
Code reviewed by at least one peer	Someone clicked Approve. The review took between 90 seconds and 4 minutes. Nobody ran the branch locally.
Unit tests written and passing	A happy-path test was written. The edge case that causes a production incident in three weeks remains untested.
Acceptance criteria met	The PO squinted at a screen for thirty seconds and said "looks good."
No critical or high-severity bugs	The bugs were reclassified as "medium" so the story could close.
Deployed to staging	Deployed to a staging environment that doesn't resemble production.

Every item is optimized for one thing: can we check a box in Jira?

Why Nobody Fixes It

Everyone knows the DoD is theater. Fixing it would require making it actually rigorous — and rigorous means stories take longer, velocity drops, and someone tells a VP the team will deliver less.

Throughput is what gets measured and rewarded. So the DoD stays weak. It's a negotiated settlement, not a quality standard.

The DoD Negotiation

New engineering director proposes load testing, integration tests in production-like environments, security reviews, canary bake periods. Reasonable items that actually prevent incidents.

Within a month, every new item is quietly dropped or made optional. The DoD returns to its previous state: a list of things verifiable by looking at Jira metadata.

The lesson: the DoD is a political agreement. Changing it requires changing incentives, delivery expectations, and management culture. You can't just edit a wiki page.

A DoD That Actually Worked

Small B2B SaaS. Three outages, two lost contracts. The CTO replaced the DoD with one rule:

"A story is Done when the engineer who built it would deploy it at 4:55 PM on a Friday without telling anyone, and sleep soundly."

It worked because: permission to slow down, velocity removed as a metric, adversarial peer review, and social accountability replaced checkboxes. Customer incidents dropped around 80% in two quarters.

Cost: 30% delivery reduction, executive air cover, total metric overhaul. Most organizations won't pay it.

Auditing Your DoD

Friday Deploy Test: Does each item increase production confidence, or just prove someone did something?
Last Incident Autopsy: Was the DoD satisfied on the story that caused your last three incidents?
Timing Test: If code reviews average under ten minutes for 500+ lines, it's a rubber stamp.
Rigor Conversation: Propose one hard item. Watch the velocity objections surface.
Uncomfortable Question: When did the DoD last actually block a story?

The Root Cause

The Agile-industrial complex built a framework where visible throughput is the primary success metric, then told teams to also care about quality. The DoD is where that tension collapses into theater.

Stop editing the document. Start changing the system that made it necessary.

Originally published at agilelie.com.

The Agile tax: planning poker costs $66k/year, the SM role can be automated in a weekend, and we're still doing waterfall anyway

Ghostinit0x — Sun, 08 Feb 2026 15:18:13 +0000

At some point I started doing math on how much Agile ceremonies actually cost. Not in "productivity" or "morale" or whatever. In actual money.

We had 8 engineers in a room for 4 hours every two weeks. Average fully loaded cost around $80/hr per engineer. That's $2,560 per session. Twice a month. $66,560 a year. To assign made-up numbers to tickets that would change scope by Wednesday anyway.

Nobody ever questioned this. Not once. If I told finance I needed $66k for a new tool there would be 3 months of procurement review. But burning that same amount on a recurring meeting where grown engineers hold up cards with numbers on them? That's just "the process."

I saw a post recently where a guy built a tool over a weekend that automated most of what his Scrum Master did. Ran standups, tracked blockers, generated sprint reports. Whole thing took him 2 days.
The responses were split. Half the people said "that's not what a SM really does" and the other half said "that's exactly what our SM does." Both groups were right about their own experience and that's kind of the point.

When a role can be automated by one dev in a weekend at some companies but is supposedly critical leadership at others, maybe the role isn't well defined enough to justify a full salary everywhere.

I'm not saying good SMs don't exist. I've met maybe two in 25 years. But the hit rate is terrible and the floor is basically a meeting scheduler with a certification.

Here's the thing that kills me. After all the ceremonies, the points, the sprints, the retros, the SM, the PO, the whole apparatus. Most teams are still doing waterfall. Scope is fixed before the sprint starts. Budget was locked last quarter. Deadline was promised to a client 6 months ago. Nothing is going to "emerge" or "pivot" or "respond to change."

We just report status more frequently now. That's the actual difference. Instead of a monthly project update we give a biweekly one. We renamed the Gantt chart to a "sprint board" and the project manager to a Scrum Master.

A VP at a Fortune 500 said it better than I can. Calling it a Sprint doesn't make you faster. It just makes you tired.
So what's the actual Agile tax? At my last org it was roughly:

$66k/yr on planning poker
$130k/yr on a SM salary for a role one dev automated in a weekend
4-6 hours per week per engineer in ceremonies

Multiply that across the team and we were spending more time talking about work than doing work

And the end result was the same waterfall we always did. Just with more meetings and a Jira board.

Anyone else done this math at their company? Curious if the numbers are similar or if we were just especially bad at this.

We'll address that tech debt next quarter

Ghostinit0x — Fri, 06 Feb 2026 01:05:36 +0000

Three years later the technical debt is still there and now it's a crisis blocking new features.

This pattern plays out constantly in enterprise software and banking tech. Tech debt starts manageable but accumulates faster than teams can pay it down because it never makes the priority list.

Small shortcuts compound. Quick fixes pile up. Temporary solutions become permanent. Everyone knows it needs attention but there's always something more urgent.

Real example from banking: Service built as temporary workaround for launch deadline. "We'll refactor this properly after launch." That service ran in production for four years. Original developer left after two. By year three nobody fully understood how it worked but we were terrified to touch it because so many other things depended on it.

When I finally got time to refactor it took six weeks instead of the two days it would've taken initially. Every shortcut we took to save time cost us 10x later.

Here's why tech debt never gets prioritized:

Product teams can't see it. Stakeholders can't see it. Doesn't show up in roadmaps or customer demos. What they see is new features, revenue impact, user growth. Invisible problem always loses to visible opportunity.

Every sprint planning same conversation happens. Engineers flag technical debt that needs attention. PM acknowledges it matters but points to committed features. "We'll tackle it next quarter for sure." Next quarter arrives with new commitments and same conversation repeats.

Tech debt only becomes priority when it breaks something customers see. By then the fix is exponentially harder because you've built multiple features on top of the unstable foundation. And everyone wonders why the estimate is suddenly so high.

Teams that handle this well dedicate fixed capacity every sprint. Twenty percent of velocity goes to technical health regardless of feature pressure. Non-negotiable.

But most organizations struggle with this. Shipping eighty percent of potential feature velocity feels like leaving value on the table. Until the system breaks and suddenly you're shipping zero percent because you're firefighting production issues caused by accumulated technical debt.

I've seen teams try hiding technical debt work inside feature estimates. Pad the story points, slip refactoring in quietly. Works until someone notices velocity dropped and you're explaining why you wasted time on internal work instead of customer value.

The honest approach is making technical health visible and defending the time it needs. But that requires leadership that understands compound interest works both ways. Technical shortcuts create interest that compounds just like financial debt.

How does your organization actually handle this? Does technical debt get real priority or is it always next quarter indefinitely?

Tech lead who doesn't code is just a project manager with a misleading title

Ghostinit0x — Tue, 03 Feb 2026 14:21:12 +0000

The $180k tech lead who can't unblock an $80k junior developer.

Seen this in banking tech more times than I can count. Junior dev stuck on Kafka consumer issue. Spent half a day trying to figure out why messages weren't coming through. Tech lead in back to back meetings all morning. When he finally gets free he looks at it for 10 minutes and says "I don't know, haven't worked with Kafka in like 18 months."

I walked over. Took me 5 minutes. Same consumer group name plugged into multiple topics. One consumer eating everything, others starving. Basic mistake but you'd only know if you actually worked with the stack.

Here's the thing. This tech lead isn't stupid. He's just been in so many alignment meetings and architecture reviews and stakeholder calls that he lost touch with the actual technical work. Got promoted for being good technically, now spends zero time being technical.

Pattern I keep seeing: promote someone for technical depth, pull them into meetings constantly, wonder why they can't help the team with technical problems anymore.

Team gets frustrated. Tech lead gets frustrated. Everyone knows something's wrong but nobody wants to say it out loud.

Not sure what the fix is honestly. You need people focused on big picture stuff. But when that person can't unblock a junior dev on a basic problem something broke along the way.

How does your org handle this? Do tech leads actually stay technical or do they drift into pure coordination after a few months?

Scripts for Suggesting Standup Alternatives to Your Manager

Ghostinit0x — Sun, 01 Feb 2026 21:10:33 +0000

Fifteen minutes times five days times fifty weeks. Sixty hours a year minimum—spent announcing what you typed into Jira yesterday.

That number gets worse when you count the context switch. The morning momentum you lose. The twenty minutes before the meeting where you can't start anything deep.

You know this is broken. Knowing isn't the problem.

The problem is that the moment you say "I think standups aren't working," your manager hears "I don't want accountability."

Before You Open Your Mouth

Three questions to answer first:

What does your manager actually care about?
What specific problem are you solving?
What are you proposing instead?

The 1:1 Opener (Low Stakes)

"I've been tracking my focus time lately, and I noticed that morning 
meetings—including standup—tend to fragment my first few hours. 

I'm not saying standups aren't valuable. But I've been wondering if 
there's a way to get the same visibility without breaking up the morning. 

Have you seen any teams experiment with async updates?"

Why this works:

Opens with personal data, not ideology
Doesn't attack the meeting—questions the format
Asks for their perspective

The Trial Period Pitch

"What if we tried it for two weeks? Async updates every morning—same 
three questions, posted by 9:30. At the end, we check in: Did you have 
the visibility you needed? Did blockers get missed?

If it doesn't work, we go back. I'm happy to facilitate."

Managers say no to permanent changes. They're not trained to say no to "let's try it for two weeks."

Quick Reference

Say this:

"I've been tracking my focus time..."
"What if we tried it for two weeks?"
"Same information, different format"

Not this:

"Standups are a waste of time"
"Nobody likes this meeting"
"Studies show that..."

The full article with seven complete scripts—including retro suggestions, Slack templates, and escalation scripts at agilelie.com.

When Scaling Process Kills Working Teams

Ghostinit0x — Fri, 30 Jan 2026 19:11:15 +0000

When "Scaling" Process Kills Working Teams

TL;DR

Small engineering teams often ship effectively until management decides they need "proper process." This pattern - hiring process people when teams are already delivering - frequently results in slower velocity, missed deadlines, and frustrated engineers. The timing of process implementation matters more than the process itself.

The Pattern

Early 2020s, small fintech startup. Deadline: 4 months to launch.

Engineering team was literally 3 people. Me as architect, plus two devs.

We had our shit together. Architecture designed, infrastructure running in the cloud, backend skeleton ready. Devs were building features. We were on track.

Then month 2 hit and management started hiring. A bunch of managers showed up. Then they brought in a Scrum Master.

First week this guy wants to implement full Agile ceremonies. Daily standups, sprint planning, retrospectives, backlog refinement. The whole package.

His reasoning: "You need process to scale."

We had 8 weeks left. We weren't trying to scale. We were trying to finish.

I've seen this same pattern play out multiple times now. Small team shipping → Management gets uncomfortable with lack of "visibility" → They hire process people → Process people need to justify their existence → Ceremonies get implemented → Everything slows down.

The thing that kills me is the timing. We were working. Why fix what isn't broken when you're 8 weeks from deadline?

Why This Keeps Happening

After seeing this pattern repeat across different companies and contexts, I've started to understand the underlying dynamics. It's not that management is stupid or that Scrum Masters are evil. It's more nuanced than that.

The Visibility Problem

When you're a director or VP watching a 3-person team work, it looks like chaos from the outside. There's no burndown charts, no velocity metrics, no sprint reports. Just engineers coding and occasionally syncing up.

For someone who's accountable to executives or investors, this feels uncomfortable. How do you report progress? How do you forecast? How do you prove the team is actually working?

The instinct is to add structure. And in large organizations where this person came from, structure meant Agile ceremonies. It's what they know. It's what feels safe.

The Justification Trap

Here's where it gets tricky. When you hire a Scrum Master or Agile Coach, that person needs to do something to justify their role. They can't just sit back and say "actually, things are working fine, I'll just observe."

Their entire professional identity is built around implementing and improving processes. So they're naturally going to push for implementation, often regardless of context or timing.

This isn't malicious. It's incentive alignment. You hired them to do a job, and that job is implementing Agile practices.

The Control Illusion

There's something psychologically comforting about process. Standups mean you know what everyone's working on. Sprint planning means you have a "commitment." Velocity tracking means you can forecast.

The problem is that this control is often illusory. I've watched teams where everyone says the right things in standups while the actual work happens in different channels. Where sprint commitments are meaningless because priorities shift mid-sprint. Where velocity metrics are gamed or become targets themselves.

But management feels better because they have reports and charts and metrics. Even if those metrics don't actually predict or improve outcomes.

The Math Nobody Wants To See

Let's do the actual calculation for that 8-week scenario I described.

Proposed ceremonies:

Daily standup: 15 minutes
Sprint planning: 2 hours every 2 weeks
Sprint retrospective: 1 hour every 2 weeks
Backlog refinement: 1 hour per week

Time cost over 8 weeks (3 engineers):

Standups: 40 days × 15 min × 3 people = 30 hours
Planning: 4 sprints × 2 hours × 3 people = 24 hours
Retros: 4 sprints × 1 hour × 3 people = 12 hours
Refinement: 8 weeks × 1 hour × 3 people = 24 hours

Total: 90 engineering hours

That's more than 2 full weeks of development time. On an 8-week deadline.

Now, you could argue that these ceremonies would improve efficiency enough to offset the time cost. Maybe. But we were already shipping. We had momentum. The architecture was done. The infrastructure was running. We knew what needed to be built.

Adding process at that point was pure overhead. There was no evidence it would make us faster. In fact, the context switching alone from stopping work to attend meetings would likely slow us down.

But more importantly - we didn't have 2 weeks to spare. The deadline wasn't flexible. The budget wasn't infinite.

The tradeoff wasn't "process vs no process." It was "ship on time vs implement perfect process."

What Actually Worked For Us (Before Things Changed)

Before the Scrum Master arrived, we had a lightweight system that was working:

Morning check-ins: Not mandatory. Just whoever was around would spend 5-10 minutes in Slack saying what they were tackling that day. If you were deep in something and didn't check in, nobody cared.

Documentation culture: Everything architectural got documented. Every decision got recorded. Not in formal documents - just in our project wiki and code comments. If someone needed context, they could find it.

Direct communication: If you were blocked, you pinged the person who could unblock you. Immediately. No waiting for standup tomorrow.

Weekly sync: Once a week we'd do a 30-minute video call to make sure we were still aligned on priorities and to surface any concerns. These were optional but most people joined because they were actually useful.

Visible work: We used a simple Kanban board in Jira. Not for process compliance. Just so everyone could see what was in progress and what was up next. No story points, no velocity tracking, no burndown charts. Just "To Do, Doing, Done."

That was it.

Was it textbook Agile? No. Would it work for a 50-person team? Probably not. But for 3 engineers with a tight deadline, it was exactly what we needed.

The key difference: Everything was designed for utility, not compliance. We did things because they helped us ship, not because a framework said we should.

When Process Actually Makes Sense

I'm not anti-process. I'm anti-bad-timing-and-cargo-cult-process.

There are absolutely times when implementing more structure is the right call:

When the team is growing quickly. If you're going from 3 to 15 engineers in a month, yeah, you need more coordination mechanisms. The informal communication that works for 3 people breaks down at scale.

When there's genuine confusion about priorities. If engineers are frequently building the wrong thing or there's constant thrashing on what matters, structured planning can help. But the key word is "genuine" - not manufactured confusion to justify the process.

When you're stable and optimizing. After you've shipped, when you have breathing room, that's when you can step back and ask "how do we want to work together long-term?" You can experiment with different ceremonies, see what sticks, refine based on feedback.

When the team asks for it. If engineers are saying "I don't know what others are working on" or "I wish we had more structure," listen to them. Bottom-up process adoption works way better than top-down.

The pattern I've seen work best: Launch with minimal process. Add structure gradually based on actual pain points. Let the team drive what they need.

What doesn't work: Implementing full Agile overnight because that's what management knows, regardless of context or timing.

Red Flags You're Seeing Process Theater

Over the years, I've gotten better at spotting when process is genuine versus when it's theater. Some warning signs:

Process is enforced but not followed. Everyone attends the standup but nothing changes based on what's said. Retrospective action items never get implemented. Sprint commitments are meaningless.

Metrics become targets. The team starts gaming story points to hit velocity targets. Defects don't get reported because it hurts the metrics. Engineers avoid risky but important refactoring because it doesn't "count."

Process people multiply. One Scrum Master becomes three. Then you need an Agile Coach to coach the Scrum Masters. Then you need a Head of Agile to manage the coaches. Each layer adds more meetings but doesn't improve delivery.

Documentation for documentation's sake. You're writing sprint goals that nobody reads. Creating detailed tickets that get rewritten during implementation. Maintaining burndown charts that management doesn't understand.

Dissent is treated as resistance. If you question whether a ceremony is adding value, you get labeled as "not a team player" or "resistant to change." Questions are deflected with "this is best practice" rather than engaged with honestly.

The difference between good process and theater is simple: good process makes work easier. Theater makes work look organized.

What To Do If You're In This Situation

If you're an engineer watching process get implemented at exactly the wrong time, here's what I've learned:

Pick your battles. Not every ceremony is worth fighting. Daily standups, even if not ideal, won't kill you. Save your capital for the bigger issues.

Speak to outcomes, not preferences. Don't say "I don't like meetings." Say "We have 8 weeks to deadline and this adds 90 hours of overhead. Can we implement this post-launch?"

Propose alternatives. Instead of just saying no to standups, suggest async updates. Instead of fighting sprint planning, suggest a lightweight version. Give management a way to get the visibility they want without the full overhead.

Document your concerns. Not to CYA, but so there's a record when the deadline gets missed. "We raised concerns about process overhead on [date]. Here were our predictions." This isn't about being right - it's about making sure the real causes get understood.

Know when to leave. If management is committed to process over delivery, and you're the voice in the wilderness, recognize that you might not win this one. Especially if you're seeing signs that dissent is being punished rather than engaged with.

That last one is hard. Nobody wants to bail on a project mid-stream. But I've learned that some organizational dysfunctions can't be fixed from the bottom. If the incentive structure rewards appearance over results, individual engineers usually can't change that.

The Larger Pattern

The more I think about this, the more I realize it's not really about Agile at all. Agile just happens to be the current framework that organizations cargo-cult.

The underlying pattern is: Management wants certainty in an uncertain domain. They want predictability when dealing with creative problem-solving. They want control when managing knowledge work that's fundamentally hard to control.

Process frameworks promise to deliver these things. "Do Agile correctly and you'll be able to forecast accurately." "Implement SAFe and you can scale predictably." "Follow these ceremonies and risks will be managed."

But software development is inherently uncertain. Requirements change. Technical problems emerge. People have different skill levels and different working styles. No amount of process eliminates this uncertainty - it just gives the illusion of control.

The best teams I've worked with embraced this uncertainty. They had lightweight ways of coordinating, strong technical practices, and leadership that trusted them to figure shit out. They added structure when they felt pain, not prophylactically.

The worst teams I've worked with had perfect process compliance and shipped late or not at all. They spent more time managing the process than doing the work. Leadership optimized for looking good in reports rather than actually delivering.

A Final Thought

I still think about that project sometimes. Would we have shipped if we'd kept the lightweight approach? Maybe. Would we have missed the deadline even without the process overhead? Possibly.

But I know for certain that adding 90 hours of ceremony time to an already tight 8-week deadline didn't help. And I know that teams work best when they're trusted to organize themselves around the work, not around a framework.

If you're managing engineers, here's my ask: Before you implement process, ask whether it's solving a real problem or just making you feel more comfortable. Ask whether the timing is right. Ask the team what they actually need rather than imposing what you think they should need.

And if you're an engineer dealing with this, know that your frustration is valid. It's not that you're anti-process or anti-collaboration. It's that you can see the gap between what helps delivery and what's just theater.

Sometimes the best process is almost no process. At least until you have evidence you need more.

If you're trying to identify where you have real coordination problems versus process theater, I created a free diagnostic that helps map this out. Not selling anything - just a framework I've found useful: https://agilelie.com/risk-management-theater

And if you've seen this pattern in your own teams, I'd love to hear about it in the comments. What worked? What didn't? How did you handle it?

Your CEO Blamed Engineering for the Outage. Here's Why That's Actually a Budget Decision

Ghostinit0x — Thu, 29 Jan 2026 03:20:44 +0000

On August 1, 2012, Knight Capital lost $440 million in 45 minutes.

Not a hack. Not market manipulation. Old code that should've been removed years earlier got pushed to production under deadline pressure. The SEC investigation didn't blame developers—it pointed to "inadequate technology governance." Executive function, not engineering function.

Yet when your system crashes at 2 AM, the morning standup still asks: "What did the team do wrong?"

The Number That Should Piss You Off

Technical debt in the US costs $1.52 trillion annually (CISQ, 2022). McKinsey says it accounts for 20-40% of the entire value of most companies' tech estate.

Here's the thing: every piece of technical debt traces back to a business decision.

Someone approved the deadline without time for testing. Someone rejected the hiring request. Someone cut refactoring because "users don't see it."

Those decisions happened in budget meetings, not sprint planning. But when consequences arrive, the postmortem happens in a retro where nobody in the room had authority to prevent the problem.

Agile Ceremonies as Blame Shields

The daily standup asks "What's blocking you?" — which makes it your blocker. Nobody asks who decided to staff the API team at 60% capacity.

Sprint planning is where technical work dies. "Can we do that refactor next sprint?" Next sprint never comes.

Retros ask "What can we do better?" — presupposing the team is the right unit of improvement. But "we keep getting pulled into production support" is a staffing decision. "Requirements changed mid-sprint" is leadership failure. "No time for code review" is deadline pressure from above.

You can't retrospective your way out of systematic under-resourcing.

83% of Developers Report Burnout

Haystack Analytics found 83% of devs experience burnout. Top reasons: high workload, inefficient processes, unclear goals.

Not "code is hard." Not "technology is complex."

Stack Overflow 2024 says technical debt is the #1 cause of developer frustration. Stripe found devs spend 33% of their time on maintenance instead of building.

That's one-third of your engineering budget paying interest on decisions made above your pay grade.

The Case Studies

Knight Capital (2012): $440M lost in 45 minutes. Old code, no deployment controls. Company sold within months.

Equifax (2017): 147 million people exposed. Known vulnerability, patch available for months, never applied. $700M+ in fines.

Southwest (2022): 16,000 flights canceled. Decades-old crew scheduling system leadership had been warned about for years. $740M+ in costs.

All three had risk management processes. What they didn't have was leadership willing to act on what those processes surfaced.

What Now?

If you're an engineering leader, start documenting the decision chain. Every cut to technical investment, every deadline set without eng input, every denied hire—write it down with dates and names.

Not for blame. For visibility. When consequences arrive, show it was a predicted outcome of a specific decision, not an engineering failure.

I wrote a full breakdown of this problem — including how Risk Management Theater lets executives check governance boxes without actually reducing risk, what metrics leadership should actually own, and specific tactics for translating technical debt into language that gets budget.

Read the full article: Code Quality Is a C-Suite Problem →

If you're tired of taking blame for predictable outcomes of executive decisions, check out The Anti-Agile Manifesto. You're not crazy. The system is broken by design.

What's your experience? Ever been blamed for an outage that was really a resourcing failure? Drop it in the comments.

Risk Management Theater: The Performance That's Killing Your Team

Ghostinit0x — Mon, 26 Jan 2026 02:28:21 +0000

You know the feeling.

It's 9:47 AM. You're in a quick sync that was supposed to last 15 minutes. It's been 43.

Someone is sharing their screen. A dashboard. Everything is green. The sprint is "on track." The team has "no blockers." The retro produced actionable insights.

And yet.

You shipped nothing last week. The same bug has been "in progress" for three sprints. The architect quit last month and nobody talks about it. There's a Slack channel called #war-room that's been active for 11 days straight.

But the dashboard is green. Welcome to Risk Management Theater.

What is Risk Management Theater?

Risk Management Theater (RMT) is the organizational practice of performing risk management without actually managing risk.

It's the standup that surfaces no blockers — because admitting a blocker makes you the blocker.

It's the retrospective that produces insights but never changes systems.

It's the dashboard designed to reassure stakeholders, not reveal reality.

It's the meeting that exists to distribute liability, not to make decisions.

RMT is what happens when the appearance of control becomes more important than actual control.

The term comes from security theater — the post-9/11 phenomenon where airports implemented visible but ineffective security measures to make passengers feel safe without making them be safe.
Same energy. Different domain.

In software organizations, RMT is the systematic replacement of real risk management with its performative equivalent. The ceremonies happen. The artifacts are produced. The dashboards glow green.
And then production goes down at 2 AM and everyone acts surprised.

Why RMT Exists

RMT isn't stupidity. It's incentives. Here's the uncomfortable truth: in most organizations, surfacing risk is punished, not rewarded.
Think about it.

When you say "no blockers" in standup, you're safe. You're a team player. You're making progress.

When you say "actually, this architecture won't scale and we need to stop and fix it" — now you're the problem. You're "not solution-oriented." You're blocking the sprint.
So people learn. Fast.

They learn that the meeting isn't about identifying risk. It's about not being the one who identified the risk.

Because if you identify the risk and it happens anyway, you're the one who knew and didn't fix it.

But if nobody identifies the risk and it happens, well — who could have known?

RMT is a collective agreement to not see what everyone sees.
It's not a bug. It's a feature. A feature that protects individuals while destroying teams.

The 5 Warning Signs

How do you know if you're in Risk Management Theater? Here are 5 signs. If you recognize three or more, you're not imagining it.

"No blockers" is the default answer
In your standups, how often does someone actually raise a blocker? If the answer is "rarely" or "never," you're not in a high-performing team with no problems. You're in a team where problems are socially discouraged.
Decisions are made before meetings
The meeting exists to "align" — but alignment means getting everyone to nod at a decision that was already made in a smaller room, with fewer witnesses.
The meeting isn't decision-making. It's liability distribution.
Dashboards are green, reality is red
Everything looks on track until it isn't. The metrics are designed to tell a story, not reveal truth. When the story and reality diverge, the story wins — until it can't.
Retrospectives produce insights, not changes
You've had 47 action items in 6 months. How many were completed? How many changed the system?
If retros are where good ideas go to die, you're performing reflection without practicing it.
Visibility means surveillance
"Transparency" has become a euphemism for tracking people, not clarifying systems. You know exactly what everyone is working on. You have no idea why the system keeps failing.

Sound familiar?
There are 5 more signs. I've compiled all 10 into a diagnostic tool — a simple scorecard that tells you exactly how deep you are in RMT.
→ Take the RMT Diagnostic
It takes 5 minutes. Be honest with yourself.

The Real Cost

RMT isn't just annoying. It's expensive. The data:

83% of developers report burnout, driven primarily by process dysfunction [1]

$110,000+ per team per year spent on Scrum ceremonies alone — before the bloat [2]

23 minutes to regain focus after each interruption [3]

153% increase in weekly meetings since 2020 [4]

But the real cost isn't in the spreadsheet. It's the senior engineer who quit because she couldn't ship anything meaningful anymore.

It's the outage that everyone saw coming but nobody could say. It's the slow death of craftsmanship — the creeping realization that your job is no longer building software, it's performing building software.

Risk doesn't disappear when you stop talking about it. It relocates.
It moves from dashboards to production. From standups to 2 AM incidents. From retros to resignation letters.

The theater continues until reality forces the curtain call.

The Question Nobody Asks

Here's what I want you to try. In your next meeting, ask one of these questions:

"What decision is actually open today?"
"What are we de-scoping to pay for this?"
"Which risk are we silently accepting right now?"

Watch what happens.

If people engage thoughtfully, you might be in a healthy environment.
If people get uncomfortable, defensive, or irritated — your RMT score is higher than you think.

The theater survives because nobody names it. Once you see it, you can't unsee it. And once you name it, others can see it too.

What Now?

If you've read this far, you're probably not in denial. You're probably exhausted.

You're probably wondering if it's you — if you're "not a team player," if you're "too negative," if you just need to "trust the process."

You're not the problem. The system is.

And the first step to fixing it is measuring it. Take the RMT Diagnostic

10 signs. 5 minutes. A score that tells you the truth.
If your score is low, congratulations — you're in a rare healthy environment. If your score is high, at least now you know. And knowing is the first step to escaping.

RMT is one of 12 patterns of organizational dysfunction I've documented after 23 years in the industry. If you want the full playbook — the patterns, the escape routes, the scripts, the case studies — check out The Anti-Agile Manifesto.

References:

[1] Haystack Analytics (2021). 83% of Developers Suffer From Burnout.
[2] Internal analysis based on average developer salary and ceremony time allocation.
[3] Mark, G., Gudith, D., & Klocke, U. (2008). The Cost of Interrupted Work.
[4] Microsoft Work Trend Index (2023). Will AI Fix Work?

Originally published at agilelie.com/blog/risk-management-theater

The $120K Question: Are Scrum Masters Worth Their Salary?

Ghostinit0x — Mon, 19 Jan 2026 16:21:27 +0000

I spent six months tracking what Scrum Masters actually do versus what they're paid. The numbers don't add up.

The Data Nobody Talks About

In 2026, senior Scrum Masters in the US are pulling $125K-$145K. That's comparable to mid-level developers—the ones writing production code, fixing bugs, and getting paged at 2 AM when things break.

San Francisco and New York? $155K+. For facilitating meetings.

Here's what made me dig deeper: remote Scrum Masters show a 15-20% premium over on-site roles. We're paying more for a job that's arguably easier when done remotely (no one can corner you for "quick syncs" in the hallway).

Meanwhile, senior developer salaries have compressed 10-15% since 2022, with 300+ applicants per position.

Something's off.

The ROI Problem

Let's do the math your VP of Engineering doesn't want you to do.

$120K (average US salary) + benefits + equipment = $150K-$180K fully loaded annually.

What could that money buy instead?

0.7 senior developers who write code AND can run their own standups
An entire year of CI/CD improvements and monitoring infrastructure
Training budget for your entire engineering team

I analyzed 156 impediments logged across four teams over six months. Scrum Masters directly resolved 8 of them—mostly booking conference rooms or ordering pizza. The other 148? Developers talking to developers, architects making decisions, managers approving budgets.

What High-Performers Do Differently

Here's the uncomfortable pattern I'm seeing:

Basecamp never had Scrum Masters. GitHub doesn't use them. Stripe's engineering teams coordinate without dedicated process managers. These companies ship products millions of developers use.

A 2023 survey of 400+ Bay Area tech companies: only 31% of high-growth startups employ dedicated Scrum Masters. The ones without them? 23% higher deployment frequency.

Spotify scaled to 600+ engineers across multiple countries without dedicated Scrum Masters. Estimated savings: $8-12M annually. That money hired senior engineers instead.

The Market Is Speaking

LinkedIn job postings for Scrum Masters dropped 34% year-over-year in Q1 2026.

Postings for Engineering Managers and Technical Leads? Up 18%.

Companies want people who can manage process AND understand technology—not one or the other.

The Real Question

I tracked what Scrum Masters do for six months across three companies:

40% of time: meetings about meetings
25%: updating Jira tickets developers already updated
15%: actual coaching or mentorship

A 2023 survey of 847 developers: 62% couldn't identify a single valuable activity their Scrum Master performed in the previous sprint.

That's a $120K calendar administrator.

What This Means for Your Team

The uncomfortable truth? Most organizations can't quantify what their Scrum Masters actually deliver. They track story points (which teams complete anyway) and meeting attendance (which proves nothing).

I've asked dozens of engineering managers to show me before/after metrics when they hired a Scrum Master. Most couldn't produce anything beyond "the team seems happier."

That's a $150K feelings budget.

Want to know if your Scrum Master position is actually worth the investment?

I built a free ROI calculator that shows you exactly what your daily standups and ceremonies actually cost—and what you could do with that money instead: Calculate Your Standup Tax

The math might surprise you. Or confirm what you already suspected.