DEV Community: Javier Castro

The Freelance Market Isn't Shrinking. It's Sorting — And the Middle Is Losing

Javier Castro — Wed, 04 Nov 2026 17:58:19 +0000

The headline rates look fine. The platform data looks survivable. What neither tells you is that the contractor who isn't a specialist and isn't cheap is getting squeezed from both sides simultaneously.

Somewhere right now, a senior backend engineer with nine years of experience is cutting her day rate for the third time this year. Not because her skills degraded. Not because the market collapsed. Because the contract she landed in March lasted five months instead of twelve, the next client took four weeks to decide, and during that gap she burned through more dry-powder than she'd budgeted for. So she adjusts. The next quote goes in a little lower. And the market — which has no memory and no loyalty — accepts that as the new normal.

This is not a story about a broken technology labor market in some abstract, macro sense. It's a story about the compression happening in the specific, unglamorous middle of the freelance stack — and about why the headline statistics keep making it look more tolerable than it actually is.

The Numbers That Feel Reassuring (But Aren't)

Pull up any contractor rate report and the top-line figures look defensible. Across all disciplines, average contractor rates reached $68 per hour in the US and £410 per day in the UK, according to YunoJuno's 2026 Contractor and Freelancer Rates Report, which drew on more than 182,000 data points across 2024 and 2025. Software engineering sits higher — cloud and infrastructure contractors averaged $93 an hour in the US, with software engineering at $88 and product management at $86.

Decent numbers, on paper. Except averages do what averages always do: they hide distribution. When a handful of AI infrastructure architects billing $200-plus an hour sit in the same dataset as a React developer trying to hold $75, the mean looks fine while the median quietly bleeds.

Tech contractor hourly rates in 2026 run from about $45 an hour for IT support to $160-plus for AI and cloud architects, with most mid-to-senior software contractors landing between $60 and $110 an hour. That's a gap wide enough to swallow careers. And the force compressing toward the lower end of that range is structural, not cyclical.

The Real Story: Contract Duration

The rate compression gets worse when you account for the thing nobody headlines: contracts got shorter. Contract lengths used to run 12 months or longer, according to reporting in The Pragmatic Engineer's tech jobs market coverage. Now they rarely exceed six months, driven by budget uncertainty.

This matters more than the hourly rate. A 12-month contract at a rate you negotiated once is a fundamentally different economic proposition than a six-month contract you have to renegotiate twice a year into a market that knows you need the work. The contractor doesn't just face a lower rate — she faces a structural negotiating disadvantage every time she comes back to the table, because the client has learned that patience is now free. The talent supply is abundant. The budget cycles are cautious. What's the rush?

You now have the highest concentration of experienced contract-eligible talent in a decade competing for the smallest pool of contract budgets in the same period. Teams are hiring contractors as a last resort, with less hiring overall, slightly lower pay, and contract lengths that have compressed from twelve-plus months to six months or fewer.

Some of that oversupply came from the layoff waves of 2023 through 2025. Former full-timers at companies like Meta, Cisco, and countless scale-ups landed in the contractor pool not because they chose it, but because the alternative was a job market where, per data tracked by Ravio, entry-level positions saw a 73% decline in hiring rates versus a 7% overall decline, and while IT spending grew roughly 10%, senior and specialized roles absorbed most of that demand. If you were mid-level and recently displaced, the contract market wasn't a comfortable detour — it was the only road open.

The Provocative Claim: This Isn't About AI, It's About Leverage

Here's where the argument gets uncomfortable for people who've been blaming the wrong thing.

The prevailing narrative frames the contractor squeeze as an AI story. That's partly true, and partly a convenient excuse for clients who were already inclined to tighten terms. Budget uncertainty, Section 174 accounting changes that made software engineering spend harder to justify on balance sheets, and post-pandemic CFO risk aversion all compounded the picture before a single line of generated code entered the conversation.

What AI actually did — specifically, in the platform-mediated freelance segment — is clarify and accelerate something already structurally underway: the elimination of commodity work that was only ever valuable because the client had no scalable alternative. A Ramp Economics Lab study using actual company spending data tracked thousands of firms from 2021 to 2025, and found that more than half of businesses spending on freelance platforms in 2022 had completely stopped by 2025. Freelance marketplace spending as a share of total company spend dropped from 0.66% to 0.14% — nearly a fivefold decline.

But here's what that statistic obscures: the "freelancer platform spend" Ramp measured was specifically spend on platforms like Upwork and Fiverr. Marketplace freelancing and strategic freelancing are different businesses. Marketplace platforms are where companies go to buy discrete outputs at competitive rates. The contractor building a cloud migration strategy through a direct relationship with a longtime client doesn't appear in that data. Neither does the senior DevOps consultant who hasn't touched Upwork in four years.

The middle didn't just get squeezed by AI. It got squeezed because it was always the most exposed layer: too expensive to be the cheap option, not specialized enough to be the indispensable option. That vulnerability existed before ChatGPT. AI just made the cheap option cheaper, faster.

Who's Actually Getting Squeezed

The bifurcation is sharp and documented. Rates have compressed at the bottom and expanded at the top. Junior and mid-level freelance rates have dropped, while the rate ceiling for a specialist freelancer has never been higher. Being a generalist is now a structurally difficult position to monetize. A generalist web developer competes with 50,000 profiles on Upwork. A developer who specializes in migrating WooCommerce stores to headless Shopify competes with maybe 200.

The Fiverr numbers illustrate the buyer-side version of this. Annual active buyers fell from 3.5 million in Q1 2025 to 2.9 million in Q1 2026 — a 17.8% year-over-year decline. In the context of almost any other marketplace business, losing nearly 600,000 buyers in a year would be a devastating signal. Except Fiverr's revenue held because the buyers it lost were predominantly low-frequency, low-spend transactional buyers who purchased commoditized services — logo designs, simple content, basic voiceovers — generating low revenue per transaction with high churn rates. These are exactly the buyers that Fiverr's strategic pivot was designed to shed.

That's a rational business move for Fiverr. It's a rougher reality for the freelancers who built their income on those buyers.

Bill rates for junior contract developers are down 8 to 12 percent depending on the stack, per KORE1's own client data from 2026 contracts. Meanwhile, the cost of being a contractor hasn't moved: no employer-side benefits, platform fees, dry periods, renegotiation overhead, and tax complexity absorb a consistent 30-40% off the top. A rate drop of 10% on a gross figure that was already doing heavy lifting doesn't leave much room.

The Counterargument, Given Its Due

The bullish case for contractors isn't fake. Robert Half's research on the 2026 tech hiring outlook found that while 78% of tech leaders plan to increase permanent headcount in the second half of 2026, 66% also plan to add contract or temporary talent over the same period. Demand for contract professionals is genuinely growing in infrastructure, cybersecurity, and platform engineering — net tech employment is expected to grow roughly 1.9% in 2026, with tech compensation rising 8-10%, and cybersecurity talent commanding 10-15% premiums for mid-level roles.

Contract-to-hire is also overtaking direct hire as the default model for senior IT roles, which expands the relevant pool. And headcount freezes have a well-documented workaround: companies freeze headcount while leaving approved project budgets untouched, because freeze memos name positions, not dollars. Contract spend slides through on a different budget line.

So the market isn't closed. It's sorting. The problem is that "sorting" sounds orderly, and for the generalist mid-level contractor caught in the middle, it doesn't feel orderly at all — it feels like the floor keeps moving.

What To Actually Do With This

The practitioners who are holding rates are, without exception, positioned along one of two axes: deep vertical specialization (not "DevOps" but "Kubernetes migrations for regulated financial infrastructure"), or a track record of outcomes that transfers across contexts — provable shipping velocity, demonstrated architecture decisions that held up, client references who'll say something specific rather than something warm.

If you're a contractor and your rate is under pressure, the question worth asking before you accept the lower number is this: can I point to a delivery outcome that a client could not have got from someone cheaper? If yes, the rate problem is a positioning problem, not a market problem. If no, the market is giving you accurate information.

For hiring managers on the other side: the six-month contract structure is rational budgeting and it is also a slow tax on the quality of people you can attract. A senior engineer with three competing offers on the table is not taking the version that says "we will probably convert you" — which means the contract-to-hire structure only works when the hourly rate is priced high enough to compensate the person for carrying the uncertainty. Compressing both the duration and the rate simultaneously selects for whoever needs the work, not whoever's best at the work.

The contractor market isn't broken. It's honest. It's telling everyone exactly what it values — and for the people caught in the middle, that message is landing harder than any headline rate would suggest.

Sources

Hybrid Agile Is Already Winning. That Doesn't Mean Teams Are Doing It Right.

Javier Castro — Tue, 03 Nov 2026 13:07:38 +0000

Most organizations have stopped arguing about agile versus waterfall. The problem is the truce they've negotiated is making both sides worse.

The meeting that crystallized the problem for a lot of delivery leads happened sometime around 2022, in an enterprise program room that smelled of catered sandwiches and mild institutional dread. On one wall: a burndown chart. On the other: a Gantt chart that stretched so far into the future it required scrolling. Both were accurate. Neither was informing any actual decision. The Scrum team was iterating. The governance board was gating. Nobody in the room was sure whether those two activities were connected in any meaningful way.

This is where the hybrid delivery model has landed at scale — not as a thoughtful synthesis of two philosophies, but as a kind of methodological détente. Burn velocity on one screen, RAID log on the other, and a program manager somewhere in the middle manually translating between them.

The Numbers Don't Lie, But They're Being Generous

According to the 18th State of Agile Report, 74% of organizations now say they use hybrid or homegrown delivery models — a number that deserves some skepticism, because "hybrid" is doing a lot of heavy lifting as a term. It covers everything from genuinely sophisticated blended frameworks to what are essentially waterfall projects with daily standups bolted on.

As one trend observer from the 17th State of Agile noted, more and more organizations are claiming a hybrid approach — not sticking to one framework — particularly in heavily regulated industries where rules require working around certain constraints.

The academic literature is equally candid about why this happened. Agile's neglect of documentation and its challenges in managing physical product iterations hindered long-term maintenance and compliance, driving the need for hybrid models. Risks like "difficulty in adjusting schedules to customer timelines" and "imperfect sprint planning" revealed gaps in pure agile frameworks — gaps that hybrid methodologies emerged to fill by combining agile's flexibility with traditional methods' predictability.

Fair enough. Nobody serious is arguing that a pharmaceutical firm should run two-week sprints on regulatory submissions, or that an aerospace contractor should treat DO-178C certification evidence as optional. Integrating agile methods into safety-critical aerospace development presents substantial challenges: strict compliance requirements like DO-178C demand documentation, traceability, and comprehensive verification activities that pure Scrum simply doesn't account for. The regulated world genuinely needs structure that pure Scrum does not natively provide.

But the claim worth sitting with is this: the hybrid model hasn't failed because it's conceptually wrong — it's failing because most organizations are using it as permission to do nothing particularly well. They've kept the governance overhead of waterfall and discarded the discipline, while adopting the ceremonies of agile and discarding the empiricism.

The Architecture of a Comfortable Compromise

Water-Scrum-Fall — one of the most common hybrid patterns — segments projects into planning using waterfall, iterative development through Scrum, and delivery through waterfall phases, retaining flexibility while adding structure. In theory, that's a reasonable arrangement. In practice, it usually produces the worst of both: fixed scope decided upfront by people who haven't talked to users, executed in sprints that feel adaptive but can't actually change direction, then shipped through a release process governed by an enterprise release board that meets quarterly.

Forrester documented this pattern over a decade ago and gave it the name that stuck. Agile adoption frequently diverged from the original Agile Manifesto because it was practitioner-led — practitioners focused on the domain they knew best, software development, while release management and project planning stayed firmly in waterfall territory.

That observation has aged impeccably. The sprint ceremonies moved into development teams. The governance artifacts stayed with the PMO. And the connective tissue between them — the bit that was supposed to make the whole thing coherent — never quite materialized. Research examining real-life Water-Scrum-Fall implementations in large enterprises found that modified agile methodologies are used but their benefits are not fully unlocked: hybrid approaches still require rigorous upfront analysis that strongly limits agility in subsequent phases, and customer feedback loops are frequently omitted entirely.

When Hybrid Actually Works

The counterargument — and it's a real one — is that for certain organizations, getting both methodologies to coexist at all is a legitimate achievement.

Halliburton, for example, implemented an agile-based process for software development while still allowing projects to comply with the corporate standard waterfall process framework — mapping agile into the existing waterfall structure, adjusting the framework to allow agility, and extracting real value from the approach. That's not a small thing inside a company with the regulatory and procurement complexity that comes with being a major oilfield services provider. Sometimes the win is just getting agile ceremonies recognized as a legitimate delivery method within an otherwise rigid system.

Agile transformations go "at risk" when parts of the organization that aren't ready to transition are forced to do so prematurely. Organizations need to plan an orderly transition by allowing both methodologies to coexist for a period of time. This is the sensible, practitioners'-eye view: pragmatism over ideological purity, especially when the alternative is blowing up a compliance-dependent delivery process that actual regulators will scrutinize.

Success in hybrid methodologies hinges on leadership support, tailored process integration, and continuous improvement mechanisms. The emphasis on tailored matters. Off-the-shelf SAFe layered onto a team that has never done a real retrospective is not a hybrid model. It's a bureaucratic expansion of something that was already struggling.

Frameworks like SAFe, LeSS, and Disciplined Agile Delivery reintroduce management layers for portfolio governance, program increment planning, and compliance auditing. Industries such as finance, healthcare, and aerospace operate under compliance frameworks that may fundamentally alter the feasibility of pure self-management. You cannot Scrum your way through an FDA audit. Something has to give, and what gives is usually some agile purist's insistence on no documentation outside the working software.

The Problem No One Wants to Name Out Loud

Here's where things get uncomfortable: a lot of what gets called "hybrid" is really just organizational inertia wearing progressive clothing.

Enterprises commonly use home-grown frameworks or something inspired by an industry-standard framework, while some still have traditional PMO teams operating like it's 2005. Org-wide agile mandates don't reliably produce business impact, so teams are left to deliver in a discordant manner because of the underlying system complexity.

That discordance has a cost that rarely shows up on sprint velocity metrics. When the governance layer and the delivery layer are operating on different cadences, with different vocabularies and different definitions of "done," the integration cost falls on individual contributors. A tech lead who spends two days per sprint updating a status report in a format the PMO can process is doing hybrid integration work that no framework accounts for. It just appears as reduced team capacity.

Most organisations have responded to the gap between management and agile by staying with plan-driven waterfall and hybrid approaches that have a track record of going well over budget while delivering much less value than predicted. The evidence suggests that slapping agile ceremonies onto a waterfall structure isn't closing the performance gap — it's creating a more complicated failure mode, one with both a burndown chart and a variance report to misread.

Performance and scalability issues are key drivers of agile's evolution, as these methodologies struggle at enterprise levels. Frameworks like SAFe and LeSS were developed to address scalability, but they introduced complexity and rigidity that counteract agile's flexibility. This is the structural irony at the center of the hybrid conversation: the frameworks built to make agile work at scale have, in many implementations, simply recreated the planning overhead they were supposed to replace.

What Good Hybrid Looks Like (And Why It's Rare)

Hybrid models that work integrate agile's iterations with plan-driven documentation to ensure regulatory adherence without sacrificing agility — particularly when combined with DevOps practices for continuous compliance. Hybrid models like MAHD enforce iterative validation cycles and modular design to meet regulatory standards without sacrificing agility.

The operative phrase is "without sacrificing agility." Not "agility minus the governance overhead" or "governance plus some standups." The real hybrid practitioner knows exactly which constraints are non-negotiable — a regulatory gate, an audit artifact, a fixed external release date — and protects genuine adaptability in everything else. The sprint backlog actually changes based on learning. The compliance checkpoint is automated where possible. The program increment isn't just renamed "waterfall planning with a PI ceremony."

Recent systematic research finds that hybrid methodologies represent a mature evolution rather than a transitional phase, validated by their effectiveness in achieving stakeholder success comparable to pure agile. That's genuinely encouraging, but the emphasis belongs on "mature" — it implies that early-stage, poorly implemented hybrid doesn't reach that bar.

Poor implementations often accompany unpreparedness by companies to fully adopt agile and the absence of senior roles like Scrum Masters who could educate teams and organizations in proper agile practices. The hybrid model rewards expertise and punishes improvisation, which is somewhat the opposite of how most organizations have treated the adoption decision.

The Truce That Nobody Signed

The uncomfortable truth about the hybrid delivery model is that it became the default not because organizations resolved the tension between adaptability and control, but because they got tired of having the argument. Hybrid is the peace treaty that allowed the transformation budget to be spent, the framework consultants to be paid, and the leadership deck to say "agile" without the IT department getting too anxious.

That's not inherently cynical — avoiding a culture war has genuine value, and coexistence between methodologies is sometimes the most honest reflection of where an organization actually is. But the truce has a price: it lets mediocre implementations hide behind a label that implies sophistication.

A team running two-week sprints inside a six-month waterfall phase, updating a RAID log nobody reads, with customer feedback arriving once at the end — that's not a hybrid model. That's a waterfall project that bought some Jira licenses.

The organizations getting genuine value from hybrid delivery are the ones who made explicit, uncomfortable decisions about which constraints are real and which are just habit. Everything else is just methodology branding.

Sources

The Daily Standup Deserves to Die. The Sprint Review Doesn't.

Javier Castro — Tue, 03 Nov 2026 13:06:59 +0000

AI has automated away the informational content of Scrum — which means the only ceremonies worth keeping are the ones that were never really about information at all.

Picture this: it's 9:30 AM, eight engineers join a Zoom call, and for twelve minutes they take turns reciting what they did yesterday and what they're doing today, confirming — one by one — that they have no blockers. The Scrum Master types notes into a Confluence doc nobody will read. The meeting ends. Everyone context-switches back to whatever AI tool is currently writing their code at twice the speed they can review it. Nothing changed. Nothing needed to.

This is the daily standup in 2026. The provocative claim worth making here isn't "Agile is dead" — that's a decade-old obituary with bad predictive accuracy. The real claim is narrower and more uncomfortable: AI has already automated away the informational content of most Scrum ceremonies, exposing which ones were always just information pipelines wearing a collaboration costume. The daily standup is the obvious casualty. The sprint retrospective, properly redesigned, may be the ceremony that matters most right now — precisely because AI makes its failure mode worse.

The Productivity Paradox Nobody Wants to Discuss

Start with the data, because it's messier than vendor slide decks suggest.

METR, the nonprofit AI evaluation research group, ran a randomized controlled trial on how early-2025 AI tools affect the productivity of experienced open-source developers working on their own repositories. Developers using AI tools took 19% longer than those working without them. AI made them slower. The perception gap is the more disturbing detail: initial developer forecasts predicted a 24% speedup; post-task self-assessment reported a 20% speedup; objective measurement revealed a 19% slowdown.

This is not a reason to throw out AI tooling. METR's own researchers note the study reflects a specific window of models and a specific type of task — experienced developers on complex, mature codebases — and METR itself now labels the result as historical, saying it no longer necessarily reflects current AI tools or current developer workflows. But the perception gap is durable evidence of something structural: teams are operating on vibes, not measurement.

At the codebase level, the problems compound. GitClear, based on analysis of 211 million lines of code, found that AI coding assistants are eroding code quality by increasing duplicated and copy/pasted code. The number of code blocks with five or more duplicated lines increased by eight times during 2024. And 2024 was the first year on record where within-commit copy/paste exceeded "moved" (refactored) code. GitClear's 2026 update extended the picture further: refactoring fell from 21% to under 4% of code changes, while duplicated code blocks per million changed lines rose 81% over the same window.

Here is what this means for delivery teams running Scrum: AI is shipping code faster, but that code is increasingly a debt instrument. AI accelerates writing code, but Scrum was never primarily about writing speed — it's about coordination, prioritization, and managing complexity and stakeholder alignment. Faster code generation makes deciding what to build, and coordinating across people, the bigger bottleneck. Congratulations on the velocity.

The Standup Is Already Doing Its Job Asynchronously

The daily standup was invented to answer three questions: What did you finish? What are you working on? What's blocking you? Those are information-retrieval tasks. In 2026, they are solved problems.

AI can replace the status-update portion of standups by pulling progress data from GitHub, Jira, or Linear automatically. Tools like Spinach, Geekbot, and Linear's built-in async updates generate pre-meeting summaries from actual commit history before anyone opens their laptop. Instead of building a sprint from scratch, the team reviews an AI-generated proposal. Teams report cutting planning meetings from two hours to thirty minutes.

Kent Beck, inventor of Extreme Programming and chief scientist at Mechanical Orchard, told LeadDev that if everybody's working in the same room, "a daily stand-up doesn't provide value for the cost." "A stand-up brings with it a daily coordination cost where everyone has to be there at the same time," he continued. "The time spent at the stand-up can't be doing other things."

Beck made that observation before AI could auto-generate the entire content of the meeting from version control history. The economic case has only gotten more one-sided. There's an irony at the heart of daily standups: they exist because Scrum values communication, but they often make communication worse. The ceremony's original purpose was to surface blockers fast. Instead it became a serialized status broadcast — exactly the kind of thing AI handles better than humans, at a fraction of the cost.

Microsoft's 2024 Work Trend Index found that 78% of developers consider "meeting overload" their biggest productivity challenge. The standup isn't the only culprit, but it's the most defensible sacrifice. Cut it — or go fully async — and the actual information flow doesn't degrade. It improves, because engineers stop treating their morning commit as the thing they'll narrate at 9:30 and start treating it as something they'd actually want read by a machine.

Sprint Planning: Keep the Decision, Cut the Theater

The case against planning meetings is similar, but the cuts are more surgical.

Teams may spend less time during sprint planning discussing the mechanics of work and more time strategically coordinating the use of AI and redefining the Definition of Done as they experiment with new tools. That reframe is correct. The problem isn't sprint planning as a concept — it's sprint planning as a manual process. Estimating story points by gut feel was always a low-signal exercise. AI now does it better: if your team historically underestimates database migrations by 50%, an AI assistant can point that out before you commit to the sprint.

Choosing the backlog, writing the goal, prioritizing, committing to capacity — all of that requires deciding what should happen, based on context that often lives outside the data AI can access. That's the part worth protecting. The ceremony should shrink to the irreducibly human decision layer: where are we going, and why. Everything else — story splitting, acceptance criteria, capacity math — is clerical work that machines do without coffee.

By 2027, weekly grooming meetings will become anachronistic at AI-mature teams. Continuous AI-assisted grooming — where stories are split, INVEST-checked, and acceptance criteria expanded as they enter the backlog — replaces the weekly gathering. Backlog refinement as a separate ceremony is already a candidate for elimination in teams using tools like Jira's AI Assistant or Linear's continuous triage. The sprint planning meeting collapses to thirty minutes of goal-setting if the pre-work is handled algorithmically.

The Sprint Review: Counterintuitively, Keep It

Here's where the argument gets interesting, because the conventional wisdom runs the other way. If code ships faster, sprint reviews become less meaningful — smaller scope, lower stakes per cycle. That analysis is wrong.

As sprint frequency increases, the scope shown in each review naturally shrinks. This might look like the review matters less. It's the opposite. Stakeholder feedback on a focused, narrower slice of working software is more actionable than feedback on a sprawling two-week dump. The sprint review's actual function — getting early signal from people outside the delivery team about whether the product is pointing in the right direction — becomes more valuable, not less, when AI is generating code at speed. Bad direction, implemented fast, is an expensive problem.

By 2025, although 78% of companies were using AI, about 80% reported no significant business impact — a "generative AI paradox" attributed to teams producing features without sufficient product guidance or validation. That's not a tooling problem. That's what happens when a feedback loop breaks. The sprint review exists precisely to close that loop with the humans who can tell you whether the feature actually matters. No AI tool has a substitute for a product manager watching a real user's face during a demo.

The Retrospective: Most Valuable Ceremony, Worst Follow-Through, New Purpose

The sprint retrospective would be the most valuable ceremony in Scrum — if it weren't also the one with the worst follow-through. AI can run the same ceremony and actually keep the results, because the lesson gets loaded before the next session instead of filed and forgotten.

That framing gets at the real problem. Most retrospectives end with action items in a Confluence page that nobody reads before the next retrospective. AI-assisted retros fix the retrieval problem, not the conversation problem. Surfacing a pattern across retrospectives is valuable. Deciding what the team should do about it is different — and that's not a job to outsource. Retro insights should be presented as conversation starters, not conclusions. A retrospective is a team accountability exercise, and handing the conclusion to an algorithm undermines what the ceremony exists to build.

But there's a new purpose the retrospective needs to absorb, because no other ceremony is doing it: if Scrum's pillars of transparency, inspection, and adaptation were important before, they're doubly so now. AI can generate a flood of output and data that a team can drown in or be misled by. Questions like "what AI-generated code did we ship that nobody fully reviewed?" and "which sprint commitments were we optimistic about because Copilot made it look easy?" belong in the retrospective now. They belong nowhere else.

A Proposal You Can Actually Bring to Monday's Planning Call

Here's the concrete version:

Kill the daily standup. Replace it with an auto-generated async digest — Linear, Geekbot, or whatever reads your actual commit and ticket activity — with a standing agreement that humans only convene synchronously if a blocker has been in the system for more than four hours and wasn't self-resolved. The information doesn't disappear; the theater does.

Shrink sprint planning to goal-setting only. Let AI handle story prep, estimation, and backlog sequencing before the meeting. Protect thirty minutes for the team to say, out loud, what the sprint is actually for — and whether the backlog reflects that. If those two things don't match, no AI tool will tell you.

Protect the sprint review. Not because it's sacred, but because it's the only ceremony that puts working software in front of people who can tell you whether you're building the wrong thing at impressive speed. With AI-accelerated delivery, this signal is the constraint. Treat it like one.

Redesign the retrospective around AI governance. Add an explicit check on code quality and review coverage alongside the usual team dynamics discussion. Not as bureaucracy — as consequence management. Someone needs to be asking where the duplication went, and whether the AI-assisted sprint created technical debt the team can't see from the inside.

The question to bring to your team isn't "should we cut ceremonies?" It's sharper: for each ceremony, ask what information it produces and whether a machine is already producing that information more reliably. Whatever survives that filter is worth keeping. Whatever doesn't was probably a cargo cult long before anyone wrote the first prompt.

The real threat to Scrum isn't AI. It's teams that automate their way to the illusion of coordination while skipping the judgment calls that actually determine whether the product is worth building. The ceremonies that survive are the ones that force those judgment calls into the open, with humans in the room who are paid to disagree. There are fewer of those than most Scrum practitioners would like to admit — but more than the "Agile is dead" crowd will ever give credit for.

Sources

The Boeing 737 MAX Didn't Crash Because of a Bug. It Crashed Because Nobody Was Allowed to Say It Might.

Javier Castro — Wed, 28 Oct 2026 20:16:17 +0000

The real single point of failure on the 737 MAX wasn't the sensor — it was the organizational structure that made raising concerns career-limiting.

Somewhere in a Boeing conference room, a clock was counting down. Not to a launch party. Not to a safety review. To a production deadline.

The business executive overseeing the MAX program had installed countdown clocks tied to major production milestones — one counting down to powering on the first airplane in the factory, another to the scheduled first test flight — placed in the same rooms where technological and business performance reviews took place. The message those clocks sent to every engineer in the building was not subtle.

That detail, drawn from the Harvard Law School corporate governance case study of the disaster, is worth sitting with. Because it is the kind of organizational signal that no post-mortem report can fully capture. It doesn't show up in code reviews or system audits. It shows up in what people choose not to say in meetings.

The Boeing 737 MAX disaster — 346 people dead across two crashes in October 2018 and March 2019 — is the most thoroughly documented case of a software system failing not because of what engineers didn't know, but because of what they knew and couldn't get anyone above them to act on. And yet the lesson most teams take from it is still, almost always, framed as a technical one: add redundancy, improve testing, don't trust a single sensor. Correct. Also completely beside the point.

The Engineers Saw It Coming

The crashes were precipitated by a failure of an Angle of Attack sensor and the activation of the Maneuvering Characteristics Augmentation System — a flight control system designed to compensate for changes in the size and placement of the engines on the MAX. The existence of that software was not disclosed to pilots until after the first crash.

That concealment is the lede. But the more damning fact is what happened years before either plane went down.

In December 2015, a Boeing engineer in the division that designed MCAS asked directly: "Are we vulnerable to single angle-of-attack sensor failures with the MCAS implementation?" That question sat in an internal email. It didn't result in a design change. The plane had two AOA sensors mounted on its nose. Boeing had designed an automated safety system that entrusted its decision-making to just one of them — a type known to fail — while Airbus typically relied on three.

A former Boeing engineer who worked on the MAX told the Seattle Times: "A single point of failure is an absolute no-no. That is just a huge system engineering oversight. To just have missed it, I can't imagine how."

Here's the thing: they didn't miss it. Internal Boeing memos and emails show engineers asking specifically about the system being triggered by a single sensor, about the consequences of a faulty sensor, and about whether pilots would react in time if MCAS activated erroneously. The questions were documented. The answers were not acted on. That is not an engineering failure. That is a management failure wearing an engineering costume.

The Incentive Was Explicit

To understand why those questions went nowhere, you have to understand what Boeing had decided the MAX was and was not allowed to be.

The goal of adding MCAS was to preserve the feel of previous 737s so pilots wouldn't need costly simulator training. That single commercial constraint — avoiding the training cost that would have accompanied a genuine new-type aircraft certification — shaped every downstream technical decision. At a meeting documented in a June 2013 email, Boeing officials agreed to diminish focus on MCAS as anything novel "in order to avoid increased costs, and greater certification and training impact."

That meeting was six years before the second crash. The decision to bury MCAS wasn't an oversight. It was a strategy.

Boeing had at one point planned to inform pilots about MCAS in their flight manuals, then reversed course and removed virtually every reference to it from pilot operating and training materials. As if it never existed. As a result, 80% of the 737 MAX planes shipped without a functioning warning system that would have notified pilots of faulty sensor data.

Full disclosure of MCAS would have invited regulatory scrutiny that might require new pilot type-rating — which would have made the MAX substantially less attractive to airlines that had already ordered it expecting a simple transition from the older 737. Competitive pressure, urgent delivery timelines, and a permissive regulatory relationship all pointed in the same direction: make the problem smaller, not solve it.

When the Culture Determines What's Audible

Despite Boeing being the acquiring company in the 1997 McDonnell Douglas merger, the deal brought significant organizational and cultural change. McDonnell Douglas had emphasized financial performance; Boeing had prioritized engineering quality. With former McDonnell Douglas executives assuming key leadership roles, Boeing's internal focus shifted: engineering quality continued to be valued, but it was now run through a stricter filter of financial discipline.

That shift is visible everywhere in the MAX program's paper trail. Some Boeing pilots, engineers, and other employees did raise safety concerns about the 737 MAX, but those concerns were either inadequately addressed or dismissed by Boeing and never reached the FAA. After the Lion Air crash — 189 people dead — internal discussions at Boeing and FAA reviews revealed concerns about MCAS, but Boeing did not issue a software fix or recommend grounding the aircraft. Instead, the company issued guidance suggesting pilots could manage the issue by following standard runaway trim procedures. Which is one way to handle a system flaw: tell the people operating the system to work around it and hope for the best.

After the first crash, the information needed to prevent another was already available. The failure mode was known. The design vulnerability had been exposed. Five months later, Ethiopian Airlines Flight 302 crashed in almost identical circumstances, killing all 157 people on board.

A former Boeing supervisor on the 737 MAX final assembly line had raised serious safety issues with senior management in June 2018, four months before the Lion Air crash. He specifically cited "schedule pressure" and wrote: "Frankly right now all my internal warning bells are going off. And for the first time in my life, I'm sorry to say that I'm hesitant about putting my family on a Boeing airplane." He recommended shutting down the production line. He was not listened to.

The counterargument worth taking seriously is that Boeing is an extreme case — a safety-critical aerospace program under immense competitive pressure, with specific regulatory dynamics that don't translate cleanly to a software team shipping a SaaS product. Fair enough. Most engineering managers will never face stakes even remotely comparable. But the organizational mechanics — the suppression of signals, the redefinition of known risks as manageable ones, the incentive structures that determine what gets escalated and what gets quietly filed — are not unique to aviation. They show up in nearly every major software incident where the postmortem eventually uncovers an email chain proving someone raised the concern months earlier.

Information from 57 whistleblowers who came forward during the Senate investigation revealed common themes: insufficient training, improper certification, and management undermining of frontline inspectors — trends often accompanied by retaliation against those who reported safety violations. Fifty-seven people. That's not a few dissenters. That's a system that had fully learned to eat its own warning signals.

The Real Lesson, Which Is Not About Sensors

At least some people at Boeing knew MCAS was dangerous because one sensor constituted a single point of potentially catastrophic failure. The technology did not design itself or fail by itself — and that is why the 737 MAX debacle was primarily a failure of management.

That framing is correct. But it still locates the failure in specific management decisions rather than in the organizational conditions that made those decisions rational from a career-preservation standpoint. The engineers who asked the right questions early were not overruled in some dramatic boardroom confrontation. Their questions just… didn't travel. Engineers flagged concerns about MCAS, and those warnings were diluted or ignored by leadership — not through any single act of suppression, but through an organization that had quietly stopped making bad news easy to deliver.

That's how most catastrophic failures actually work. Not through villainy — though Boeing's internal documents contain their share of that — but through an organizational design that makes bad information expensive to surface and comfortable to ignore. The countdown clocks in the conference rooms were not just about production. They were a statement about which problems were worth solving under which timeframe. Engineers read that message accurately.

The actionable thing — the thing you can bring to your next sprint planning or your next architecture review — is not "add a second sensor." It is this: ask yourself what a junior engineer on your team would have to lose by telling you that the system you're about to ship has a flaw you haven't fully characterized. If the answer is anything more than a few minutes of discomfort, your organization has already built the same countdown clock. It's just hanging somewhere you haven't noticed yet.

The 737 MAX disasters represent a systemic failure in software-based system design, verification, and certification — not a coding error per se, but a breakdown in safety culture, requirements engineering, and independent verification of software behavior under fault conditions. Every one of those breakdowns has a human decision behind it. And behind each of those decisions was an incentive structure that made it easier to classify a problem as acceptable than to stop the clock.

Boeing eventually fixed MCAS. The redesigned system now ingests data from both AOA sensors and only activates if both agree on a high angle-of-attack reading. A single sensor failure can no longer trigger it. The technical fix took months. The organizational conditions that made the original design acceptable took decades to build. There is no patch for that.

Sources

The Middle PM Is Not a Generalist. It's a Warning Sign.

Javier Castro — Thu, 15 Oct 2026 11:15:51 +0000

The PM role is splitting into two distinct archetypes — and the one stuck between them isn't versatile. They're just overdue for a reckoning.

Picture a product manager at a mid-sized enterprise SaaS company — somewhere in the analytics or fintech corridor. They run the sprint ceremonies, write the PRDs, manage the roadmap presentation for the quarterly business review, and pride themselves on being "technical enough" while also being "strong with stakeholders." They are, in the parlance of every PM resume written between 2017 and 2023, "a bridge between business and engineering."

That bridge is now a bottleneck.

Not because this person is bad at their job. They may be quite good at it, in the way that a skilled fax machine operator was quite good at their job in 1997. The problem is structural. The PM role is no longer one job. It's becoming two — and the territory in the middle, where most working product managers actually live, is quietly collapsing.

The Fork in the Road Has Already Happened

The generalist PM role has been splitting in two, and by most accounts it's been obvious since at least mid-2025. The divergence isn't subtle anymore.

The first archetype is the builder-PM: AI-native, ships prototypes independently, works on teams that deliberately blur the PM/engineer line. This is the PM who shows up to a design review with a working Figma prototype, or drops a functional feature scaffold in Cursor before the engineering spec is even written. Old PM-to-engineer ratio assumptions are collapsing because the job now includes shipping code, not just speccing it.

The second is the integrator-PM: high-EQ, cross-functional, owns the roadmap in messy B2B environments where internal alignment is still fundamentally a human problem. This PM survives at large enterprise orgs not by prototyping but by knowing exactly which VP to get in a room before a roadmap review, and precisely which talking points will neutralize the objections from legal before they surface. Their superpower is political intelligence, not technical fluency.

The most significant data point validating this shift came out of LinkedIn in December 2025. The company dismantled its traditional associate product manager program and replaced it with an associate builder track that trains hires to code, design, and product manage — while also adopting small "pods" of full-stack builders. LinkedIn's chief product officer Tomer Cohen confirmed the transition on Lenny's Podcast, announcing that the new program would begin in January and teach participants "how to code, design, and PM at LinkedIn."

Applicants don't submit a resume. They submit a 60-second demo of a product they built, and answer questions about how they used AI in building it.

That is not a hiring preference. That is a public statement about what the word "product" now means.

The Middle Is Not a Strategy. It's a Position.

Here is the claim worth arguing over: the PM stuck in the middle isn't a generalist. They're a specialist in tasks that are being automated out of relevance.

That's a sharp thing to say, and it deserves a fair hearing as a counterargument. Many practitioners — reasonable ones — will push back. Product management has always required both builder instincts and political fluency. Marty Cagan at SVPG has spent years arguing that the best PMs are deeply involved in product creation and act as the connective tissue of a cross-functional team. The integrator skills and the builder skills aren't mutually exclusive; they're complementary. The "full-stack PM" is arguably the ideal, not the outdated archetype.

That counterargument is correct in theory. It also describes a very small number of people. In practice, the group under the most pressure is the one doing neither archetype role distinctively — operating in the middle at a mediocre level on both dimensions and calling it range.

Product management is becoming an 80/20 profession — not because 80 percent of PMs are about to lose their jobs, but because the distribution of value is getting much more extreme. A smaller group will create a disproportionate amount of impact, and the gap between strong and average will become much easier to see.

The labor market is already registering this. Senior PM hiring at staff, principal, and director levels grew 34% in 2025, while junior and mid-level PM hiring shrank 12%. The role isn't disappearing — it's concentrating at the top. And when you look at where the cuts came, they followed a predictable pattern. According to data analyzed by Mind the Product, management layers were most affected, with VP-level PMs down 38%, directors down 35%, and managers down 31% from their peak — managers representing the largest reduction in absolute terms.

It was the middle of the org chart that got hollowed out. The people whose jobs consisted mostly of translating information between engineers and executives, running ceremonies, maintaining roadmaps, and drafting quarterly reviews. That is precisely the work that tooling now handles faster and with less friction. The middle layers of product management — focused solely on stakeholder management or process orchestration — are being automated out of relevance. Microsoft reportedly discussed reducing the number of middle managers and non-coders specifically in a bid to increase the ratio of programmers to product managers.

This was not a surprise, for anyone paying attention.

Why the Middle Felt Safe for So Long

The middle position had a reasonable structural rationale for a long time. Enterprise organizations are genuinely complex. Aligning engineering, design, marketing, sales, and finance around a shared roadmap requires sustained human effort that doesn't compress cleanly into a sprint tool or a shared Notion doc. Large B2B customers want a PM who knows how to handle their procurement process, not one who ships wireframes. The integrator skills were real, valued, and often underpaid.

But that same complexity became a hiding place. A PM who fills their week with alignment meetings, status updates, and stakeholder briefings can look extremely busy while contributing very little to the actual direction of a product. The comfortable middle is the PM whose primary value is being organized, articulate, and good at running process — and who is having a harder and harder time explaining why that's a differentiated skill.

Meanwhile, the barrier to entry for creating functional software has collapsed. With tools like Lovable, Cursor, and Replit, a PM who cannot prototype their own ideas faces a hard career ceiling. The distance between a thought and a usable first version has become too short to justify handing every idea over the wall. A PM who can walk into a technical conversation with something tangible is operating from a very different position than one who arrives with a document describing what someone else should build.

The integrator path has its own structural risk, too. Builder-PMs are more exposed to commoditization as software creation gets easier; integrator-PMs are more exposed to top-down directive pressure when capital is tight. Neither track is inherently secure. But at least each has a clear value proposition. The middle has a resume.

What Concrete Moves Actually Get You Out of It

There is no single escape hatch. But there are two honest choices, and a third that pretends to be a choice while actually being inaction.

The first honest choice is to commit to the builder track. That means shipping something publicly, right now — not planning to learn a prototyping tool next quarter, not watching tutorials, but actually publishing a Lovable app or a Cursor-built prototype that solves a real user problem. LinkedIn's new model aims to build people who can take an idea from concept to launch with far fewer handoffs. That is the bar. Not theoretical capability. Demonstrated shipping.

The second honest choice is to go deep on the integrator track — but with ruthless specificity. Not "I'm good at stakeholder management," which is what every middle PM says. A demonstrable track record in a specific vertical (fintech compliance, healthcare procurement, enterprise security) where the human alignment problem is genuinely hard and the domain knowledge takes years to acquire. Generalist PMs who rely primarily on coordination skills face reduced demand in highly technical environments, while those who combine strategic thinking with domain mastery are increasingly viewed as high-impact contributors.

The third option — continuing to describe yourself as "balanced" or "full-stack" without evidence for either — is the one that leads to the awkward performance review conversation in eighteen months.

The most useful question to ask yourself before your next Monday standup: if you removed all the coordination and meeting facilitation from your week, what would you actually have built? If the answer is "not much," that's not a reflection on your work ethic. It's a signal about which archetype you're drifting toward — and whether you've made that choice consciously or by default.

The generous read on all this is that the PM role is maturing into two genuinely different professions, and that's fine — specialization is how every discipline grows up. The less generous read is that the generalist middle was always, to some degree, a job description that survived because it was hard to measure and easy to hire for at scale.

Both reads are probably true. The market is just finally resolving the ambiguity.

Sources

The Contractor Who Cuts Their Rate Isn't Losing Ground — They've Already Lost It

Javier Castro — Tue, 13 Oct 2026 17:57:59 +0000

Rate compression in the freelance tech market isn't the result of a bad economy. It's the invoice for a decade of freelancers refusing to think like businesses.

There's a particular kind of conversation happening on Slack channels and Reddit threads right now. A senior backend contractor — eight years of production Kubernetes experience, several successful delivery engagements behind them — posts their rate card. They used to bill £700 a day. Now they're quoting £550 to stay competitive and still not getting responses. Someone in the thread suggests going lower. Nobody pushes back.

That conversation isn't about market forces doing their inevitable thing. It's about a structural failure that was building quietly across the entire independent contractor ecosystem during the years when the market was too hot for anyone to notice.

According to data tracked by The Pragmatic Engineer, contractor rates are dropping. Companies now hire contractors only as a last resort, pay slightly less than before, and contract lengths that used to run twelve months or longer have collapsed to six months or under as budget uncertainty has become the default planning posture. The easy read: bad market, wait it out. The honest read is harder to swallow.

The contractor rate compression story is not primarily a story about supply and demand. It's a story about positioning failure — chronic, industry-wide, and largely self-inflicted.

The Market Is Genuinely Tighter. That Part Is Real.

Before getting into the positioning argument, the macro context deserves a clean summary.

There are 35% fewer software developer job listings on Indeed today than there were five years ago. Across the same period, total job listings across all industries are actually up 10%. Software development is not merely underperforming — it's the outlier going in the opposite direction from nearly every comparable knowledge-work sector.

Interest rate changes explain most of this. The end of zero percent interest rates disrupted hiring, collapsed VC funding, and changed the survival calculus for the startups that had been the most aggressive consumers of contract labor. When capital is cheap, headcount flexibility is valuable. When capital has a real cost, every contract seat is a line item that someone has to justify in a quarterly review.

Remote hiring dynamics compound the problem: businesses hiring remotely can now recruit better engineers for 10–15% less than before, because the qualified candidate pool expanded globally while the number of available roles contracted locally. The bidding floor dropped across the board, and it dropped fast.

And then Fiverr — one of the most prominent signals of freelance market health — cut approximately 30% of its workforce in September 2025, framing the restructuring as a move toward becoming an AI-native company. A freelance marketplace laying off staff to pursue an AI-native model is not a subtle market signal. It's a neon sign.

So yes: the market contracted. That is not in dispute.

But Rate Compression Is Not Just a Market Problem

Here is the uncomfortable part. Most contractors currently experiencing rate compression were not charging correctly even during the boom years.

They were charging what other contractors charged. They were pricing time, not value. They were taking calls from recruiters and accepting day rates that moved in a narrow band dictated by the staffing agency's margin rather than any actual assessment of what a successful delivery was worth to the client organization. When the market was hot, that sloppiness didn't matter because demand absorbed everyone.

The problem with pricing your time during a bull market is that you never build the discipline — or the evidence — to defend your rate in a bear one.

In 2025, hiring managers reported 1,000 or more candidates for a single role was no longer uncommon. That is, by definition, a buyer's market. And in a buyer's market, the seller who survives is the one who has already done the work to differentiate — not the one who starts scrambling for differentiation after the first rejected proposal.

The contractors getting squeezed hardest right now fall into a recognizable pattern: generalist positioning, time-and-materials pricing, no documented delivery outcomes, limited direct client relationships, and no clear answer to the question "what does a company get when they hire you specifically, rather than someone with a similar CV?" That's not a market problem. That's a business model problem that the market just stopped subsidizing.

The 6-Month Contract Is the Canary

Contract durations have compressed from the former norm of twelve-plus months to six months or fewer, driven by budget uncertainty. That shift encodes something important about how clients now think about contractor risk.

Short-duration contracts, renewed frequently at softer rates, are a client's way of keeping optionality. They're not planning around the contractor's continued presence. They're not pricing in the relationship value or institutional knowledge the contractor accumulates. They're buying a short block of capacity and reserving the right to recalibrate in six months if the market gives them a cheaper alternative, the budget gets cut, or some internal hire eventually covers the domain.

This is the exact structural position that a well-run freelance practice should be engineered to avoid. The contractor who has positioned themselves around a narrow, high-consequence problem domain — specific compliance frameworks, legacy system modernization in a sector with real regulatory overhead, performance engineering in high-throughput systems where failure has tangible business cost — has a much easier time justifying a longer commitment at a maintained rate. The client is not pricing their time. They're pricing the risk of going without them.

Domain specialization has become increasingly critical in tech hiring broadly, with later-stage companies consolidating around empowered full-stack engineers and reducing headcount in generalist categories. The same logic applies with more force to contractor engagement: the generalist capacity provider gets repriced; the domain-specific problem solver gets renewed.

The Fair Counterargument

The positioning failure thesis has a genuine counterargument, and it deserves a fair hearing rather than a footnote.

Not every contractor has the optionality to specialize narrowly. Developers who came up through staffing agencies, took what was available, and built breadth rather than depth were often responding rationally to what the market was offering them at the time. Agencies reward placement speed, not specialization depth. The contract market rewarded availability and generalism for years because enterprises were buying flexible capacity, not niche expertise.

The tech sector reacts to market changes with more intensity than any other industry — no other industry hired with the same frenzy in 2022, and no other industry cut back hiring so sharply in 2024–2025. A contractor who built their practice in 2019–2022 was responding to real market signals. Expecting them to have built a pristinely differentiated specialist business during a period when generalists were being snapped up is a bit like blaming someone for not wearing a raincoat when the forecast said sun.

That's fair. The context shaped the behavior.

But the tighter market is not temporary. US accounting rules (Section 174) effective from 2023 now require software engineering costs to be amortized over five years, making direct hiring and contract spend more expensive to justify on a balance sheet. Interest rates have not returned to zero. The structural pressure on contractor budgets is not a two-year aberration; it's the new baseline.

What Rate Compression Actually Signals

The contractors who maintain their rates through the current compression share something in common: they can articulate what goes wrong for the client without them. Not in terms of tasks not getting done — any contractor can say that. In terms of specific, costly outcomes that the client organization is exposed to if this particular piece of expertise disappears from the engagement.

The market is showing higher hiring bars alongside lower compensation offers for most candidates — but that pressure is explicitly not applying to specialized roles and AI-adjacent domains. The divergence isn't accidental. It maps almost exactly onto the distinction between contractors who have positioned around a quantifiable risk and those who have positioned around general availability.

Rate compression, looked at closely, functions less like a tide that raises or lowers all boats equally and more like a filter. It removes the pricing power from the contractor who couldn't convincingly answer "why you?" during the good years, and leaves it mostly intact for the one who could.

Cutting your rate is sometimes the right tactical move in a slow patch. But if you're doing it because you genuinely cannot articulate why you're worth the higher number to the specific client in front of you — the market didn't create that problem. It just finally made it visible.

The argument worth having isn't whether contractors should lower rates to stay competitive. It's whether the next six months of engagement at a lower rate is building toward a position where the following six months don't require the same conversation again.

Most aren't building toward that. Most are just riding the compression down, assuming it will eventually stop on its own.

It won't stop on its own.

Sources

The Delivery Professional's Guide to Client-Facing Roles Gets Almost Everything Wrong

Javier Castro — Tue, 13 Oct 2026 17:57:35 +0000

The skills that make a great Scrum Master or PM aren't the problem. The direction in which those skills point is.

Picture a recently laid-off Agile Coach — let's say one of the roughly 1,100 whose positions were eliminated when Capital One dissolved its entire Agile delivery function, while Royal London simultaneously made 90% of theirs redundant. She has a decade of facilitation experience, a wall of certifications, a résumé full of impediment-removal wins, and a sincere belief that her people skills will translate cleanly into account management or customer success. She is, in many ways, right about the skills. And almost entirely wrong about which ones she's actually been using.

That gap — between what delivery professionals think they do and what client-facing roles actually demand — is where most career transitions between these worlds quietly break down. Not with a bang. With a polite "we've decided to move forward with another candidate" email after the second-round interview.

The Layoff Wave Nobody Is Pretending Didn't Happen

The tightening of Agile-specialist roles has been steady and visible for anyone paying attention. Part of the pressure comes from what some practitioners call the "90-Day Agile Coach Phenomenon" — individuals with minimal experience rebranding themselves as Agile Coaches, with a lack of depth that eventually catches up with the entire discipline. Add to that a structural reality Scrum.org's own community forums have documented with uncomfortable candor: many executives view the Scrum Master role through a traditional management lens, expecting direct control, visible productivity improvements, and immediate ROI.

When the ROI case fails to land, the role disappears. When a company like Capital One concludes its transformation is mature enough to run without dedicated Agile headcount — stating that "the agile role in our tech organisation was critical to our earlier transformation phases but as our organisation matured, the natural next step is to integrate agile delivery processes directly into our core engineering practices" — a thousand people update their LinkedIn profiles simultaneously.

Many of them pivot toward account management, customer success, or business development. The logic is seductive: these are relationship-driven roles, and delivery professionals have spent years managing relationships. Problem solved.

Except that's not quite what delivery professionals have spent years doing.

The Inward-Facing Trap

Here is the uncomfortable truth the career-transition advice industry consistently papers over: the relationships a Scrum Master or project manager spends their career building are almost entirely internal. The stakeholders are colleagues, engineering leads, product owners, and senior executives one floor up. Depending on the situation, a Scrum Master operates as servant leader, facilitator, coach, mentor, teacher, impediment remover, or change agent. Every single one of those stances points inward, toward the team and its delivery ecosystem.

Scrum Masters may deal with external stakeholders here and there, but it's rare they'd build relationships with them at the depth a client-facing role requires. That's not a knock on the role. It's a description of what the role is.

Customer success, account management, and business development are structurally different. What looks similar on the surface — "relationship management" — is actually a fundamentally different orientation. One points inward toward delivery. The other points outward toward commercial outcomes, renewal rates, expansion revenue, and client health scores that determine whether a business unit hits its quarterly number.

The project manager who excelled at keeping engineering teams unblocked has spent years getting very good at a form of stakeholder management where the power dynamic runs in their favor. Internal teams need the PM. External clients — particularly in enterprise software — do not need the account manager. They tolerate the account manager, and they renew (or don't) based on whether they feel genuinely served. That's a different job.

What Actually Does Transfer — and What Doesn't Survive Contact

None of this means the transition is impossible. Some skills cross the gap cleanly and should be named explicitly.

Risk framing transfers well. A PM who spent three years identifying delivery impediments before they became crises has a practiced instinct for reading early-warning signals in a client relationship — a quieter executive sponsor, a delayed signature, a shift in the questions being asked. Client-facing professionals call this "account health monitoring," and most people who haven't run complex delivery programs have to learn it from scratch. The delivery professional walks in with that muscle already developed.

Structured communication transfers. The discipline of proactive status updates, clarity on what's decided versus what's still open, documentation of what was promised — that's exactly what enterprise clients demand from their account teams, and exactly what undertrained account managers fail to deliver. (It turns out "keeping everyone in the loop" is a rarer skill than anyone advertises.)

Navigating organizational complexity transfers. The Scrum Master who spent two years coaxing a risk-averse middle management layer toward empirical ways of working has, in the process, learned to read org charts, identify real decision-makers behind formal titles, and build influence without formal authority. That's a surprisingly accurate description of what senior account managers do when they're expanding an enterprise footprint.

What doesn't transfer is the mode of listening. In delivery, you listen for blockers — things that prevent the team from moving forward. In client-facing roles, you listen for opportunity, dissatisfaction, and competitive risk simultaneously. The delivery professional's ear is tuned to process friction. The account manager's ear is tuned to something closer to business intelligence. Retuning takes deliberate practice, not just a title change.

The Missing Piece: Commercial Fluency

The transition failure point that rarely gets named is commercial fluency — a comfort with the mechanics of how clients actually buy, renew, and expand. Gross churn, net retention, expansion ARR, time-to-value — these are the metrics that define whether a customer success function is working. Velocity, cycle time, and sprint burndown are not.

The pattern is consistent: the former Scrum Master lands a customer success role, applies excellent process discipline, keeps clients informed, documents everything — and then gets blindsided at a renewal conversation because they've never had to tie their work to revenue language in a room where budget decisions are being made.

The fix is less romantic than "your skills transfer." It involves deliberately seeking out commercial exposure before the transition: co-owning renewal prep cycles with a sales partner, sitting in on QBRs (quarterly business reviews), learning to read a customer's P&L context alongside their product satisfaction score. A Scrum Master who doesn't know what a net revenue retention target is isn't ready for an enterprise CSM role at Salesforce or ServiceNow. A PM who has only ever presented to internal engineering leadership will struggle in front of a procurement committee.

The Counterargument Deserves a Fair Hearing

There is, of course, a version of this that cuts the other way. The project management consultant role involves parachuting into messy situations, quickly assessing what's broken, designing a better way of working across different industries, tech stacks, and cultures — and requires the confidence to challenge clients' assumptions. That description could pass for a portrait of a battle-tested Agile Coach.

And the SaaS customer success world is, frankly, staffed with former account managers who couldn't explain a sprint review if you spotted them three syllables. A delivery professional who brings actual technical credibility, process rigor, and honest relationship instincts into that space isn't starting behind — they're starting with a genuine edge, if they've done the commercial homework.

The question isn't whether the skills are valuable. The question is whether the person carrying them has bothered to understand what the new job actually asks of them, beyond the surface-level similarity of "working with people."

The Honest Verdict

The delivery-to-client-facing career pivot is real, viable, and underexplored. The Scrum Master's facilitation depth, the PM's risk antenna, the Agile Coach's ability to read a room and move organizational energy — these are legitimately valuable in relationship-driven, commercial roles.

But the transition narrative the industry tells — that your soft skills are the bridge and everything else follows naturally — is flattering and incomplete. The bridge exists. It just has a toll that not enough people budget for: learning to care about revenue retention as viscerally as you once cared about sprint velocity, learning to listen for opportunity the way you learned to listen for blockers, and accepting that your new "team" is technically a client who can fire you at renewal.

That reorientation is not a small thing. The delivery professionals who navigate it successfully are the ones who treat it as a substantive skill gap to close — not a formality before the LinkedIn headline update.

Sources

The PMO Didn't Fail Agile. It Failed to Justify Itself.

Javier Castro — Fri, 25 Sep 2026 19:42:47 +0000

The Project Management Office isn't disappearing because agile teams don't need governance — it's disappearing because too many PMOs never learned to do anything except enforce it.

Picture this scene, which plays out with depressing regularity across enterprise IT floors: a product owner finishes a sprint and, before she can breathe, receives an email from the PMO asking her to convert her product backlog into a Gantt chart for the monthly project board. She has no Gantt chart. She has working software, a velocity trend, and a prioritized backlog that's been reviewed with stakeholders.
The PMO gently but firmly asks her to convert it into a Gantt chart anyway. At the next project board, she shows the Gantt chart — and slowly, reliably, her behavior changes.

That single exchange is how traditional PMOs have been quietly suffocating agile delivery for years. Not through dramatic confrontation. Through a thousand small administrative assertions that the old system of record is still the real system of record.

The PMO's identity crisis is real, and the agile community has been wrestling with it for over a decade. But something has shifted. Organizations no longer question whether PMOs are necessary — they question whether PMOs are relevant where it actually matters. The real challenge isn't execution discipline anymore. It's whether the PMO strengthens strategic alignment, improves decision quality, and contributes to outcomes that senior leaders recognize as valuable.

That's a profoundly different conversation from "can we comply with Prince2."

Here's the claim worth sitting with: most PMOs that were dismantled or gutted during agile transformations weren't victims of a methodology war. They were victims of their own inability to articulate value beyond the documentation they produced. The Gantt chart wasn't the problem. The belief that producing the Gantt chart was the job — that was the problem.

The Controlling PMO and Its Natural Enemies

A PMO is a management structure that standardizes project-related governance processes and facilitates sharing resources, tools, methodologies, and techniques. Traditionally, PMOs have focused on governance — ensuring projects remain on track, within budget, and compliant with defined processes. That approach works well in predictable environments.

"Predictable" is doing a lot of work in that sentence. Financial services. Government infrastructure. Large construction programs. There, a directive PMO — one that takes full ownership of projects, directly managing them through assigned project managers, and maintains tight control over methodologies, resources, and execution — makes obvious sense. The requirements don't shift every sprint. The auditors are coming regardless.

Move those same structures into a product organization running continuous delivery cycles, though, and the fit degrades fast. In some enterprises the PMO runs like the "process police." They may seek early reassurances from a coach that all change is negotiable. A PMO will usually be aware of a directive for "agile transformation," and they may see it as their duty to water it down as far as possible. The Scrum.org community has been documenting this dynamic with uncomfortable frankness. The gambit is essentially "embrace, extend, and extinguish." And as custodians of the organization's project management standards, they may genuinely see the preservation of the status quo as the right thing to do.

That "genuinely" matters. These aren't villains. They're people doing exactly the job they were hired for, rewarded for years to do in exactly this way. The dysfunction isn't individual — it's structural.

Three Trajectories, and the One Nobody Wants to Take

When an agile transformation collides with an existing PMO, many organizations are confused about what happens to these people and the office itself. There are three possible trajectories, including the creation of an Agile Practice or Center of Excellence. The fourth option — doing nothing and hoping the tension resolves itself — is, statistically, the most popular choice.

At Dell Technology, Gary Dismukes, then Director of Engineering Project Management, chose the most dramatic path: he eliminated his own job as part of the agile transformation. That's a genuinely rare act of organizational courage. Most PMO directors facing the same circumstances find reasons why their situation is different, why their organization's complexity requires the overhead, why this particular portfolio couldn't survive without central coordination.

Some of them are right, actually. Agile teams won't be garage start-ups free to do their own thing — they're part of a wider enterprise, with obligations towards it. Agile change must happen while the organization is in flight, while it is still delivering value, and without damage to reputation, quality, or stakeholder confidence. A PMO that understands this — that its job is now to protect the transformation rather than protect itself from it — becomes genuinely useful. It takes on a servant-leadership function where Scrum Masters may lack the authority or connections to be effective.

That's the inflection point. Relatively few PMOs successfully cross it.

The VMO Rebranding and What It Reveals

The most telling signal of how thoroughly the ground has shifted is the emergence of the Value Management Office — the VMO. When so many enterprises have the strategic goal of maximizing product value to customers, changing their project management office into a value management office is supposed to help them do it. The widespread adoption of agile methods has driven a shift from a focus on projects to one on products, bringing dramatic changes in how organizations manage and deliver not only IT services but their entire product and service value streams.

SAFe version 6 introduced the VMO explicitly, framing it as replacing the traditional PMO with a product focus rather than a project focus. Reaction in the practitioner community was predictably split. Some welcomed the conceptual shift. Others dismissed it as governance theater with a fresh coat of paint.

The skeptics have a point. Renaming a function doesn't change the instincts of the people running it. A controlling PMO director handed a VMO org chart and a new title will, absent serious deliberate reinvention, run a controlling VMO. The Agile Alliance's thinking on this has grown sharper: enterprises need to bridge the gap between traditional governance structures and true business agility, shifting focus from managing projects or products to delivering measurable value through adaptive governance — where Agile Value Management Offices are not just concepts but institutionalized realities.

That phrase "institutionalized realities" lands with appropriate weight. Most VMOs aren't yet that. They're aspirations dressed as org structures.

What a Legitimately Useful PMO Actually Does

The organizations that have gotten this transition right share a few visible characteristics. At Fannie Mae, the Agile Center of Excellence — functionally the successor to their PMO — pivoted toward an explicitly consulting posture. The Agile COE was leveraged to support, not own, the transformation. It was expected to have firm and impartial footing in both the business and delivery camps of the organization. That's the key word: support, not own. And it paid off in reach — the COE focused on creating and conducting an internal training program for management as well as for teams to establish a shared understanding of the Agile Manifesto. Over the course of 2016, over 4,900 people participated in Agile training.

A Center of Excellence can gather information, lead change, share best practices, and keep people on the same page. Scaled Agile calls this a Lean-Agile Center of Excellence — a small team dedicated to implementing the Lean-Agile way of working. According to Scaled Agile, "creating a LACE is often one of the key differentiators between companies practicing Agile in name only and those fully committed."

The functional difference between this model and the legacy PMO isn't really about templates or methodology. It's about power orientation. A traditional PMO derives authority from compliance — you need its sign-off to proceed. A functioning Agile COE derives authority from expertise — teams seek it out because it makes them better. One is a tollgate; the other is a consultancy. The market for tollgates is shrinking. Fast.

In any management function, including PMO, this transition needs to happen sooner rather than later. In organizations with a well-established project culture and a strong, active PMO, that entity should become one of the change agents and advocates of evolution. That's the Scrum.org line, and it's the right one — though it implicitly acknowledges that this usually doesn't happen.

The Legitimate Counterargument

To be fair to the PMO traditionalists: full abolition of centralized governance is also a failure mode, and a less discussed one. It's not just a matter of running projects at an operational level and making sure they deliver on schedule. It's about ensuring alignment with corporate standards so risk is controlled — and evidenced. At scale, executives can't manage all of this by themselves.

In organizations with genuine regulatory exposure — banking, healthcare, critical infrastructure — agile teams that route around governance don't eliminate risk. They relocate it. And when the auditors arrive, someone needs to have the paper trail. Traditional models of how projects, portfolios, and organizations are governed represent thinking that originated in the 1890s, and they remain remarkably impervious to change. Some of that persistence reflects institutional capture. Some of it reflects the inconvenient fact that certain problems don't actually get easier to manage without coordination.

The product-to-project shift also creates new coordination risks that don't get enough attention. In organizations following a product operating model, each product operates in an iterative agile fashion, but integration across them looks more like traditional big-batch waterfall. People can interpret the product operating model as a divide-and-conquer mechanism, which works fine when focusing on individual product goals but can lead to disaster when tackling integrative work. Someone needs to manage that seam. When there's no functioning PMO, it often doesn't get managed at all — until it becomes a production incident.

The Real Test

The PMO's survival isn't a philosophical question about whether governance and agility can coexist. They obviously can. The question is narrower and more uncomfortable: can this particular PMO, staffed with people who built careers on compliance enforcement, reinvent itself as a source of delivery intelligence and organizational coaching that teams actually want to engage with?

That's the test. And the honest read of the evidence is that most PMOs are still studying for it rather than passing it.

The ones that survive won't look like the ones that got built. They'll be smaller, more senior, more genuinely expert, and completely uninterested in the Gantt chart. The ones that don't survive will spend their final months arguing that the Gantt chart was actually the point.

Sources

Hybrid Delivery Isn't a Compromise. It's the Strategy You Were Pretending Wasn't Happening.

Javier Castro — Thu, 17 Sep 2026 00:42:43 +0000

The "Agile vs. Waterfall" debate died somewhere between the third SAFe rollout and the second audit finding — and most teams quietly moved on without telling the coaches.

Picture a mid-sized financial services firm in 2024. The delivery teams run two-week sprints. The backlogs are groomed. The standups start at 9 a.m. sharp. And yet, every six months, the whole program freezes while executives wait for a steering committee sign-off baked into a gate review that was designed in 2009. Nobody calls this a contradiction. They call it "how we work here."

That's not confusion. That's a hybrid delivery model. And it's becoming the dominant organizational reality — not as a failure to commit to Agile, but as a deliberate, if often unacknowledged, operating choice.

Hybrid is now the normal mode for Agile ways of working. Enterprises use home-grown frameworks or something inspired by an industry-standard one, with some still maintaining traditional PMO teams that would look perfectly familiar to a project manager from 2003. The provocative claim worth arguing: the rise of hybrid delivery models isn't a sign that organizations lack Agile courage — it's evidence that pure Agile ideology was always underselling what large, regulated, multi-stakeholder organizations actually need to govern. The Agile community has treated hybrids as a dirty word for too long, and that posture has made the conversation less honest, not more useful.

The Ideology Problem

The Agile Manifesto was written by seventeen software developers at a Utah ski resort in 2001. Smart people. Important document. But it was written for teams, not enterprises — and that distinction has been causing damage ever since.

The core management controls of most large enterprises — governance, planning, prioritization — are still wired for certainty and prediction, not adaptability. Until those controls are reframed, Agile stays stuck in pockets of the organization, never fully connected to strategy or outcomes. Pure-Agile advocates have consistently underestimated this structural mismatch. Their solution: more certifications, more ceremonies. Their puzzlement: why didn't the org chart move?

"Agile" now means anything, everything, and nothing — and many organizations are Agile fatigued, with the "Agile Industrial Complex" doing its fair share of the damage. Martin Fowler, one of the original Manifesto signatories, put the issue plainly: the challenge now is "dealing with faux (fake) Agile." Consultants who treat Agile as a collection of processes rather than a culture shape transformation around the "how" — turning it into a linear, step-by-step change program, which is a fairly ironic thing to do with a philosophy built around adaptability.

The result is organizations that hold retrospectives but can't change a release date without board approval.

What Hybrid Actually Looks Like in Practice

Hybrid methodologies represent a mature evolution rather than a transitional phase. As organizations scaled Agile beyond small teams, limitations became evident — Agile's neglect of documentation and challenges in managing physical product iterations hindered long-term maintenance and compliance, which is how you end up needing a hybrid whether you wanted one or not.

The specific patterns are worth naming. Water-Scrum-Fall, for instance, segments projects into planning using Waterfall, iterative development through Scrum, and delivery through Waterfall phases — retaining flexibility while adding structure. This pattern is widely mocked in Agile coaching circles. It also describes how a substantial portion of enterprise software actually ships. Around 20% of organizations are now formally blending Agile and plan-driven methods to address scalability, complexity, and organizational policy alignment — and that's just the ones willing to say so out loud.

In regulated industries, the hybrid isn't optional. It's legally and operationally mandated. Security standards often require defined processes to analyze and mitigate vulnerabilities, whereas lean and Agile methodologies aim to avoid rigid linear processes. That tension doesn't get resolved with a manifesto principle. Siemens addressed it by developing S2C-SAFe — an extension of the Scaled Agile Framework built to satisfy the IEC 62443-4-1 security standard — because complexity in strongly regulated industries increases not only when scaling Agile practices but also when aiming for compliance with security standards.

People unfamiliar with regulated environments quickly dismiss the need for code review artifacts, requirement documents, and specifications. To file a product in compliance with FDA and ISO requirements, those artifacts are non-negotiable. The Agile Manifesto's preference for "working software over comprehensive documentation" made any documentation feel like an annoyance. That tension doesn't resolve with more training. It resolves with a delivery model that holds both realities at once.

The Stage-Gate Comeback Nobody Officially Announced

Stage-gate processes were supposed to be dead. In the 2010s, they became shorthand for everything Agile was rebelling against — bureaucratic checkpoints, phase-locked planning, executive tollgates that introduced months of latency. They're back. And in sophisticated company.

Cooper's Stage-Gate methodology, adopted by 75% of North American product developers by 2000, demonstrated that structuring work into sequential stages with evaluation gates reduced time-to-market while improving output quality. Cooper later extended the methodology to agile-stage-gate hybrids, showing that the core principle — structured stages with decision gates — held up even as execution methods evolved.

Being product-oriented and iterative doesn't preclude the use of stage gates. Practitioners at pharma firms, hardware manufacturers, and financial regulators have been working with this insight for years while the methodology debate raged elsewhere. A hybrid approach combining Stage-Gate and Agile serves both hardware and software activities, though the need for synchronized delivery schedules between hardware and software isn't well addressed by Agile methods, which don't emphasize forward planning. Conversely, the uncertainty in defining software scope challenges the up-front scope definition that Stage-Gate relies on. Neither ideology won. They converged because neither was complete.

The Fair Counterargument

Here's where the honest version of this argument has to make room for dissent. Critics of hybrid models — and there are serious ones — point out that hybridization frequently becomes a cover story for organizations that never genuinely committed to Agile principles in the first place.

Agile practices are widespread, certifications abound, and yet many organizations are experiencing more control with less learning, and growing fatigue rather than adaptability. A governance gate layered on top of Scrum ceremonies isn't a hybrid model — it's Waterfall with better vocabulary. What's actually needed is making decision-making, rules, measures, and value explicit. Agility breaks down not because of governance, but because its purpose and value are poorly understood.

That's a sharp distinction. A hybrid model works when the governance layer genuinely serves the delivery — when compliance checkpoints generate audit artifacts as a natural byproduct of the work, not as additional reporting burden dumped on teams afterward. It breaks when organizations use "hybrid" as justification for command-and-control structures that were never going to change anyway.

Org-wide Agile mandates don't always produce business impact, leaving teams to operate in a discordant manner because of the underlying system complexity. Throwing a hybrid label at that discordance doesn't fix it. Only honest diagnosis does.

Hybrid models address enterprise coordination, compliance, and documentation needs while retaining Agile's iterative feedback and engagement benefits. But successful implementation requires overcoming cultural resistance, coordination complexity, and skill gaps. Leadership buy-in, cross-functional training, and context-specific adaptation aren't optional extras — they're the whole job.

Governance as Delivery Infrastructure

The most mature teams operating in hybrid models have stopped treating governance as the enemy of speed. They've recast it as delivery infrastructure — same category as CI/CD pipelines or test automation.

One of the biggest misconceptions is the belief that governance slows teams down. Lack of governance is usually what slows organizations down the most. That's counterintuitive until you've watched a team ship fast into a regulatory audit and spend three months in remediation because nobody captured the required traceability artifacts during development. Speed without governance doesn't produce agility — it produces rework.

The PMP certification, traditionally associated with waterfall methodologies, now includes Agile project management concepts. PMP-certified professionals are expected to understand both predictive and adaptive approaches — the latest exam covers Agile frameworks, hybrid models, and the ability to choose the right methodology for a given project. That's not a concession by the certification industry. It's a recognition that practitioners who need to function inside real organizations need a bigger tool belt than any single methodology provides.

The organizations that finally crack delivery at scale aren't those that double down on ceremonies or tooling. They're the ones that reimagine governance as a bridge between the executive table and delivery teams.

Where This Leaves the Debate

The question isn't whether hybrid delivery is intellectually coherent — it clearly is, and the evidence is accumulating across sectors from pharmaceutical manufacturing to defense contracting to financial services. The more uncomfortable question is whether the Agile community is going to keep treating hybrids as a failure mode, or finally acknowledge them as an architecture choice.

Hybrid methodologies emerge from Agile's limitations in large-scale and regulated environments, combining iterative flexibility with structured governance. Success depends on leadership support, tailored process integration, and continuous improvement. That's not a description of retreat. It's a description of organizational realism.

The teams most worth watching right now aren't the ones flying the pure-Agile flag or the ones who never left their Gantt charts. They're the ones that have stopped having the ideology argument and started designing delivery systems around their actual constraints — budget cycles, regulatory calendars, vendor dependencies, and the stubborn reality of org charts that weren't designed by the Manifesto's authors.

Hybrid isn't giving up on Agile. It's growing up past the part where the framework was supposed to solve the politics.

Sources

The Standup Is Now Automated. The Team Is Slowly Forgetting How to Think Together.

Javier Castro — Tue, 15 Sep 2026 18:37:27 +0000

AI has not broken Agile — it has revealed that most teams were using ceremonies as a substitute for actual collaboration, and now that the substitute has been automated away, there's nothing left beneath it.

Picture a sprint planning session at a mid-sized SaaS company, sometime in early 2026. Nobody is playing planning poker. An AI sprint assistant has already analyzed the backlog, grouped the related work, and dropped a suggested sprint plan into Jira before anyone opened their laptop. The standup happened at 8 a.m. — asynchronously, via a bot in Slack that pinged everyone for a status update and compiled the results into a digest. The Scrum Master is on the call, technically, but her main job today is reviewing what the AI said.

This is not a thought experiment.
Atlassian's Jira Summer 2026 release shipped a "Delivery Agent" — a built-in agent designed to handle recurring coordination work, running standup digests and stakeholder status updates without manual effort.
Their AI Sprint Planning Assistant analyzes the backlog, groups related work, and suggests realistic sprint plans that teams can review, adjust, and import directly into Jira.
Meanwhile, tools like Spinach.io sit in the Atlassian Marketplace positioned as your AI Scrum Master, automatically linking Jira tickets mentioned in meetings and suggesting new tickets for anything discussed that doesn't already have one.

Efficiency metrics love this.
Depending on which 2025 survey you read, between 84% and 91% of developers are now using AI tools in their workflows, with sprint planning overhead reportedly down 30–60%.
Those numbers are real. The question nobody is asking loudly enough is: what was happening inside that overhead?

The Ceremony as a Technology Transfer Protocol

Agile ceremonies were never primarily about the artifacts they produced. The standup was not about the status update. The planning session was not about the story points. Both were — at their best — structured pretexts for something harder to schedule: knowledge transfer, trust calibration, and the kind of low-stakes disagreement that prevents high-stakes surprises later.

Consider planning poker specifically. The technique dates to 2002, when James Grenning created it partly to solve what he described as the problem of people in agreement talking too much and dominating estimation. The ritual of simultaneous card reveals was an epistemic forcing function — it surfaced genuine variation in how different people understood the same piece of work.
The wild divergence between a senior developer estimating 2 points and a junior estimating 13 wasn't a failure of the meeting; that gap — and the conversation it forced — was the meeting.
The product owner flagging scope creep concerns, the QA engineer spotting testing challenges nobody else had considered: these are not inefficiencies to be smoothed over. They are the system working.

Involving everyone on the team — developers, designers, testers — is the point, because each member brings a different perspective on the work. When product management proposes something that seems simple, development and QA need to weigh in, because experience has taught them what complexity may be lurking beneath the surface.

Now AI tools like SprintPoker and Agile Poker for Jira offer to bypass that friction entirely.
They provide AI-generated complexity insights and historical issue matching to make sprint decisions faster.
AI highlights risks, dependencies, and suggests effort based on past data — before anyone in the room has had a chance to realize they might disagree with the model's interpretation. Research on GPT2SP-style automated estimation approaches found they can outperform traditional planning poker on raw accuracy metrics across thousands of historical issues. But optimizing for accuracy on past data, on familiar ticket types, against a team's historical velocity — that's precisely the wrong metric. Teams don't fail because they estimated a typical story incorrectly. They fail because something was not a typical story, and nobody realized it in time.

The Code Review Inflation Problem

The standup and estimation changes are concerning. The code review transformation is something else entirely.

The question haunting CTOs and heads of engineering right now is how to deal with large quantities of code review that have been growing as AI agents generate most code at many tech companies. Since late 2025, the era of developers writing code by hand appears to be ending at startups and in Big Tech, with AI agents working faster and generating more pull requests than developers ever did — and the size of those PRs increasing.

The volume numbers at Synthesia are striking enough to make any engineering manager uncomfortable.
As of August 2026, the number of pull requests had risen 120% year-over-year, with 95% of those requests containing AI-generated code.
And the response to this avalanche of AI-generated code is — more AI.
The most common approach is to add an AI code review step to every pull request, with dozens of vendors now offering this functionality — CodeRabbit, Gitar, Greptile, GitHub Copilot Code Review, Qodo, Claude Code Review, Ellipsis — and bots leaving comments for developers to parse.

There is something almost poetic about this. AI generates code, AI reviews the code, and a human somewhere in the middle is theoretically validating the exchange. In practice,
qualitative studies indicate that AI feedback can reduce social friction but introduces additional cognitive load related to validating AI suggestions, with developers tending to treat AI comments as advisory rather than authoritative, selectively integrating them based on context and trust.
Which sounds reasonable, until you consider the volume.
Over a recent period, the number of PRs opened has increased fivefold, with growth speeding up markedly from late 2025 when PRs and commits nearly doubled in a short stretch alone.
You cannot selectively integrate 120% more review comments with the same cognitive bandwidth you had before. Something gets skimmed. Synthesia's own CTO said as much: "I don't know if we ever get to the point where you can truly trust the agentic generation of code."

What Gets Structurally Lost

Here is the uncomfortable thing that Scrum.org is willing to say plainly, even if most vendors won't: the biggest threat is not that AI replaces Agile practitioners. It is that AI reveals what many organizations suspected — they never needed Agile practitioners. They needed someone to manage Jira.

That observation is sharper than it sounds, and it cuts in both directions. If a Scrum Master's job was primarily ceremony administration and burndown chart generation, then yes, automation exposes that. But the organizations getting into trouble right now are the ones that had real Agile practice — collaborative estimation, genuine retrospectives, code reviews as mentorship vehicles — and are now automating those practices at the surface level while telling themselves the value is preserved.

The deeper danger in replacing humans with AI in these processes is the erosion of organizational capability — not just task completion, but the ability to diagnose novel failures, interpret ambiguous signals, understand system history, and adapt under pressure. These capabilities emerge through sustained human participation, not merely through the presence of functional artifacts. This is where capability debt becomes visible: immediate output is maintained by borrowing against future human understanding.

A controlled three-condition experiment at a mid-sized digital agency, comparing AI-only, human-only, and hybrid sprint planning, recently underscored exactly this risk.
Longitudinal studies are needed to measure whether continuous AI-assisted planning produces deskilling effects in junior developers — if estimation and risk identification are permanently offloaded, the capacity to evaluate AI outputs may gradually erode, creating a dangerous dependency loop.
A three-sprint window cannot detect that erosion. It takes a couple of years, a team turnover cycle, a novel technical challenge — and then suddenly nobody remembers how to have the disagreement that saves the project.

Mechanical Scrum, standups without tangible purpose, estimation rituals that pretend to forecast the future, Jira-as-performance-art — teams normalized Agile as a checklist.
That pre-existing failure mode is real, and AI exposing it is arguably useful. But the answer to ceremony-as-theater is not automated ceremony. It is teams that actually use the space those ceremonies create.

Psychological safety is associated with the behaviors required in AI-mediated work: surfacing errors, questioning model outputs, and iterating processes. These behaviors enable continuous correction rather than brittle optimization.
You do not build that psychological safety by removing the friction-generating moments from your sprint cycle. You build it precisely inside those moments — when the junior engineer's 13-point estimate makes the room go quiet, and someone has to ask why.

The Counterargument, Given Its Due

The optimistic case for AI-assisted ceremonies is not nothing.
Generative AI addresses problems that Agile practitioners already experience daily — analyzing and categorizing vast amounts of customer feedback, identifying patterns across retrospectives, and detecting market shifts buried in noise.
If AI can surface that a team has had the same blocker in four consecutive retros and nobody connected the pattern, that is genuinely valuable. A standup digest that rescues fifteen minutes from a distributed team's morning is a real win.
The optimal human-AI collaboration works as a cognitive scaffold rather than a division of labor, producing risk identification that exceeds either baseline in isolation.

The research from a Procter & Gamble study of 776 professionals, cited by Scrum.org's Agile AI Manifesto, found that when AI removes information processing burden,
humans focus more effectively on relationship work, and teams using AI for customer analysis have richer conversations, not fewer.
That possibility is real. The question is what counts as information processing burden versus what counts as the actual work.

Research suggests roughly 30–40% of tasks within Agile ceremonies could be potentially automated, increasing team efficiency.
That leaves 60–70% that cannot — and that unremarkable majority is where teams actually produce or fail to produce the shared understanding that makes software delivery work.

The Agile Manifesto's first value — individuals and interactions over processes and tools — was not a statement about efficiency. It was a statement about where the work actually happens. Automating the standup digest is not automating the standup. Automating the sprint plan is not automating the alignment. And when those ceremonies have been stripped to their minimum viable ceremony, the organization that discovers it has a coordination problem will have also lost the muscle memory for fixing one.

The smarter teams are not asking whether AI can run their ceremonies. They are asking which parts of their ceremonies are ceremonies and which parts are the actual product. That distinction is harder to answer than any sprint planning algorithm, and no model is going to surface it for you.

Sources

Your AI Adoption Strategy Is Solving the Wrong Problem

Javier Castro — Mon, 14 Sep 2026 13:09:37 +0000

Companies keep optimizing the part of software delivery that was already working — writing code — while the organizational dysfunction that surrounds it grinds every AI-generated efficiency gain back to zero.

Picture a reasonably typical Q1 planning cycle at a mid-size software company, circa right now. The CTO has returned from a conference with a crisp mandate: the organization is going "AI-first." Copilot licenses go out to every engineer within the month. A transformation deck circulates — complete with a 3x productivity multiplier and a timeline that implies shipping will roughly double by Q3. The engineering leads nod in the right meetings. And then the sprint starts, and nothing meaningful changes.

This is not a technology failure. It's a category error.

The dominant corporate narrative around AI adoption runs on a seductive but flawed premise: software delivery is slow because code takes too long to write. Fix the writing, fix the throughput. It's a clean story that maps perfectly onto a Copilot demo, a sales deck, or a board update. The only problem is that experienced practitioners have known for years that writing the code is rarely the bottleneck. And now, finally, there's enough field data to say so plainly.

The Strategy Deck vs. The Standup

For much of the past two years, the conversation about AI in software engineering has been dominated by throughput metrics — lines of code written, pull requests opened, features prototyped — even though more code is not the same as more delivered software.

The CircleCI 2026 State of Software Delivery Report, analyzed by Thoughtworks, gives this abstraction a hard edge. Even top-10% teams, those running 47% more workflows overall, achieved essentially flat main-branch activity. Feature branch throughput surged by nearly 50%, but almost none of it translated into shipped changes. For the median team, the picture is starker: a 15% increase in feature-branch activity alongside a 7% decline on the main branch.

More activity. Less software reaching users. The strategy deck predicted the opposite.

The 2025 DORA Report found something similar: in a study of roughly 5,000 technology professionals, individual effectiveness went up at the top, but software delivery throughput did not meaningfully change. Their analysis suggests the bottleneck lies not inside the developer's editor but in the systems and processes surrounding that editor — processes that AI tooling doesn't touch.

This is the uncomfortable truth that sits underneath all the transformation decks: AI makes the fast part of software delivery faster. The fast part — actually writing code — already occupied only a fraction of an engineer's day. Developers spend around 16% of their time actually coding. Organizations have invested heavily in accelerating that 16% while leaving the other 84% largely untouched.

The Perception Gap Has Its Own Data

In July 2025, METR, an AI safety research nonprofit, published results from a randomized controlled trial with experienced open-source developers completing real tasks in mature codebases. Before starting tasks, developers forecast that allowing AI would reduce completion time by 24%. After completing the study, they estimated it had reduced time by 20%. What actually happened: AI tooling slowed developers down by 19%.

That gap — between what developers felt was happening and what the clock recorded — is worth sitting with. The slowdown came from time spent prompting, reviewing AI-generated suggestions, and integrating outputs with complex codebases. Through 140+ hours of screen recordings, researchers identified five key contributors to the slowdown — frictions that likely offset any up-front gains from code generation.

The METR researchers were careful not to over-generalize, and the study population was small. Improvements in prompting techniques, agent scaffolding, or domain-specific fine-tuning could unlock real productivity gains. The authors frame their findings as a data point in a fast-evolving landscape that still requires rigorous evaluation. Fair enough. But notice what the study's subjects were doing: they felt faster while being slower. That perception gap is exactly the kind of signal that gets laundered into a "3x productivity" slide.

The coding-specific productivity picture is mixed in other ways, too. A 2025 State of Software Delivery Report by Harness found that 67% of developers spent more time debugging AI-generated code, and 68% spent more time fixing AI-created security issues. Meanwhile, the number-one frustration among developers in the 2025 Stack Overflow survey — cited by 45% of respondents — was dealing with AI solutions that are "almost right, but not quite," and 66% say they are now spending more time fixing that almost-right code.

The Organizational Friction Nobody Wants to Put in the Deck

Here is where the strategy gap becomes genuinely structural rather than just technological. While more development teams perceive they're gaining time from AI, they're also reporting greater organizational inefficiencies than before. That's not a contradiction — it's what happens when you accelerate one part of a constrained system.

Atlassian's 2025 State of Developer Experience report, drawn from 3,500 developers and managers across six countries, makes the underlying tension explicit. Half of developers report losing 10 or more hours per week to non-coding tasks driven by poor information access, fragmented tools, and constant context switching. AI coding assistants don't fix any of that. And the leaders making the tooling decisions appear increasingly disconnected from this reality. 63% of developers now say leaders don't understand their pain points, up sharply from 44% last year — likely because leaders are banking time savings achieved through AI without addressing existing points of friction.

The friction isn't just interpersonal. The proliferation of GenAI tools presents teams with a paradox of choice: new capabilities arrive continuously, but the abundance of disconnected, overlapping, non-interoperable tools has produced a fragmented ecosystem that imposes its own cognitive load. At the XP2025 workshop on AI and Agile development, practitioners were asked to name their biggest frustrations. "Too many tools, unclear which to use" was the most-voted challenge, cited by 73.3% of participants. The cure has become part of the disease.

Individual developers and organizations benefit from AI-generated content, but the cumulative effect degrades shared resources: codebases accumulate technical debt, knowledge resources become polluted, reviewer capacity is exhausted, and the trust that collaborative development depends on erodes. The structural forces behind this include gameable metrics, corporate speed mandates, and reduced developer agency.

The Measurement Problem Nobody Wants to Name

Many engineering leaders are making big decisions about AI tools without really knowing what works and what doesn't. According to LeadDev's 2025 AI Impact Report from 880 engineering leaders, 60% of leaders cited a lack of clear metrics as their biggest AI challenge. And the metrics that are being used are frequently the wrong ones. Lines of code generated, acceptance rates, tokens consumed — easy to count, nearly meaningless as delivery indicators.

"Many organizations don't know whether they're being more productive than they actually are because they're not measuring accurately." That's from a Thoughtworks practitioner discussing the 2026 CircleCI report, but it could describe almost any large engineering organization right now. Companies are reporting AI "wins" against metrics that were always weak proxies for delivery performance, and nobody in the transformation program has a strong incentive to point that out.

The irony is sharp: Stack Overflow's 2025 developer survey found that more than 84% of developers were using or planning to use AI tools. But trust in those tools dropped sharply — only 29% of 2025 respondents said they trust AI, down 11 percentage points from 2024. In technology adoption, familiarity usually builds confidence. With AI coding tools, the opposite is happening: the more developers use them on real, messy, production-grade codebases, the more skeptical they become.

Where the Gains Are Actually Real

This is not an argument that AI tooling delivers nothing on engineering teams. That would be wrong, and the counterargument deserves a serious hearing.

There are organizations where meaningful gains have materialized — and the pattern among them is instructive. The teams absorbing AI-driven acceleration are the ones with mature platform engineering practices: self-service infrastructure, standardized deployment pipelines, automated quality gates, and built-in observability. They were already good at delivery. AI made them better.

The productivity gains at the individual level are real for specific task types. Almost all developers (99%) now report some time savings using AI tools, with 68% saving more than 10 hours a week. But those hours need somewhere to go. If they flow back into the same meeting-heavy, context-switching, information-hunting organizational model, they dissolve. AI has drastically accelerated code generation and prototyping, but that speed only exposes and amplifies existing bottlenecks in deployment and organizational processes. Code can be written in minutes; in large organizations, deployment can still take months.

The other genuine advantage has been at the junior end of the experience spectrum. Research consistently finds that AI tools disproportionately benefit less experienced developers, compressing the performance gap between new and senior engineers. That's a real organizational win — but it requires senior engineers to have headroom to review, mentor, and catch the downstream quality issues that AI generation tends to produce. That headroom is exactly what gets squeezed when leadership declares AI a force multiplier and quietly reduces team headcount to match.

The Question That Doesn't Appear in the Deck

The InfoQ Culture and Methods Trends Report for 2026 invoked a pointed warning from agile pioneer Jim Highsmith, quoted during a panel discussion: "If you failed at agile, you will fail catastrophically at AI." It sounds like hyperbole until you consider what it actually describes. Many organizations still haven't embedded the fundamental principles of agile development in their ways of working, and are now layering AI-generated speed on top of that missing foundation.

This is the claim worth sitting with: the organizations most aggressively branding themselves as AI-first are often the same organizations that never resolved the deeper delivery dysfunctions that have been documented in DORA reports for years. They are using AI to run faster on the same broken track. Recent research reveals that nearly 95% of GenAI pilots currently fail to deliver meaningful results due to strategy and integration gaps — not because the models are bad, but because the organizational infrastructure to absorb the output doesn't exist.

The gap between the AI strategy deck and what actually ships is not a technology problem. It's an organizational design problem wearing a technology costume. No amount of Copilot licenses, agent deployments, or sprint velocity reporting changes that. What changes it is doing the slower, harder, less photogenic work: fixing deployment pipelines, reducing cross-team dependency latency, giving engineers fewer tools and more clarity, and — inconveniently — measuring outcomes that actually reflect user value rather than repository activity.

The good news is that AI genuinely helps organizations that have already done that work. The uncomfortable corollary is that for organizations that haven't, the AI investment may just be making the existing problems arrive faster.

Sources

The Account Manager Isn't Broken. The Job Description Is.

Javier Castro — Mon, 14 Sep 2026 13:09:09 +0000

Most SaaS companies claim to have fixed their churn problem by building a customer success function. What they actually did was create a second sales team, give it a different name, and call it retention strategy.

Picture this: a mid-market account manager at a B2B SaaS company sits down in January with a book of 40 accounts. Her job title says "Account Manager." Her comp plan says "renewal rate" and "net revenue retention." Her manager's weekly readout focuses almost entirely on at-risk pipeline. By March, she has quietly become a reactive firefighter — chasing down unhappy customers 60 days before contract end dates, armed with a discount playbook and a Gainsight health score that was last updated sometime in Q4.

This is the quiet dysfunction sitting at the center of modern account management. Not the technology, not the headcount, not the market — the job itself. The role that was supposed to be the steady, relationship-oriented counterweight to new logo pressure has instead been rebuilt, metric by metric, into something much closer to a last-minute sales closer. And the industry's response — more tooling, sharper dashboards, smarter churn prediction — keeps treating the symptom while the structural disease goes unexamined.

Retention Became the New Growth, Then Got Mismanaged

The pivot toward retention as a core business driver was not irrational. In SaaS, customer acquisition costs kept climbing while retention emerged as the primary determinant of long-term profitability. When growth-at-all-costs hit its ceiling around 2022 — interest rates rising, VC funding contracting, IPO windows shutting — the existing customer base stopped being a nice-to-have and became the actual business. Strong retention signals product-market fit. It also makes the unit economics work. These things stopped being talking points and started being survival requirements.

Investors started demanding it explicitly. For most SaaS companies, net revenue retention became one of the four metrics on the front page of any board presentation, alongside bookings, gross retention, and cash burn. The message was clear: in B2B SaaS, NRR near or over 100% is table stakes, and over 41% of SaaS businesses with an ARPA above $500/month hit that mark.

For best-in-class midmarket and enterprise players, NRR in the 115% to 125% range became the benchmark. The math is seductive: expand existing accounts fast enough and you can offset acquisition slowdowns without hiring another sales rep.

What followed was entirely predictable. Companies built out customer success teams, rebranded account managers, installed health-score dashboards, and declared victory. The problem is that declaring a retention focus and actually executing one are two different things. The gap between them falls squarely on the account manager.

The Tool Stack Grew. The Clarity Did Not.

The customer success software market has become genuinely crowded. Gainsight, which effectively created the category, exited at $1.1 billion in 2020. Totango and Catalyst merged in early 2024 to challenge Gainsight's market leadership — notably, no money changed hands; it was a pure combination-of-strengths play. Vitally raised a Series B from HubSpot's venture arm. Smaller entrants keep appearing.

And yet, despite the proliferation of platforms, the fundamental complaint from practitioners has barely changed. The current generation of customer success tools is criticized for lacking critical project management and product reporting capabilities, while failing to integrate with essential customer data spread across the rest of the tech stack. The result: businesses are forced to either manage work inside a platform not built for productivity, or run customer data and daily activity through separate systems that don't talk to each other.

At LinkedIn, the internal solution was building an Account Prioritizer — a data product that predicts upsell opportunities and churn risks across products, freeing account directors to execute sales strategies rather than spend their days crunching numbers. The old approach had account directors burning hours on data analysis instead of actual selling. That is a fair and honest description of what the tooling gap actually costs — not strategic sophistication, but time. Time that should be spent with customers instead gets spent inside CRM fields and spreadsheet exports.

The irony is that better churn prediction tempts organizations to operationalize renewal management as a purely reactive process: wait for the red signal, then deploy the account manager. But product usage and delivered ROI remain the most significant factors in whether a customer expands or stays — outcomes shaped months before any renewal conversation begins. A health score at 90 days out is not early warning. It's a late-stage symptom report.

The Job Description Is the Bug

Here is the central problem, stated plainly: account management in most SaaS organizations has been designed to solve for the moment of renewal, not for the conditions that make renewal inevitable.

The best companies recognize that while they are selling technology, renewal decisions are driven by people — and enterprise-focused organizations need to know who the executive sponsor is and move quickly if that sponsor leaves. This is wisdom that sounds obvious in a conference talk and then quietly disappears when quota letters go out in January.

Consider the structural pressure: moving new business, retention, and account management under a single CRO makes sense in theory — why bother acquiring customers if you can't keep them — but it also means retention targets compete directly with acquisition targets for priority and resources. In a down quarter, the new logo usually wins the attention and the budget. The new logo doesn't exist yet to complain about being neglected.

Top-performing enterprise-focused companies invest more FTEs in customer success to drive down gross churn; the best SMB-focused companies deliberately go the other direction, leaning on technology and self-service instead. The lesson — that enterprise relationship management requires genuine human investment — gets quietly buried when CFOs run headcount ratios against ARR and decide the account management team looks oversized.

What does an account manager actually need to do the job well? Deep product knowledge, enough time to understand the customer's actual business outcomes, a real connection to the product roadmap, and organizational authority to escalate problems before they become contract risks. What they usually have instead is a Salesforce dashboard, a QBR deck template, and a comp plan that pays identically whether the renewal closes on day one of the quarter or day 90. Because either way, it's a renewal.

The Fair Counterargument

It is worth taking seriously the argument that tooling consolidation and measurement rigor have genuinely improved things. Platforms like Totango have enabled companies to proactively detect and resolve churn risks — with reported outcomes of 23-plus points of churn reduction and significant expansion revenue growth. That is not nothing. Companies that treated retention as an afterthought in 2019 are now measuring it properly, flagging at-risk accounts earlier, and building dedicated playbooks.

The broader economic slowdown made customer success teams more essential than ever for preserving revenue, while simultaneously requiring them to do it with fewer resources. Doing more with less has forced some genuine creativity: tighter customer segmentation, better usage-triggered outreach, clearer ROI reporting that gives customers a reason to renew before anyone picks up the phone.

And the churn data does show that intentional retention investment matters. Top-quartile SaaS companies maintain a quick ratio above 4x even after reaching $100 million ARR — meaning for every dollar of lost ARR, they add four in recurring revenue. That gap between top quartile and average does not close by accident. It closes through operational discipline that account management teams, when properly resourced and structured, can actually deliver.

What the Role Actually Needs to Become

The account manager of the next few years will not be defined by how well they read a health score. A strong customer success organization cannot operate in isolation — it becomes the company's learning engine, relaying what's actually happening in the field back to sales, product, and marketing teams. That function — translating customer reality into product decisions, identifying structural gaps before they become churn events, acting as a genuine business advisor rather than a check-in calendar — is what justifies the headcount.

Signing new SaaS customers has become meaningfully harder unless vendors can demonstrate high, measurable ROI with rapid time to value. The account manager who can articulate that ROI narrative clearly — not just repeat what the marketing deck says, but map product usage to actual customer outcomes in the customer's own language — will retain the accounts that matter. The one who is mostly processing renewal paperwork and sending "just checking in" emails will get exposed by the next budget review, long before any technology does the exposing.

The real structural fix is simpler and harder than any dashboard: give account managers smaller books, earlier involvement in product decisions, and compensation structures that reward long-term expansion rather than just keeping logos from churning. Focusing seriously on net revenue retention requires a companywide mentality shift — including investing more heavily in existing customers than in new business. Most companies talk about that shift. Relatively few org charts reflect it.

The account manager is not failing. The job as currently designed is simply not set up to succeed at what it claims to be doing. Fix the job before you buy another platform to compensate for it.

Whether that argument lands depends entirely on whether your leadership team genuinely believes retention is a product problem, a relationship problem, or a metrics problem. Most boards will tell you it's all three. Which one they're actually funding? Look at the headcount plan, not the strategy deck.