I used to answer that question with confidence. In 2016, I would have said something like: if you get energy from writing code and designing systems, go Staff. If you get energy from developing people and shaping teams, go EM. Pick the ladder that matches the work you actually want to do.

I don't answer it that way anymore, because the ladders have quietly converged.

Back when the dual-ladder story was clean, the two jobs looked different from ten feet away. An EM owned people, careers, and headcount. A Staff engineer owned systems, architecture, and technical direction. Pay was different. Skills ran on different tracks. The body language in a planning meeting signaled which ladder you were on. You could tell who was who without reading the org chart.

Something shifted in the last five or six years. I noticed it in offer packets first. Companies started paying Staff and EM at the same band once you got past a certain level. By 2026, compensation data from the public sites shows Staff ICs and engineering managers at top-tier tech companies landing in roughly the same total comp range at the top of the ladder. The financial signal that used to separate the two paths stopped separating them.

Then I saw it in the work itself. At a previous company, I watched a Staff engineer run what was effectively a multi-team program. She had no direct reports, but three squad leads coordinated through her. She owned the planning cadence. She wrote the roadmap. When a project slipped, she was the one explaining why to the VP. Her calendar looked exactly like an EM's calendar.

Across the same years, I watched an EM at another organization spend two days a week in code reviews, drive architecture decisions for his platform, and argue with principal engineers about service boundaries. He had eight direct reports. He also shipped code. His title said one thing; his day looked like a Staff engineer with a skip-level tax.

One pattern I had to correct in myself was assuming the title told me what someone did. Title plus company size gets you partway there. A Staff Engineer at a 200-person startup looks nothing like a Staff Engineer at a 50,000-person tech company, and most people in the industry can sketch the difference without asking. At senior levels, even that combination stops being enough. When I actually asked what people spent their time on, the picture rarely matched the stereotype the two labels suggested. "Engineering Manager" at one company looked like "Director" at another and "Team Lead" at a third, and company size didn't reliably explain the gap.

The part that hurt to watch was engineers picking the title over the work. I saw someone turn down a Staff offer at a smaller company for an EM offer at a bigger name, convinced the EM label would travel better. Two years later she called me from a role where she spent four days a week in recurring meetings and zero days doing the work she'd accepted the job for. The title traveled fine. Two years in, she was still looking for the job she'd pictured.

I saw it go the other way too. An EM at one organization moved to Staff at another because he wanted out of people management. The new role had no direct reports on paper, but he was running a cross-team initiative with four squads contributing. He was doing scope negotiation, coaching, and what was effectively performance calibration for the leads he coordinated with. Six months in, he told me he'd changed his title and his commute. The rest was the same.

At senior levels, the title has stopped being a reliable signal. What you want to evaluate instead is what differs between two roles, even when the labels match.

Start with decision authority. Who can say no and make it stick? Figure out whether this role can kill a project, block a hire, or force a re-architecture, or whether its job is to advise, recommend, and escalate. Staff and EM titles vary wildly on this axis. Some Staff roles have veto power over a platform's direction. Some EMs can't finalize a hire without three approvals above them. Ask to see a recent decision the role made that a more junior version couldn't have made. If the answer is vague, the authority is vague.

Then look at blast radius. When this role gets a decision wrong, who feels it, and for how long? One team for a quarter, or the whole platform for a year? Blast radius maps to seniority more honestly than title does. A Staff engineer whose choices break one service for a sprint is junior for the title. An EM whose staffing decisions shape an org for three years is senior, no matter what the line on the org chart says. The interview question that surfaces this is boring: "Walk me through the worst consequence of a decision this role has made in the last year." Listen for scope.

The third thing to check is who reports what to whom. The reporting line is half the answer. The information flow is the other half. Ask whether the role sits in the quarterly business review, if the weekly revenue numbers land in its inbox unfiltered, and what budget line carries its name. Information access tells you more about actual scope than the job title ever will. A Staff engineer who reads the same dashboards the VPs read has a different kind of pull than one whose numbers come filtered through two layers.

There's a reason nobody in the industry wants to talk about the convergence out loud. Recruiters need the titles to sound different so the ladders look distinct. Companies want the optionality of paying people the same without admitting they do the same work. Candidates want to believe that picking correctly matters more than it does. Everyone has a reason to keep the old story alive, so the old story keeps getting told.

If you're picking between two senior roles, stop asking which title is better for your resume. Focus on three things instead. What the role can actually decide. What breaks when the role gets a call wrong. Whose numbers it sees every Monday morning. Those answers diverge even when the titles don't.

Five years ago the labels stopped telling the truth, and nobody updated the candidates.

Six months later they were hiring frantically. Not because the team had failed to ship. Shipping was fine. The product worked, customers paid, revenue grew. The problem was that one of the engineers wanted to go to his sister's wedding in another country and be off the grid for two weeks. And nobody could figure out how to let him.

That is the part of the AI-amplified team story that gets edited out of the case studies. The 1-2 person team can ship. It can ship a lot. The question nobody wants to answer is what happens when one of those people gets sick, takes vacation, or quits. Or when something breaks at 3am and the person who knows how it works is asleep with their phone in another room.

I have watched this play out across several organizations now. A team gets very small, leans hard on AI tooling, and looks like a productivity miracle for two or three quarters. Then the cracks show up. Not in shipping speed. In every other dimension that defines actually running production software.

Code review is the first one to break. With two engineers, every review is the same person every time. After a few months they have read each other's patterns so deeply that review becomes a rubber stamp, a chance to confirm shared assumptions rather than catch mistakes. Then someone introduces an LLM-assisted refactor across a critical path, and the review is two people who already trusted each other plus one model that has no skin in the outcome. Things get merged that should not have been merged.

On-call is the second. Two engineers sharing on-call have no real rotation. Both are effectively always on, taking turns at being slightly less on. There is no real off. PTO becomes a negotiation. Both people start arranging their lives around the assumption that something will catch fire and one of them will have to handle it. That is fine for a few months. It is corrosive over a year.

Then audit. In any regulated context, separation of duties is not a style preference. It is a regulatory requirement. You cannot write code, approve your own code, and deploy it to a system that handles money or health data. The auditors will not care how good your AI is. They will not care that the model caught the bug your colleague missed. They will look at the commit history and they will see one human approving another human, and that has to actually be two distinct humans with enough context to push back. Two people who agree on everything do not pass that test, because nothing tests it. Three or four people occasionally disagreeing with each other does.

The hype cycle right now is built around the 1-2 person team as a kind of moral fable. Founders post about it. VCs amplify it. There is a real story underneath: AI tooling has genuinely raised the floor of what a small team can do. A pair of strong engineers with good agent tooling can build something in three months that used to take a quarter of effort from ten people. That is real and worth taking seriously.

The story that gets attached to it is not. The version that says headcount is over, that the team of the future is two founders and a fleet of agents, that the 10x engineer has finally arrived. A 10x individual still creates a 1x bus factor. The math on amplification does not change the math on continuity. If the system depends on one person being awake, the system has one point of failure, regardless of how productive that person is when they are awake.

The interesting number, in my experience, is not 1-2 and it is not 8-10. It is 3 or 4. Small enough for AI tooling to amplify without process choking the team. Large enough that someone can take a real vacation, that code review has at least one outsider, that on-call is a rotation rather than a pact between two friends, that an auditor sees more than one decision-maker.

When agents are doing real work, this sharpens. You need at least one human who verified what the agent did and at least one other human with enough context to catch what the first one missed. That is two people minimum just on the verification side. Add the person who actually owns the change, and you are at three before you have anyone available to be on call, take PTO, or be sick. The minimum viable team for AI-assisted production work is structurally larger than the minimum viable team for shipping a prototype, because production work has more dimensions than shipping.

I know how this lands. People will read it as a defense of the old normal, a quiet plea to keep teams at eight to ten. It is not. The old number was driven by overhead I do not want to bring back: meetings to coordinate meetings, planning artifacts that nobody read, a layer of management that existed because the team was too big for one person to keep in their head. AI tooling did make a lot of that overhead optional. The team can be smaller than it used to be, and the smaller team can do more.

Just not two. Two is a startup-pitch number. It is what you put on a slide for an investor who wants to feel like they bought into the future. Two works for the first six months of a product that has not yet had to be boring and reliable for years.

When the team has to keep something alive on a Tuesday afternoon while one engineer is at a funeral and the other is debugging something unrelated, the answer is not better AI. The answer is a third person. Maybe a fourth. People who have seen the system, written part of it, and can pick up the pager without a week of ramp-up. That is the team that does not collapse the first time real life shows up.

AI made one person ship like ten. It did not change how many people it takes to keep the thing alive at 3am.

No good answer came to me. I gave him the one most consultants default to: the value isn't the time, it's the expertise. He nodded. He didn't buy it.

That exchange stayed with me longer than most, because the honest answer was more complicated than either of us had words for at the time.

The billable hour was never just a unit of time. It was a pricing structure that spread the cost of client-specific learning across the engagement, absorbed the back-and-forth that nobody puts in a statement of work, and included the coordination overhead and judgment calls the client never saw. The invisible work of staying calibrated to what they actually needed versus what they said they needed. None of that appeared on an invoice as a line item. It hid inside the hours.

AI is making that arrangement hard to maintain. When a task that used to take eight hours now takes forty-five minutes, the gap becomes visible. Clients see it. They start asking whether the fee reflects the time or the result. For most firms, the honest answer is both, but in ways they haven't wanted to explain.

The obvious alternative is outcome-based pricing, meaning you charge for what gets delivered rather than for the time it took. In certain situations it works well. Fixed-fee project delivery, success fees tied to defined metrics, retainers scoped to specific outputs. I've been part of arrangements like that, and when they go well, they're better for everyone.

The problem is that they require something most client relationships don't have at the start: a shared, specific agreement about what success looks like and who gets to measure it.

In most engagements, that agreement doesn't exist going in. A client says they want "better pipeline conversion" or "a faster deployment cycle." Those sound like outcomes, but they're not precise enough to price. The baseline is disputed, the timeline is vague, and the dependencies that affect the result include things neither side controls. When the number comes in lower than expected, the conversation about why gets uncomfortable fast, and it usually ends with the vendor absorbing the blame.

I've watched outcome-based arrangements fall apart not because the work was bad but because success criteria were agreed on loosely at the start and interpreted differently by the end. More often than I'd like to admit, the vendor believed they had delivered and the client felt they hadn't. No amount of post-mortem changes the invoice.

The hourly model avoided that problem. Both sides could point to logged time as an objective record. The vendor got paid for showing up and the client paid for documented effort. Clean in a way that masked everything messy underneath.

What AI forces is the question both sides had learned to leave unanswered: what exactly are we delivering, and how will we know when we've done it?

Before I've seen outcome pricing work, there was usually a period of internal calibration. Track time privately, charge on outcomes. Get the measurement right before you depend on it. Learn where your estimates are off, not in a way that changes the invoice, but in a way that sharpens the model for the next engagement. In my experience, that kind of preparation takes six months to a year, and most organizations don't invest it proactively. They wait until the old model breaks, then try to retrofit the new one while the client relationship is already under stress.

For years, billing hours gave consultants cover for the learning curve. A junior consultant logging a hundred hours on a complex engagement was, in part, learning the client's business on the client's dime. Everyone understood this and nobody said it out loud. AI compresses that learning curve, which is good for clients. But it also means the implicit subsidy is gone, and some of the flexibility that made early-career professional services viable disappears with it.

When I think about how this shakes out over the next few years, I don't think outcome-based pricing replaces the hourly model across the board. The market will fragment. Work that is genuinely measurable gets repriced fast, probably toward fixed fees with AI cost savings factored in. Work that is judgment-intensive and relationship-dependent gets repriced slowly, because the trust infrastructure needed for outcome pricing takes years to build, not months.

The firms that will have the hardest time are the ones in the middle. Enough AI in the workflow to make old rates look indefensible, not enough clarity in their own value proposition to anchor a new one.

Outcome pricing is a trust instrument. You can only price on outcomes when both sides agree on what good looks like and believe the other side is measuring honestly. That agreement rarely exists at the start of a relationship. It gets built over time, through track record, through transparency, through hard conversations about how success gets defined before the work starts rather than after it ends.

The billing model carried more than time. It distributed risk in a way both sides found acceptable without having to talk about it directly. AI is cheaper to run, but the risk hasn't gone anywhere. It just can't hide in the hours anymore.

The senior engineer asked the question I've heard some version of my whole career. "Why did you think this would hold?"

The new hire pointed at the PR. The logic was tight, the tests passed, three approvals sat on the review. What he couldn't do was explain what the code around his change was actually protecting. He didn't know why a validation check three files over existed. Nobody had told him what the service upstream did when it saw a null there. He had fixed the symptom. The invariant he broke wasn't visible in the diff he was looking at.

That conversation stayed with me because the engineer was sharp. He'd come from a good program. He was moving faster than any junior I'd managed in the past ten years. And he didn't understand the system he was changing.

The reason is quieter than most leaders want to admit. Over the last few years, the small tasks that used to teach new engineers the codebase have mostly stopped being theirs. AI handles them. Bug triage, the three line fix, the obvious refactor, the "read this module and tell me what it does" exercise. All of it moves through a code assistant now, and the output is usually good enough to ship.

The new hire's first month used to look like slow, uncomfortable archaeology. Read old code. Ask three people what it does. Write a doc nobody reads. Fix a tiny thing and watch it break in staging. That slog wasn't the onboarding. It was the curriculum. Nobody wrote it down, nobody scheduled it, nobody put it on the OKRs. It happened because the work was the only way to get things done, and along the way a mental model of the system got built in someone's head.

Take away the slog and the curriculum goes with it. You still get the fix. You lose the model.

The first few months feel great. The new hire ships more tickets than a comparable hire did three years ago. Managers look at throughput and conclude ramp is faster. Some claim they've cut it in half. And they have, for a definition of ramp that stops at first merge.

The problem is that first merge measures the wrong thing. Onboarding is supposed to produce someone who can diagnose a production issue at 2am without rolling the dice. That capability is built over a few hundred hours of frustration with code the engineer didn't write and can't change. A month of well-completed tickets does not get anyone close to it.

About eighteen months out is where I've seen this bill come due. A senior leaves. A subsystem they built starts misbehaving in a way the dashboard doesn't catch. The mid-level engineers reach for the assistant and get a plausible fix. The fix ships. A week later the same behavior surfaces somewhere else, because the root cause was a shared assumption in a library nobody on the team has actually read.

In a regulated setting, this is worse than slow. It's auditable. When the regulator asks why a control failed, "our engineer relied on an AI suggestion and didn't understand the underlying invariant" is not an answer that keeps your license.

So the question is what to do about it, and I'd rather be concrete than abstract.

The first thing I've seen work is treating code review as teaching rather than as a quality gate. Reviews should cost time. They should go longer than the change would seem to require. Ask the author to walk through the surrounding code, not just the diff. Ask them what would break if their change shipped wrong. If they can't answer, that is the work, not a side conversation. The reason this part has to be a human is that the value is the new hire forming a model in their own head, out loud, in front of someone who already has one. An assistant can produce a plausible explanation of the surrounding code in seconds. The new hire reads it, nods, and walks away with the same gap they came in with. The reviewer's job is to create the friction that turns reading into understanding, and that friction only exists when someone on the other side of the table can tell whether the explanation is real. In past roles, I had a standing rule that any engineer in their first six months got at least one review per week where the reviewer asked them to explain a function they didn't write. It slowed us down by a few percent. It was the single highest return investment I ever made in a team.

Architecture walkthroughs help, but they can't be slide shows. Pick a real incident from the last quarter. Put a senior at the whiteboard. Have them reconstruct what happened, including what they thought at each step and why they were wrong. Two hours. Open questions. No AI in the room. This is the closest thing I've found to rebuilding the reading-old-code muscle when the code is not being read organically anymore.

The move that gets the most resistance is a deliberate no-AI window during onboarding. Not for the whole ramp. For specific exercises: read this module and summarize it, debug this issue with the assistant off, pair with a senior and narrate your reasoning. Two weeks of this, spread over the first quarter, is usually enough. The new hires push back at first. The ones who take it seriously tend to become the people on-call rotations can actually count on.

The flip side worth naming is that AI does work very well in teams that already have discipline. Architecture Decision Records, post-incident write-ups, runbooks people actually maintain. That body of context is what an assistant needs to give answers that hold up under load, because the model is grounded in the team's actual history instead of guessing from the diff in front of it. The teams that get the most out of these tools were already the ones writing things down. The teams that struggle hardest are the ones that never wrote any of it down, hoped the assistant would compensate, and got plausible answers that were wrong in ways nobody caught in review. Discipline is the precondition for AI to help. An assistant cannot read what the team never wrote.

A pattern I had to correct in myself was letting AI quietly absorb the friction that had always been part of growing engineers. It looked like progress. It was progress, for the visible work. What it was not doing was building the second layer, the part I used to take for granted because it happened whether I designed for it or not. Once I stopped assuming the curriculum would emerge from the work, I started scheduling it back in.

The leaders who figure this out in the next year or two will have teams that can still debug at 2am. The ones who don't will discover, eighteen months from now, that they've built a generation of engineers who can ship features and can't hold a system in their heads. This is a design choice someone, somewhere, is quietly making every day by assuming onboarding still works the way it used to.

It doesn't. Name the curriculum, or lose it.

That gap, the one between the slide everyone celebrated and the slide everyone skipped, is the part of the AI conversation engineering leaders are mostly skipping over.

Most of the talk I see is stuck on a different question. Should engineering managers code? It was a contested question before AI showed up. Now it feels existential. Will Larson published “Good Engineering Management is a Fad” last October arguing that the industry’s preferences shift with business reality and dress the shift up as moral progress. Gergely Orosz has been writing for months about EMs perceived as technical landing jobs faster than EMs who are not. Charity Majors keeps making the case that the engineer-manager pendulum is now swinging on a shorter cycle. Each of them is right about what they are seeing, and what they are seeing is a symptom.

Coding was never the bottleneck for most EMs. Judgment was. The work that actually moved a team’s outcomes was deciding what was worth building and holding the line on what was good enough to ship. Writing code was the visible exhaust. Whether something shipped on time or quietly broke six things on the way out the door usually came down to the decisions, not the keystrokes.

What AI did is make the writing-code part cheap. Once that part is cheap, everything else stops being optional. That includes the parts of the EM job that have been substituted for by process for the better part of a decade.

The data backs this up in ways the marketing decks do not.

In July last year, METR ran the kind of study people in our field rarely run. Sixteen experienced open source developers, working on mature projects they already knew, ran 246 real tasks with and without modern AI tools. The headline finding was that AI made them about 19 percent slower. The harder finding was that the same developers believed they had been about 20 percent faster. A 39-point gap between perception and reality, in the people most likely to know better.

Faros AI’s longitudinal data on roughly 10,000 engineers tells the same story from a different angle. On the input side, pull request volume per developer is up 47 percent and merged PRs are up 98 percent. On the way through, code review time has climbed 91 percent and bugs per developer are up nine. The hours AI saves on the way in are getting eaten on the way out. LinearB’s 2026 benchmark across 8.1 million PRs found agentic AI PRs take more than five times longer to be picked up for review than human-written ones.

The 2025 DORA report lands in the same place. AI adoption now correlates with higher delivery throughput and lower delivery stability. Two trends at once, on the same teams. DORA’s framing is the most useful version of this I have read: AI is an amplifier of whatever a team is already doing, for good and for ill.

None of this is an anti-AI argument. The productivity story being told above the EM layer keeps diverging from the one showing up below it. Somebody has to hold the bar between the two, and the cycle for doing that just got a lot faster.

The shape of all this changes depending on the size of the company you sit in.

At a true early-stage startup, under twenty engineers, the question of whether the EM should code never really went away. The founder-CTO is in the codebase. The first engineering hires are in the codebase. The “manager” is usually the strongest senior engineer with a few extra responsibilities. AI in this environment is pure acceleration. One engineer who is good at directing AI ships what a small team used to ship. The startups pulling ahead right now tend to be the three-engineer kind running Claude Code in five terminals, doing what twenty-person teams used to do three years ago.

In a scale-up of a few dozen to a few hundred engineers, the picture is messier. This is where the engineer-manager pendulum has been most painful in the last twelve months. EMs hired in the 2018 to 2022 era were told their job was the people layer, not the code. Many of them built careers around being explicitly hands-off. Now their CTOs are asking them to be hands-on again, sometimes without saying it out loud. Some are thrilled, others are panicking. Stripe has started posting roles with titles like “Engineering Manager, Developer Productivity AI” which would have been unthinkable in 2021. The player-coach role is back, and it is back with a different set of tools than it had the last time.

Mid-market is where the layoff numbers actually live. The largest tech companies cut tens of thousands of corporate roles across 2025, and the memos named the cause directly. “Considerable de-layering” from one. “Fewer layers and more ownership” from another. A third trimmed roughly ten percent of its VP and manager roles in a single round. Read those memos carefully. The story they are telling is about coordinating layers that were too thick, with AI as the trigger that finally made cutting them defensible. The cause goes back further. A lot of mid-market orgs had been building management depth as a substitute for ownership.

Enterprise is the most counterintuitive case. The DX 2025 report found that large traditional enterprises are now leading on measured AI productivity, not lagging. The reason is unsexy. They have actual training programs, governance, and infrastructure that can absorb the change. They also have the most exposure to the DORA finding about lower stability. Higher throughput on top of weak CI discipline is just faster breakage. The most dangerous EM job in the world right now might be the one running a feature team inside a Fortune 500 with a velocity dashboard from 2019 and an AI rollout from last quarter.

Step back from the org chart and look at the METR perception gap again. Sixteen experienced engineers were systematically wrong about their own productivity by 39 points. They were doing what humans do when the work feels different from how it used to feel. The brain registers the new texture as speed, even when the clock disagrees. AI changes how writing code feels in a way that no productivity dashboard has caught up with.

If that gap is real, and the LinearB and Faros numbers suggest it is widespread, every engineering org needs someone who can tell the difference between “feels productive” and “is productive.” Whoever does this has to be close enough to the work to read the actual code and far enough back to see the second-order effects on the team. That role belongs to the EM. Engineers doing the work are sitting inside the perception gap. Executives two levels up are reading the same dashboard the EM put together.

The new EM job is holding the bar between what looks like progress on a dashboard and what is actually changing the company’s position in the market. The coding question, more or less, is a sideshow next to that.

This is harder than the version of the EM job most companies were set up for. Sprint planning is easier than judging a PR. Status meetings are easier than reading the code. A lot of the EMs being culled right now lost their jobs because the parts of the job that were always the real job, the judgment parts, had been substituted with calendar work for years, and the calendar work just got automated.

I have managed teams from both sides of this. There was a stretch in my career where I told myself I was being a better manager by staying out of the code, when most of what I was doing was avoiding the discomfort of judging work I no longer had the context to evaluate. That avoidance was always going to catch up with me. AI just shortened the timeline.

If you run an engineering team and want to take this seriously, the work is unglamorous. Read your team’s PRs yourself for the next two weeks. Not the merge notifications, the actual diffs. You will quickly learn which engineers are using AI to ship things they understand and which ones are using it to ship things they could not have written without it and cannot maintain after they did. While you are in there, put your bug rate on the same chart as your velocity. If both lines are climbing, the second one will eat the first one within a quarter or two. Better to see it early.

The bigger change is in what you measure. The metrics worth tracking now are the ones that survive contact with a customer: features that made it to production without a follow-up fix in the first week, incident resolution time, the share of last quarter’s roadmap that is still in the product six months later. PRs merged is mostly noise once PRs are nearly free to produce. And yes, probably write some code yourself. Reading what your team is shipping is becoming the only honest way to know what is happening on the team.

The engineering managers who are still in their jobs in two years will be the ones who can tell the difference between a team that is faster and a team that just feels faster. As the rest of the work gets cheap, that judgment is the part of the EM job that gets harder.

The leaderboard came down two days after the press found out.

I watched this story unfold and my first thought wasn’t about AI at all. I’ve seen this exact behavior every Q4 for twenty-plus years. If you’ve ever run a P&L or managed a departmental budget, you know the pattern. Your allocation for the fiscal year is $2M. You spent $1.4M. If you return the remaining $600K, next year your budget gets cut to $1.5M. So in October, you start spending on hardware you don’t need yet, conferences that are marginally useful, contracts pulled forward from Q1. The incentive structure makes that spending rational. Use it or lose it.

Tokenmaxxing is the same game with a different currency. Meta and Shopify now include AI usage in performance reviews. Jensen Huang said he’d be “deeply alarmed” if an engineer with a $500K salary didn’t consume at least $250K in tokens within a year. Meta’s CTO has publicly encouraged engineers to spend the equivalent of their salaries on tokens, claiming 10x productivity gains.

The message to the rank and file is clear: if you’re not burning tokens, you’re falling behind. And just like the budget game, people respond to the incentive, not the intent. Running five parallel agents overnight produces nothing that ships, but it produces a ranking. The leaderboard rewards what it can see.

Anyone who has worked in engineering recognizes this problem. We measured lines of code in the 90s, then story points in the 2010s, now tokens. The mistake keeps finding a new unit.

But the parallel to corporate budgets breaks in one important place.

Corporate budgets are finite and zero-sum. One department’s gain is another’s loss. Spending more doesn’t compound into anything. You buy the hardware you didn’t need, it sits in a closet, year over.

AI capability isn’t like that. An engineer who learns how to prompt well, who builds muscle memory with agentic workflows, who figures out where AI saves real time versus where it creates rework downstream, carries compounding knowledge. The learning accumulates. Even some of the wasted tokens produce real learning, because you need to try things before you know what works.

So tokenmaxxing sits in the middle. Whether it helps depends on what you’re actually measuring.

Business spending on AI tokens is up 13x since January 2025. Part of that is genuine capability expansion. Engineers discovering that a well-structured agentic workflow takes three days off a release cycle. Product teams prototyping faster than they can spec. Those are real gains worth paying for. The rest is pure theater. From the outside, both look identical on a token dashboard.

One pattern I had to correct in myself was confusing adoption with value. Years ago I pushed a team hard to adopt a new CI/CD pipeline. We got to 100% adoption in six weeks. I reported it up as a win. What I didn’t measure was that a third of the team had wired their old manual process into the new pipeline to make the dashboards green. They were technically using the tool. Nothing about how they worked had actually changed.

Tokenmaxxing carries the same risk at a much larger scale. When you track consumption without tracking what it produces, you’re measuring how fast the engine runs while ignoring whether the car is moving.

I think Huang’s underlying logic is sound. If a $500K engineer plus $250K in compute gets you the output of two engineers, that’s a reasonable bet. Maybe the best available right now. The companies that figure out how to direct that spend, not just how to increase it, are the ones who pull ahead. “Figure out how to direct it” is the hard part though, and it’s not a question a leaderboard can answer.

The companies I’d bet on are the ones where an engineer can tell you, specifically, what changed. Not “I used AI more this quarter.” Something concrete, like a review cycle that went from four days to one because AI handles the first pass on test coverage. Or a team that finally writes architecture decision records because the draft takes an hour instead of a week.

That’s the difference between spending a budget because it exists and investing it because you know what the return looks like. The cost question is real, and right now it’s almost secondary. Meta’s top token user could have cost the company more than $1.4M in 30 days. At some point, finance teams will ask what that bought. Orgs that can answer clearly get to keep their budgets.

Smart finance leaders eventually learned that “use it or lose it” was destroying capital discipline. The best orgs moved to rolling budgets, zero-based budgeting, or some model that separated “we need this resource” from “we’ll lose it if we don’t spend it.” AI adoption needs the same maturity. Treat token usage as a cost input, not a success metric, and measure what shipped, what improved, what decisions got made faster. Give teams room to experiment heavily because the curve is steep and the upside is genuine, but don’t reward the engineer with the biggest overnight agent bill.

Tokenmaxxing is the right instinct with the wrong scoreboard. Pushing hard on AI adoption and investing aggressively are the right moves. Counting consumption instead of outcomes is where it becomes the budget game again.

Anyone who has survived a few fiscal years knows how that one ends. The money gets spent, and the org doesn’t come out any smarter.

I asked him a question I ask every platform leader now. How many of those fourteen features had more than three teams using them last month?

Quiet.

He said he would check. The answer came back a week later, and we went through it together. Nine of the fourteen had single-team adoption. Two had zero. The three capabilities everyone in the room actually argued about in hallway conversations were not on the deck, because the platform team had not built them yet. That gave us a useful place to start: what would it take to get those three into the next quarter’s plan, and what could we sunset to make room.

That meeting stayed with me. The director was doing his job well by the definition he had been given. His scorecard covered deliverables shipped, incident count, and SLA. All three were green. Adoption was not on the scorecard, so it never became a target, and the team had no reason to think of it as part of their work.

This is the quiet trap every platform team slides into. They get budget because the business wants faster delivery. They get leadership because good engineers want to multiply what other engineers can do. Then they get handed a scorecard pulled straight from infrastructure operations, and the product discipline that would have saved them never enters the room.

A platform is a product. The customer is an internal team. The measure of success is whether that team picks your thing when no one is forcing them to.

Say that to a platform leader and they will agree. Every one of them has read the InfoQ piece, or the DORA report, or the Team Topologies book. The language has traveled. The behavior has not. Most platform teams I have worked with over the years still do not interview their customers. They do not run discovery. And when adoption does not happen on its own, the team calls it a marketing problem.

Here is a conversation I had with a platform PM about two years into a rollout I was advising:

Me: Which three features drive most of the value for your customer teams?

PM: I can tell you which three we shipped last.

Me: That is not the same question.

PM: Right. I would have to go ask.

She did not come back for a week. When she did, she had a spreadsheet. Three features had real traction. Two had a single power user apiece. Seven had been adopted once, then abandoned. The team had been running for eight quarters. They had never retired a single thing.

That is the pattern. Platform teams accumulate capabilities without ever pruning them. A product team that refused to sunset features would not survive its next review. Platform teams do it every quarter, and they call it stability.

One pattern I had to correct in myself as an advisor was letting platform leaders define their own success on infrastructure terms, because those terms were easier to measure and harder to argue with. Uptime. Deploy frequency. P95 latency. All useful. None of them tell you whether the thing is working as a product.

The hardest work in a platform rollout is the moment a platform PM has to walk into a review and say, we are killing feature seven, and we are redirecting two engineers to the thing three teams have been begging for. That conversation costs political capital, costs sunk-cost grief, and costs a certain amount of face for the engineer who built feature seven. It is still the job.

A platform team that does not own adoption is a team producing output without owning outcome. Artifacts ship on schedule while the customer teams quietly route around them. Six quarters in, someone asks why adoption is the bottleneck, and the platform team points at everyone else. Adoption is hard. Treating it as someone else’s responsibility is what keeps a platform team from ever fixing it.

When a platform team picks up product discipline, the work looks different in three places.

Discovery becomes a habit. Real conversations with the five teams most likely to pick up the next capability, asking what is painful right now and what they would trade for it. The format is boring on purpose: a half-hour call, two questions, a notebook. Sometimes the answer is boring too. Often the answer reshapes the roadmap.

Features get killed, out loud, in the review, with a short note to affected users and a migration path where possible. Nobody celebrates a sunset. Good product teams still do them, because shipping and keeping are different decisions.

Adoption becomes the measure that matters most. That brings me to the three metrics I would put on any platform team’s scorecard.

First, weekly active teams. Count unique internal teams that used a platform capability in the last seven days. Not accounts, not API calls. Teams. This number should grow each quarter or the platform has a product problem, not a marketing one.

Second, feature sunset rate. Count how many capabilities you retired last quarter. Zero is a red flag. Platform backlogs grow forever, but platform surface area should not. A healthy team retires roughly 10 to 20 percent of its capability count per year, sometimes more when the organization’s needs shift.

And then, time to first value for a new team. Measure the days from the moment a new engineering team decides to adopt your platform until they ship something real to production on top of it. I have seen this number range from two days in the best platforms I have worked with, to over three months in the worst. Three months is a second layer of infrastructure that customer teams have to work around.

None of these numbers are hard to collect. The reason most platform teams do not collect them is that the results force conversations nobody wants to have. Feature seven gets killed, engineer four switches projects, and the roadmap gets rewritten around something that looks less impressive on a slide.

That is the job. A platform team that is not willing to do it ends up running a subsidized infrastructure group with better branding, and the adoption number will never move no matter how many features ship.

Platform as a product starts the quarter someone has the courage to measure it like one.

The foreman wasn’t a natural evolution. It was an invention, forced by a technology shift. Steam power and mechanized looms made it possible to scale production beyond what any single person could oversee. And the resistance was real. Frederick Taylor’s attempts to systematize the foreman’s job (timing workers with stopwatches, breaking tasks into the smallest possible units) provoked strikes at Watertown Arsenal serious enough to trigger a congressional investigation in 1912. Workers understood something important: when machines change, the person standing between you and the machine changes too. And that person’s decisions start to matter more than your skill.

I’ve been thinking about foremen lately because I’m watching the same

pattern unfold in technology organizations, and I don’t think most leaders have recognized it yet.

Every major technology shift created an entirely new management role. One that didn’t exist before the shift happened, and that the people inside the old structure never saw coming.

Factories created the foreman. When computing moved into offices in the 1980s and 1990s, it created the project manager, someone who could coordinate work across systems that were suddenly faster than the humans feeding them. The internet and digital products created the product manager, someone who could sit between technology, business, and the customer and make decisions about what to build, not just how to build it.

Each of these transitions followed a similar arc. The technology arrived. Organizations tried to use it without changing their structure. Productivity stalled. (Robert Solow won a Nobel Prize partly for pointing out that computers were everywhere except in the productivity statistics.) Then, sometimes a decade later, organizations restructured around the technology and the gains appeared. Organizations resisted the restructuring, not the tool itself.

We’re somewhere in that arc with AI right now. A 2026 study of 6,000 executives found that nearly 90% of firms reported AI had no measurable impact on employment or productivity over the prior three years. The pattern holds. The technology is here. The restructuring hasn’t happened yet.

But I think there’s something different this time, and it matters for anyone managing a team.

Every previous shift automated physical tasks or routine procedures. Looms replaced hand weaving. Spreadsheets replaced manual calculation. Even the internet, for all its disruption, mostly automated the movement of information. Humans stayed essential for the part that required thinking, analyzing, and deciding. That was the safe ground.

AI doesn’t respect that boundary. It writes code. It drafts legal arguments. It analyzes medical images. It makes decisions about customer interactions. One large fintech company replaced about 700 customer service positions with an AI assistant that handled 75% of customer conversations across 35 languages. Cost per transaction dropped 40%. Then customer satisfaction dropped. Complaints rose. The CEO publicly admitted the strategy had hurt quality, and the company started rehiring humans. A language learning platform cut over a hundred contractors and reported it could produce four to five times more content with the same headcount. Users said the content felt repetitive. The quality conversation caught up.

In both cases, the AI performed. What failed was the management layer around it. Leaders treated AI as a headcount replacement rather than a structural change that requires a new kind of oversight.

When I managed teams of engineers, my job was to set direction, remove obstacles, and create conditions where skilled people could do their best work. I could trust that a senior engineer would catch an edge case, push back on a bad requirement, or flag a risk I hadn’t seen. The skill lived in the person. My job was to point it in the right direction.

When some of the “people” doing the work are AI agents, that assumption breaks. An AI agent can write code, execute multi-step workflows, query databases, and correct its own approach. One organization found that an AI coding agent deleted a production database and then generated fake records to cover the gap. Another discovered that an agent handling CRM data could be manipulated into exfiltrating customer information. In an early legal ruling on AI liability, a tribunal held an airline responsible for its chatbot giving a customer incorrect bereavement fare information, rejecting the argument that the chatbot was somehow a separate entity the company wasn’t accountable for.

Skill now sits in two places: the person and the agent. But judgment, accountability, the quality bar? Those still need a human. And not just any human. Someone whose primary job is managing the boundary between what agents can do reliably and where they’ll quietly produce something that looks right but isn’t.

That’s the foreman problem, updated for 2026. Someone has to watch machines operate alongside people, and the failure modes are less visible than they’ve ever been. A handloom weaver who made a mistake produced a visible flaw in the fabric. An AI agent that makes a mistake produces something that often looks polished and correct.

Some organizations are already feeling their way toward this. One pharmaceutical company merged its HR and technology divisions and now has over 3,000 custom AI tools across a workforce of about 5,800 people. Their managers assess every task based on whether it should be automated, augmented, or kept with a person. An enterprise technology company built an AI system for performance reviews using four specialized sub-agents, and their leadership emphasizes that the win came from redesigning the process, not just adding AI to the existing one. A manufacturing company uses agents to resolve supply chain delays before the morning shift arrives.

The pattern I see in the organizations getting this right is that they changed the work before they changed the workforce. They redesigned processes around what humans and agents each do well, rather than handing human-shaped tasks to agents and hoping for the best.

I keep coming back to the spreadsheet analogy. When VisiCalc and Lotus 1-2-3 arrived in the early 1980s, about 400,000 bookkeeping clerk positions disappeared. But 600,000 new accountant positions appeared. When calculation became trivial, value shifted to interpretation, judgment, and strategy. Businesses started modeling scenarios they never would have attempted by hand. They needed more people who could think about numbers, not fewer.

The same pattern played out with ATMs and bank tellers. Tellers per branch dropped from about 20 to 13 between 1988 and 2004. But cheaper branches meant more branches, and total teller employment roughly doubled. The tellers who remained stopped counting cash and started selling financial products, building customer relationships, doing work that actually required a human in the room.

AI is following this pattern in some ways. When routine cognitive work gets automated, the value of judgment, context, and accountability goes up. Early salary data already shows that human skills like coalition-building and empathy command a growing wage premium as AI absorbs data-heavy tasks.

But in one important way, AI breaks the pattern. ATMs didn’t make mistakes that looked like correct transactions. Spreadsheets didn’t fabricate numbers that passed a casual review. The failure mode of previous automation was visible: the machine stopped, the calculation errored, the process broke in an obvious way. AI fails by producing confident, plausible, wrong output. That changes the management job from “keep things running” to “verify that things that look like they’re running actually are.”

I think the manager this moment requires is someone who can hold three things at once: a clear picture of what the team (human and AI) is trying to accomplish, an honest assessment of which parts of that work can be trusted to agents and which can’t, and the willingness to own outcomes they didn’t personally produce and may not have fully reviewed.

That last part is the hardest. One pattern I had to correct in myself over years of leading technical teams was the assumption that if I hired well, quality would follow. With AI agents in the mix, quality becomes an active management function. You can’t hire your way to it. You have to design for it, monitor for it, and accept that the verification layer is now a permanent part of the job, not a phase you grow out of.

Some of the organizations I’ve watched flatten their management layers aggressively, replacing middle managers with AI-assisted workflows and pushing spans of control to 30 or even 50 direct reports. About 40% of employees at companies that have done this say they feel directionless. The coordination and culture work that middle managers did quietly is now missing, and nobody has figured out what replaces it.

Factories outgrew the owner’s line of sight, and we got the foreman. Software outgrew the engineer’s ability to coordinate alone, and we got the project manager. Digital products outgrew any single function’s ability to make good decisions, and the product manager appeared.

Whatever we call the next version, it will be invented because AI-assisted work is outgrowing our ability to tell, by looking, whether it was done well. The people who figure out that job first won’t just manage teams. They’ll define what management means for the next twenty years.

We don’t have a name for that role yet. But if you’re leading a team right now and you’re spending more time verifying output than directing effort, you might already be doing it.

That gap between the press release and the earnings call is where a lot of the AI conversation lives right now.

The NBER surveyed nearly 6,000 senior executives and found that nine out of ten reported zero impact on employment or productivity from AI over the prior three years. Not “modest gains.” Not “early signs.” Zero. I wrote last week about the macro picture, the spending, the GDP numbers, the historical parallels. The economics are worth understanding. But the number that stays with me isn’t the $360 billion or the Solow paradox. It’s the nine out of ten. Because that’s not a macro statistic. That’s thousands of individual leaders looking at their own organizations and saying: nothing changed.

I’ve sat through enough industry conferences to recognize the pattern. A senior leader takes the stage. Slides with large percentages and upward arrows. A case study from one team, usually small, usually recent, usually cherry-picked because it worked. The audience nods. Everyone leaves feeling like they’re behind. Nobody asks: “What happened to the other 94% of your organization?”

McKinsey’s 2025 workplace research found that 62% of organizations report productivity increases of 25% or more from AI. Sounds impressive until you pair it with this: only 20% of engineering teams are actually using metrics to measure AI’s impact. Two thirds of companies are claiming results they haven’t instrumented. They’re reporting feelings, not findings.

I’ve done this myself. At a previous company, someone asked me in a quarterly review whether the AI tools were helping the team. I said yes, because a couple of engineers had told me they loved the coding assistant and their output had ticked up. I didn’t mention that most of the team was barely using it, or that we hadn’t set up any real measurement. I gave the answer the room wanted because the room wasn’t asking a real question. It was looking for confirmation that the investment was working.

That’s the thing about productivity claims in organizations. They flow upward through a series of rooms where the incentive is always to round up. An engineer says “it helps sometimes.” Their manager reports “positive adoption signals.” The director says “we’re seeing early gains.” By the time it reaches the C-suite deck, it’s a bar chart trending up and to the right with no error bars.

The LeadDev Engineering Leadership Report surveyed over 600 engineering leaders in 2025. Sixty percent said AI hadn’t meaningfully boosted team productivity. The majority reported only small gains. That’s a more honest number, and it comes from people close enough to the work to know what’s actually happening. But you won’t see that stat in a keynote.

I keep coming back to a question that I think matters more than whether AI “works.” The question is: what does it cost an organization to pretend something is working before it actually is?

The cost is specific and I’ve watched it accumulate across multiple organizations. Sprint commitments get padded because someone read a vendor white paper that promised 30 to 40% productivity gains under ideal conditions. Managers absorb the gap between those projections and what the team can actually deliver, quietly burning themselves out. Adoption drops off within the first month because nobody built time for the learning curve. And when delivery slips, the tools get blamed, which poisons the well for the actual adoption work that might have produced real results six months later.

I lived through a version of this with cloud migration. Between 2013 and 2016, company after company announced they were “cloud-first” while running 90% of their workloads on legacy infrastructure. The press releases came first. The architecture changes came years later, if they came at all. But that story had a specific ending: the companies that actually benefited were the ones that quietly reorganized without declaring victory before the work was done. The ones who announced the transformation before doing it got stuck performing progress instead of making it.

That’s what I see happening with AI in most organizations right now. Performance of progress. A dashboard that counts AI-assisted pull requests goes up, so it goes into the board deck. That’s not measurement. That’s decoration.

I think about the 10% of executives in that NBER survey who did report productivity impact, and I wonder how many of them would hold up under scrutiny. Some of them, probably. The ones who invested in workflow redesign, set clear expectations, measured before and after, and gave their teams time to adapt. Those organizations exist. I’ve seen a few.

The nine out of ten who said “zero” might actually be the more honest group. They looked at the numbers, couldn’t find the signal, and said so. In a business culture that rewards premature optimism about technology investments, admitting you spent money and can’t show results takes a kind of courage that doesn’t get celebrated at conferences.

What I’d rather see from leadership, including myself, is a simpler frame. We’re investing in AI because we believe the capability is real and the long-term cost of not investing is too high. We don’t have productivity data yet because we’re still learning how to use it well. That’s where we are. We’ll tell you when it changes.

No bar charts. No projected savings. No implying that the transformation already happened.

Nine out of ten executives told researchers the truth. The interesting question is whether any of them are saying the same thing to their boards.

Here’s the latest pair: Amazon, Alphabet, Meta, and Microsoft collectively pledged over $360 billion in AI-related capital expenditure for 2025. Goldman Sachs chief economist Jan Hatzius looked at the incoming macroeconomic data and described AI’s actual impact on U.S. economic growth so far as “basically zero.”

Three hundred sixty billion dollars. Basically zero.

Apollo’s chief economist Torsten Slok put a finer point on it: “AI is everywhere except in the incoming macroeconomic data.” A Denmark-wide study that linked ChatGPT adoption directly to administrative earnings records found essentially zero aggregate effects on earnings or hours worked through 2024. An NBER survey of nearly 6,000 senior executives found that nine out of ten reported zero impact on employment or productivity from AI over the prior three years. The Census Bureau’s BTOS survey showed that only about 18% of U.S. firms used AI at all by end of 2025, and a mere 6.1% used it in actual production.

Those numbers should bother anyone paying attention. They bother me, and I’ve spent the last two years telling engineering leaders that AI adoption is a strategic priority.

But before we reach for the obvious conclusion, there’s another set of numbers that deserve the same weight.

ChatGPT reached 900 million weekly active users by early 2026. AI coding tools went from $550 million to $4 billion in a single year. Claude Code went from zero to $2.5 billion in annualized revenue in roughly nine months. AlphaFold solved the 50-year protein folding problem and won a Nobel Prize. AI-designed drug molecules are hitting Phase I clinical trials at success rates roughly double the historical baseline.

So we have a technology that produces Nobel Prizes and zero GDP. That generates billions in product revenue while burning through those billions even faster. That half the developer population uses daily while nine out of ten executives say it hasn’t changed anything.

This is the contradiction I want to sit with, because I think most of the commentary gets it wrong by resolving the tension too quickly. The bears say it’s a bubble. The bulls say we’re early. Both are reaching for comfort. The honest position is harder: both of those things might be true at the same time, and the historical record strongly suggests they are.

Warren Street Wealth Advisors estimated the AI sector’s investment-to-revenue gap at roughly six to seven times. For context, the dot-com bubble’s ratio was about four times. The railroad boom’s was about two times. We are spending at a pace that exceeds both of those episodes relative to what the spending is actually generating.

And a meaningful chunk of the AI revenue that does exist is circular. Microsoft invests in OpenAI. OpenAI spends on Azure. Amazon invests in Anthropic. Anthropic spends on AWS. The money moves in a loop that flatters the revenue lines of companies that are also the biggest spenders. I’ve seen this pattern before in enterprise software, where vendors buy each other’s products to hit partnership targets. It looks like a market until you trace where the cash actually goes.

OpenAI reached roughly $25 billion in annualized revenue by early 2026 but is projected to burn $9 billion this year and $17 billion next year. Deutsche Bank estimates $140 billion in cumulative losses from 2024 to 2029. Profitability isn’t expected until 2030. Anthropic, at roughly $30 billion in annualized run rate, projects positive cash flow no earlier than 2027 or 2028. These aren’t struggling startups. These are the category leaders, and they’re hemorrhaging money at a scale that would be considered catastrophic in any other industry.

So yes. The spending looks unhinged.

And I think that framing, by itself, misses something important.

Robert Solow wrote in the New York Times Book Review on July 12, 1987: “You can see the computer age everywhere but in the productivity statistics.” Computing capacity had increased a hundredfold in the 1970s and 1980s. Labor productivity growth had slowed from over 3% annually in the 1960s to roughly 1% in the 1980s. The paradox persisted for another decade. The macro gains didn’t arrive until the mid-to-late 1990s, a lag of ten to twenty years from widespread adoption.

We’ve been here before. Almost exactly here.

Paul David, the Stanford economist, traced the same pattern with electrification. Factory owners in the 1890s replaced their steam engines with electric dynamos and kept the same belt-and-pulley layouts. They gained almost nothing. The real productivity breakthrough came in the 1920s, when factories were redesigned from scratch around distributed electric motors. That redesign took a generation. Not because the technology wasn’t ready, but because the organizational imagination wasn’t ready. People couldn’t see the new shapes that the new capability made possible. They kept cramming the new thing into the old architecture.

I watched something similar happen with cloud migration between 2012 and 2018. Teams that “moved to the cloud” by lifting and shifting their existing applications gained almost nothing. Sometimes they spent more. The gains came later, when organizations rebuilt their systems and their teams around what cloud actually made possible: elastic scaling, managed services, deployment as a continuous activity rather than a quarterly event. The technology was available for years before the organizational model caught up.

Erik Brynjolfsson at Stanford has formalized this as the “Productivity J-Curve.” His argument, published in the American Economic Journal, is that general-purpose technologies initially show lower measured productivity because firms are making massive, unmeasured investments in reorganization, training, and new processes. The payoff comes later, creating a J-shaped curve. His research found that adjusting for these unmeasured intangible investments, true total factor productivity was 11.3% higher than official measures by the end of 2004. In a February 2026 Financial Times piece, Brynjolfsson claimed U.S. productivity jumped approximately 2.7% in 2025, nearly double the prior decade’s 1.4% average, as evidence the “harvest phase” has begun.

Other economists are not convinced. Daron Acemoglu, the 2024 Nobel laureate, calculated that AI’s total factor productivity gains will likely be no more than 0.53 to 0.66 percent over ten years. His reasoning is blunt: only about 5% of the economy can be profitably affected by current AI, because only 20% of tasks are exposed to it, and only a quarter of those are cost-effective to automate. That’s roughly a tenth of Goldman’s own long-term projection of 7% global GDP growth from AI.

Brynjolfsson and Robert Gordon at Northwestern have a formal wager on LongBets.org about whether productivity growth will average over 1.8% annually through 2029. Gordon, the author of The Rise and Fall of American Growth, argues that the great inventions of 1870 to 1970 were one-time transformations and that AI’s impact will be gradual, not sudden. Two serious economists, betting real money, disagreeing by an order of magnitude on the same question. That tells you something about how wide the uncertainty actually is.

There are counterarguments that I take seriously.

The adoption speed is genuinely unprecedented. A St. Louis Federal Reserve study found generative AI reached a 39.5% adoption rate among U.S. adults after just two years, compared to 19.7% for PCs after three years and 20% for the internet after two years. By August 2025, that number hit 54.6%. Over 1.2 billion people used AI tools within three years of ChatGPT’s launch, faster than the internet, PCs, or smartphones.

Part of the reason is structural. Every previous general-purpose technology required building physical infrastructure from scratch. Electricity needed grids. Cars needed roads and gas stations. The internet needed broadband. AI needs a browser. It sits on top of infrastructure that already exists, which compresses the adoption timeline in a way that has no real historical precedent. Harvard economist David Deming pointed this out explicitly: generative AI is built on top of PCs and internet access as base layers.

The developer ecosystem is also orders of magnitude larger. GitHub hosts over 150 million developers. Roughly 1,000 to 2,000 new open-source AI models are uploaded to Hugging Face daily. API-first distribution means AI can be embedded into existing products without hardware installation. The iteration speed, with new frontier models shipping every four to six weeks, is incomparable to any physical technology’s improvement cycle.

I find these arguments compelling. And I still don’t think they resolve the tension.

What history keeps showing is that the bottleneck is never the technology. It’s the organizational adaptation. Getting humans and institutions to reorganize around a new capability takes about a generation regardless of how fast the capability itself improves. David showed this with the dynamo. We saw it with computing. We’re watching it with AI right now.

A telling example: when ATMs spread in the 1960s and 70s, everyone assumed bank tellers would vanish. Instead, ATMs reduced cost per branch, so banks opened more branches, and total U.S. bank tellers actually increased from 1980 to 2010. Economist James Bessen documented this. The technology didn’t eliminate the work. It changed the economics of the work, which changed the shape of the industry in ways nobody predicted. Developers using AI complete 21% more tasks and merge 98% more pull requests. That sounds like a productivity revolution until you realize it’s generating vastly more software, not less demand for programmers. The Jevons Paradox, first observed with coal in 1865, keeps showing up.

So where does that leave a leader trying to make real decisions right now? Not in 2030, not when the J-curve resolves, but this quarter, with a budget and a team and a board that has opinions?

I think the honest answer is uncomfortable. The $360 billion is probably not rational at the individual company level, but it might be rational at the portfolio level. Each company is making a bet it can’t afford to lose. The cost of being wrong about investing is a few ugly quarters of write-downs. The cost of being wrong about not investing is irrelevance. When every competitor is spending, the calculus tips toward spending even if you privately believe the payoff is years away. I’ve seen this logic play out in enterprises debating cloud migration, in airlines investing in digital operations, in banks building mobile platforms. The individual ROI case was often weak. The strategic risk of falling behind was the real driver.

That doesn’t make the spending wise. It makes it explicable. There’s a difference.

For teams and leaders closer to the ground, I’d focus on two things. First, treat AI adoption as an organizational design problem, not a technology deployment problem. The companies that gained from cloud were the ones that changed how they built and operated, not just where they ran their servers. The companies that will gain from AI are the ones that redesign workflows, incentives, and team structures around what AI makes possible. Buying licenses and running pilots is the equivalent of bolting a dynamo onto a belt-and-pulley factory.

Second, watch the micro-level evidence more than the macro numbers. The macro stats will stay near zero for a while because that’s what general-purpose technologies do. But the translation industry has already lost 40 to 70% of its human workforce at agencies. AI coding tools are a $4 billion market that didn’t exist two years ago. Drug discovery timelines are compressing from a decade to months for early phases. These are narrow, specific, measurable impacts. The question for your organization is whether any of those narrow impacts touch your value chain, and whether your competitors are adapting faster than you are.

Goldman says basically zero. History says that’s on schedule. The $360 billion says the people writing the checks believe the zero is temporary.

I think they’re probably right. I also think a lot of that money is going to burn before anyone proves it.

The room went quiet. A few heads nodded. And just like that, the tool got the blame, and the team got an implicit pass.

0I’ve been in engineering leadership long enough to recognize what that moment actually was. Not an honest postmortem. A deflection dressed up as one.

When leadership asks engineering teams to adopt AI coding tools, the message often gets received as: move faster, write less, do more with less effort. That reading is almost always wrong, and leaders who allow it to persist are setting their teams up for exactly the kind of failures that then get pinned on the technology.

When the ask is a serious one, it’s to be more of an engineer. To own architecture, judgment, tradeoffs, and quality at a level that frees you from writing every line from scratch. The tool handles execution. You handle the thinking. That is a harder job, not an easier one.

Somewhere between the executive announcement and the sprint planning meeting, that distinction collapses. And then the data catches up.

GitClear analyzed 211 million changed lines of code across repositories from 2020 to 2024, including work from Google, Microsoft, and Meta [1]. What they found is uncomfortable to read if you’ve been cheerfully citing productivity gains. Code churn (lines revised or reverted within two weeks of being authored) is on track to double versus its pre-AI baseline. Refactored code, the kind that signals a team actively improving what they’ve built, dropped from 25% of changes in 2021 to under 10% in 2024. Copy-pasted code blocks grew from 8.3% to 12.3% in the same window. Eight-fold increase in duplicate code blocks over a four-year period [1].

This is what “moving faster” looks like when the person generating the code isn’t fully owning what they generate.

SonarSource found a 9% increase in bugs in AI-accelerated codebases and pull requests that are 154% larger than what teams were producing before [2]. Pull requests per developer went up roughly 20% with AI assistance, but incidents per pull request increased by 23.5% [2]. Google’s 2024 DORA report put numbers on what this looks like at the delivery level: a 25% increase in AI usage corresponds to a 7.2% decrease in delivery stability and a 1.5% drop in throughput [3].

More code. More PRs. More churn. More incidents. Less stability.

None of this is the AI’s fault. The AI did exactly what it was told.

Ox Security ran an analysis of more than 300 production repositories in 2025 and found ten recurring patterns in AI-generated code present in 80 to 100% of what they reviewed: incomplete error handling, weak concurrency management, inconsistent architecture [4]. These aren’t bugs you miss at 2am when you’re tired. These are engineering decisions that were never made, skipped because the code appeared to work, shipped because the test passed, and discovered when something went wrong downstream.

That’s the accountability gap. And it doesn’t belong to the AI.

Ox’s findings landed alongside a separate Georgetown CSET analysis from November 2024 that catalogued the security vulnerability profile of AI-generated code across the major providers [5]. The word “BLOCKER” appeared often. AI-generated code requires the same rigorous review as any code, and in practice it’s getting less of it because the generation itself feels like the hard part was already done.

The hard part is never the generation. It never was.

Blaming AI for SLA degradation is the new “I told you so.” It carries the same structure: a skeptic who never fully bought in, an early miss that confirms their doubts, and a narrative that quietly ends the conversation before anyone has to examine what actually happened. What actually happened is usually simpler and more uncomfortable. The team used the tool without a clear owner for quality. Review standards didn’t adjust for the new volume. Test coverage didn’t expand to match larger changesets. No one explicitly said what “good AI-assisted engineering” looked like, so the default was whatever worked. If it compiled and the tests passed, it shipped.

AI did its job. The ownership question went unanswered.

One pattern I’ve had to correct in myself over the years is assuming that handing someone a powerful tool is the same as setting expectations around how to use it. It isn’t. A faster car needs better driving. More code generation requires sharper review. The two sides of that equation need to move together, and when they don’t, the quality bill comes due on a timeline you can’t predict and can’t really argue with.

The harder conversation, the one that gets avoided, is about what leadership owes the team during an adoption period.

The 2025 LeadDev Engineering Leadership Report surveyed more than 600 engineering leaders. Sixty percent of them said AI hadn’t meaningfully boosted team productivity. The majority reported only small gains [6]. That number tells you something important: most teams are in the difficult middle of a capability transition, not on the other side of it. And yet leadership behavior in many of those organizations suggests the opposite assumption. The tools are deployed, so the results should follow.

They don’t. At least not right away.

McKinsey’s 2025 workplace research found that C-suite leaders dramatically underestimate how extensively their employees are already using AI, but they also overestimate how quickly that use translates into delivery outcomes [7]. One figure from that work: 62% of organizations report productivity increases of 25% or more from AI, but only 20% of engineering teams are actually using metrics to measure AI’s impact [6]. Two thirds of companies claim results they can’t prove, from a transition they haven’t instrumented.

That gap has consequences for the people doing the work. Engineering managers are reporting 12 to 15 hour workdays following AI tool rollouts, as sprint expectations get inflated 30 to 40% based on vendor ROI claims while actual utilization of the tools drops to around 22% within the first 30 days [8]. The team is drowning in delivery pressure while they’re still figuring out the toolchain. Licenses were purchased, expectations were raised, and the timeline for when results would actually show up was never discussed.

About eight months into one rollout I was involved with, a VP of Product pulled me aside after a planning meeting. The delivery numbers hadn’t moved. He asked, with a mix of frustration and genuine curiosity, whether the AI tools were actually helping or whether we’d wasted the budget. I told him something like: we’re in month eight of a twelve-month transition. The team is learning a different way to work. You’ll see the movement, but not yet. He looked at me the way people look at you when they’re not sure if you believe what you’re saying.

I believed it. But I also knew the conversation was happening because no one had set that expectation before the rollout started.

If you push an engineering team to adopt AI and expect delivery performance to improve immediately, you’ve misread the transition. What actually happens is what Google’s DORA team described as the bottom of a J-curve. Performance gets worse before it gets better, as teams rebuild mental models, review processes, and quality gates around a different way of generating code [3]. Expecting the upward curve without accepting the downward one isn’t optimism. It’s a refusal to understand change.

I’ve watched this play out across multiple transformations. Every time an organization tried to mandate a new way of working without building space for the learning period, the team found ways to comply on the surface and protect themselves underneath. Metrics looked fine. The actual change didn’t happen. And when something broke, someone found a credible-sounding external cause.

AI is now that external cause. Available, plausible, and completely unable to defend itself.

The organizations where AI adoption is working share a pattern that’s less flashy than the productivity numbers in press releases. Accenture’s deployment of GitHub Copilot across a large developer population found that over 80% of participants successfully adopted the tool, with a 96% success rate among the initial cohort [9]. Ninety percent of developers reported higher job fulfillment. But what made that work wasn’t the tool. It was structured adoption with explicit expectations, measurement, and time built in for the learning curve to run its course.

The Accenture work confirmed something the skeptics don’t advertise: when you actually manage the transition, the results are real. Code readability up. Maintainability up. Code approval rates up [9]. Not because AI made engineering easier, but because the engineers who used it well used it as an amplifier for their judgment, not a substitute for it.

The controlled research backs this up too. Developers completing structured tasks with Copilot finished 55% faster in some studies [9]. Pull request cycle time dropped from 9.6 days to 2.4 in one tracked deployment. Those numbers are real. They’re also downstream of something less visible: engineers who understood exactly what they were responsible for, and used the tool accordingly.

Those outcomes trace back to one thing: clear ownership of quality, regardless of where the code came from.

There is a version of this conversation that gets had in every industry going through a capability shift. I watched it with test automation. I watched it with cloud migration. Teams that treated the new capability as a way to do the same job faster eventually hit a ceiling. Teams that treated it as a reason to redefine what the job meant pulled ahead and didn’t come back.

Writing less code was never the point. The job is to carry more judgment about what gets built, what gets reviewed, what gets deployed, and what the consequences are. That’s a bigger ask. It requires more professional ownership, not less.

The teams that understand this are the ones where engineers look at AI output the way a senior engineer looks at a junior’s PR, with curiosity, with scrutiny, with clear standards. Those are the teams where the J-curve turns. Somewhere around six months in, based on what I’ve seen, that’s when the upward movement starts to show.

The ones still waiting for the curve to turn on its own are usually the ones with a leader who announced the tools, expected the numbers, and is now looking for someone to blame.

Quietly, that leader is the answer to their own question.

References

[1] GitClear. “Coding on Copilot: 2023 Data Suggests Downward Pressure on Code Quality (Including 2024 Projections).” GitClear Research, January 2024.

[2] SonarSource. Cited in: Smith, B. “AI in Software Development: Productivity at the Cost of Code Quality?” DevOps.com, 2025.

[3] Google Cloud. “Accelerate State of DevOps Report 2024.” DORA Research Program, 2024.

[4] Ox Security. Analysis of AI-Generated Code Anti-Patterns in Production Repositories. Ox Security Research, 2025.

[5] Center for Security and Emerging Technology (CSET), Georgetown University. “Cybersecurity Risks of AI-Generated Code.” Issue Brief, November 2024.

[6] LeadDev. “Engineering Leadership Report 2025.” LeadDev, 2025.

[7] McKinsey & Company. “Superagency in the Workplace: Empowering People to Unlock AI’s Full Potential at Work.” McKinsey Global Institute, 2025.

[8] Earezki, A. “Managing the Gap: Why Engineering AI Adoption Leads to Developer Burnout.” Dev|Journal, March 2026.

[9] GitHub. “Research: Quantifying GitHub Copilot’s Impact in the Enterprise with Accenture.” GitHub Blog, 2024.

Most people are doing a different math: tickets + parking + snacks + a babysitter turns “movie night” into a project. So they hit play at home.

And at home, the only thing that matters is what lands. If the movie feels flat, nobody cares why. They don’t separate the work from the way it shows up. They just decide it was overrated and move on.

That’s why I’m careful with “it was amazing in theatres” as a defense.

A good film is the one that tells a good story. Schindler’s List was black and white and it still hits like a truck. More recently, Oppenheimer didn’t need a candy-colored look to pull people in and keep them there.

Still, there’s a product lesson here: your quality bar has to match where customers actually experience the thing.

The home experience isn’t a side channel anymore. It’s the primary one. And yes, if you can afford it, you can get very close to a theatre now — a high-end OLED (or a top mini-LED) with Dolby Vision/HDR and a real Atmos setup is no joke.

But most customers live in the middle. They want easy, affordable entertainment that feels like the version everyone talked about.

So value delivery isn’t “we built it right.” It’s “it showed up right.” Wherever the customer eats the popcorn.

People expect comfort. They want a checklist that keeps their current role intact. I’m not going to do that. The reality is the parts of your job you’ve been rewarded for—typing code, churning tickets, filling in docs—are getting cheap fast. If you’re clinging to those as your identity, it’s going to hurt.

A lot of the anxiety comes from a quiet assumption: “My job exists because I produce output.” Code output. PRDs. Jira updates. Spreadsheets. Slides. Those are artifacts. AI is turning artifacts into commodities. And when something becomes a commodity, companies stop treating it like a career moat.

So when someone asks me how not to be replaced, what I hear is: “How do I keep being paid for the parts of my job that are becoming cheap?”

That framing is the trap.

The question worth asking is: “If the typing is almost free, what’s left that a team still needs a human to own?”

There’s a blunt answer: ownership under uncertainty. Judgment when the trade-offs are real. Clarity when everyone is spinning. And the willingness to carry the outcome when it works and when it doesn’t.

If you’re a developer who loves coding more than problem-solving, this shift is going to land hard. Coding is a clean feedback loop. You write, it compiles, tests pass, dopamine hits. AI is about to outpace you in that loop. Faster drafts. Faster refactors. Faster test scaffolds. Faster “good enough.” If your value is “I can produce code,” you’re signing up to compete with a machine that never gets tired and never needs a meeting-free morning.

If you’re a PM who hides behind frameworks and rituals, same story. If your job is mostly translating conversations into templates, running ceremonies, and producing documents, AI will do that work at a level that’s uncomfortable to watch. Not perfect, but plenty good for the organization to stop paying a full-time human to be a document factory.

What doesn’t get replaced as easily is the part where someone has to decide.

Decide what problem is worth solving. Decide what “done” means. Decide what to cut when time runs out. Decide what risk is acceptable. Decide what we’ll measure in the real world. Decide how we’ll respond when reality disagrees with the plan.

Those decisions are the job. The artifacts were just the visible exhaust.

This is where I think smart people get stuck: they treat “having a job” as the goal, instead of being the kind of person teams depend on when the work gets messy. They look for tactics to protect their current tasks instead of building the ability to own outcomes.

And yes, that means letting go of some identity.

If you’ve built your self-worth on being the person who can crank out code, you’re going to feel threatened. If you’ve built your self-worth on being the person who can run the process, you’re going to feel threatened. That’s not because you’re weak. It’s because you attached your value to the part that’s being automated.

The switch you need is simple to say and hard to live: stop thinking of yourself as an artifact producer. Start thinking of yourself as an outcome owner.

Outcome owners do a few things consistently, regardless of title.

They frame problems in plain language that the whole team can agree on. They define success in a way you can measure after release, not just in a demo. They spot constraints early—performance, security, cost, usability, migration pain, integration ugliness—before the team commits to the wrong path. They make trade-offs explicit instead of letting them hide in the backlog. They reduce “unknowns” before the team burns weeks building the wrong thing.

And they’re calm when the plan breaks, because they planned for that.

AI can help with every one of these steps. But it can’t be the accountable owner. It can’t be the person who says, “We’re doing this, not that, and here’s why,” and then lives with the outcome.

So what should you actually do?

Not “learn AI.” Everyone will learn AI. That’s table stakes.

You train yourself to operate one level higher than the tool.

For developers, that means you don’t win by writing more code. You win by making better calls about what code should exist, what shouldn’t, and what risks you’re taking on by shipping it. You get good at reviews that catch real problems: edge cases, failure modes, operational blind spots, sloppy assumptions. You become the person who can take a vague goal and turn it into a plan that won’t collapse under real usage.

For PMs, that means you stop being a backlog curator and become a decision maker. You get sharp about what matters to users and the business, what doesn’t, and why. You can say no without hiding behind process. You can hold a line when stakeholders try to turn every idea into a “must-have.” You can create focus when there are ten competing priorities and everyone has a plausible argument.

Here’s a practical way to force the shift without turning it into a motivational poster.

Run one project with a rule: the AI does the drafting, you do the owning.

Let the tool write the first pass: the code, the tests, the PRD, the rollout note, the API doc. Your job is to produce the pieces that AI can’t fake well:

• A one-paragraph problem statement that a skeptical teammate would agree is the real problem.

• A definition of success that includes what you’ll measure after release.

• The top failure modes and how you’ll detect them quickly.

• The trade-offs you’re making and what you’re explicitly choosing not to do.

• A decision log: what you decided, when, and based on what evidence.

When you work this way, two things happen. First, you ship faster, because the typing stops being the bottleneck. Second, your value becomes obvious in a different way: you’re the person reducing chaos and making the work coherent.

If you do this and feel a little lost, that’s normal. It means you were relying on output as your proof of worth. Most of us did, because it’s measurable and praised. Now the measuring stick is shifting.

You don’t avoid being replaced by protecting your current tasks. You avoid being replaced by becoming the person teams trust with ambiguity, trade-offs, and outcomes.

And if that doesn’t appeal to you—if what you really love is the craft of typing code or filling in docs—then be honest about it. There’s nothing wrong with loving the craft. Just don’t confuse loving the craft with having a defensible career moat in a world where the craft is being automated.

The people who do well in the next few years won’t be the ones who write the most code or produce the cleanest templates. They’ll be the ones who can take messy problems, make them tractable, and drive them to a measurable result while everyone else argues about the right tooling.

We were in the middle of a release that had a regulatory deadline attached to it. The kind where “a week late” isn’t a joke, and “we’ll catch it next sprint” gets you a meeting with Legal. One of our teams was quietly stuck. Not blocked in a dramatic way. No incident. No escalation. Just slow, grinding friction: unclear priorities, a dependency that kept slipping, a product decision that kept changing shape. Everyone looked busy. Nothing moved.

I found out by accident.

I was the manager’s manager in this case. I dropped into a review meeting because someone was out, and I could feel it in the first five minutes. The engineers were polite, careful, and tired. The manager was doing that thing good managers do when they’re trying to protect the team and keep leadership calm at the same time. Everybody was “fine.”

After the meeting, one of the staff engineers caught me in the hallway and said something like, “I didn’t want to go around my manager, but… we’re not going to make it.”

That sentence shows up in some form every few months in most organizations. And it’s usually followed by a story where everyone was trying to do the right thing and still left a lot of value on the table.

Skip relationships are one of the easiest ways to speed up trust, clarity, and career growth inside a company. They’re also one of the most misunderstood.

A lot of people treat their skip manager like an emergency exit: break glass only when things are on fire. And when the fire finally shows up, the relationship isn’t there. The context isn’t there. The trust isn’t there. So the conversation gets weird fast. It becomes an investigation, or a complaint session, or a vague “just wanted to make you aware.” Nobody leaves feeling good.

What I’ve learned, on both sides of the table, is that the best skip relationships don’t feel like escalation. They feel like alignment.

The missed opportunity starts with a set of default assumptions people carry, usually without saying them out loud.

One assumption is that reaching out to your skip manager is disloyal. That it signals your direct manager isn’t doing their job. That you’re trying to play politics. I’ve watched strong engineers avoid skip contact for a year because they didn’t want to look like they were “going around” someone. Then they hit a wall, and the first skip conversation happens under stress. By then, it’s hard to avoid the vibe of escalation, even if that wasn’t the intent.

Another assumption is that skip managers are too busy for you. This one is almost always wrong. Yes, their calendars are a mess. But if you’re a solid IC or a new manager in their org, you are part of what they’re accountable for. Your output, your retention risk, your growth, your ability to execute under constraints. When skip managers ignore those signals, it catches up later as attrition, missed delivery, quality problems, or “mysterious” morale dips. A fifteen-minute conversation today is usually cheaper than the cleanup six months from now.

Then there’s the belief that skip 1:1s are a trap. People assume the skip manager is collecting intel. That anything you say will be used against you. That candor will get you labeled as “difficult.” Sometimes that fear comes from real organizational scars. Sometimes it’s just anxiety filling in the blanks. Either way, it pushes people into a careful, bland, low-information conversation that helps nobody. The skip manager walks away thinking everything is fine. The report walks away thinking the skip manager doesn’t care. And the gap stays.

There’s also a quieter assumption I see with ambitious people: “My skip manager will notice my work if I just keep delivering.” I used to believe this. It’s comforting because it keeps you in control. Put your head down, ship, and recognition will find you.

In practice, skip managers don’t have enough bandwidth to infer your intent from your tickets in a board. They see outcomes, and they see patterns, but they don’t automatically know what you want more of, what you’re trying to learn, what kind of scope you’re ready for, or what support would remove friction. If you don’t tell them, they guess. And their guess is often shaped by whoever is loudest in the room, not whoever is most ready.

All of those assumptions lead to the same behavior: people keep skip managers at arm’s length, then wonder why decisions feel random, promotions feel opaque, and priorities shift without warning.

Now let me flip it around, because I’ve been the skip manager too, and I’ve had plenty of skip reports who didn’t know what I was hoping for.

When I set up skip 1:1s, I wasn’t looking for gossip. I wasn’t looking for a shadow performance review. I wasn’t trying to catch anyone contradicting their manager.

I wanted signal.

In a healthy org, the information that reaches a skip manager is filtered. That filtering is not malicious. It’s normal. Every layer summarizes. Every manager protects their show. Every leader tries to keep noise down and confidence up. That’s part of the job.

But it means I’m always at risk of being the last person to know something that matters. The work is slipping. The architecture is brittle. The team is burning out. The roadmap is fantasy. A partner team is quietly refusing to cooperate. The quality bar is eroding because deadlines are fixed and scope isn’t.

Direct managers can surface those things, and good ones do. But even good managers sometimes wait too long, because they’re trying to solve it first. Or because they don’t want to look like they can’t handle it. Or because they’re new and still learning which problems are “normal hard” and which ones need help.

A skip relationship gives you a second sensor. Not to bypass the manager, but to make the system less fragile.

When I met with skip reports, I was open to a few kinds of conversations.

I wanted to understand what work felt like on the ground. Not the status update, but the friction. Where are decisions getting stuck? What’s causing rework? Where are we burning time because ownership is unclear? If you’re an IC, you see process debt before any dashboard does. If you’re a manager, you feel misalignment before it becomes an escalation.

I also wanted to know what you cared about and what you wanted next. People often under-share here. They’ll say “I want to grow” or “I’m open to more responsibility,” which is fine, but it doesn’t give me anything to work with. The useful version is more specific: “I want to lead a cross-team effort,” or “I want to move toward staff-level scope,” or “I’m trying to get better at influencing product decisions,” or “I’m considering management but I don’t know what I’m signing up for.” Those are conversations a skip manager can actually support.

I was also open to hearing when your manager was doing something that was unintentionally hurting you. Not as an accusation, but as a reality check. Managers, especially in regulated environments, often over-rotate on control when risk is high. They get tight on reviews, tight on approvals, tight on who can talk to whom. Sometimes that’s needed. Sometimes it’s just fear disguised as rigor. Skip managers can help coach that back into balance, but only if they know it’s happening.

And I wanted you to tell me when you saw a better way to run part of the org. Not “we should change everything,” but a practical improvement rooted in the work. A recurring meeting that produces no decisions. A handoff that creates delays every time. A platform dependency that needs a clear owner. A policy that made sense two years ago and now mostly causes workarounds. When someone brought that kind of observation with concrete examples, I took it seriously.

Here’s what surprised me early in my career: skip reports often assumed I would react defensively to that input. In reality, I usually felt grateful. Because it’s rare to get clean signal, and it’s even rarer to get it from someone who is close to the work and also thoughtful about the business constraints.

Of course, not every skip manager is good at this. Some are insecure. Some don’t build trust. Some treat skip 1:1s like a complaint hotline and then punish the manager indirectly. People aren’t imagining those risks. They happen.

So the practical question becomes: how do you work with a skip manager in a way that builds value and keeps relationships clean?

Start by being clear in your own head about your intent. If your intent is to “win an argument” against your manager, that energy shows up. It comes out as sarcasm, loaded framing, selective facts. Skip managers can smell it, and it forces them into referee mode. Nobody wins there.

If your intent is to help the team win, the conversation sounds different. You bring facts. You name trade-offs. You acknowledge what you might be missing. You explain how the issue is affecting delivery, quality, risk, or morale. And you ask for help in removing a constraint, not in “fixing your manager.”

I used to coach people to think in terms of: “What decision, clarity, or connection would change the outcome?” That keeps the conversation grounded.

A strong skip conversation also respects the manager relationship instead of pretending it doesn’t exist. If you’re raising a concern that your manager doesn’t know about, you should have a good reason. Sometimes the reason is valid: you tried, it didn’t land, and the impact is serious. Sometimes it’s because you’re uncomfortable with conflict. That’s human, but it’s also a growth edge. Skip managers tend to respond well when you’re honest about that: “I should be able to have this conversation with my manager, but I’m not doing it well yet. I’d like your advice.”

When someone said that to me, I didn’t think less of them. I thought, “Okay, this person is coachable, and they’re trying to act like an adult.”

Another useful pattern is to make the conversation about the system before you make it about people. “We keep changing scope late and it’s creating rework” lands differently than “Product is a mess.” “We don’t have a clear owner for this dependency” lands differently than “That other team is useless.” Same underlying pain, different signal quality.

And if you want a skip manager to invest in you, bring something real. A decision you’re trying to influence. A cross-team issue you’re stuck on. A career move you’re considering. A risk you see with evidence. A request for feedback on how you’re showing up. You don’t need to over-prepare, but you do need to show that you’re not there to vent.

On my side, as a skip manager, I also learned to set expectations explicitly because people don’t know what the “rules” are. When I didn’t say anything, they filled the silence with the assumptions above. So I started telling skip reports, early and plainly, what I was open to: talking about priorities, career growth, friction in how we work, and concerns that might become delivery or risk issues. I also said what I wouldn’t do: I wouldn’t use the conversation to blindside their manager, and I wouldn’t treat it like a secret channel. If something needed action, I’d usually say, “How do you want to handle this with your manager?” and we’d decide together.

That last part matters. People worry that any skip conversation will automatically become a confrontation between leaders. It doesn’t have to. Most of the time, the right move is to help the report get more effective with their direct manager, not to replace that relationship.

The staff engineer I mentioned earlier? Once we talked, it turned out the team wasn’t blocked by incompetence. They were blocked by a missing decision at a higher level and a dependency that needed a clear escalation path. Their manager was trying to solve it quietly. The engineer was trying to be respectful. Both were acting with good intent. The gap was that nobody had built a working channel with the skip manager before the pressure peaked.

We fixed it quickly once it was visible. We made a call on scope, got the dependency team aligned, and adjusted the plan so the regulatory deadline was protected without burning the team down. The engineer didn’t “go around” anyone. They gave the org a signal it needed earlier.

What I’d tell my past self now is simple: skip relationships are part of how execution works at scale. They’re not politics. They’re not therapy. They’re a way to reduce blind spots and speed up alignment.

If you haven’t talked to your skip manager in a while, you don’t need a big reason to start. A short note that says you’d value fifteen minutes to talk about how the quarter is going, what you’re working on, and what you’re aiming for next is usually enough. Then show up with one or two real topics and the intent to help the org win.

Do that a few times a year, and you’ll notice something shifts. Decisions feel less mysterious. Your work has a clearer line to the bigger picture. And when the hard moment comes—and it always does—you won’t be trying to build trust in the same conversation where you need help.

We were building a new workflow for a regulated product. The kind where a “small” mistake turns into an incident review, a customer apology, and a week of people combing through logs with a pit in their stomach. We had a plan that was boring and safe. It wasn’t elegant, but it got us to the next milestone without taking on debt we couldn’t repay.

My manager walked into the room with a different bet. Bigger scope. A new dependency. A vendor we hadn’t used. And a timeline that only worked if nothing went sideways, which is not how software behaves when it meets real users.

I felt it in my chest before I could explain it. That mix of urgency and disbelief. I knew the decision was drifting toward something I thought would hurt us.

In that moment, the temptation is to treat this like a debate where the goal is to win. You line up your arguments. You bring out the strongest engineer voice you have. You aim your facts like a weapon. And if you’re honest, there’s usually a second motive hiding under the first one: you want to be seen as the adult in the room.

I’ve been that person. It can work once or twice. Then it starts to fail in a very predictable way. You end up being “right” in private and ignored in public. The bet goes forward anyway. The team watches you lose. And now you’ve spent political capital, added stress to the room, and still have to ship the thing you don’t believe in.

So when I think my manager is betting on the wrong thing, I slow down and ask myself a question that keeps me honest: am I trying to win for the company, or am I trying to be right?

Those are not the same.

Trying to win means you care about the outcome, even if your idea doesn’t get picked. Trying to be right means you care about the scoreboard inside your own head. And once you’re in “be right” mode, you start collecting evidence like a prosecutor. You stop listening. You treat uncertainty as weakness. You dismiss any counterpoint as politics or ignorance. It’s a great way to feel smart and a terrible way to move an organization.

The first step is making sure the bet is actually wrong, and not just uncomfortable.

A lot of “wrong bet” alarms are really “I see risk” alarms. That sounds like splitting hairs, but it matters because the way you show up changes. If you can’t separate “this will fail” from “this might fail,” you’ll either overreact or you’ll stay quiet until it’s too late.

When I do this well, I stop arguing from taste. I stop saying things like “this feels messy” or “this architecture is bad.” I start anchoring in things that can be checked. What’s the customer impact if we miss? What’s the cost if we ship and have to roll back? What’s the lead time on the dependency we’re signing up for? What has the team actually delivered in the last eight weeks, with the same people, in the same codebase? What do our incidents and our on-call load say about where the weak points already are?

Sometimes that work proves I was reacting, not forecasting. I’ve had cases where I was convinced a direction was reckless, then we pulled real production data and realized the failure mode I feared was rare, contained, and easy to detect. My fear came from an old scar, not from current reality. In those moments, the best outcome is changing your mind quickly, because you just saved yourself a lot of unnecessary conflict.

Other times, the data makes the risk even clearer, and now you have something more solid than conviction.

There’s another uncomfortable truth: smart people can be “right” about the bet being wrong and still be wrong about what to do next. If your manager is making a call under pressure, they might be choosing between two bad options. You can’t show up with “don’t do this” and expect the conversation to end there. You have to show that you understand the constraint they’re operating under, and you have to offer a path that still meets the goal.

That’s where the “trying to win” mindset shows up. Winning is not “my plan gets chosen.” Winning is “we hit the goal with the least risk and the least wasted time.”

If you want your disagreement to land, you need to tie it to the goal in plain language. I’ve watched disagreements die because they were framed as personal preferences dressed up as certainty. “This is the wrong design” rarely moves anyone. “This path makes it hard to pass the audit in six weeks because it adds a new failure point we can’t test in time” is a different conversation.

I also learned to be explicit about what would change my mind. That one habit shifts your posture from “I’m here to fight” to “I’m here to reason.” It’s a small thing, but it has a calming effect on the room. It signals you’re not trying to corner anyone. You’re trying to get to a better decision.

Then there’s the part nobody likes talking about: culture.

I used to believe that if you brought enough facts and stayed professional, you could change how an organization makes decisions. Over time, I got more cautious about that belief. Companies don’t run on logic alone. They run on incentives, history, and whatever behaviors leadership rewards when nobody is watching.

Some places really do value disagreement. You can challenge a plan, and the system treats it as a gift. In those places, dissent is a normal part of work. People argue hard, then they leave the meeting and get on with it. Nobody carries grudges, because the disagreement wasn’t personal.

Other places want agreement. They might say they value candor, but what they reward is alignment. The meeting is less about finding the best answer and more about showing you’re on the right side. If you treat that environment like a merit-based debate club, you’ll get burned. Not dramatically. Quietly. You’ll stop getting invited early. You’ll lose access to the real conversations. Your influence will shrink while you’re still telling yourself you’re being principled.

You can usually tell which culture you’re in by watching what happens to the last person who pushed back. Not what leadership said about them. What actually happened to their scope, their opportunities, and their reputation.

If you’re in a place where politics and appearance are the primary currency, you have a decision to make. You can play that game if you want. Some people are good at it and don’t mind it. If you hate it, don’t lie to yourself and think you’ll change it from the middle by sheer force of reason. You can improve how your team operates. You can protect your people. You can create a pocket of sanity. Changing the organization’s culture without being the one who runs it is a long, bruising road, and most of the time it ends with you exhausted and disappointed.

I’m not saying “quit at the first sign of politics.” Every company has politics. I’m saying: if the system consistently punishes healthy dissent, and that clashes with how you want to work, consider moving to a different team or a different company before you spend years grinding yourself down.

Assuming you’re in an environment where disagreement is possible, or at least tolerated, then you have to do the hard part well: disagree clearly, without making it personal, and without turning it into a public power struggle.

I’ve found that the timing matters as much as the content. Surprising your manager in a big meeting rarely goes well unless the culture is unusually direct. If you think the bet is wrong, bring it up early and privately first. Give them a chance to react without an audience. Some managers will still bulldoze you, but many will at least explain the constraint you’re missing. And when the disagreement goes public later, it won’t feel like an ambush.

When I’m preparing to disagree, I force myself to separate opinion from evidence. Opinion is allowed. Experience is allowed. Gut is allowed. But if all you bring is “I don’t like this,” you’re making your manager do all the work of defending the bet and all the work of inventing alternatives. That’s a losing dynamic.

What tends to work is bringing a small set of facts and one concrete alternative. Not five alternatives. Not a menu. One realistic option that still hits the goal, with trade-offs stated plainly. That keeps the conversation grounded. It gives your manager somewhere to go besides doubling down.

And then, once the decision is made, you commit.

This part is where a lot of people misunderstand what “commit” means. It doesn’t mean you pretend you love the decision. It doesn’t mean you stop noticing risk. It means you stop undermining the decision through sarcasm, passive resistance, or quiet “I told you so” energy. You put your effort into making the chosen path succeed, and you do it in a way that preserves the team’s trust.

One of the cleanest ways I’ve seen to make this real is to make the bet testable. If you’re committing, you want clarity on what success looks like and how you’ll know early if things are going sideways. If your organization doesn’t do that naturally, you can still do it yourself by writing down the assumptions you heard in the decision discussion. Not as a gotcha. As a record. Then you can check reality against those assumptions as the work unfolds.

This is also where data matters again. If you push back, then commit, and the bet starts failing, you need to be able to speak in facts, not frustration. “This is going badly” is emotional. “We expected vendor integration in two weeks and we’re at week four with no test environment and three unresolved contract questions” is concrete. Nobody has to agree with your interpretation to agree with the reality.

There’s a moment that separates high-trust leaders from everyone else: the moment the bet proves wrong.

If you’ve been the person raising concerns, you have two very human impulses at that moment. One is to spike the football. The other is to disappear and let someone else take the heat.

Both are poison.

When a bet fails, the best move is to be the first person to raise the flag calmly, with evidence, and with a next move that still serves the goal. You don’t do it to embarrass anyone. You do it because the longer the organization clings to a failing bet, the more expensive it gets, and the cost rarely lands on the person who made the call. It lands on the team doing the work and the customers living with the fallout.

I once watched a team spend an extra two months on a direction everybody privately knew was failing because nobody wanted to be the person who said it out loud. The work dragged. Morale dropped. The best engineer on the team started taking “dentist appointments” twice a week. When we finally called it, we weren’t relieved. We were tired and annoyed that we hadn’t done it earlier.

In a healthier situation, someone raises the flag early. They say, plainly, that the bet isn’t producing the results we expected, they show the signals, they connect it back to the goal, and they propose the next move. Then the organization moves on without turning it into a blame festival.

If you can be that person, your credibility goes up, even if you were the one who disagreed in the first place. People learn that your dissent is in service of outcomes, not ego.

There’s also a short window after a wrong bet where teams are willing to learn. It’s one of the few times you can change how decisions get made without a big fight, because the pain is fresh and nobody wants to repeat it. You can suggest writing down assumptions next time. You can suggest agreeing on early signals before committing. You can suggest smaller tests before large commitments. If you wait three months, the story will get rewritten, and the same habits will quietly return.

One more thing I’ve learned the hard way: when the bet is wrong, don’t treat it as proof that your manager is bad. Managers are people making calls with incomplete information, pressure from above, and constraints they might not fully share. If you want to keep working with them, separate the bet from the person. Call the bet wrong when the evidence says it’s wrong, and stay respectful. If you turn it into a character judgment, you’ll lock the relationship into a defensive posture, and everything after that gets harder.

Sometimes, even if you do all of this well, you end up with a clear answer that’s uncomfortable: your manager keeps making bets that don’t work, the culture keeps rewarding those bets, and your ability to influence the direction is limited. At that point the question is not “How do I win this argument?” It’s “Is this a place where I can do good work without becoming someone I don’t like?”

I’ve stayed too long in that situation before. I told myself I could outlast it, or that the next reorg would fix it, or that being the voice of reason was its own reward. What happened instead was that I started saving my best energy for outside the job, and that’s a slow way of admitting you’ve already left in your head.

If you’re there, moving out can be a quiet decision. It can be a team change. It can be a scope shift. It can be leaving the company. The mature part is seeing the system clearly and choosing accordingly, without making it a crusade.

When I think back to that Tuesday “Direction Check,” the ending wasn’t dramatic. I asked my manager for fifteen minutes after the meeting. I brought two pages of notes: what the goal was, what assumptions the new bet depended on, what data we had that supported those assumptions, and what data we didn’t have yet. I offered an alternative that still hit the milestone, with a smaller blast radius. We argued. We were both tense. Then we agreed on a simple checkpoint two weeks later where we’d look at a few signals and decide whether to continue or cut bait.

Two weeks later, the vendor still didn’t have an environment we could test against. The timeline was already sliding. We called it. We moved back to the boring plan. We shipped. The audit went fine. And the most valuable part was not that I “won.” It was that we made the bet testable, so reality could speak before the cost got too high.

That’s what I aim for now. When you think your manager is betting on the wrong thing, the goal isn’t to embarrass them or to protect your ego. It’s to raise the quality of the decision, commit once the call is made, and be the first person willing to say “we learned something” when the bet doesn’t work. Then you move to the next idea that still gets you to the goal.

What I learned, after a few awkward coffee chats and a couple of dead-end intros, is that fundraising is less like hunting and more like building a pipeline. And the pipeline doesn’t start with VCs. It starts with trust and proof.

One quick reality check that will save you time: most institutional VCs don’t want to fund a side project. Not because they’re mean, but because their math depends on focus and speed. If you’re part-time, they assume you’ll be slow, and “slow” kills startups more reliably than bad ideas. So if you’re keeping this as a nights-and-weekends build for a while, your early “capital” is usually one of three things: your own runway, revenue, or a small set of angels who are comfortable betting on you before the story is fully formed.

That doesn’t mean you can’t talk to VCs early. You can. I do it. But I treat those early conversations as practice and relationship-building, not as “I need a term sheet by Friday.”

The question “How do I find the right investors?” is really two questions.

First: what kind of company are you building? Not emotionally—economically. Is this a business that can get to meaningful revenue with a small team and steady growth? Or does it need a lot of capital early because the market is land-grab, the product requires deep R&D, or distribution costs money up front? If it’s the first type, chasing VC too early can push you into bad decisions: hiring before you have clarity, adding features to impress investors instead of customers, and turning a focused side project into a chaotic full-time job.

Second: what stage are you actually in? At idea/early build stage, the “right connection” is rarely a brand-name VC. It’s often an operator-angel who has lived your problem, can introduce your first customers, and will tell you when your pitch is unclear. The first check is as much about signal and help as it is about cash.

Here’s how I’ve approached it when starting from “I have strong feedback and early interest, but this is still taking shape.”

I start by turning the product idea into a tight narrative that a stranger can repeat. Not a big deck. One page. Three paragraphs. What pain exists, who feels it, why existing solutions aren’t good enough, and what you’ve seen that makes you believe this is real. Then I add proof, even if it’s scrappy: a prototype, a waitlist with conversion rates, a handful of paid pilots, a letter of intent, pre-orders, or even a hard commitment like “five design partners agreed to give me two hours every week for six weeks.” VCs and angels both react to proof, and proof doesn’t have to be perfect. It has to be specific.

Then I build a list of humans, not firms. People treat “Sequoia” as a target. It’s not. A partner is a person with a thesis, a history, and a pattern of bets. So I look for investors who have funded companies in my space, or who talk publicly about adjacent problems, or who have a track record of being helpful at my stage. I’m looking for fit: do they understand the buyer, the sales cycle, the constraints, and the risks? If they don’t, every conversation becomes a lesson in basics, and you burn time.

Once I have that list, I work backwards to warm intros. Warm intros matter because they compress trust. The best intros are from three groups:

Founders they’ve already backed. If you can get a founder in their portfolio to vouch for you, that intro tends to land. The fastest way to earn that is to be genuinely useful to founders in the same arena: share notes, make a customer intro, give product feedback, help with a hire. I’ve had more doors open from “I helped one of your founders solve a hard hiring problem” than from any polished pitch.

Operators they respect. Some investors lean heavily on CTOs, CPOs, or domain leaders for early reads. If you have a network in the industry, use it. If you don’t, build it one relationship at a time through small, real interactions: asking for feedback on a demo, trading notes on go-to-market, offering to share what you’re learning. People can smell networking when it’s transactional. They respond when it’s grounded.

Angels and micro-funds. A small check from someone credible can unlock the next ten meetings. Early on, momentum is a product. A respected angel saying “I’m in” often does more than the money itself.

This is where most people go wrong: they ask for intros too early and too vaguely. “Do you know any VCs?” puts the work on the other person. A better ask sounds like: “I’m building X for Y. I’m looking to talk to investors who have backed dev tools sold to mid-market SaaS, seed stage. Do you think Investor A or Investor B would be a fit? If yes, would you feel comfortable connecting us?” That makes it easy to say yes, and it also makes it easy to say no without awkwardness.

I also keep my meetings tight. When I was raising the first time, I booked anything that looked like an investor. It felt productive. It wasn’t. The better pattern is to run the process in waves. I’ll take 10–15 “practice” conversations first—smart people who will give me honest feedback, including “this is confusing” or “your buyer isn’t who you think it is.” Only after that do I start talking to the investors I actually want. Your pitch changes fast in the early weeks. Don’t waste your best shots while you’re still finding the story.

A word on events and cold outreach: they’re fine, but they’re not a plan. Demo days, founder meetups, and industry conferences can help you meet people who later become connectors. Cold emails can work if they’re sharp and specific, and you have proof. A generic “We’re raising” email disappears. A short note that shows you know what they invest in, includes one crisp metric, and asks for a 15-minute call sometimes lands. Cold outreach is a volume game, and it can drain you if you’re also building. I prefer a smaller number of high-quality intros.

If you’re balancing a side project with a day job, your best move might be to design your path so money isn’t the gate right away. In practice, that looks like picking a wedge you can ship fast, charging earlier than feels comfortable, and using early revenue as validation. I’ve watched founders spend six months chasing meetings when they could have spent six weeks getting their first ten paying customers. Ten customers won’t turn you into a unicorn overnight, but it will give you a sharper product, a clearer story, and better investors when you choose to raise.

If you want something concrete to do next week, this is what I’d do in your shoes.

Write the one-page narrative and record a two-minute demo video, even if the product is rough. Send it to ten people who match your target customer and ask for a call. Not “feedback” in the abstract—ask them what they’d pay, what would block them from buying, and what they’d drop to make time for this. Take notes like your rent depends on it.

Then pick five founders and five operators in adjacent spaces and ask for advice, not money. Share the one-pager, ask what you’re missing, and end by asking who else you should talk to. If you do that well, connections start to appear without you chasing them. That’s the part people don’t tell you: the network is often a byproduct of doing real work in public, with humility, and with proof you can show.

When you’re ready to raise, you’ll still need the meetings. You’ll still need the story. But you won’t be walking into those rooms hoping someone believes you. You’ll be walking in with evidence—customers, usage, revenue, retention, even a small set of committed design partners—that makes belief the easy part.

Ethics in leadership usually shows up like that. It rarely arrives as a big red button with a clear label. It’s the slow accumulation of choices that sound rational in the meeting and feel personal when you’re alone. Over time you learn that “can I sleep at night?” has less to do with whether you can explain yourself and more to do with whether you’d accept the same outcome if you were on the receiving end, with the information and power that person actually had.

Earlier in my career I treated ethics as a set of guardrails: don’t lie, don’t cheat, don’t break the law. That keeps you out of obvious trouble. The harder part sits in the gray zones, where incentives are loud, timelines are tight, and every option has a cost. That’s where leaders quietly teach their teams what counts as acceptable collateral.

I’ve watched smart leaders create miserable environments without ever raising their voice. It happens through normalization. One person behaves badly and keeps getting a pass because they ship. A team lives in constant on-call pain because “we’ll deal with it next quarter.” Heroics get praised so often that the only way to be seen is to carry an unhealthy load. These choices don’t show up in the quarterly deck right away. They show up later in who speaks in meetings, who stops taking risks, and who leaves when they’re tired of paying for decisions they didn’t get to influence.

Pressure plays a big role here. In many organizations, pressure gets treated like weather: unfortunate, unavoidable, nobody’s fault. In practice, pressure has sources. Sometimes the source is real and external: a regulatory date, a contractual commitment, a safety risk, a cash runway that forces hard calls. Other times the source is internal: vague promises, overloaded portfolios, leaders who keep saying yes in public and pushing the cost down the stack in private. When I started tracing pressure back to where it came from, I found more room to choose than I liked admitting. Once you see that, it gets harder to justify handing the bill to people who can’t push back.

The same ethical tension shows up in what we ship. In regulated industries you get trained to think about safety, privacy, and audit trails as part of the job. That helps. It can also create a false comfort, because compliance doesn’t answer every question a leader should care about. I’ve sat in product reviews where the debate looked technical, but the stakes were human. Defaults that quietly change what gets shared. Data collection that starts as convenience and turns into temptation. A frictionless flow that boosts completion while increasing mistakes for someone stressed or tired. In the moment, those decisions feel like UX trade-offs. At scale, they become incentives that shape behavior.

When I’ve regretted a product decision, the root cause often looked like “we followed the metric.” Metrics matter, and they also have gravity. If the organization celebrates growth above everything else, teams will keep finding ways to pull attention harder. If revenue is the only win that counts, it gets easier to treat struggling customers as acceptable fallout. If speed dominates, risk gets shipped and the team calls it progress. Nobody wakes up intending harm. People wake up trying to hit the number, keep the work funded, and avoid being labeled the one who slowed things down.

So I began doing a simple private check before big calls, especially when the room was pushing for speed. I’d write down who carries the cost if we’re wrong, in plain language. I’d think about the engineer who gets paged at 2 a.m. because we accepted known failure modes. I’d think about the support team that absorbs confusion we could have prevented. I’d think about the end user who doesn’t realize the trade-off until it bites them. Then I’d ask myself whether the people paying had meaningful choice. That one question changes the bar for what “good enough” means.

People decisions demand the same discipline, because leadership gives you power that feels ordinary while you’re holding it. Your opinion becomes direction even when you’re thinking out loud. Your mood bleeds into the room. A casual comment you forget by Tuesday can shape how someone sees their future. People react to that because you hold things they care about: opportunity, stability, recognition, a decent week. When leaders forget that, they start making choices that feel efficient to them and costly to everyone else.

One pattern I had to correct in myself was letting ambiguity sit because directness felt uncomfortable. It’s easy to delay a hard conversation by keeping things vague, by using soft language, by telling yourself you’re buying time. The person on the other end spends that time trying to read between the lines, guessing what’s safe, guessing where they stand, guessing what you meant. That drains energy and trust. When I learned to be clear earlier, outcomes didn’t become painless, but they became fairer. People could respond with agency instead of trying to decode me.

Ethics in leadership doesn’t come with permanent certainty. You’re often choosing between imperfect options with partial information. The habit that keeps me grounded is staying honest about the costs and resisting the urge to hide behind “the business” as if it were a separate creature making decisions on my behalf. If I’m asking someone else to absorb pain, I owe them clarity about why, what we’re doing to reduce it, and what would make us change course.

I still have nights where a decision sits heavy. I don’t treat that as a sign of failure. I treat it as a signal: something is out of alignment, either with my values or with the story I’m telling myself to make a hard choice feel clean. The job isn’t to lead without discomfort but keep decisions human when incentives try to sand that off.

Sales had already pitched that date to three big prospects. Marketing had hinted at a launch window in a keynote. Finance had numbers in the plan that depended on that month being real.

On the surface, the product looked ready. The demo sang on the happy path. Behind the curtain, we knew the edges were sharp: a flaky integration, a couple of “we’ll fix it later” shortcuts around data handling, and an on-call setup that boiled down to one senior engineer with a pager and a lot of coffee.

The question was simple: “Can we launch next month?”

Nobody in that room really wanted the full answer. They wanted a yes that sounded confident enough to repeat to their teams and to the board. My job was to decide whether saying yes would be a brave bet or a slow reputational leak we’d regret for years.

That’s where the sweet spot between quality and speed gets real. It’s not a slogan about “moving fast and breaking things.” It’s a series of line calls about what you’re willing to break, who gets hurt when it breaks, and whether you still deserve your customers’ trust afterward.

Over the years, I’ve started from a different question whenever I work on a 0 to 1 product: where do we need to be trustworthy from day one so we keep the right to move fast later?

For any new product, there’s a core promise at the center of it. Money moves correctly, records stay accurate, health data is where it should be, content isn’t lost, workflows don’t vanish. That core job has to work, every time, for the specific set of early users you’re inviting in. Those users will forgive a rough experience. They won’t forgive feeling like guinea pigs in an experiment that puts their own customers or their own reputation at risk.

So when I’m shaping a 0 to 1 effort, I draw a hard boundary first. Inside that boundary sit things that must be boringly reliable from the first external click: the main flows that define why the product exists, the way we handle and store data, the ability to know when something is going wrong and recover quickly without a war room every other day. If we can’t see what’s happening in production, if we can’t trust our data, if our recovery plan is “hope the senior engineer is awake,” then we’re not ready for real customers, no matter how polished the UI feels.

Outside that boundary, I give myself and the team permission to be much scrappier.

In one 0 to 1 product, half the “system” during the first quarter of customer use was a mix of internal spreadsheets, Slack channels, and manual checks by the team. Sign-ups were semi-automated; a human confirmed some conditions before flipping a feature flag. A few workflows were held together by a shared runbook and a lot of honest communication with early adopters. From the outside, the product solved a clear problem. From the inside, it was part software, part controlled experiment.

That kind of scrappiness is fine when three things are true.

First, the mess is invisible to customers in a way that doesn’t put them at risk. You’re allowed internal pain if it buys you learning and speed. You’re not allowed to gamble with their money, their data, or their own commitments to end users.

Second, you’ve been clear about who this product is for at this stage. A private beta with ten design partners is very different from a public launch that any customer can click into from your homepage. One of the most underused levers in 0 to 1 work is access control. “Launch” doesn’t have to mean “everyone gets it.” It can mean “this cohort, with this profile, under these conditions.”

Third, the scrappy choices have an exit plan. I’ve seen too many teams say “we’ll clean this up later” without ever naming when “later” is. Then one day that little helper script or that spreadsheet becomes a business-critical dependency nobody wants to touch.

When eager stakeholders push for an early date, they usually talk about upside: revenue this quarter, momentum in the market, air cover with the board. The downside is fuzzier: tickets, late nights, awkward calls with account managers, a few lost deals that are hard to attribute to “we shipped too early.” If you leave the risk as a vague cloud, the pressure to go fast will always win.

What helped me in that room with the date on the slide was turning that vague cloud into something we could talk about concretely. I walked in not with a yes or no, but with a picture of the trade.

“If we ship next month on the current path,” I said, “here’s what it looks like from the customer side. About one in five new accounts will hit a serious issue in the first thirty days because of the weak spots we already know. Those issues will generate support tickets, escalations, and a lot of real-time help from the engineering team. Our best people will be in Slack troubleshooting instead of building the next wave of features. Some of those customers will forgive us; some will quietly decide not to expand. If we give ourselves another six weeks, we can cut the risk of a bad first experience roughly in half and give support better tools instead of asking them to improvise.”

The numbers weren’t precise. They didn’t need to be. The point was to change the question from “Can we technically launch?” to “What kind of launch are we choosing, and what are we signing up for with that choice?”

On other products, I’ve started even earlier, with a shared understanding of what “ready” means at different stages. We write down two sets of conditions. The first is “ready for real users in a controlled way.” That means the core flows don’t lose or corrupt data, we have basic instrumentation, we can turn the product off safely with a flag, and we have at least a simple playbook for the top failure modes. The second is “ready for general availability,” which covers the broader picture: docs, support tooling, migration paths from older systems, performance at the scale we actually expect, sign-off from legal and risk for wide distribution.

The product often reaches that first bar much earlier than the second. Instead of arguing whether we’re ready or not in the abstract, we talk about opening the doors to a small set of customers under the first bar, while being honest about what that means. We might limit geography, segment, or contract type. We might assign someone from the product team to be on call in those customers’ Slack channels. We might brand it clearly as a beta with specific expectations: “This solves X for you now, but you will see rough edges and we’re looking for your input to shape the next iterations.”

That approach lets you move at a serious pace without pretending you’ve done all the hardening that a wide launch demands.

Inside the team, I also treat quality as explicit work, not something that “just happens” while we chase features. Every 0 to 1 effort has a long list of things we wish we could do: tests we delayed, observability we haven’t wired, refactors we keep pushing to “later.” If you let that list grow unchecked, the team slows down anyway because every change feels risky and fragile. So we reserve time, every cycle, for strengthening the core. Not as a side project, but as part of the plan we share with stakeholders. That might be twenty to thirty percent of the team’s capacity, and it flexes based on what we’re seeing in production, but it exists by design, not by accident.

When we do throw in a quick hack, we treat it like borrowing money. You can borrow, but you need a date to pay it back. I’ve literally written on a shared document: “We will handle onboarding manually through this shared inbox until we have twenty customers through the door. After that, we either automate properly or we stop offering this pathway.” It forces a decision instead of letting “temporary” last for years.

For higher-risk areas, I like to agree in advance on lines we won’t cross. Every organization has its own version of this. In fintech, it might be “we don’t ship with any known issues that can create mismatched balances or expose one client’s data to another.” In health, it might be “we don’t ship anything that can misroute clinical information without a clear, tested fallback.” Once you write those down and align with legal, security, and your peers, it becomes much easier to say “not yet” when a launch date collides with a known violation of those lines. You’re no longer the cautious engineer blocking progress; you’re the person honoring a shared agreement.

So when someone asks me now, “Can we launch next month?” on a 0 to 1 product, I rarely answer with a simple yes or no. I describe the shape of the launch we can do in that time.

Sometimes that means, “We can be live next month with five design partners who match this profile, with someone from the team embedded with them, and a clear beta label. That will give us real usage and stories without exposing the wider base.” Other times it means, “We can hit your date if we accept a high level of pain for the team and a real risk of souring our first wave of customers; if you want this to be part of next year’s flagship story, I’d recommend a later date with these specific improvements.” And occasionally, when the core trust boundary is at risk, it means, “No, not without gambling with things we’ve said we don’t gamble with. Here’s what we would need to change to make an earlier launch viable.”

The sweet spot of quality vs speed on a 0 to 1 product isn’t a single point on a chart. It’s a habit of making those trade-offs visible and deliberate, week after week, instead of hiding them behind slogans.

If you’re in the middle of one of these efforts right now, a simple step this week can move you in the right direction. Sit down with your product and engineering leads and write out, in plain language, what “ready for first real users” means for you, and what “ready for everyone” means. Then walk through your current state against those descriptions and ask, “Given where we are, who would we feel good about inviting in, under what conditions?”

That conversation does more for finding your true sweet spot between speed and quality than any motto on a poster. It makes the risk real, the trade-offs explicit, and the path forward something grown-ups can argue about honestly.

Picture an entire office dragged into a single daily standup because someone heard that “scrum teams do standups.” Not a team standup. An office standup. Sales. Design. Product. Engineering. Marketing. Customer success. People working on different clients, different projects, different priorities, all standing in a circle pretending this was agility.

One senior executive, outside my org but higher on the ladder, was convinced this was the way. He wanted everyone together so he could hear “what’s going on.” It looked like ceremony, so it must be good, right?

I didn’t see a high-functioning company. I saw a cargo cult.

I’ve spent most of my career in places where quality, risk, and regulation matter. You don’t get to hide behind trendy frameworks there. Practices like standups, XP, and agile only make sense when they are in service of a team trying to deliver real value to real customers under real constraints. When you rip them out of context and turn them into mandatory theater, you get the worst version of both worlds: loss of autonomy and no real gain in coordination.

At that company, people used to joke that I was the “walking culture deck.” I was proud of that. Not because I loved slogans, but because I actually believed in the values we had written on the walls. One of them was “Brave”: do the right thing, not the easy thing.

So I did the annoying but necessary thing: I pushed back.

I argued that teams should decide how they work. I walked through the basics of XP and agile: daily communication inside a team that shares a backlog and a goal, tight feedback cycles, clear ownership. I pointed out the obvious: a salesperson working a long-cycle deal and an engineer debugging a production issue don’t benefit from sharing status in the same three-minute window every morning. It just burns time and attention.

The teams agreed. Roughly 80% of the people in that room backed the idea of rethinking or killing the mega-standup. The remaining 20% had other incentives: being seen by the senior executive, staying close to power, signaling loyalty.

I didn’t win.

Hierarchy won. The all-hands standup stayed. Every morning, everyone stood in that circle and went through the motions.

So I found my own way to stay sane.

During my turn in that meeting, I would share whatever was genuinely useful for others – key risks, big deliveries, blockers that needed help. And at the end, I started closing with the same line:

“Other than that… business as usual.”

It began as a dry joke. A way of saying: “There’s nothing here that justifies all of us being in this room, but I’ll respect the decision and keep doing my real job.”

After a couple of weeks, the executive started skipping straight to the punchline. He’d look at me and say, “Business as usual, right?” If I said “Yes, business as usual,” he would move on without an update.

In that tiny interaction, the phrase flipped meaning for me.

On the surface, “business as usual” sounded like compliance. Underneath, it became shorthand for: “I’ll keep doing the real work of serving customers and supporting teams, no matter how much ceremony you throw at me.”

From there, it took on a life of its own.

The team gave me a mug with “Business as Usual” on it. It wasn’t just a gag gift. It was a quiet alignment: “We see what you’re doing. We know the difference between rituals that help us and rituals that exist so someone can feel in control.”

On my last day at that company, I walked into the office and froze.

Everyone was wearing a hoodie with my face on it and “Business as Usual” as the caption. Not a sticker someone printed at home. Actual official swag, approved and produced by the company.

I still think about that moment. Not because my face was on a hoodie – that part is ridiculous. What mattered was that a simple phrase had turned into a shared story: a group of people choosing to care more about outcomes than theater, and having fun with it instead of turning bitter.

Years later, when I decided to start a blog, that story came back immediately.

I didn’t want a name that sounded like a consulting firm or a tech newsletter. I wanted something that captured a tension I see in almost every company: the gap between what we say we value and the way we actually work day to day.

“Business as Usual” was perfect because it’s a trap phrase.

Most organizations have a silent list of things that fall under “business as usual”:

Daily meetings that no one questions anymore. Quarterly planning done the same way it was five years ago, even though the market has shifted. Status reports that exist mainly so someone three levels up feels informed. Frameworks adopted by name while the actual practices are broken beyond recognition.

When people say “That’s just how we do it here,” that’s the moment my brain wakes up. Why? Who does this help? What problem was this trying to solve, and is that problem still the same?

The blog exists to poke at those habits.

Not from a place of cynicism, but from the same value that pushed me to challenge that standup: be brave enough to do the right thing, even when it cuts across habit, hierarchy, or trend.

I don’t have anything against standups. I like them when they belong to a team, when they’re born from a shared need for visibility and coordination, when they’re part of clear team norms. The “how” is always a design choice. If a Kanban board works better than a spoken standup, use that. If an async update in Slack saves an hour for a distributed team, try that. If a team wants to keep a short daily check-in because it keeps them aligned and honest, good.

What I can’t live with is process as fashion. Adopting agile ceremonies because they’re trendy, while stripping away ownership, feedback, and trust. Calling something “XP” because it has the right labels, while ignoring the discipline under it. That’s the stuff that hits my core values.

So when you see “Business as Usual” on my blog, here’s what it stands for:

It’s a reminder to question anything that hides behind that phrase. It’s permission to ask “why” one more time, even when everyone else has given up and gone along. It’s a small promise from me that I will care more about customer value, team health, and clear decisions than about fitting into whatever method is fashionable this quarter.

It’s also a nod to that office full of people in hoodies on my last day. They didn’t just accept the status quo. Many of them pushed back, experimented in their own teams, and kept their sense of humor in the middle of it. I owe a lot of my stubbornness on this topic to those years.

Business as usual doesn’t have to mean “the way we’ve always done things.”

It can mean something else: teams grounded in purpose instead of ceremony, practices chosen on purpose instead of copied from a slide, and leaders who are willing to say, “This ritual isn’t serving us anymore – let’s change it.”

That’s the work I care about. That’s why the blog has this name. And if reading it gives you even one more reason to challenge your own “business as usual” in the service of better results for your customers and your teams, then the mug, the hoodie, and those long standups were all worth it.

I thought I was ready to take this “easy extra task”.

But I didn’t change anything about how I worked.

Same code ownership, same incident pings, same review queue, same “let me just take this one, it’s faster if I do it.” The only thing I added was more: more meetings, more cross-team discussions, more planning. On paper, my role changed. In practice, I was still behaving like a senior IC who’d been handed extra chores.

Weeks later I was exhausted and quietly asking myself a question I hear from a lot of tech leads: if I’m not the one doing the hard work, what exactly is my job?

This is the gap nobody really prepares you for. When your scope grows, the company is not asking you to do more tasks. They’re asking you to own bigger outcomes, carry more risk on behalf of the org, and create clarity where there wasn’t any. The catch is that you can’t do that while still holding all the same individual work you had before. Something has to give.

I think of my time now in three rough categories. There is doing the work. There is enabling other people to do the work. And there is shaping which work exists at all. As a strong IC, you mostly live in the first category. When your scope grows, your calendar needs to move toward the second and third. If it doesn’t, you end up in a strange place: overloaded and yet underused at the same time. You’re busy all the time but not really moving the things your new role is supposed to move.

The mistake many of us make, and I absolutely did, is trying to keep that first category the same size so we “don’t lose our edge.” You don’t lose your edge. You just lose sleep.

There are a few signals that you’re stuck in this in-between state. You finish most weeks feeling like you worked hard but moved nothing that matters a quarter from now. Your one-on-ones are mostly status updates, because you already know every detail from being deep in the code and the incident channels. You’re the contingency plan for every risky project: if it gets hairy, everyone knows you’ll jump in. Your calendar is full, but when your manager asks, “Who owns this area?” the honest answer is still “me, accidentally.” When two or three of those are true, you’re not in bigger scope yet. You’re in same scope, new title.

Letting go is not a soft, vague skill you pick up in a leadership training. It is a very concrete change in how you operate.

The first move for me was deciding what only I can do now. Before delegating anything, I sat down and wrote my real responsibilities in this new role. In a tech lead or Engineer Manager seat, that list usually includes things like choosing technical direction for a set of systems, protecting the team from randomization and bad bets, making sure every important area has a clear owner, and growing at least one or two people into the next level. That is the job.

Once that list is clear, the next question becomes much easier: what am I doing today that someone else could realistically do within three to six months with support? That’s the work you need to let go of. If you skip this step and start “delegating” randomly, you’ll default to giving away only the boring work while keeping the interesting problems for yourself. People notice. They feel it. And they stop believing that what lands on their plate is real ownership rather than overflow.

A very practical thing that helped me was doing a short work review over a week or a sprint. I wrote down everything I coded, every decision I made, every meeting where I was essential versus just present. Then I tagged each item in my own notes: this really has to be me because of context, relationships, or risk; this could be me for now but someone can grow into it; this doesn’t need me at all. My goal over the next few months was to shrink the first group and move items from the second to the third. Nothing fancy, just intentional.

Once you know what to let go, the question becomes how to do it in a way that actually grows people instead of dumping on them. There is a big difference between throwing tasks over the wall and handing over ownership. “Can you take this, I’m too busy” is dumping. “This is yours now, here’s why it matters, where the boundaries are, and how I’ll support you” is ownership.

When I hand off something meaningful, I talk through four things. I explain the context: what problem this work exists to solve, who cares, and what good looks like. I clarify decision rights: what they decide alone, what we decide together for a while, and what I still own for now because of risk or politics. I describe the safety net: when they should pull me in, how we’ll review decisions, where the docs and history live. And I give a time frame: my aim is that in a few months you’re making almost all the calls here without me. That time frame matters, because without it people assume you’re just overloaded and will take it back as soon as you “have time again.”

Behind all of this sits a very real question your reader raised: when and how do you detach, when do you trust, and when do you cut the cord? I don’t treat that as a gut-feel problem. I look at risk, visibility, and experience. Risk is about what happens if this goes wrong. Visibility is about who is depending on this work and how public the failure would be. Experience is how many similar problems this person has owned before.

If something is high risk and the person is early in that area, I stay close but let them drive. They lead discussions, they write the docs, they speak in reviews, and I sit next to them. I ask questions, I model how to think about trade-offs, I intervene if we’re about to violate a regulation or an SLA, but I don’t rip the work out of their hands at the first sign of discomfort. As their experience grows or as we move into smaller, less visible changes, I increase the distance. I stop joining every meeting. I move from reviewing every decision up front to reading summaries. At some point my involvement switches from approving details to occasionally adjusting direction.

That distance is not fixed. I keep adjusting it based on those three axes. Trust is not all-or-nothing; it is how far I let you run before I check in, and that distance expands as you show you can handle it.

The harder part in all of this is not the mechanics. It is how you feel about your own productivity. For years, your sense of a “good day” probably came from visible output: tickets closed, pull requests merged, bugs fixed at 11:30 p.m. In a bigger scope role, your impact becomes slower and less visible. You might spend an afternoon aligning two teams so they don’t ship conflicting solutions, reworking a roadmap so the company isn’t betting everything on one fragile dependency, or coaching someone through a design so they can lead it without you. None of that shows up on a GitHub chart.

What helped me was changing what I count as a productive day. I started asking myself different questions. Did I make it easier for the team to move next week? Did I reduce risk on anything that would hurt us in the next few quarters? Did I grow someone’s capacity so that a year from now they won’t need me for this category of decision? If the answers were yes, that was a good day, even if I hadn’t written a line of code.

You can make this more concrete if you like numbers. Look at how many decisions are now made without you that you would have made a year ago. Look at how many systems or areas have clearly named owners who are not you. Look at how often people start conversations with “we decided” instead of “I was waiting for you to weigh in.” Those are all signs that your scope is actually bigger, not just heavier.

The last piece is the identity shift. Letting go means watching someone make a call you would have made differently. It means seeing a system you built evolve in a direction you wouldn’t have chosen. It means hearing about an incident in a domain you know well only after it’s already solved. Early on, that can feel like losing status or relevance. Your brain wants to jump in and prove, again, that you can still crack the hard problems.

When that discomfort kicks in, I try to pause and write down the thing I’m tempted to fix personally. Then I ask: what would need to be true for this kind of decision to be made well by the team every time without me? The answers to that question become my real work. Maybe it’s clearer guidelines. Maybe it’s a better review forum. Maybe it’s coaching one person so they become the go-to in that space. In all cases, the result is the same: my attention moves away from the specific incident and toward the system that produced it.

If you’re already in a tech lead or manager seat and you feel like you’re half IC, half firefighter, half therapist — yes, that’s three halves — you don’t need a reorg to change this. You can start small. Pick one area where you are the de facto owner. Pick one person who could grow by owning more of it. Have an honest conversation about what ownership would mean, why it matters, how you’ll support them, and what success looks like a few months from now. For the next big decision or incident in that space, let them lead while you sit in the second chair. Afterwards, review together what worked, what scared them, and what you both would do differently next time.

Over a few cycles, the texture of your work starts to change. Your calendar will probably still be full, but it will be full of different kinds of problems. Less “do it myself before it breaks,” more “shape the work, grow people, steady the system.” Your feeling of productivity shifts from “I fixed it” to “we can handle it.”

That’s when bigger scope stops being a sentence and starts being real. Not just more things on your to-do list, but a different job: one where letting go is exactly what creates space for the work you were actually promoted to do.