Miguel Ouro

Miguel OuroSep 15, 2026

At least 10% of your developers ship less than one effective day a month. I said that out loud on Tuesday, at an after-work session. The room wasn't junior. Engineering directors. Heads of AI. Twenty years behind them and more technical depth than I have. It went quiet. Then someone pushed back. "Are you telling me they work less than one day a week?" He had softened my number without noticing. I said a month, not a week. And he still couldn't believe it. His question contained the actual error. Working is not producing. Those people work more than forty hours a week. Every one of them. That has nothing to do with what reaches production. Then came the justifications. Team meetings. Supervising others. Reviewing. Redoing. Unblocking someone else. A long list of verbs that all sound like work and none of which ship anything. And none of them are lazy or underskilled. They're the opposite. They just don't have time to go deep into a single line of code anymore. Their day is dictated by other people's AI output. Reviewing it. Correcting it. Explaining why it can't go to production. Nobody in that room was lying. They had just never counted. Productivity is easy to understand in a factory. Units out, hours in. In a software company it slips through your fingers. And most people reduce it to speed. Ship faster. That's a third of it. The other two are quality and consistency. Fewer errors, and processes that run the same way twice. Which means measuring errors. Including the ones made by people who don't know how to use AI properly. Nobody I ask has a number for that. McKinsey's 2026 survey hit the same wall from the other side. 80% of respondents say AI improved their individual productivity. Only 37% say it contributed anything to EBIT. Flat against last year. Everyone feels faster. Almost nobody is richer. The gap isn't the technology. The time saved never gets reinvested into anything countable. It stays on the desk of the person who saved it. So before your next AI budget, answer one question. How many effective days does your team actually ship in a month? If you don't have that number, you're not measuring productivity. You're hoping.

Miguel OuroSep 24, 2026

AI made producing cheap. It didn’t make judging cheap. A 40-page document landed in my inbox this week. 20 minutes to write. 2 hours to work out that it said almost nothing. I don’t blame the person who sent it. They did what we all do now. Ask AI for the document. Skim it. Send it. The problem is what happens next. Someone still has to read the 40 pages to find out whether there is anything worth reading. AI collapsed the cost of producing. It did almost nothing to the cost of verifying. Generating costs cents. Checking whether what was generated is actually useful still costs what it always cost: Your attention. Your judgement. And your time. Now move that into engineering. A pull request that takes four minutes to generate can still take forty minutes to review. Sometimes longer. Because the code looks plausible everywhere. And is wrong in one place. So your team ships more commits than ever. But your senior engineers spend more of their week reading instead of building. That isn't necessarily productivity. It can simply be a transfer of work. The work moved from the person producing it to the person checking it. And only one of those shows up in most productivity metrics. And before this sounds like an executive complaining about everyone else: I do it too. I produce more than I ever have. I write faster than I ever have. But some weeks I honestly can't tell whether I thought better... or simply thought more often. Nobody sends an invoice for that. The cost comes out of judgement. And eventually, everyone pays it. So when someone asks: "Where should we put AI in the business?" I'd ask a different question first: What is it costing us to read what we already produce? Most companies can't answer that. They measure output. Almost nobody measures the review load that output creates. Maybe that's the metric we should start watching. Because the next time a 40-page document lands on your desk, don't just ask: "Who generated this?" Ask: "Who paid to read it?" This week, it was me. Two hours. Tell me it hasn't happened to you.

Miguel OuroSep 17, 2026

Forward Deployed Engineer. Heard of that role? Neither had I. Until a few weeks ago. An engineer who embeds inside the client and puts AI into production. No layers, no middlemen. I mentioned it over coffee this week to a friend. Head of AI, twenty years in. He cut me off halfway through. "That's already happening inside my own company." Two speeds. Same organisation. Same budget. One side: small teams, direct client contact, delivery in days. The other: legacy profiles whose overhead eats the budget before anything ships. It isn't one company against another. It's one company against itself. And it explains what I've been seeing in the market for months. Some still run squads of seven to nine people. And no, these aren't old companies. Some aren't even ten years old. Others run squads of three. MVP in days. Client iteration on day four. New version before Monday. Clients notice. And they've started saying it out loud. That by the time they finally test what they bought, they're six months behind whatever got announced while it was being built. They're right. Completely. But the vendor isn't the problem. Your procurement process was designed for a different tempo. Your RFP asks how many people are on the team. The useful question is how many days until you see something working. Your approval cycle takes longer than the MVP. Your committee reviews CVs when delivery is the only thing that can be verified. So you pick the slow vendor. Every time. The form decides before you do. Nobody is going to tell you the vocabulary changed. There's no internal memo. And your current vendor has no incentive to mention it. Falling behind on technology is fixable with a cheque. Falling behind on how the work you buy gets organised is not. I found out over coffee. When was your last coffee like that?