|
Sr. Content Developer at Microsoft, working remotely in PA, TechBash conference organizer, former Microsoft MVP, Husband, Dad and Geek.
|
One of the most interesting projects my colleagues have done with LLMs has been building a system with Bayer to allow pharmaceutical researchers to query decades of information about studies buried in PDF reports. Sarang Sanjay Kulkarni describes its evolution from keyword-based search to an intelligent research assistant capable of answering complex questions and drafting regulatory documents.
When transformation isn’t producing results, the first instinct is to look at delivery. Teams aren’t shipping fast enough. The backlog is bloated. The release cadence is inconsistent. The organization reaches for the familiar remedies: new frameworks, better ceremonies, more alignment meetings. Sometimes this helps at the margin. The underlying problem persists.
Look closer, and the diagnosis shifts. Product teams aren’t unclear because they’re undisciplined. They’re unclear because the direction they’ve been given isn’t defined precisely enough to act on. Priorities change without notice. Investment decisions made last quarter are quietly re-litigated this quarter. Teams spend a disproportionate amount of time trying to understand what they’re supposed to be building and why — and not enough time building it.
Go deeper still, and the real constraint comes into focus. The connection between the strategy Executives have articulated and the execution happening in teams is broken. Not because the strategy is wrong, and not because the teams lack capability. Because the system connecting those layers, the governance that should be shaping how decisions are made, at what altitude, with what information, hasn’t been designed. Ambiguity that arrives from above is transmitted downward unchanged. Decisions that should be resolved at the Portfolio layer are escalated or deferred. The organization mistakes motion for direction, and remains, despite genuine effort, largely unchanged.
Nobody intended this. The system produced it.
The four layers of an organization (Executives, Portfolio, Product, and Delivery) are not a reporting hierarchy. They are a system for making and sustaining decisions at different altitudes. Executives own the investment thesis: where are we committing capital and capability, and why? Portfolio translates that thesis into an explicit strategy. A defined set of outcomes, expressed as bets, with measures that make progress visible. Product owns the solution space. Determining what is worth building and why, grounded in evidence from the market. Delivery produces working solutions that test the assumptions underneath those decisions.
What makes this system function is not the existence of these layers. It is governance, deliberately designed, that connects them: the defined decision rights, the evidence flows between layers, the forums where direction is set and updated, and the transparency that ensures every layer is navigating by the same version of reality.
When that system works, value is realized quickly. The path from investment commitment to measurable outcome is short, visible, and actively managed. Disagreement produces better decisions rather than circular conversations. Each layer moves with confidence because it knows what it is accountable for and what the layer above and below it is accountable for.
When governance isn’t designed, or has been left to form by habit, the system seizes. Strategy stays aspirational. Discovery stays disconnected from investment. Delivery stays busy without direction. And the cost accumulates invisibly across quarters, in work that ships without compounding into capability and in investment that continues to flow without evidence that it is working.
Most organizations design their governance as a reporting structure that presents to whom, which forums exist, and for which updates. That is the wrong starting point. Governance defines how decisions work: who owns what decision, at what altitude, with what information, and what the system does when the evidence shifts.
Each layer has distinct decision rights. Executives own the investment thesis. Portfolio owns the strategy. The translation of that thesis into explicit, testable bets. Product owns the solution space, determining what is worth building based on market evidence. Delivery owns execution. Building, testing, and learning at a cadence that surfaces results before the budget is spent.
When these rights are clear and the interfaces between layers are designed, the system can move. When they blur, when Executives are making product decisions, when Portfolio is managing delivery detail, when teams are left to infer a strategy that was never made explicit, the system seizes at exactly the points where it should flow.
Good governance doesn’t just define who decides. It defines the quality of information each layer operates with, the cadence at which decisions are reviewed, and the mechanism for updating direction when evidence demands it. Without it, every layer defaults to one of two failure modes: over-controlling decisions that belong at a lower altitude, or absorbing ambiguity from above rather than resolving it.
One of the most consequential flows in the system runs upward. And it is the most consistently underdesigned.
Discovery done well is not a product team exploring possibilities. It is a disciplined, objective inquiry into market opportunity and customer reality: what problems exist, what behavior patterns are present, what unmet needs have commercial consequence. The goal is not to generate ideas. It is to produce a clear, factual picture of where value can be created that the business is not currently creating.
That evidence only becomes strategic intelligence when it is filtered through specific business goals. The question is not “what could we build?” It is “given where we want to compete and what we need to achieve, what does the market tell us about the direction worth pursuing?” That framing transforms discovery from a product function into a direct input to the investment thesis, something that Executives and Portfolio teams need to engage with actively, not receive as a slide summary after the fact.
Which means discovery has to happen in full transparency. Not as a report delivered upward once conclusions have been reached, but as a shared process in which every layer, Executives, Portfolio, Product, and Delivery understand the game being played, the hypotheses under test, the evidence being gathered, and what success looks like at each stage. When everyone navigates by the same evidence, re-litigation loses its raw material. Parallel versions of reality cannot survive shared visibility.
The organizations that move quickly do not have unusually decisive individuals. They have systems designed to produce decisions rather than defer them.
A bias to action, designed into governance, means every layer operates with the information it currently has; it defines what success looks like, commits to a timeframe, runs the experiment, and surfaces what it learned. It does not wait for certainty before moving. It creates certainty by moving. Each tranche of investment is contingent on the evidence produced by the previous one, which keeps risk bounded and learning compounding.
For Portfolio, this means claiming the agency to shape the path when direction from above is ambiguous, rather than waiting for permission to materialize. Waiting is not a neutral act. In a system that requires decisions to flow, deferring them is itself a structural choice to transmit confusion downward. For Product, it means committing the most informed hypothesis to a testable bet rather than continuing to discover in the absence of a decision. For Delivery, it means building toward observable outcomes and surfacing evidence on a cadence short enough to influence the next investment decision.
The governance creates the forum where that evidence is integrated. Not a status meeting. A decision meeting where each layer reports what it expected, what happened, and what that means for where investment flows next. The agenda is consistent. The decisions are different every time, because the evidence is always moving.
Consider a mid-sized enterprise software business in the middle of a significant shift in its commercial model. The executive team has concluded that long-term growth depends not on serving every customer’s every request, but on investing deeply in a small number of differentiating capabilities that position the business distinctively in the market. The strategic intent is clear at the top.
Three layers below, the picture looks entirely different. Customer-facing teams are measured on retention and satisfaction scores, so they advocate loudly, and understandably, for features that address the most vocal accounts. Engineering teams, operating largely independently, are making architectural decisions optimized for technical coherence rather than commercial outcome. Product teams are trying to build towards broader customer value, but are pulled constantly toward the most recent escalation. Everyone is working hard. Nobody is working on the same problem.
The absence is governance. There are no explicitly defined decision rights: no clarity on who can commit the product to a customer-specific request, who can decline one, or what the standard is for calculating whether a piece of work is worth doing relative to the business strategy. There is no mechanism for surfacing the cost of misalignment. The accumulated drag of investment flowing toward work that doesn’t compound into the executive team’s stated direction. Teams pull in different directions, not because they are misaligned in their values, but because the system was designed to let them.
The fix is not a new strategy deck. It is how the system is designed. Stable, cross-functional teams where customer knowledge, technical judgment, and commercial accountability are integrated rather than siloed. Change the incentive structure at the point of decision. When the team building the product also owns the customer relationship and is accountable for the commercial outcome, the tension between what an individual customer wants and what the business strategy requires becomes a decision the team has to make explicitly, not a conflict they can refer upward or quietly ignore.
Decision rights, defined at the right altitude, make the cost of misalignment visible. Discovery, done in full transparency rather than within functional boundaries, gives every layer, including Executives, the same objective picture of where the market is moving and which capabilities need to express differently to get there. Portfolio works with Executives to translate that picture into a defined set of bets: explicit outcomes, measurable over a bounded timeframe, funded in tranches contingent on what each previous tranche produced. The governance creates the forum where those bets are reviewed on a consistent agenda. What did we expect, what happened, what do we do next with the investment, and where changing course requires engaging with the evidence, not simply calling a new meeting.
The system does not eliminate tension between customer needs and strategic direction. It forces that tension to be resolved at the right altitude, by the right people, on the basis of shared evidence. That is what makes the disagreement productive rather than circular.
If the transformation is moving more slowly than it should, the diagnostic is rarely about individual teams. It is about the system connecting them.
Decisions get re-litigated when governance doesn’t define who owns them and what evidence settles them. Discovery gets disconnected from strategy when product teams explore in one direction while executives invest in another because the system was never designed to make those two things visible to each other at the same time. Portfolio decisions stall when the agency to shape the path hasn’t been claimed, and Product and Delivery teams slow down when they are absorbing ambiguity that should have been resolved one layer above.
The organizations that install durable transformation systems design the system deliberately. The decision rights, the evidence flows, the forums, the cadence, and the transparency that makes it structurally difficult for any layer to operate on a different version of reality than the one everyone is navigating by.
The system does not change itself. Governance does.
This content comes from our product and strategy practice, which specializes in structuring product organizations for clarity, flow, and customer alignment, while linking delivery decisions to enterprise strategy.
Anthropic has hit pause on a billing change affecting developers who use its Claude Agent SDK through a paid subscription — pulling back on the very day it was scheduled to go live.
The announcement comes after a turbulent week for Anthropic. On June 9, the company released Fable 5 and Mythos 5 — its first generally available Mythos-class models, built with hardened cybersecurity guardrails — only for the US government to issue an export control directive days later, forcing Anthropic to pull both models for all customers worldwide.
Now, it seems, Anthropic is looking to bring a little good news to its global user base, by holding off on a billing change that may have cost many developers and third-parties more for their automated Claude usage.
Back in May, Anthropic told subscribers it was splitting its usage allowance in two. Until now, everything a Claude subscriber does — chatting, writing code in the terminal, or using third-party tools built on the Agent SDK — draws from a single monthly pool. From June 15, the company said, Agent SDK usage would move to a separate, capped monthly credit for Pro, Max, Team, and Enterprise subscribers, ranging from $20 for Pro users up to $200 for top-tier Max and Enterprise seats.
For third-party tools like Zed that rely on the Agent SDK to connect users’ Claude subscriptions to their products, the change wasn’t insignificant. In a blog post published the day after the May announcement, Zed’s head of growth and marketing Franciska Dethlefsen noted that subscriptions had previously subsidised that kind of usage at roughly 15 to 30 times the equivalent API cost — a figure gleaned from analysis by engineer and entrepreneur Matthew Diakonov — and that the new credits would be billed at full API rates.
Dethlefsen did point to one workaround, though: users who ran Anthropic’s official Claude CLI directly in a terminal inside Zed, rather than through the Agent SDK, would have remained on their existing subscription limits.
The same tool, billed differently depending on how you invoked it.
On Monday, though, Anthropic started emailing subscribers saying the planned change was off, as per reports on forums such as Hacker News. The company’s support documentation has also now been updated to match, confirming that Agent SDK usage continues to draw from standard subscription limits and that no separate credit exists to claim.
“We’re pausing the changes to Claude Agent SDK usage described below,” the message notes. “For now, nothing has changed.”
The timing created an awkward situation for companies that had already communicated the change to their own users. Conductor, a multi-agent coding tool built on the Claude Agent SDK, published a post telling customers they were in the clear for now. “Anthropic has delayed the subscription updates to Claude plans,” the Conductor team wrote. “You can continue to use your Claude plan with Conductor as normal.”
The June 15 pause is the latest in a series of billing changes Anthropic has made around third-party Agent SDK access, and the underlying tension is one the whole industry is grappling with. As Anthropic’s head of Claude Code Boris Cherny put it back in April, when announcing an earlier restriction on third-party tool access, subscriptions “weren’t built for the usage patterns of these third-party tools” — an acknowledgement that flat-rate pricing and open-ended agentic usage don’t mix well.
GitHub arrived at the same conclusion and acted on it, retiring Copilot’s flat premium request model in June in favour of token-based billing — a change that drew its share of complaints but went ahead regardless.
In the same week as Anthropic’s billing reversal, a proposed class action lawsuit was filed in a California federal court, alleging that Claude’s Max subscription tiers fall well short of their advertised usage multipliers during heavy coding sessions.
On the billing front, Anthropic hasn’t said when a revised approach will arrive, saying only that it’s “working to update the plan to better support how users build with Claude subscriptions.”
What we do know is that the company is feeling the heat from the US government over Fable and Mythos. Coupled with its plans to become a publicly traded company, and rumored price cuts from its fierce rival OpenAI, it’s clear Anthropic is trying to keep its developer base onside — and the billing pause is one way it can do that for now.
The post Anthropic pauses Claude Agent SDK subscription change on day it was due to take effect appeared first on The New Stack.
This month we dig into whether Claude Design is any good, why so many people feel like AI is costing them time rather than saving it, and what it really means to stop being a doer and start being a director. Along the way we wander into the loss of craft, the ethics of AI, and a joke so niche it needs its own history lesson.
Claude Design is the tool that grabbed our attention this month. It builds out designs for you, and it is genuinely impressive. We used it to rebuild the website for a small UK charity that funds children's education in India, going from nothing to a finished static HTML site in around eight hours, with Claude Design handling the design and Claude Code doing the build. Beyond the standard twenty pounds a month subscription, it cost roughly fifty quid in extra credits, which for a small organization is a no-brainer.
Claude design and code together allowed Paul to create a fully working website in less than 8 hours.
It turns out it does more than websites. It builds presentations too, and exports them to PowerPoint or PDF for offline editing. We put together a fifty three slide deck for a client in about two hours, work that would normally have eaten the best part of four days.
Here is what we liked. It works with design systems, you can import one from Figma, you can make manual edits without burning tokens, and you can select elements visually to tweak them. The things that hold it back are that you can't export back to Figma, there's no easy publish button, and the usage allowance vanishes in what feels like five minutes flat. When you hit the wall it cheerfully suggests you try again on Sunday, which is no use when you're mid project and have already forgotten what you were doing.
One word of warning. If you don't guide it heavily, Claude Design has tells, like a recurring decorative bar under the hero section that serves no real purpose. Then again, every designer has a style you can spot, so we're not convinced that's the criticism people think it is.
A lot of people tell us AI isn't saving them time, it's costing them more of it. That confused us at first. How can a tool that turns four days of slide work into two hours possibly slow anyone down? The more we coached people through it, the clearer the answer became, and it has very little to do with the tools. It comes down to how organized you already are.
If you're not fundamentally efficient in how you work, and especially if you've never had to delegate to other people, AI exposes that straight away. The people struggling most are the ones who still want to be doers. They want to be in the code, pushing pixels in Figma, or typing every word themselves. To get real value from AI you have to shift from that doer mindset to a director one.
It reminded us of the moment in the Steve Jobs biopic where Wozniak asks Jobs what he actually does, given that Woz writes the code and builds the hardware. Jobs answers that he conducts the orchestra. Woz is the finest violinist in the room, but someone has to bring all the players together. That conductor role is exactly the shift most of us need to make.
A real example from this month. Working on a client presentation, we had three things running at once. Notion AI was drafting the outline in one window. Claude Design was studying the client's website to build a matching design system in another. A third agent was drafting video transcripts for a separate project entirely. Three workstreams all moving at the same time, where you would once have plodded through them one after another.
That is a genuinely hard skill to build. The people best placed for it are those with management experience, because they're used to handing work off and holding several threads in their head at once. If you've never worked that way, it can feel distressing, and there's even a name for where it leads, which our reader of the month gets into.
There's a design leadership parallel too. Talented designers get promoted, then can't resist sneaking back into Figma to do the work themselves. The same thing happens with AI. The agent produces something perfectly good, but it isn't quite what was in your head, so you fiddle and fiddle and fiddle, burning the very time you were meant to save. The upside is that you can't hurt an AI's feelings, so just say "no, that's not it" and move on.
The fix is unglamorous. Get organized before the agents fully take over.
We didn't agree on all of this. Marcus prefers using AI linearly and still enjoys the doing, the writing itself, rather than conducting an orchestra. That led us into deeper water about craft. Is the joy in the tool or in the output? Paul has found real satisfaction teaching AI to write in his voice while keeping the part he actually loves, communicating ideas with passion. Marcus worries that stripping away the craft, the genuine ability to play the instrument, costs us something real, and asks how the next generation of designers will learn without the junior grind.
We tested it against Monet, photography and the industrial revolution. Someone recently posted a supposedly fake Monet online and asked people to explain why it fell short of the real thing. They wrote whole essays about flow and composition, until it turned out to be a genuine Monet. So how much of our resistance is legitimate and how much is simply discomfort with change? We don't pretend to know. There are real problems with AI, the blatant disregard for intellectual property and the environmental cost chief among them, and they deserve people shouting about them. But the genie is out of the bottle, and as a species we've never once managed to put one back.
The single takeaway. Start building your management habits now. Get organized, practice delegating, and learn to hold several threads at once, before that choice gets made for you.
Marcus brought the counterweight to all that optimism. The article is Life with AI causing human brain 'fry', which introduces a term coined by the Boston Consulting Group.
"AI brain fry" is the mental exhaustion that comes from using or supervising AI tools past your cognitive limits, the sort caused by reviewing endless AI generated code, juggling multiple assistants, and rewriting lengthy prompts over and over.
It hits software developers hardest, since agents now churn out code faster than humans can review it for security flaws and overall coherence. Fittingly, the piece reached us via one of the developers at Headscape, who waved it about as proof that AI is a problem. We agree the problem is real. The article's advice is for company leaders to set clear limits on AI use to prevent burnout, though quite how they're meant to spot the issue without us telling them is another matter.
The catch is that a cynical manager will just point out that their whole day already feels like relentless context switching, so good luck getting much sympathy.
For a related read, Marcus also flagged AI didn't delete your database, you did, a sharp piece arguing that you should take responsibility for what you ship to production rather than blaming the AI when it all goes wrong.
We end, as ever, with Marcus’ joke. This one needs a UK history lesson, so our apologies to anyone under forty.
I guessed orange, but it was chocolate. I guessed toffee, but it was peanut. I guessed strawberry, but it was coffee. I was wrong on so many Revels.
Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes.
"Culture follows structure. The destructive tendencies of a team are the consequence of how the organization is actually structured." - Aimé Flemm
Aimé doesn't blame teams when they go toxic. He looks at the org chart. At his first gig, the UX-only team grew bitter — making screens nobody used, blocked from talking to customers, drowning in dependencies. The team's behavior wasn't a coaching problem. It was a structural one. At his current company, building backend software for EV charging stations, he watched the opposite happen: leadership flipped seven component teams (backend, billing, etc.) into seven end-to-end feature teams with one Product Owner. Two-week sprints. Switching costs collapsed — they could decide on Wednesday to change direction, refine on Thursday, and have all seven teams pivot together by the next sprint. The org became truly adaptive. Aimé's question to every Scrum Master listening: is your organization fit for purpose? If the work is predictable and specialism-heavy, component teams can work. If you need adaptability, the structure has to match. Don't coach behavior that the structure forces.
In this segment, we talk about Larman's Laws of Organizational Behavior, the Star Model by Jay Galbraith, and Org Topologies.
Self-reflection Question: Look at the team you're coaching. Which of their "destructive habits" might actually be a rational response to the structure you've put them in?
This week, Aimé recommends two books that complement each other. First — and his "holy bible" — is Large-Scale Scrum: More with LeSS by Bas Vodde and Craig Larman. "I remember reading this for the first time. It took me two weeks, the whole book. And I was just constantly texting people — 'this is it! It all makes sense now. I finally know what to do.'" For the how of organizational change — workshop ideas, possible structures, change tactics, and the people side — LeSS is the book. The companion book Aimé pairs with it is 10x Organization by Alexey Krevitsky, Roland Flemm, and Craig Larman — strong on the what and the why, with a 2x2 visual map that helps you explain to management where you are today, where the market needs you to be, and what should change. (You can also listen to our episode with Bas Vodde and our BONUS episode with Roland Flemm for a deeper view.)
[The Scrum Master Toolbox Podcast Recommends]
Angela thought she was just there to coach a team. But now, she's caught in the middle of a corporate espionage drama that could make or break the future of digital banking. Can she help the team regain their mojo and outwit their rivals, or will the competition crush their ambitions? As alliances shift and the pressure builds, one thing becomes clear: this isn't just about the product—it's about the people.
🚨 Will Angela's coaching be enough? Find out in Shift: From Product to People—the gripping story of high-stakes innovation and corporate intrigue.
[The Scrum Master Toolbox Podcast Recommends]
About Aimé Flemm
Aimé Flemm joins us from the Netherlands. Our guest is an organizational design coach who starts where most agile transformations stop. He works at the structural level: redesigning the incentives, reporting lines, and systems that either enable or quietly kill agility. His belief: you can't coach your way out of a broken org design.
You can link with Aimé Flemm on LinkedIn.
Log in
