Process Redesign: The Difference Between 10% and 10x

During most of my internships, less than half my workday was spent writing, testing, and deploying code. The rest went to meetings, coordination, and waiting for decisions I wasn’t allowed to make.

That experience helps me understand why companies struggle to see returns on their AI spend. BCG reports that only 6% of companies are seeing meaningful value through reduced costs or increased revenue.

Most of the AI adoption I have seen looks like buying seats for a coding assistant. That does pay off. But coding is only half of the job, so making it faster can only get us so far. Even making it instantaneous would only double your output if the rest remains the same. The difference between 10% and 10x gains has to come from redesigning the process.

When I was younger, I read a book about learning to learn. The idea was simple: improving that ability pays off in everything you learn afterward. I think about AI adoption similarly. Most companies are rushing to add AI features to their products. I would start with the teams instead: improve how you investigate problems, test ideas, and build software. Those gains carry into every product you build.

What does a software engineer do?

Software engineers do a lot more than write code. We debug producition issues, help design new features, prioritize the backlog against new features, and architect systems. We also spend time waiting on other teams, scheduling meetings to decide what happens next, or clicking through a UI to investigate logs.

Better models don’t automatically change those workflows. If investigating an issue still means scanning through logs and then pasting the error into your coding agent, that work stays pretty manual.

Redesigning the system so that an agent can search logs, check its findings against code, and query data means improvements in the models immediately translate into improvements in how you work and where you spend your time.

Rethink time spent in meetings

Meetings are the clearest case: better models don’t make them more effective. Large companies spend a lot of time in them. It’s worth asking what each meeting was meant to accomplish and whether it still makes sense in its current form.

That doesn’t mean meetings aren’t needed. A good meeting earns its time by asking the questions that should be answered before committing to full implementation: Is this necessary? Are we solving the right problem? Can the change be smaller? But this requires everyone to enter the meeting with an understanding of what will be discussed.

Agreement was cheaper than evidence

When implementation was expensive, it made sense to agree on an approach before trying it. Evaluating unfamiliar frameworks, testing services, and adapting generic examples to your use case could take weeks of work. Building two versions and throwing one away was hard to justify.

Those economics have changed. Coding agents make it cheaper to build and compare prototypes. There’s time to explore several solutions rather than just taking the first one that appears to work.

After almost 18 months of coding with agents, I still sometimes underestimate how much they can do on their own. Earlier this year, I described to an agent a feature that would automatically divide transcripts into sections, expecting to work on a plan together. Instead, it built the feature end to end in 20 minutes. After some UX and backend cleanup, it was close to shipping. Agents still often fall short, but we need to keep recalibrating what we can safely delegate and where our judgment is necessary.

As the cost of experimentation falls, more questions become worth answering, more assumptions worth checking, and more ideas worth testing. An experiment that wasn’t worth doing two years ago may be worth doing now. A product that was too ambitious at the time may now be in scope.

The processes we built on top of the old constraints are still here, and they are what prevent many organizations from using what the models can now do. The issue is not the LLMs; it’s the process.

Why the process stays slow

Changing a process requires 3 things: understanding the work, understanding the technology, and having the authority to act. Large companies often split these roles by design: product managers own the problem, DevOps owns the infrastructure, and engineers sit somewhere in between. Everyone knows the process is slow. Almost no one is in a position to judge whether it’s needed or has the pull to make the change.

Smaller organizations often keep these closer together. Roles overlap, founders can make decisions directly, and there are fewer hoops to jump through between having an idea and executing on it.

Larger companies can create room for experimentation too. It takes a cultural change for people to take the time to step back and question how they work. In a rapidly evolving world, a process that made sense two or five years ago may already be outdated. Do the assumptions under which it was built still hold? Answering those questions requires a willingness to rethink how we work and rebuild when necessary.

The approval processes that once prevented wasting resources can now cost more than the experiments they prevent. They also discourage initiative. You see a problem, have an idea, and want to try it. Instead, you have to schedule meetings to discuss the idea or get permission. Repeat that enough times and people will be trained to do what they’re told, rather than what is necessary.

Give teams room to carry work through

When one person can investigate a problem, test an approach, and share a working version in hours, it makes sense to give them responsibility for that entire stretch of work. Set clear goals and constraints, then give them room to act. Someone with good judgment and domain knowledge can carry an idea much further than ever before.

Engineers can take on more of the product decisions within their area. Someone who understands the problem can test an idea, evaluate whether it works, and bring back something concrete to discuss.

Before meeting to decide on a dashboard, I can have three agents build different versions and publish previews. Sharing the previews beforehand lets people arrive with questions, so the meeting can focus on comparing the options and discussing what works and what’s missing.

Cheaper experiments let you ask more questions: Does this layout make sense? How does the user experience actually feel? Does this dashboard survive real data? What happens if we simplify it? Implementation becomes a way to find out.

To carry that work through, teams need enough control of their stack: application logic, infrastructure, deployment, and monitoring. If every experiment requires queuing behind a shared DevOps team, faster implementation just gets you to the queue sooner.

Giving people more room to act still leaves questions of quality and coordination. A working prototype can hide poor code. Architecture, security, and maintainability still require technical judgment. Work in one area can replicate centralized efforts or affect another, so someone needs to keep track of how the pieces fit together. I don’t have an answer for how this works. Giving teams ownership clear ownership, with short check-ins and clear centralized documentation , seems like a good place to start.

The remaining gate

Too many workflows still use humans as meat proxies: copying a stack trace, pasting it into a chat window, and asking the model to explain. Engineer away those steps. What’s left matters more than ever: judgment.

I still decide what’s worth building and whether the result is good. I don’t need to direct every step of the investigation. When implementation is cheap, it’s easier than ever to build everything, so focus matters more, not less. And what comes back still needs to be checked. The alternative is a slop grenade: passing on unchecked model output so someone else has to wade through it and catch the mistakes. That doesn’t eliminate the work. It just passes it to someone else. Use fast experimentation to find the right ideas, then build the winner properly.

Faster code gets you to the next handoff sooner. Redesigning the process removes the wait.