Every system is perfectly tuned to get the results it does." That’s not a criticism—it’s an observation. Your organization’s processes and bureaucratic checkpoints exist because they solved a real problem. Even if that problem may not be here anymore. For example, Architectural review boards emerged because you needed specialist knowledge from multiple domains to make safe decisions. Change control processes exist because change was expensive, adn risky so controlling it made sense. These weren’t mistakes. They were rational responses to constraints that existed when that solution was designed. But constraints change. And when they do, the systems built to manage them don’t automatically evolve. They just become friction.

When development teams achieve 10x productivity through AI augmentation, something shifts. The bottleneck in your system moves. It’s no longer developer productivity. It’s organizational throughput. Your approval processes were designed for a slower development cadence. So multiplying development productivity by 10, just created a new problem. Your developers may sit idle waiting for permission to deploy what they built in a fraction of the time.

Here’s the math that should trigger alarm: Take your development backlog depth. Divide it by 10. Now compare that number to the time it takes to get a new business requirement approved and deployed. If approval cycles are 2-3x longer than that adjusted backlog, you’re underwater.

This is where Deming’s principle becomes critical: “A bad process will beat a good person every time.” You can’t hire your way out of this. You can’t motivate your way out of this. You have to inspect the system itself. Which approval gates still serve their original purpose? Which ones exist out of habit? Which ones can be automated with the same certainty as human review?

The job now is organizational archaeology. Understand why each process exists. Determine whether those reasons still apply. Then rebuild your governance in light of new tools and new constraints. Not to eliminate oversight—but to align it with the pace at which value can actually flow. Your bureaucracy was once your stability. Don’t let it become your noose.

For roughly $1,000 a month, individual developers can now produce 10x the output they could five years ago. This isn’t theoretical—it’s happening now. But there’s the tension in that headline. That 10x development speed doesn’t automatically translate to 10x business value. In fact, it often reveals a hidden crisis.

The problem isn’t technical. It’s economic and organizational. We’re now paying for two cost streams instead of one. You have fixed subscription costs (Licencese) , and variable usage costs (Tokens). And as your team learns to use AI effectively, those token costs will fluctuate. While they are learning, costs will spike. As they land on suitable patterns, they will plateau. Finally, optimization and fine-tuning will bring the usage down some. Engineering leaders need to understand what they’re actually trying to buy. It’s not lines of code, but functionality that reaches customers. That’s the real unit of value.

But there’s a catch. That tension from the headline I mentioned. The Theory of Constraints tells us every system has one real bottleneck. For years, that bottleneck appeared to be developer productivity. Now it’s shifted. AI has compressed development time-costs. But what about our approval processes, governance reviews, and deployment pipelines? We designed them for the old pace of delivery. Consdier this: your review board takes six months to approve a design. And now your developers can build that design in two weeks. You haven’t gained anything. Developers can’t work on the next design because it’s still in review. You’ve just created expensive idle time!

The math on this is brutal! Divide your backlog depth by 10. Is the resulting depth shorter than your approval cycle time? If so, developers become a cost center waiting for permission! Good news though: This crisis is preventable. But only if you act now!

Start by understanding your real costs and your real bottleneck. Calculate what you’re actually spending on developer time plus token usage. Then ask: where do decisions get made in your process? Use decision velocity metrics. Track whether approvals happen at the Directly-Responsible-Individual (DRI) level (0) or get escalated up the chain (+1, +2, +N). Those escalation patterns reveal your bureaucratic bottlenecks. Work to reduce the score, move decisions down the orgnaization. And that means putting money where your mouth is. And then, help do the same for your business proposals!

Run a pilot program. Experiment with controlled autonomy. Define acceptable risk boundaries and new decision-making rules upfront. Let your team learn what AI can do while you learn what your organization can safely automate. Because the real 10x isn’t in code generation. It’s in aligning development velocity with organizational throughput. That’s where the value actually lives.

I recently had to prep for a client call. The problem? I didn’t know their market well, and I didn’t have time to research it myself. In consulting, you’re expected to speak the client’s language. You have to understand their market position, current initiatives, competitive headwinds. And all that just to know how your engagement fits their broader strategy. That kind of research takes hours. Hours I didn’t have.

So I tried something different. I gave my AI agent a list of questions: What’s their market position? What initiatives are they pursuing? What headwinds are they facing? What’s their recent public history? I also told it to use public sources, and to cite it’s sources. Then I let it work.

The AI transformed my questions into search queries. It executed those searches and extracted semantically relevant snippets. Then it used that context to create structured research document with citations. What would have taken me 4-6 hours took 30 minutes. I showed up to that call prepared.

This brought to mind a shift in thinking I’ve been exploring. AI isn’t about automation—it’s about augmentation. The question isn’t “What can AI do for me?” It’s “What would I do if I had a team working with me?” If I had a research assistant, I’d delegate: “Here are my questions. Go research these and brief me before the meeting.” That’s exactly what I did.

AI excels at transformation tasks. That is, it’s good at changing data from one shape to another. In this case: questions → search queries → search results → relevant snippets → synthesized research document. That’s a sequence of transformation tasks. And internet research? That’s entry-level knowledge work. Searching and condensing. AI puts entry-level research assistant capabilities in your hands. With some obvious caveats around credible sources, obviously!

Tools like AI internet search has opened entire worlds of transformation tasks! You’re not limited to what the AI knows from training, nor even from the context you can directly give it! It now has the ability to gather current information, and cite sources! You can use this to build context you can verify, much in the same way you’d start trying to learn something!

The workflow I used isn’t consulting-specific. You could use this approach for design research. You can get context on unusual uses of Azure resources!. Or preparing business cases for leadership. Or collecting industry best practices for your team. Any time you need to gather and synthesize information quickly, this pattern applies.

I’ve documented the workflow and made it available. Note: This is not about replacing your thinking! It’s about compressing the information gathering stage. That way you can focus on synthesis and decision-making. The research assistant does the grunt work. You do the knowledge work.

If you’re curious, the workflow is here: https://github.com/djscheuf/non-dev-agentic-toolkit/blob/main/README.md#research–learning. Try it with your own AI agent. Adapt it to your domain. See what happens when you delegate the research and keep the thinking.

Over the last several months, I’ve been working with AI agents to build software. And I’ve noticed something interesting. I’m achieving output levels that used to require a team of five developers. Not by coding faster, but by working differently.

The more I lean into agentic development, the more I find myself drawing on my experience as a team lead. Across my career, I’ve served in roles from junior developer to adviser to engineering directors, and often as a team lead. And those team lead skills? They’re suddenly the most valuable tools in my toolkit.

Before being able to lead a team, you need to practice leading yourself. That principle applies here too. I’m spending my time differently now. Instead of heads-down coding, I’m defining team processes for my AI agents. I’m conducting code reviews on their output. I’m deeply considering my design. Just like I did when it would be handed off for someone else to build. And of course, I’m jumping in to help the agents figure out when something has gone wrong.

Here’s what that looks like in practice: I built a multi-agent orchestration workflow. I frequently had many agents work on the same codebase. Each agent gets clear boundaries and context. Human-in-the-loop checkpoints happen at stage completion, sometimes as often as each red-green-refactor cycle. I can focus on defining, reviewing, or enabling one feature at a time. I do the design work up front, and let the agents implement. While they’re doing so, I move on to brain work on another piece.

The key insight? The AI doesn’t know your intent. It can only discover it through your documentation, your ADRs, or what you’ve told it. So I wrote down my process. I wrote down the questions I ask myself. I’m trying to write down the stuff I always assume. Just like mentoring a junior engineer.

And it follows that same progression: I do, you watch. I do, you help. You do, I help. You do, I watch. You do, I check the results. That transformation doesn’t happen overnight.

A team is not merely a group of individuals you throw together and call a team. That’s a mob. They need a common purpose, and some coordination to their action. What we’re building with AI agents isn’t the same kind of team, but it requires a similar approach. The team lead skills are now critical for the most effective developers.

You get to write the rules. You get to build your ideal software team, starting now. If you have the courage to try, and the patience to iterate!

Last month, I completed several sprint stories simultaneously for the first time. Not sequentially. Not by context-switching between them. Actually in parallel, with different AI agents working on each story at the same time. Leaving the snake-oil feel out of it, how could a single developer do the same scope as a team !?

The breakthrough wasn’t “use AI agents”. At least not by themselves. I’d been coordinating multiple agents for weeks, but always in the same workspace. The problem? Change Collision. When agents share a workspace, they’d fight between their changes. Agent A’s changes confuse Agent B. Agent B’s test runs interfere with Agent A’s build. The coordination overhead killed any productivity gains.

Then I remembered Git worktrees. If these bits of code were completely in different zones, so I didn’t have to worry about them conflicting… I needed separate working zones! So I set up separate worktrees for each. And opened independent IDE windows to drive them. Physical workspace isolation solved the collision problem entirely.

What surprised me wasn’t just that it worked. It was how my role shifted. I wasn’t writing code anymore. I was orchestrating. One agent would start its TDD cycle while I reviewed the other’s results. When both hit their validation/integration phases, I’d spot-check then guide the merge. I shifted from writing code to building validation systems. Stuff like unit tests, log file capture, and support scripts. And when I wasn’t doing that I was coordinating parallel work streams.

This brought to mind something I’ve been hearing about in industry circles: The Software Factory. Developers building automated validation rather than writing implementation. I won’t claim to have a whole factory setup. But a backbone of solid workflows, and some test harnesses made it possible. Mix in Trunk-based development with feature branches, and you’re cooking with gas! The evolution happened faster than I expected. It wasn’t flawless, for sure, but I got the knack for it within a couple days. Now it’s my default mode. But I had to trust the Agentic output!

You build Agent trust through quality gates, not hope. Hope is not a method. Automated tests, and validation create the safety net that enables autonomy. Orchestration beats micromanagement. Get your system to produce quality code reliably. Then worktrees let you scale from one developer to a small development team.

Can one developer build the same scope of work as a team? Yes, If that developer steps back. Act like a lead. Build repeatable AI systems. Then coordinate several agents working in isolated worktrees. Then it might actually work.

AI isn’t a silver bullet. It’s not an omni-tool that solves every problem. It’s not the miracle everyone’s been waiting for. But what if we’ve been asking the wrong question about what AI actually is?

Think about a 3D printer. The real value isn’t in how it prints, e.g. additive manufacturing. It’s that you can use it to print anything you imagine, so long as you can describe what you’re trying to do. AI works in a similar way. Its chief value isn’t in being the one magic tool. It’s in being a tool for making all kinds of tools.

You’ve might have already experienced this without realizing it. You ask AI to do something. It doesn’t quite work. So you ask it: “How can I make that prompt better?” And it helps you refine the prompt. You used AI as a tool-maker! It created a better tool, the improved prompt, for doing the thing you wanted in the first place. That’s the pattern. Over time, for repeated tasks, you’re gradually making sharper and sharper tools.

But here’s where it gets interesting. AI excels at transformation tasks, that is changing data from one form to another. Summarization, Translation, Reframing, that kind of thing. It’s not great at computation or repeatable execution. But it can generate the script for you! Need something done repeatedly and reliably? AI can help you build the automation. Need to transform information? AI can do it directly or help you create the workflow to do it better next time.

This means our job has shifted. We need to think deeply about our work. Not just what we do, but why we do it. Drucker called this out in the Effective Executive. He said a Knowledge workers need think through what should be done and why. That includes who will use what we’re producing, and their context! We have to define the task well before we can hope to improve it.

What is it you’re trying to do? Why are you trying to do that? Who’s going to use what you’re making? Only then can you identify where AI fits, where it can create tools to make your work better. Then we look for the spots where we need tools. Transformation tasks that could use AI directly. Computation tasks are where we use AI to generate a repeatable script.

Here’s where things get interesting! Like 3D Printing, you don’t have to be an expert in modelling to print a new useful tool. For AI, you don’t have to have the expertise in an expert framework to be able to use it. You just need to be able to describe it… or have a sound explanation from someone who can. AI can create workflows that make expert frameworks executable.

Take something like Wardley Mapping, or decision facilitation, or any framework you’ve read about but struggle to apply consistently. Gather context. Get the framework write-up. Capture your experience and observations. Find some Online discussions of the patterns and anti-patterns. Then work with AI to translate that context into a step-by-step guiding workflow. You’ve just created a tool that can make you and your team better at strategic thinking. That’s AI as tool-maker’s tool in action.

We’re not just automating existing tasks. We’re entering a new tool-making revolution. The only limit is your imagination—and that’s quite literal here. But you need to understand what the tool is capable of first. Then you can use it to the limits of your imagination. The question isn’t “What can AI do for me?” Instead ask: What tools do I need? And how can AI help me make them?

The more things change, the more they stay the same. And the age of AI is no different. Software engineers learned new languages, frameworks, and techniques the same way for decades. They built a toy project. Want to learn Python? Write a small app. Want to understand design patterns? Implement them yourself. It’s how we’ve always learned. So when I wanted to understand AI “Skills”, I decided to play a game.

I’m fond of solo journaling RPGs. The whole mechanic is simple: roll some dice to get a prompt, then write about it. That’s easy enough to explain to an AI, so I wondered if I could teach the AI to facilitate the game. Not play it for me, mind you! But teach it to handle the drudgery. In this case: rolling the dice, looking up results in tables, and managing game state. That way I could focus on the part I actually wanted: writing the story!

Good news: it worked. I found you need something that’s almost entirely not work to really get a sense of what these tools are capable of. That said, it did take some work. AI is great at transformation verbs. This time it was turning a description of a process (the game rules) to the sequential execution. In short, I had to transform the written rules, into a workflow. And the context and tables into skills the AI would use while following the workflow. The AI invokes Skills only when needed. This keeps the context window clean while providing deep expertise on demand. For example “How do I find out which scenario to prompt the user with?” That skill loads only when I need it, not while I’m writing my response to the prompt. And the AI doesn’t invoke it while trying to look up the setting from a different results table.

We learn more by doing than by theorizing. At some point, you have to bite the bullet and just go. But there’s something wonderful about learning through play! You’re freeing yourself from the expectation of “I’m a professional.” You’re acknowledging “I don’t know,” and giving yourself permission to tinker. It takes time, yes, so you have to balance that. But that freedom to experiment is where the learning happens.

The new core skill in the Age of AI isn’t coding or analysis. It’s clearly articulating your intent! With AI skills specifically, there are two parts. You have to articulate when that skill applies, so the AI can find the skill at the right time. And you have to describe how to do that skill well, or else the skill doesn’t help the AI do the work consistently! AI excels at transformation tasks. The trick is learning to structure the context. You have to know when to load what information. Then design interactions that remove drudgery while preserving what matters.

A solo RPG is certainly an unusual approach. But don’t be afraid to literally play around with the new tools to learn them. Or consider starting with skills that others have built at skills.sh, then refine them for yourself. The pattern that’s worked for decades still works. You just have to give yourself permission to play.

The game I used: The Wandering Tea Garden

I was cleaning up documentation today when I discovered something unsettling. Several of my ADRs contained code examples of patterns I’d long since superseded. One ADR was completely obsolete! I chose a different path months ago, but the document remained. It even had implementation examples I definitely didn’t want my AI agent following! If the agent referenced these during planning, it would build patterns I’d explicitly decided to abandon!

That’s when it hit me: outdated documentation isn’t just annoying anymore. It’s context poison.

When was the last time you ate something from your fridge that had been sitting there for weeks? Documentation rots the same way. But here’s the critical difference: a junior developer can ask questions, and recognize when documentation doesn’t match reality. Your AI coding buddy can’t. It trusts what’s written. It has no informational immune system to protect it from misleading context.

This brought to mind something from my post on Delete Over Deprecate: deleted can’t pollute, deprecated can. The same principle applies to documentation. As long as that outdated examples exist, you’re weighting the statistical probability. That is your AI is more likely to generate code matching those old patterns. You’re actively poisoning every future prompt.

ADRs solidify tacit knowledge. They capture the decisions and trade-offs your team made during design. But you should also review them over time as part of knowledge curation. And here’s the trick: the right thing to do now may be eliminating some of that solidified information! We have to recognize when the right thing to do is delete components from the ADR, not just mark them deprecated.

So what changed? Documentation hygiene became a new form of maintenance. “Either you’ll schedule this maintenance, or the machine will schedule it for you.” It will get scheduled when the AI inevitably produces terrible results. You’ll pay the maintenance burden trying to fix bad outputs, and redo work. Or worse: you won’t catch it soon enough because the AI will produce code that works but doesn’t match your intent!

The solution is simpler than it sounds. Treat documentation cleanliness as part of code review. Before you merge, ask: do the current docs match the implementation we’re about to merge in? If not, correct it. Keep your documentation and current context marching in lockstep with your code.

You have to be your AI’s information immune system. Delete context poison! Prune your documentation regularly, or accept that you’re feeding your AI teammate a steady diet of poisoned apples.

If you don’t schedule your maintenance, your machine will schedule it for you. And that applies regardless of the type of machine, including you! Leftover Maintenance becomes unplanned work. You catch the flu or maybe a machine breaks. Either way you’re stuck holding the bag.

We ought to put First Things First. You can delay Maintenance, sure. But it comes due with interest. By contrast, simple daily maintenance is cheap, like brushing your teeth. But if you don’t do it first thing, you will likely forget.

But like any habit change, getting the new one to stick is tricky. Start with a small experiment, and try a bunch of them. Start with identifying what is ‘maintenance’. For a developer, it could be documentation, or package updates, or adding missing tests. For a leader, it might be clearing thru your email backlog. It might mean journaling, or inspecting your systems.

Once you know what it looks like, it’s a simple matter of scheduling. For a developer or team, schedule a 1-2 hour block right after Sprint Planning. Do the maintenance work, and get it merged. Then go back to regular development. Even if it’s just one document, just one test, or just one package. You left the app in a little better state.

If you want to take a more aggressive approach, you can. For a leader that might mean booking the first 30min of every day for the next week. Assigning each a Maintenance task (Journal, Inbox-0, System Check). And then actually sticking to that commitment.

The pattern remains the same. What goes first, gets done. And it doesn’t have to be expensive or heavy. Little and often make much. Start building the sustainable habit.

Are you going fast enough? Most of the time, the answer is no. We always want to deliver faster than we did last time. Or to deliver more than we did last year. But speed is not a work-product issue. Speed is a Leadership Issue.

The system you are working is in perfectly tailored to get the results you currently do. And doing the same thing again, hoping for a different result is the definition of insanity! Speed is a leadership issue, because it is a work-system issue. If you want better speed, you have to change the work-system. And leaders own the work-system!

So if you want your system, your team, your org to go faster, you have to change the system. How do you do that? Start by asking what the future needs to look like. Consider development flow. You could describe the new future state with a target Cycle-time. For example you might target a cycle time of 10 days or less. This is basic vision casting and communication. Not just “We need to be better…”, but “We need to be better. And here’s what that looks like!”

With “What that Looks Like” in hand, the next question is: What has to be true if the system is going to perform that way? You’ll probably find a lot of these. Filter "New Truth"s for those within your influence. Then from those you can influence, focus on the bottleneck. Every system has a bottleneck. Only by addressing the bottleneck can we improve the flow thru the system.

Fixing a bottleneck will cause the system to shift. Let the system settle into it’s new normal. Then repeat this process. Pick your target. Identify "New Truth"s. Filter, and focus. Then fix. Be a Leader who iterates. Speed is a Leadership issue. Own your work-system! Pick logical evolution, over hopeful insanity!