Astra Graded Higher and Took Four Hours. Better for What?
By Atiba de Souza
The win that showed up with a bill
We were stuck, and stuck in the worst way. Not bad enough to throw out. Not good enough to publish with confidence.
My team was on the a pharmacy-industry company social content for Rx Growth Hub. It was not reaching the quality bar on Claude. It was grading around 5, 5.5.
Then Astra came out. The team switched. The grades rose to close to 7.
That was the win we wanted. Then the second number walked in behind it. The same job, for one pharmacy, went from an hour and a half to almost four hours.
The tradeoff, in the two numbers that matter: the social content for Rx Growth Hub graded around 5 to 5.5 on Claude and close to 7 on Astra. The same job, for one pharmacy, went from an hour and a half to almost four hours. Two and a half times slower, for the better score.
So I asked the team the only question that mattered at that point. How do you define better?
That question is the whole article. Not because it is clever, but because your team is going to face it, if they have not already. And the answer will get made in a room without you, and you will live with it for a year.
The model is not your problem
The model is a capability story. Your problem is a judgment story.
Every time a new capability lands, somebody on your team has to decide what better means for the work in front of them. If that decision only ever gets made by you, in your head, in the moment, then you will make it again next quarter, and the quarter after that, and you will call that leadership. It is not leadership. It is you being the human API between your own taste and your own team.
Here is what made the Astra switch interesting, and it is the part I want you to steal. The tradeoff was real and it was double-sided. Choosing on quality score alone would have shipped a pipeline that cannot scale across pharmacies. Choosing on speed alone keeps content nobody wants to publish. Neither of those is a decision. Both are a coin flip with a justification stapled to it.
The only way out is to make the tradeoff explicit, out loud, with the people who have to run it. That is not a model question. That is a thinking-transfer question.
CASE Method: a scheduled, structured post-task reflection meeting. Not task assignment, and not a set of forward instructions handed over before the work starts. You delegate the task, stay completely hands off while it runs, and hold the meeting only after it is complete. Four questions, whose job is to excavate how your team thinks and bridge the gap to how you think. E is "Easier Than Expected," a strengths-surfacing question, not "Easier." It is not a status check and it is not a list of corrections you read out.
Delegate thinking, not tasks. Traditional delegation transfers output. CASE Method transfers input — how to process information, recognize patterns, and make decisions the way you would. That is the difference between a team that pings you all day for exceptions and a team that thinks like owners.
Why you will want to skip this, and why that instinct is expensive
Let me name the thing you are already feeling, because pretending you are not feeling it is how these articles become useless.
If you go hands off, they will do it wrong. They will pick the fast model and ship work you cannot publish, or they will pick the slow one and blow the throughput, and you will find out a week later, and you will fix it yourself at 11pm, and it will be your fault for not steering.
That fear is real, and it is not irrational. Staying hands off is a cost. Something will come back worse than you would have done it. That is the tuition.
The second cost is quieter and it is the one that actually stops people. A reflection meeting asks you to explain how you think. Out loud. To someone who will ask why. You may never have had to articulate your own taste before, and the first time you try, you will hear yourself be vague. That is uncomfortable in a way that correcting someone's output is not. Correcting is cheap. Articulating is the work.
And there is a third one specific to this moment. Model churn has probably made you feel behind. If you do not move to the better model fast, you are falling behind. If you switch, your throughput dies. Both feel true, so you pick whichever one you can defend in a meeting and move on.
So the resistance is not laziness. The CASE Method moves the risk off the thing you control, the work, and onto the thing you do not, your team's judgment. That is a real rewiring. Name it before you ask anyone to do it.
The part of the method that carries the weight
CASE Method is not a task-assignment acronym. It is not a set of forward instructions you hand over at the start of work. That is the misread I see most, and it happens because C-A-S-E sounds like something you hand someone. It is the IP behind The Delegation Trap, and the trap is exactly that misread.
It is a meeting that happens after the task is done. That ordering is the whole thing.
Here is the ranking, because not every part of this carries the same weight. If you remember one thing, remember the timing and the hands-off rule. Get those wrong and the meeting turns into supervision, and supervision produces compliance, not judgment. You do not hand someone the wheel and then reach over at every intersection. You hand over the wheel, let them drive, and then talk about the drive afterward.
The four questions matter. What they are for matters more. They exist to pull out how your team thought while the work was in front of them, so you can see where their reasoning and yours diverge, and close that gap on purpose instead of by osmosis.
The one leaders skip is E. E is not "Easier." E is "Easier Than Expected," and its job is to surface a strength. Ask what turned out easier than they expected. If the only answer is the score, you have not found a strength yet. You have found a number. Push until they name the part of the work that got lighter, because that is the part they now own and you can stop holding.
When not to run it
Do not run it on a task that is still moving. You will get status updates, not thinking.
Do not run it when the only outcome you want is compliance and you already know the answer you want to hear. That is a performance review wearing a reflection meeting's jacket, and people can tell.
Do not run it for the first time on your most politically loaded project. Start where a wrong answer costs you a day, not a quarter.
And do not run it if you are not willing to hear that they would choose differently than you would. The meeting is not a funnel to your answer. If the tradeoff is real, two answers can both be defensible, and your job is to make the standard explicit, not to win.
| Inconsistent delegation and reflection | Consistent delegation and reflection |
|---|---|
| The model gets picked before the team touches the work, on quality score alone or speed alone | "Better for what" gets named together, then the pick gets made |
| The leader stays in the work while the task runs | Hands off until it is done, no exceptions |
| Reflection happens only when something goes wrong | Reflection is on the calendar after every task |
| The meeting is a status check and a list of corrections | The meeting is four questions about how they thought |
| E gets answered as "it was easier" | E gets answered as "this part was easier than expected," and it names a strength |
| A win skips the reflection because it worked | A win gets the reflection most, because you need to know why it worked |
Back to the four hours
The turn in the Astra story is not that the better model was better. Everybody expects that.
The turn is that better arrived with a bill attached, in the same week, from the same change. Grades up. Throughput down by two and a half times. "Better" stopped having one answer.
So the output of the CASE meeting is not a feeling of alignment. It is a sentence your team can say without you in the room: better for what, and here is what we are trading to get it. Quality gain and throughput cost, measured in the same conversation. If you only have the quality number, you ship a pipeline that cannot scale across pharmacies. If you only have the speed number, you keep content nobody wants to publish. Both of those are non-answers. Reject them in the room, out loud, and make them show you both numbers.
That is the decision. Not "is this model better." Better for the thing we are actually trying to ship, at the volume we are actually trying to ship it.
Here is the version you can do Monday. Pick one task a capable person could own. Hand it over and do not touch it while it runs. Put thirty minutes on the calendar for after it is done. Ask the four questions. Hold your corrections until the end, then hold most of them. Write one line afterward that answers better for what, in language that will still make sense next quarter.
And when the costs show up, because they will, here is what to do with them.
The hands-off anxiety. It hits around hour two. You will want to open the file. Do not. Write down what you would have done, in one line, and bring it to the meeting as a question instead of a correction. The line is data. The correction is a shortcut that costs you the whole point.
Hearing yourself be vague. The first time you explain your own taste, you will hear the fog. Say "I do not have language for that yet, give me a minute," then actually try. The vagueness is the raw material. The meeting is where you refine it. That is the rewiring, and it does not happen anywhere else.
The chance they choose differently. They might. If their reasoning holds and the tradeoff is defensible, say so out loud and adopt it, or say plainly what standard you are adding and why. What you cannot do is overrule without naming the standard, because that teaches them the standard is "ask the boss," and you are back to being the human API.
The tools will keep changing. Something will land that makes today's tradeoff look quaint. What compounds is a team that can answer better for what without walking it back to your desk, because you spent the thirty minutes after the task teaching them how you think.
Questions