I have a guy on my team with 'architect' in his title who asked me what a REST API is last month. The team quietly works around him, but the situation feels unsustainable. I wrote down the full story here: [link para o seu post]. How have you handled this without getting fired?
I've been a software architect for 25 years, mostly in banking infrastructure. Something that's been bothering me and I wanted to get HN's perspective on.
The Certified Scrum Master pipeline works roughly like this: a 2-day course, approximately $1,000, pass rates above 95%, and no engineering background required. The Scrum Alliance has certified over 1.4 million people through this process.
After certification, many of these folks land roles paying $90K-$130K facilitating sprints, standups, and retros for teams of senior engineers.I'v e worked with good Scrum Masters who genuinely helped teams. I want to be clear about that. But the structural model seems odd to me:
The certification requires zero technical knowledge, yet the role involves managing a technical team's workflow daily.
A mid-level engineer with 5 years of experience writing production code often earns a comparable salary to the person facilitating their meetings.
The certification body has a direct financial incentive to expand the perceived necessity of the role. More essential the role seems, more certs sold. At $1K per cert and 1.4M certified, that's $1.4B in certification revenue alone.
In most teams I've observed, removing the SM role would redistribute about 30 minutes of weekly facilitation across people who already understand the work better than the SM does.
The counter-arguments I can think of:
Not every team has a tech lead who wants to handle process. Fair point. But that's an argument for better leadership, not a separate process role.
SMs handle organizational impediments. True in some orgs. But in practice, most impediment removal I've seen is a management function that existed before Scrum.
The role protects the team from outside interference. Valid, but you don't need a certification for that. You need someone with organizational authority, which the SM role often lacks anyway.
I'm not arguing that every SM is useless. I'm questioning whether a 2-day certification with no technical prerequisites is a sound foundation for a six-figure role managing engineering teams.
Has anyone here worked in an organization that genuinely benefited from having a dedicated Scrum Master? What made it work vs. the cases where it didn't?
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.
I've been working in bank tech for 25 years and this pattern just keeps repeating everywhere I go.
Team sits down for sprint planning. Takes forever. Probably 4 hours by the time we're done arguing about story points and breaking shit down and mapping who needs what from who.
Everyone leaves knowing what they're doing for two weeks. Board looks great. All organized.
Couple days later something breaks. Or priorities shift. Or we find out another team needed something we didn't know about. Plan falls apart.
Next sprint? Same thing. Four hours. New plan. Dies in a few days.
Tracked this once because it was making me insane. Out of 20 sprints maybe 3 actually ended close to what we planned at the start. The rest just completely different by the end.
So what are we even doing? It's not planning if nothing survives. More like... I don't know. Making management feel better? Having something to point at?
Teams I saw shipping well never did this. They'd just grab what looked important and start. Things changed? Cool, adjust. Keep moving.
Anyway. Been watching this happen for years and nobody ever questions it. Starting to wonder if it's just me or if everyone knows this is bullshit but we all just go along with it anyway.
Interesting strategy. I've thought about getting certified
just to have the credibility. The irony would be certified Scrum Master saying "we don't need full ceremony right now" harder to dismiss as
"doesn't understand Agile."
This is the part that gets me. When it works, it's just someone doing basic execution. When it doesn't, you're paying $120k for someone to send calendar invites and forget retros.
That contrast you described, pharma-sales-rep energy vs the guy people yell at mid-meeting got me thinking about the actual ROI. I've been tracking salary data and trying to see if SM presence correlates with delivery metrics (deployment frequency, lead time, that kind of thing). Looked at around 40 teams. Couldn't find any meaningful difference.
Would love to know if I'm missing something in the analysis.
One thing I keep wondering: that good SM you had, would she have been just as effective as a tech lead who spends 10% of her time on facilitation? Or does the dedicated role actually matter when you find the right person?
The contrast you're describing is interesting, one great one who made things pleasant vs the rest being net-negative.
I've been looking at what differentiates the good ones, and it seems to come down to:
1. Actually removing blockers (not just logging them in Jira)
2. Taking admin work off the team vs creating more process overhead
3. Protecting the team's time vs adding more ceremonies
The SAFe certification thing you mentioned... I tracked certification-to-effectiveness correlation and couldn't find one. Plenty of certified SMs who don't understand the work, and great facilitators with zero certs.
What did that one good SM do that the others didn't? Trying to identify the pattern.
That pattern of making the role redundant is interesting - I've been tracking this across companies and it seems pretty common.
I analyzed time allocation data from Scrum Masters and found they spend ~60% of their time in meetings about meetings. The actual "servant leadership" part averages 4.2 hours per week according to an Agile Alliance study.
The teams that work best seem to be the ones that either:
1. Rotate facilitation duties among senior devs (~10% time)
2. Have tech leads who code 80% and facilitate 10%
Curious if that matches what you've seen when those responsibilities got reassigned to teams?