The LLM Will Not Come Back Tomorrow
An LLM can solve a problem you frame. It does not remember to care, return tomorrow, or ask whether the problem was e...
AI Makes Technical Execution Cheap. Judgment Stays Scarce.
12 min read
The Scarce Skill Sits Between the Boxes
24.09.2026, By Stephan Schwab
More capacity is the right purchase when the work is understood and the team simply lacks hands. But when requirements mutate, releases depend on heroics, or added developers have not improved delivery, more hands amplify the system that is already stuck. AI does the same more quickly. The missing capability is protected, independent judgment that can follow a problem across business intent, product choices, technology, and operations.
Lenny Rachitsky’s takeaways from Netflix Chief Product and Technology Officer Elizabeth Stone put systems thinking at the center of work in the AI era. Her practical advice is to step back from the immediate task and ask what larger business problem it serves, whether the solution should work across the product, and whether it belongs in a shared capability.
That sounds obvious.
So does backing up your databases.
Companies still discover the need immediately after the damage.
The Familiar Call Solves a Familiar Problem
Staff augmentation is good at adding capacity to a delivery system that already knows what to do.
The familiar supplier call feels safe because it turns a difficult delivery problem into a simple purchasing action.
The CEO sees an approved response: add a person. The CTO gets a specialist without a long hiring process. The delivery manager gets another name against the backlog. The supplier already knows the contract, rates, and preferred format for CVs. Nobody has to reopen the assumptions behind the work.
Sometimes that is exactly right.
Call the staffing company when:
- the desired outcome and acceptance criteria are stable
- the architecture can absorb parallel work
- the team has enough capacity to onboard, guide, and review another contributor
- the missing skill or capacity is narrow and understood
- success genuinely means producing more of the work already being done
That is a capacity problem. Buy capacity.
The mistake is using the same purchase when the evidence says the system itself is struggling. More people do not repair contradictory priorities, slow decisions, weak ownership, repeated rework, or a release path held together by whoever happens to remember the dangerous parts.
They give the broken system more people to keep busy.
Staff augmentation can also filter out the broad developers most capable of strengthening the team. Even when it finds an excellent person, the engagement can still restrict that person to execution. The CV may contain judgment. The purchase order does not.
AI Makes Local Output Cheap
When local output gets cheaper, the expensive mistakes move to the connections between decisions.
AI can accelerate a bounded task. It can produce a first implementation, compare options, identify a likely defect, draft a test, or explore an unfamiliar codebase. A capable developer can move across technical layers faster than before.
Good. Use it.
But local speed does not prove system coherence. The company can now produce five plausible implementations before lunch and still have no idea which one belongs in the product.
The faster the parts move, the more damaging bad connections become:
- a sales promise becomes a product requirement without a domain owner
- two teams solve the same need with incompatible abstractions
- a vendor optimizes the feature while weakening the operating model
- an AI prototype quietly becomes production software without ownership
- a technical shortcut changes what the business can safely promise customers
The bottleneck moved. Typing was never the whole job, but now even the pretense is getting difficult to maintain. The scarce capability is deciding what deserves to exist, how it fits, who must own it, and what the organization will have to live with after release.
That is systems thinking.
Cross-Stack Is Not Yet Cross-Domain
A person can work across the entire stack and still optimize the wrong business system.
The return of the generalist is often described as a technical expansion. Frontend developers learn the backend. Backend developers work with infrastructure. Everyone learns enough AI tooling to be dangerous before breakfast.
Useful, but incomplete.
The difficult boundaries are not only between technical layers. They sit between customer behavior, commercial promises, domain rules, product choices, architecture, security, operations, support, and the way decisions actually get made inside the company.
Consider a supposedly simple workflow automation. The ticket asks for an approval step.
A technical executor can implement the state transition.
A systems thinker asks different questions:
- Who has authority to approve, and where does that authority come from?
- What happens when the approver is absent?
- Does approval make the action final, reversible, or merely eligible for another step?
- Which existing product surfaces already express the same rule?
- What evidence will operations, finance, or a customer need later?
- Is this one feature, or the first accidental version of a shared capability?
Those are not interruptions before the real work.
They are the real work.
The code makes the answers executable. It does not make the answers correct.
The Seam Is Where Delivery Fails
Organizations love boxes because boxes make purchasing, reporting, and blame wonderfully tidy.
Business defines the need. Product writes the requirement. Developers implement it. Operations runs it. A supplier fills any missing capacity. Each box can show completed work.
The customer can still receive nonsense.
Delivery does not fail only inside the boxes. It fails in the translation between them. A domain assumption loses its caveat. A commercial deadline quietly becomes an architectural decision. A product manager accepts a vendor estimate without seeing the operational compromise inside it. A developer solves the literal ticket while the underlying workflow remains broken.
Nobody did their job badly.
Nobody owned the whole result either.
This is why adaptable generalists matter. Their value is not that they know a little about everything. Their value is that they can follow a decision across boundaries, notice where its meaning changes, and bring the right people into the same conversation before the change becomes a release problem.
That breadth is not a lack of specialization. Connecting domains is the specialization.
Why Leaders See the Pain but Miss the Pattern
This is not a competence gap. It is a consequence of role, attention, and proximity.
The CEO sees delayed initiatives, rising costs, customer complaints, and promises that keep moving. Those signals arrive through summaries built by people who each see one part of the system. By the time they reach the top, the awkward connections between them have usually been edited out.
The CTO sees much more detail, but in fragments. An incident interrupts an architecture decision. A hiring problem interrupts a product discussion. A supplier escalation interrupts the work needed to stop the next escalation. The role creates broad context and destroys uninterrupted attention at exactly the same time.
The team sees the local causes. One developer knows the requirement is unstable. Another knows the deployment is fragile. A product manager knows three stakeholders disagree. Operations knows the workaround is becoming permanent. Nobody has the mandate and time to follow the pattern across all four.
The organization is not short of intelligence. Its intelligence is distributed, busy, and trapped inside roles.
Useful outside judgment does not come from standing at a distance and declaring everyone blind. It comes from joining close enough to inspect reality while retaining enough independence to question explanations that have become routine. The advantage is dedicated attention: following a recurring problem across meetings, decisions, code, handoffs, and releases until the underlying constraint becomes visible.
Your Staffing Supplier Is Not Failing You
A staffing company is paid to fill the brief, not to prove that the brief describes the wrong problem.
Your favorite supplier may be responsive, honest, and very good at finding people. Keep their number.
Just stop expecting the commercial model to do a different job.
Staff augmentation starts with a role to fill. Its machinery is built to turn requirements into candidates, candidates into placements, and placements into billable capacity. The supplier succeeds when the seat is filled with someone who matches the brief and stays useful.
An Embedded Software Delivery Partner starts one level earlier: why does delivery feel heavier than it should, and is another seat actually the intervention that changes it?
That question can lead to code. It can also reveal that the backlog reflects three incompatible versions of the product, that a commercial promise has no operational owner, or that the team is waiting days for decisions and being blamed for taking weeks to deliver.
The framing determines what the organization permits the person to do.
Frame someone as technical execution and the rules become clear. Receive the requirement. Estimate the work. Implement the ticket. Escalate ambiguity through the proper channel. Stay away from commercial, product, and operational decisions because those belong to other grown-ups.
This is a perfectly valid purchase when the problem is genuinely known and the company only lacks capacity.
It is a terrible purchase when the problem is slow, confused, or unreliable delivery.
In that situation, limiting a senior to technical execution removes the exact value you claimed to want. They see that the requested feature duplicates an existing capability but are not invited to challenge scope. They discover that the domain experts disagree but are told to follow the signed-off requirement. They know the release plan cannot support the commercial promise but are expected to make the pipeline green and leave the contradiction untouched.
Then the company buys a workshop on alignment.
Apparently irony has a budget code.
Judgment Has to Stay Close to the Work
The point is not another coder. It is someone with enough access, independence, and attention to find the constraint everyone else is working around.
An Embedded Software Delivery Partner works inside the delivery system and across the domains that shape it. That position matters more than any individual technical task.
The primary contribution is judgment:
- noticing that several unrelated delays share the same decision bottleneck
- tracing a recurring defect back to an ownership or domain problem
- recognizing when apparent capacity loss is actually rework
- separating an architecture constraint from a coordination constraint
- spotting the workaround that has quietly become an operating dependency
- seeing when the team is solving the requested problem while the business needs a different one
Technical ability supports that work. It allows the partner to inspect the code rather than rely on a presentation, test whether an explanation survives contact with the system, and help turn a useful observation into a durable change.
That is different from being hired primarily to code. If the missing capability is simply another developer producing well-understood work, staff augmentation may be enough. The partner becomes useful when the organization needs someone to discover why apparently capable people and sensible plans still produce recurring friction.
Hands-on proximity keeps the judgment honest. Independence and protected attention make the pattern visible.
Why This Matters Economically
The business case is not systems thinking. It is avoiding another quarter of paying for motion that does not become business value.
A CEO should be suspicious of an intervention that sounds broad. Broad can mean vague, unaccountable, and very fond of workshops.
The answer is not to pretend this is a narrow technical purchase. The answer is to make the operating result concrete.
The company should see:
- fewer initiatives stalled between business decisions and technical work
- less paid capacity consumed by rework and misunderstood requirements
- earlier exposure of promises the delivery system cannot safely support
- lower dependency on the one person who remembers how everything fits
- working software reaching customers and operations sooner
- improvements that remain with the team instead of creating another supplier dependency
Adding another contractor is easier to count. That does not make it easier to justify after six months if lead time, release confidence, and customer outcomes have not moved.
The economic distinction is straightforward. Added capacity increases what the existing delivery system can attempt. Added judgment can change why that system keeps losing time in the first place.
The CTO Remains the Technical Leader
An embedded partner should expand the CTO's reach, not build a private power center beside it.
Systems thinking is not a license for a broad outsider to wander through the company collecting authority.
Calling the staffing supplier can feel safer for the CTO. Asking for more capacity says the problem is resourcing. Bringing in another experienced peer can sound like admitting the CTO has failed to solve the system.
That is a bad reason to buy the wrong service.
The CTO remains accountable for the technical organization and its direction. Domain experts remain accountable for domain truth. Product leaders remain accountable for product choices. Developers remain accountable for the quality of what they create.
The partner improves the connections.
That means working with the CTO, not around them. It means making decisions and evidence easier to inspect. It means helping the team gain capability rather than creating dependency on a heroic individual who alone understands the whole maze.
The useful result is not a new dependency on the partner.
The useful result is that the organization can see and manage its delivery system more clearly than before.
There should be no private reporting route around the CTO, no audit disguised as help, and no attempt to win authority by making the existing team look weak. The partner works under the CTO’s mandate, makes difficult evidence visible, and helps act on it inside the work.
Capacity and Judgment Solve Different Problems
Capacity helps when the path is clear. Judgment helps when the path itself is uncertain.
Staff augmentation fits when the work is understood and the team can turn additional capacity into additional useful output.
Dedicated cross-domain judgment becomes more useful when:
- adding people has not improved lead time or release confidence
- requirements keep changing after implementation starts
- business, domain, product, and technical leaders hold different versions of the problem
- critical releases depend on heroics, memory, or repeated manual intervention
- AI produces more drafts and code but not more reliable customer outcomes
- the CTO knows where the recurring friction lives but lacks the time to work through it inside the team
- you cannot yet explain whether the constraint is capacity, decisions, architecture, ownership, or delivery practice
The two forms of help can work together. Sometimes the sensible sequence is to expose the real constraint, repair the delivery path, and then add capacity where it can finally help.
But when you do not yet understand why delivery is stuck, buying capacity first is not the conservative choice.
It is paying to postpone the hard question.
Judgment Needs Access
If you want only technical execution, write clear tickets and buy technical capacity. There is no shame in naming the purchase honestly.
If you want someone to improve delivery across business, domain, product, technology, and operations, do not lock that person inside the technical box. Give them access to the assumptions, the subject-matter experts, the conflicting incentives, and the decisions that shape the work before it reaches the backlog.
Then measure the result at system level:
- less rework caused by misunderstood needs
- shorter time from decision to useful software
- fewer duplicated capabilities and local workarounds
- safer releases and faster recovery
- clearer ownership after the feature ships
- better adoption because the software fits the real workflow
AI will keep making more output available. That is not the same as making the organization better at deciding, connecting, and owning.
The companies that understand the difference will not merely ship more artifacts. They will build systems that still make sense after everyone has moved quickly.
That requires technical ability.
It also requires the judgment to know when technology is not the only domain in the room.
Talk It Through
Tell me what is happening. I listen, ask a few practical questions, and reflect back what I see: where the risk may sit, what may be blocking delivery, and what looks worth checking next. No pitch, no obligation. Confidential and direct.
Talk it through. Practical reflection, no pitch.
Start a Conversation
🎭 This Week's Episodes
Telenovelas show what we can't say in client meetings. The drama is heightened, but the patterns are real.
Three Ways to Understand a Country
Stefan drives Sophie to the Pacific for two days. The beach is big enough to make her feel appropriately small. Back at the finca the rain keeps th...
The Resignations
Nathan Cole resigns on a Monday morning with two sentences and no argument left in his body. By Tuesday his desk is empty and the company's institu...
Technical Consultancy
Embedded Delivery Partner
Embedded into your team as an active contributor, reducing delivery friction and helping important work move cleanly.
Technical Advisor
Peer-style technical assessments before far-reaching decisions; reduce architectural and product risk early.
Product & Delivery
Ship working software to real users earlier. Measure impact and adapt based on evidence rather than assumption.
Custom Software Development
High quality, maintainable software. Short-term augmentation that leaves lasting capability in your own team.
Recent Articles
- When Everything Is Finally Under Control (28.09.2026)
- AI Makes Technical Execution Cheap. Judgment Stays Scarce. (24.09.2026)
- The LLM Will Not Come Back Tomorrow (19.09.2026)
- The One-Person AI Company Is a Greed Fantasy (15.09.2026)
- Test Production Without Leaving a Mess (10.09.2026)