Will Lawrence

Product leader, UX full stack developer and entrepreneur working on a startup to modernize an age-old industry with an easy to use app and the cloud.

[Will Lawrence @willhlaw]

Stabilize-Rebuild-Scale https://t.co/R60gMH4elh

[Allie K. Miller @alliekmiller]

A workflow audit is no longer the best way to figure out how to use AI in your job.

Despite the advice from AI labs, I'm more convinced, because of AI's reasoning capabilities and long context horizon, that the right starting point is goals + context connectors + interview.

The workflow audit is moving too many people into quick-win "yay I just did that one thing so much faster!" productivity land and missing the entire business transformation side.

For example...

Team does research. Person A reads six articles and hands them to Person B. Person B pulls it together into a report. The report goes to the client, who uses it to audit part of their own work.

If you run a workflow audit on that, the "AI upgrade" is both painfully obvious and dreadfully boring. You have AI do the research. You have AI draft the first pass. The human reviews.

Maybe a fancier version of that workflow builds a branded template, lets AI run the research itself, and a human adds a voice memo for context. Then you ship... the exact same report. But faster! Which feels great for about a week. And then you assume the next steps are making more frequent reports.

BUT that report only ever existed because it was the right asset in 2019 to help your client run their own audit, when your real constraint was time and people. That constraint is gone. So why are you still manufacturing the identical artifact at every step?

It just so happens that in 2019 the best way to complete that outcome for the client was a report. It just so happens that the best way to make the report was Person B compiling everyone's input. It just so happens that the best way to get input was reading articles and writing them up.

A lot of "it just so happens" from 2019 DO NOT hold in 2026. And based on my AI advising work, a workflow audit just doesn't surface them, because it optimizes the steps instead of questioning the destination.

Goals + context connectors + interview does.

Start from the goal (ex "help the client audit their work", not "produce a report"). Connect Codex or Claude Code into tools (especially notes, email, CRM, chat like Slack, meetings, docs/drive) so AI pulls from live sources and the client's own systems instead of a static handoff. Have AI interview the human to capture the nuance and judgment for why this process even exists.

The answer might look nothing like a report. Maybe it's a brand-new auditing product business line that you can launch. Maybe it's an interactive report that the end client can plug straight into. Maybe it's a more real-time research repository the end client can talk to all year instead of waiting for the big monthly drop. Maybe you realize that the client can make the same report in 2 seconds and the resources it takes to create and distribute it on your end just doesn't make sense to keep running in 2026.

For every asset you make, ask the very obvious question "why the hell do we do this thing?" Ask yourself what outcome or influence or action you are actually trying to solve for. Then ask the 2026 version. Is this still the most effective, efficient, valuable, creative, low friction, engaging, and long-term relationship-deepening way to get there?

A workflow audit gets you a faster horse.

Steal my prompt and replace your workflow audit - pasting it in the next tweet.

[Thariq @trq212]

been asking others at Anthropic how they stay in the loop with Claude and fully understand the work being done

this is one of my favorites from Suzanne:

[Will Lawrence @willhlaw]

Importance of bridge builders for founders and leaders, whether being one yourself or having one on your team. https://t.co/el3FtK56v4

[Paweł Huryn @PawelHuryn]

The roadmap was doing two jobs.

One was scheduling:
we cannot build this yet.

That part of the argument feels right. Fake engineering scarcity is dead. If a vendor says a custom field needs a Q3 roadmap slot, the buyer now hears a credibility problem.

But the roadmap was also doing a second job:
this is not what the product is.

That job gets more important when code gets cheaper.

Cheap code makes it easier to satisfy every customer request. It also makes it easier to turn a focused product into a pile of exceptions, edge cases, and half-owned behavior.

You try to satisfy everyone. You end up being mediocre at best.

The hard part is no longer "can we build it?"

It is whether the request exposes real product debt, belongs in configuration, or should stay a no.

Code got cheaper.
Focus did not.

[Will Lawrence @willhlaw]

“Forget scattered AI pilots. CIOs win the AI gold rush by building the infrastructure that turns raw experimentation into massive enterprise capacity.” https://t.co/VKP7USOJx1

[Sunil Neurgaonkar @SNeurgaonkar]

@DJ_CURFEW The sharpest insight here: AI doesn’t remove the bottleneck, it moves it from execution to judgment.

Once output is cheap, architecture, taste, QA, and customer context become scarce.

The hard part is measuring 100x without mistaking velocity for impact.

[Jack Quinn @JackQuinn]

This thread is one of the more honest snapshots of enterprise AI maturity I’ve seen in a while.

A few patterns repeat almost universally across the replies:

- ChatGPT everywhere, but very few scaled multi-agent workflows
- Power users building personal agents while the rest of the org lags behind
- “No formal AI strategy” but broad experimentation permissions
- Managers reacting to low-quality AI output without clear standards for acceptable use
- Governance heavy enough to slow scaling, but not structured enough to define authority boundaries
- Build vs buy debates happening before companies understand what operating model they’re actually trying to create

What’s interesting is that many organizations still think they are adopting “tools.”

In reality they are beginning to reshape:
- delegation structures
- execution pathways
- decision velocity
- organizational authority surfaces
- knowledge asymmetry inside teams

The “haves vs have-nots” framing in the post is especially important. Once a small subset of employees operate with materially amplified execution capability through agents and automation, organizations eventually have to answer uncomfortable questions:

Who gets delegated authority?
What actions remain human-reviewed?
What becomes replayable?
What standards define acceptable AI-generated work?
How do personal workflows become institutional capability instead of isolated leverage?

The comments from @tessi3r, @MarcusSpillane, @ConvergePanel, @kekkodamato_, and others all point toward the same underlying issue:

the blocker is no longer model access.
It is organizational governance capacity.

Most enterprises are still trying to govern AI as software procurement when the real transition is operational and structural.

That gap is increasingly where Decision Governance Group operates. A lot of our work is helping organizations map the actual decision and authority surfaces emerging underneath AI adoption before those structures harden accidentally through shadow workflows, power-user concentration, or unmanaged agent deployment.

The companies that move successfully over the next few years probably won’t be the ones with the most pilots. They’ll be the ones that can clearly map authority, escalation, replayability, and execution boundaries as AI systems become embedded into daily operations.

[Steve Yegge @Steve_Yegge]

Brendan Hopper, Matt Beane and I have a thesis, one that I've been sharing around lately, and we want CEOs and boards to hear it.

Before I get to the thesis, let's revisit Clayton Christensen's Innovator's Dilemma (ID), the theory he developed at HBS to explain why big companies often get eaten by upstarts during technology shifts.

In short, the ID says incumbents serve their best customers so well, and tune themselves so ruthlessly for doing exactly what they do today, that they can't chase the disruptor tech coming up from below until it's too late.

The classic solution to the Innovator's Dilemma is to create a "bubble" in your company. You carve out an innovation team with a budget and mandate, as unfettered as practical by the parent organization. This is to combat the 2-level trap presented by the dilemma.

The economic trap is Christensen's original point: a disruptive technology can't justify itself under your existing P&L, because it serves smaller or weirder customers at margins your real business would never accept.

The governance trap is what gets piled on top once you're big: SOC2, FedRAMP, etc. mean every new idea has to clear a lot of process before it can move. The bubble is intended to escape both at once, with its own economics and permission slips.

The standard innovation "bubble" solution famously doesn't work very well. You may solve the problem inside your bubble, but you often can't roll it out to the rest of your company for the original reasons. Everyone is focused on doing their current stuff, and nobody has time for a major change.

Our thesis is that there is an entirely different way out of the dilemma this time around. No bubble needed, as long as you follow a simple rule. That rule is, let your people play. Give them back any time they earn from automating their jobs with AI. Then incentivize them to use that time to improve the company's processes.

When you see an engineering team announce a 40% productivity boost from adopting AI — a number that's been showing up in plenty of LinkedIn posts lately — your first reaction as a CEO or manager is probably to say, that's awesome, we can do more work now! Or you might simply expect to see 40% more output from the team.

Either way, you have just asked them to spend their extra time building faster horses (your current business) instead of letting them go figure out what a car would look like for your company. They gained some productivity from AI, which could have been your ticket out of the Dilemma, and you immediately slurped it back for your existing business.

This will get your company killed in the medium to long haul, because your company tomorrow will look almost nothing like it does today. Conway's Law says your software and your org chart mirror each other; as AI rewrites how you build software, the org has to shift to match. But if you're stealing the hours back saved by your employees, then you're not letting your org pivot naturally in the direction it needs to shift.

@RealGeneKim and I saw this in person at @arkanalabs a few weeks back. As long as your people know they'll be recognized and rewarded if they improve the company's processes — public credit for cross-team workflow wins, promotion criteria that actually count process improvements, managers who treat freed-up hours as a feature rather than a budget line — then they will use their "play time" to seek out other teams, and start pivoting you to becoming AI-native. This way it can unfold in whatever bespoke way is most natural to your company, rather than in some ivory-tower research bubble. For every company, the way it unfolds will be a bit different.

I think of this approach, of giving the time back to the humans who automate parts of their jobs with AI, as the new solution to the Innovator's Dilemma. The old bubble solution was to separate a bunch of people from their regular jobs, and try to give them the freedom to solve the problem in isolation.

In contrast, by giving your regular employees their hours back, the innovation bubble is still there, but it's now dispersed across the company, as lots of very tiny bubbles: one bubble per person who has liberated some hours.

If you've ever read Slack by DeMarco and Lister, a great book from back in the 90s, then our thesis should resonate. What companies need is to empower their own employees, the ones who actually work together (even across departments)--the ones who know how the business works--to shift the company in the new directions together. Gradually, but with intentionality.

You still have the frankly awful problem of token budgets. For every employee you upskill into baseline AI literacy (which I'd define loosely as using coding agents throughout the workday), you've added a non-trivial opex spend — for the heaviest agentic users it can run into five figures a year. I won't sugar-coat it; you need to find that money somehow. I don't have a magic solution, but I'm very happy that other models are catching up to Claude, because they're becoming good enough for real work now.

But token budgets alone aren't enough. To live through the Innovator's Dilemma this time around, your employees need a time budget, too. Give it to the ones who earn it using AI, then incentivize them properly, and I think you're headed in roughly the right direction.

Thank you for coming to my TED tweet.

[Will Lawrence @willhlaw]

“Technology delivery will always have constraints. Decision velocity does not have to be one of them.” https://t.co/ydaAAaRllj

[Eric Lubow @elubow]

@clairevo I love that everyone can build, not just engineers. People should feel empowered to get their creativity out in meaningful ways. We just need to make sure that production code gets the right rigor applied: https://t.co/O1Mjkne61r

[Brij Pandey @LearnWithBrij]

Claude Code ships with 5 architectural layers most engineers never open.
Not features. Not settings. Layers — each solving a distinct problem that LLMs alone can't solve. And four of them have nothing to do with prompting.
Here's the full Agent Development Kit:

Layer 1 — CLAUDE.md → The Memory Layer
Architecture rules, naming conventions, test expectations, repo map. Always loaded. Always active.
Two scopes:
• ~/.claude/CLAUDE.md → global
• .claude/CLAUDE.md → project
This isn't context you paste in before every session. It's context that never needs repeating. The agent's constitution.

Layer 2 — Skills → The Knowledge Layer
Each SKILL.md carries a description. Claude matches it at runtime and forks the skill into an isolated subagent. On-demand, never always-on.
Task-specific knowledge without inflating your main context window. Modular by design.

Layer 3 — Hooks → The Guardrail Layer
PreToolUse → PostToolUse → SessionStart → Stop → SubagentStop

This is the layer most teams skip. And the one they regret skipping first.

Hooks are NOT AI. They're deterministic event-driven shell commands.
• Auto-lint on every Write
• Hard-block on rm -rf
• Slack notification on Stop
Event fires → Matcher checks → Command runs
Quality enforced at the infrastructure level. Not the prompt level.

Layer 4 — Subagents → The Delegation Layer
Each subagent gets its own context window, model, tools, and permissions.
Main agent delegates down. Receives results up. That's it.
No infinite recursion — subagents can't spawn subagents. Main context stays clean. Hard boundaries by design.

Layer 5 — Plugins → The Distribution Layer
Bundle your skills + agents + hooks + commands into a plugin. One install. Whole team inherits the behavior.
Think npm packages — but for what your agent knows how to do.

Wrapping everything:
→ MCP Servers on the left (GitHub, databases, APIs, custom integrations)
→ Agent Teams on the right (parallel execution, message passing, shared permissions)

The 5-layer stack in one line:
CLAUDE.md sets rules → Skills provide expertise → Hooks enforce quality → Subagents delegate work → Plugins distribute to the team
Most production failures in agentic systems trace back to one missing layer.

Which one is the gap in your current setup?

[Aaron Levie @levie]

Whether it’s existing consulting firms, new ones that emerge, FDEs from agent vendors, or new internal agent engineering roles, the amount of work that is going to be created to implement agents in enterprises will exceed anything we imagine today.

The complexity of implementing agents in any existing organizations is very real. When I talk to large enterprises, as you move from a chat paradigm to agents that participate in meaningful workflows, there are a number of things they need to do.

First, you have to get agents to be able to talk to your data securely across your systems. In many cases, enterprises have decades of legacy infrastructure that contain the valuable context for AI agents. That’s going to take a ton of work to go modernize and move to systems that work well with agents.

Then, you need to ensure that you’ve implemented agents with the right access controls and entitlements, the right scopes to be safely used, and have ways of monitoring, logging, and securing the work that they do.

Next, you need to actually document the processes in the organization in a way that agents can utilize for doing the work. You also need to figure out what the new workflow looks like when agents and people are working together on a process, and who steps in where. Just replicating the old workflow will mute the gains. Oh and you likely need to create evals for your top new end-state processes.

Finally, you have to keep up with a rapidly changing set of best practices and architectural shifts happening in the agent space. While it’s fun for people to change their personal productivity tools on a dime, it’s 100X harder to do this in a business process. The speed of change is a blessing and a curse right now for anyone trying to keep a stable system design.

All of this means that individuals and companies that develop expertise on the above set of components (and more) are going to be needed to help organizations actually implement agents at scale. This is also the rationale for vertical AI agents right now that can go in deep on a business domain and help bring automation to it.

This is a huge opportunity right now whether you’re doing this internally or as an external business provider.

[Will Lawrence @willhlaw]

https://t.co/p3ZcRIwikA

[Will Lawrence @willhlaw]

This looks like an interesting tool for reducing token usage and increasing intelligence for AI Agent on existing code bases. https://t.co/Clbx0WqbdT

[Will Lawrence @willhlaw]

Need to be cautious of what operational flows, even AI, are critical path and in one cloud provider’s hands. https://t.co/sYmC8L1oO3

[Lenny Rachitsky @lennysan]

My biggest takeaways from @rabois:

1. The team you build is the company you build. Founders get distracted by markets, customers, and technology. If you have the right people, those problems get easier. If you have the wrong people, none of those things save you.

2. Build your company on undiscovered talent. The only way to scale an organization against incumbents with infinite budgets is to find talent that large companies’ hiring machines will misprocess. In practice, this often means skewing younger—not because young people are inherently better but because they have fewer data points, which means typical evaluation systems can’t categorize them accurately. This is where the alpha often is.

3. Hire more “barrels,” not “ammunition.” A “barrel” is someone who can take an idea from zero to outcome without hand-holding. Most companies have only a handful of these people. Hiring more people without expanding the number of barrels doesn’t increase output; it increases coordination tax and creates drag. The ratio of barrels to ammunition is what determines the number of important things a company can pursue simultaneously.

4. CMOs are becoming the #1 consumer of AI tokens. At a few of Keith’s top portfolio companies, the heaviest user of AI is the chief marketing officer. These CMOs are running analytics, shipping campaigns, and generating insights that previously required entire teams of deputies.

5. The three signs a company will win: operating tempo, internal talent development, and “the relentless application of force” from the top. Keith identifies a consistent pattern across his best portfolio companies. First, operating tempo: Ramp shipped physical cards in three months when the industry standard was 9 to 12. Second, talent development through internal promotion rather than senior external hires; the CMO at one of his top companies was the previous chief of staff. Third, the CEO’s willingness to push harder as things improve, not less. Mike Moritz told a friend of Keith’s that the most common trait of the best CEOs is “the relentless application of force.” Complacency is the natural by-product of success, and the CEO’s job is to offset it.

6. For consumer products, talking to customers is not just unhelpful; it’s actively harmful. Keith refuses to let companies he advises conduct consumer research. His argument: Consumer decisions are subconscious. Ask any Porsche owner why they bought the car, and 99% will cite every reason except the real one. Once misleading customer feedback enters the organization, it locks into people’s brains and distorts every subsequent decision.

7. Keith believes the PM role may not survive the AI era. Taking customer inputs, building a sequential year-long roadmap, and coordinating between teams are structurally incoherent when AI capabilities change weekly. The skill that matters now across all three roles—PM, designer, engineer—is business acumen: understanding the company’s equation and knowing what to build next.

8. Great hiring comes from great referencing. Run at least 20 references, and keep going until you hit negative feedback. Ask specific, forward-looking questions (e.g. “Would you start a company with them?”). If every reference is positive, you haven’t gone deep enough.

9. Use a 30-day feedback loop to sharpen your hiring instinct. Thirty days after every hire, ask: would I hire this person again? This is as predictive as waiting years, and dramatically faster for improving your judgment. Make this a habit, and your hiring quality will compound.

10. Criticize in public, not private—it optimizes for the system. Keith endorses a management practice that most people find confrontational: delivering negative feedback in front of the team, not behind closed doors. Private criticism optimizes for the individual, but the rest of the company doesn’t know the issue is being addressed, which breeds anxiety and suspicion. Public criticism lets colleagues see that leadership is aware, creates opportunities for others to volunteer help, and turns feedback into a team-building exercise.

Full conversation: https://t.co/5MI134kdx5

[Thariq @trq212]

https://t.co/nKTDfC7zMm

[Will Lawrence @willhlaw]

Excellent article on the future of software engineering and why taste will be important. https://t.co/elcZlX1GSe

[Dan Mall @danmall]

https://t.co/jtbzJPXyjt