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.

Most of the time, scope is a placeholder. It’s a word we use when we’re reacting to a pattern but haven’t done the hard work of naming it. For ICs, that makes scope feel slightly mystical and out of reach. Some blend of “be more senior,” “do bigger things,” and “have more impact,” while still shipping your current backlog and not dropping any balls. I used to take that kind of feedback as a character judgment: maybe I don’t think big enough, maybe I’m just a solid mid-level engineer who happens to have a Staff title. Over the years, after sitting through enough promo committees and calibration meetings, I stopped treating scope as an identity label and started treating it as a description of the problems you’re trusted to hold.

As you move from mid-level to senior and Staff+, your company quietly changes the job on you. Earlier in your career, the game is simple: take a defined problem, do solid work, don’t blow anything up. The unit of work is a ticket, a story, a feature, a clear slice of analysis. Past a certain point, the expectations shift. The question becomes: can you be trusted with problems that are fuzzy, cross-cutting, politically sensitive, and important enough that leaders lose sleep over them? That shift is what people are trying to point at when they say “scope,” even if they don’t have the language for it.

When managers and promo committees talk about scope they’re usually blending a few dimensions in their heads. They’re looking at outcomes: what results you’re accountable for, and how much they matter to the business. They’re thinking about ambiguity: how clear the problem is when it lands on your desk, and how much shaping has to happen before the work is even ready for a ticket. They’re watching risk: what can go wrong if you make a bad call, or if the work fails in production, or in front of a regulator, or on a key customer account. They look at time horizon: are you solving next quarter’s problems, or shaping the next one to three years. They pay attention to coordination: how many teams, disciplines, or systems have to move together for this to work. They notice stakeholders: who cares about this work – your squad, your org, senior leaders, partner teams, regulators. And they look at systems: are you touching one service or flow, or the shape of a whole platform or product area.

Most senior IC rubrics in engineering, product, design, and data are some remix of these ideas. At Staff levels and beyond, scope is less about how many things you ship and more about how consequential the problems are that you reliably take from fuzzy idea to stable reality. That’s helpful to understand conceptually. The trouble is that when it shows up as “you need bigger scope,” it still doesn’t tell you what to do on Monday.

From an IC seat, that sentence often lands in two unhelpful ways. First, it sounds like “just do more.” You’re already maxed out. Being told to “take on more scope” can sound like “be 120% as productive, with the same support and the same constraints.” Second, it’s underspecified. No one tells you which dimension of scope is missing. Are you too focused on near-term execution? Are you avoiding ambiguous problems? Are you only owning slices of projects instead of end-to-end outcomes? The default reaction is either shame – I’m not senior enough – or confusion – I don’t know what they want from me. Neither reaction helps you grow.

A more useful approach is to treat scope as a diagnostic clue rather than a verdict. Over time, I started to hear “you need bigger scope” as a family of more specific messages. When a manager uses that phrase, it often maps to one or more recurring patterns.

Sometimes it means you own tasks, not outcomes. You reliably deliver your tickets, designs, or analyses, but someone else is holding the end-to-end customer or business outcome. You’re seen as contributing to important work, not owning it. Your name shows up all over Jira, but when people talk about who owns the result, they name your manager, your tech lead, or the project lead.

Sometimes it means you avoid messy, ambiguous problems. You do great once the problem is defined. Your design docs are clean, your execution is solid, and you hit your dates. But you’re not the person people call when something is unclear, cross-cutting, or politically touchy. When a senior leader says “we need to fix onboarding; customers keep dropping,” that problem quietly routes around you and lands on someone who is known for shaping vague problems into concrete work.

Sometimes it means your work is too local. You’re doing good work inside your immediate team or service, but it doesn’t change much outside that boundary. Other teams don’t feel your impact. If your project vanished, only your squad would notice. In calibration, your manager struggles to explain how your work affected anything beyond your lane.

Sometimes it means you don’t change the trajectory. You improve the quality, stability, or speed of work that was already going to happen. You close gaps, fix bugs, refactor messy code, tighten up specs. All of that is valuable, but you rarely originate or reshape the work so that the overall trajectory of a product, system, or metric is meaningfully different. Leaders don’t see a before-and-after story tied to you; they see incremental improvement.

Sometimes it means risk lives above you. When a decision has regulatory, financial, or reputational risk, the call is always made by someone more senior. You’re consulted, you do the analysis, you write the doc, but you’re not the accountable owner. When things go well, you’re thanked for your help. When things go badly, your manager is called into the meeting.

Sometimes it means you’re stretched thin but not concentrated. You’re helping on many things, often as the fixer or the one who unblocks others. You parachute into incidents, do quick reviews, patch things up. But because your effort is fragmented, nothing with your name on it shows up as a clear, consequential outcome. People know you’re useful; they don’t see a big bet that you own end-to-end.

And sometimes it means leaders don’t think of you for the next big thing. When leadership allocates the next hairy problem or high-visibility bet, your name doesn’t come up. Not because you’re not capable, but because you haven’t yet built the pattern of owning and winning at those kinds of problems. In conversations about who should run a critical migration or lead a risky redesign, you show up as “strong support” rather than “primary owner.”

None of these patterns feel good to read. I’ve been in several of them. The upside is that each one suggests a different set of moves. The job is to figure out which one fits your situation, with as much honesty as you can manage.

You don’t have to decode this alone. Your manager might not have perfect clarity either, but you can pull them into sharper thinking. In your next 1:1, instead of asking “how do I get bigger scope,” ask them to look at specific work. For example: when you say “bigger scope,” can we get concrete about where you already see me at the right level and where you see the gap to the next one. Or: if you look at the last 6–12 months of my work, which projects felt like the right scope for a senior engineer or PM, and which felt too small or narrow. What’s the pattern.

You’re aiming for stories, not slogans. Calibration and promo discussions are full of phrases like “Staff-level scope” or “principal-level impact.” Underneath those phrases are real events: launches, outages, audits, strategic shifts, customer escalations. Your goal in that 1:1 is to get your manager to replay those scenes and place you inside them. That gives you something you can actually work with.

One exercise I give people I coach is very simple. List your top three to five projects from the last year. For each one, write a line or two on the scope dimensions: what outcome were you on the hook for; how ambiguous was the problem when you started; what was the risk profile; what time horizon did it affect; how many teams and systems were involved; who were the key stakeholders. Then compare that list to your level rubric, and if you can, to example promo packets at the next level in your org. Look for two things: your median scope, which is what’s typical for you, and your most frequent scope pattern. When I sit in promo meetings, that median and that pattern matter far more than your single biggest win.

Company context warps all of this. Scope is not an absolute quantity; it’s relative to the company’s size, structure, and risk profile. At a big company like Amazon, you can work on a single service whose customer and revenue impact would count as a whole business at a startup. On paper that looks huge. In practice, your day-to-day might still be narrowly framed if you’re only tweaking small pieces of that system. In large, regulated environments like fintech, health, or aviation, risk and stakeholders matter a lot. Owning scope often means owning the relationship with risk, compliance, or legal partners and being trusted to navigate them without babysitting. In FAANG-scale product orgs, coordination and systems tend to be the bottleneck. Bigger scope might mean taking on a cross-team migration, a shared platform that many teams depend on, or a multi-year vision for a product area. In earlier-stage companies, time horizon and outcomes often dominate. A Staff IC might own a whole problem space end-to-end – discovery, design, build, launch, iterate – because there’s no one else to catch the pieces.

When someone says “you need bigger scope,” you can quietly ask yourself: bigger in which of these dimensions, relative to the way this company actually works. That question alone will keep you from chasing abstract bigness and will steer you toward the parts of scope that matter where you are.

Once you have a sense of the pattern, you can make moves over a three to six month window that grow your scope without turning you into a martyr. One move is to shift from feature ownership to problem ownership. Stop framing your work as “I own Feature X” and start framing it as “I own Problem Y for Customer Z.” That small shift changes who you talk to, what metrics you watch, and how you make tradeoffs. Another move is to volunteer for one ambiguous, cross-cutting problem. Not five. One. Pick something like stabilizing a flaky area that spans services, rationalizing a confusing part of the UX that touches multiple surfaces, or untangling a recurring incident pattern.

You can also start taking the first pass on defining the work. When a vague request comes down from leadership, offer to draft the problem statement, the success metrics, and a couple of options. Senior scope often starts with being the person who can turn “we should fix onboarding” into a concrete plan others can inspect and refine. At the same time, concentrate your impact. If you’re spread across many efforts, work with your manager to consolidate. Ask which one or two bets this half, if they go well, would clearly demonstrate Staff-level scope for you. Then be intentional about saying no to other nice-to-have asks that would dilute that.

Another powerful move is to own the risk conversations. Instead of escalating risk for others to solve, show up having already mapped the risks, proposed mitigations, and made a recommendation. Over time, people start to trust you with hairier decisions. And as you do all of this, narrate your scope. Don’t assume people see the size of the problems you’re holding. Use status updates, design docs, and 1:1s to make the scope visible: the cross-team decisions you’re steering, the tradeoffs you’re holding, the future impact you’re designing for. That’s not bragging; it’s creating an accurate shared picture of your role.

When you write promo packets or self-reviews, skip the vague claim “I took on bigger scope” and show it instead. Anchor your stories in the same dimensions. Describe the outcomes: what you owned end-to-end, how many customers or systems it touched, what changed in the metrics. Describe the ambiguity: how fuzzy things were at the start, what you did to clarify the problem space. Describe the risk and the stakeholders you carried, the time horizon you were shaping, the coordination and systems you orchestrated. Then explicitly connect those examples to your level rubric so the reader can see that your median and most frequent scope have already moved to the next level, not just one lucky project.

For me, the big unlock was stopping the habit of treating scope feedback as a judgment on my worth. When I heard “you need bigger scope,” I used to translate it to “you’re not actually Staff; you’re just pretending.” That mindset made me defensive and quietly anxious for years. Over time, with some help from managers and peers who were honest with me, I started treating scope as a design problem instead. Given my skills, interests, and the current state of the org, how can I shape my portfolio of work so that my median and typical scope match where I want to be.

Seen that way, scope becomes something you and your manager can design together. You have real constraints: reorgs happen, roadmaps change, leaders rotate, market shocks hit. Luck and timing always play a role. But you have more influence than you think over the shape of the problems you hold and the way they’re perceived. Once you stop treating “you need bigger scope” as a mysterious curse, you can start treating it as an invitation to redesign the work so that it grows you and moves the business at the same time.

In this first episode, Rex tries to impress the room with a spotless operating model, only for everyone to realize the whole thing collapses into one box: “Ask Dee.” Uma connects the dots faster than he expected and calls out the real situation—every critical path depends on one person keeping the lights on.

By the third panel, the mask is off. The company’s growth curve rises and falls with Dee’s availability, as if he were an API with guaranteed uptime instead of a human trying to do a job. His dry reaction says what everyone else is thinking. He isn’t part of the system; he is the system, and that’s exactly the problem.

It’s the engineer who says “sure, I can do that” in every planning meeting. The PM who quietly picks up the work nobody signed up for. The ops lead who keeps taking on “just one more” responsibility until they’re effectively doing three jobs. Their calendars are packed, their Slack is on fire, and their names show up in every “thank you” email.

And yet… they’re stuck.

The steady, reliable “can-do” people become the unofficial insurance policy of the company. Early in their career, that label is pure upside. Managers trust them. Leaders remember them. Work finds them. At some point, usually in that band between senior and “should be leading bigger things by now,” the same trait that made them stand out starts to box them in.

When I think back on the people who carried the heaviest load on my teams, I see two distinct patterns that often get blurred. One is the hero. The hero shows up in visible crises. They save the production outage at 2 a.m., pull the all-nighter before the board meeting, personally carry the death-march project over the line. Their stories are loud and retold.

The other pattern is the can-do person. They’re not chasing drama. They are the ones who quietly say “yes” when something ambiguous, messy, or unowned appears. They pick up extra scope without complaint. They catch the dropped balls before anyone sees them hit the ground. Most of their work is invisible glue.

You can be a hero without being can-do: show up only for big, visible saves and keep your distance from the slow, grinding work in between. And you can be deeply can-do without ever being the name in the all-hands story. It’s that second group I worry about most, because they often don’t realize they’re in trouble until the ceiling is right above their head.

Most can-do careers start the same way. Someone throws them into chaos, they figure it out, and people remember. “I can count on you.” At 25, that sentence feels like oxygen. At 35, it starts to feel heavier.

Over time a few things happen.

They say yes on autopilot. Their identity is built on being the one who comes through, so “no” feels like letting the team down, not like focus. They become human routers. Problems get sent their way because everyone knows they’ll either handle it or find someone who will. Their work drifts toward the unplanned and the orphaned. They’re closing gaps and smoothing rough edges instead of shaping the actual system of work.

On paper, their career looks strong. Performance ratings are high. They’re pulled into important conversations. Leaders praise their reliability. If you only looked at feedback forms and kudos channels, you’d assume they’re on a fast path.

The trap shows up somewhere else: in the quiet promotion conversations behind closed doors.

I’ve heard versions of the same sentence in many of those rooms: “They’re amazing, but if they stopped doing X, the whole thing would fall apart.” Or the softer one: “She’s great, but I’d like to see her taking on a bigger scope.” On the surface this sounds like fair feedback. In practice, it ignores the invisible scope that already stretches them across half the organization—the incidents they quietly own, the glue work between teams, the mentoring, the unblocking, the stray responsibilities nobody has written down.

The can-do pattern has trained the company to treat that as background noise rather than real scope. Their current role has quietly expanded far beyond its title, but their next role never seems to show up.

If you zoom out from the individual and look at the team, the picture shifts again. From the outside, a team with one or two strong can-do people looks healthy. Projects land. Incidents get handled. Stakeholders are mostly fine.

If you listen inside the team, you start to hear different phrases.

“Let’s wait for Alex, they know this best.”
“Ask Priya, she always figures this stuff out.”
“Run it by Jordan, they usually take things like this.”

Those aren’t just signs of respect. They are signals of dependency.

People learn a kind of soft helplessness. Instead of wrestling with ambiguous work long enough to understand it, they touch it lightly because they assume the can-do person will step in if things get messy. Skill growth stays shallow. The hardest, muddiest work drifts to the same person every time, and everyone else stays in safer, narrower lanes. The bus factor collapses. You’re one resignation or one medical leave away from a real problem, even if your dashboards and OKRs are all green.

The can-do person often feels like they’re doing the right thing. In their head, they’re supporting the team, helping, unblocking, “just jumping in this once.” What they don’t see is the ceiling they’re building over the team’s capability. The more they quietly absorb, the less anyone else has to stretch.

Healthy teams share pain and context. The scary incidents rotate. The fragile systems are understood by more than two people. People are allowed to struggle long enough to actually grow. None of that happens by accident in a culture that rewards the fastest “I’ll take it.”

There’s a simple test I use with senior folks who suspect they might be in can-do overload: what really happens if you disappear for a month?

Not in the contingency plan you wrote, in reality.

Who panics? Which projects pause or get quietly cut down? Which executives start emailing your manager? Where does your name suddenly appear in status meetings because people are trying to reconstruct what you actually do?

Whatever falls apart in that scenario is a mirror of how you’ve been working.

Now switch chairs and look at this from the manager side. As a manager, nothing feels safer than having a can-do person on the team. When an executive drops a surprise “critical” initiative in your lap, you already know whose name just popped into your head. That instinct is the beginning of the dependency.

You tell yourself you’ll protect them “next quarter,” when things calm down. In the meantime, instead of pushing back on scope or trading work with another team, you slide the new mess toward the can-do person. They say yes, like they always do. The work gets done. You avoid a fight over priorities. You don’t have to bet on someone unproven.

On paper, it works. For a while.

Then you look up and see what you’ve built. One or two high performers are quietly burned out. Their calendar is a wall of “quick syncs,” escalations, and stray responsibilities that don’t match their title. Their growth has stalled because every career-defining project shows up as a late-stage scramble with no room to shape the problem. The rest of the team hasn’t built the muscle to carry heavy, unclear work or to negotiate priorities with stakeholders because someone else always absorbs the chaos. Your group has a reputation as the team that can “always take one more thing,” so other leaders keep piling it on.

No manager writes that down as their operating model. It grows out of a thousand small decisions where the easy answer was “give it to the person who always says yes.”

The harder path for a manager is often the right one. Saying no on behalf of your team even when you know your can-do person could push through. Protecting their calendar for work that changes the system, not just this quarter’s fire. Rotating the hard, messy, politically risky work so other people stretch into it. Being honest in performance conversations: not just “you’re so reliable,” but “you’re the safety net for too many things; that’s not sustainable for you or for us. Let’s spend the next year making sure three other people can carry what only you can carry today.”

That conversation is awkward. It also marks the point where you stop using them as a crutch and start treating them like a future leader.

At company scale, I’ve seen the same pattern in different clothes. In fast-growing or heavily regulated environments, you absolutely need people who can walk into a new domain on Monday, talk to auditors at 9, debug at 10, and explain trade-offs to the board at 11. In the early years, those people keep you alive.

The trouble starts when leadership quietly uses them as a substitute for clear structure and hard trade-offs.

You begin to see chronic priority overload: everything is “critical,” but the same names appear whenever something must be saved. Role gaps become permanent—missing product owners, weak incident management, unclear data ownership—all covered by a few people “who know how things work.” Stories at all-hands center on how “people stepped up” and “teams rallied.” The quiet work of simplifying systems, cleaning up ownership, and removing sources of chaos rarely gets mentioned.

At that point, can-do employees stop being a strength and start being a kind of hidden liability. The company has built part of its operating model on a small set of people always saying yes. That doesn’t show up in the risk register, but it should.

I’ve sat in board meetings where leadership proudly cited “how our people always step up” as proof of a strong culture. Ten years ago, I might have nodded along. Now, I listen for the second half of the sentence. If the same people have been stepping up for years, you don’t just have commitment; you have an unpriced dependency.

So what do you do if you recognize yourself in this?

I wouldn’t tell a can-do person to stop being can-do. That instinct is usually tied to pride in their craft and genuine care for the team. The goal is not to blunt it, but to aim it.

One practical shift is to change “Sure, I’ll take it” into “Yes, if…”. Yes, if something else comes off my plate. Yes, if this comes with the mandate to fix the system that keeps producing this kind of mess. Yes, if we agree who owns this long term and it’s not just me by default.

Another is to make the invisible visible. For a month, track your can-do work. Every incident you step into, every escalation, every surprise ask, every “quick favor,” every extra responsibility you quietly accept. Then sit down with your manager and go through it together. Which of these should exist at all? Which should move to someone else or to another team? Which are things you will keep doing, but only with different conditions next time?

Day to day, there’s a simple habit that changes the arc over time: teach first, fix second. When someone brings you a problem, resist the reflex to grab the keyboard. Ask questions. Pair on the solution. Write down what you both learned. Share it somewhere people can actually find. It feels slower in the moment. Over six or twelve months, it’s the difference between being the only person who can carry the messy work and being the person who quietly raised the bar for everyone.

When you do that long enough, your value starts to shift. You’re no longer defined by how much extra work you can personally absorb. You’re recognized by how much meaningful work the group can handle because of the systems, ownership, and people you’ve grown.

Good companies will notice that shift and support it. Great ones will expect it and design around it. And if your company just keeps handing you more unbounded work, calling it praise, and never changing the system underneath, that’s not a sign that you need to be even more can-do. It’s a data point about where you stand.

A lack of clarity. A stalled debate. A dozen “we’ll decide next week” moments that pile up until someone up the chain finally steps in. By the time that decision lands, context has vanished, ownership fades, and what began as hesitation becomes control.

We call it “top-down,” but it usually starts lower — inside a leadership gap that no one wanted to name. Teams wait for direction, managers hesitate to commit, alignment becomes an endless ritual. When progress stalls long enough, someone senior eventually says, fine, we’ll decide. And just like that, the autonomy that made the team strong gets replaced by compliance.

Once that happens, the mood shifts. Morale dips. People start whispering about what should have happened. The grapevine fills with alternate versions of the truth. The organization’s energy moves from delivery to debate.

The instinct in those moments is to push back — to prove that the decision was wrong or that the team wasn’t heard. I’ve seen talented people spend weeks trying to win an argument that no longer matters. But here’s the quiet reality: once trust breaks, persuasion stops working. The fastest way to rebuild it isn’t through more meetings or perfect logic. It’s through results.

When a team delivers something that actually works, everything changes. Working software, cleaner operations, a measurable improvement that customers notice — those things speak louder than any post-mortem or executive memo. They re-establish credibility where it counts: in outcomes, not opinions.

I’ve watched teams recover ownership this way. They stop chasing approval and focus on one tangible problem they can fix. They deliver quietly, share results openly, and let performance speak for them. Within a few cycles, the same leaders who once dictated direction start asking for input again. That’s how trust comes back — one working release at a time.

For executives, that moment is a mirror. If you find yourself making more top-down calls, look for the vacuum underneath. Top-down isn’t a leadership style; it’s a symptom. It tells you where clarity, courage, or accountability went missing. The goal isn’t to fill every gap from above — it’s to create the conditions where gaps don’t form in the first place.

And for teams, the lesson is simple but hard: don’t waste energy fighting politics when you can out-deliver it. Every measurable result restores a piece of autonomy. Every small success builds the case for trust.

Leadership isn’t about control or consensus. It’s about momentum. When things stall, someone will always step in to move them forward — the only question is who.

If you want fewer top-down decisions, fill the vacuum with progress.
Nothing protects ownership like a team that keeps proving it deserves it.

This was early in my career. I didn’t have pattern-recognition yet, no crystal ball, just a gut feeling that he wasn’t trying to grow me—he was trying to keep things quiet and keep his paycheck steady. He wasn’t a bad manager - maybe not a good leader. He just didn’t want the noise that comes with pushing for the right thing in the right way.

I tried his advice on for size. I spoke less about customers. I stopped asking the questions that made meetings longer. I grabbed tickets that fit the time budget without touching other teams. My stress dropped. My impact did too. I could feel myself getting flatter. That was the red flag my instincts needed: if your manager plays small, you can either shrink with them or figure out how to grow without making them carry the risk.

So I treated it like an engineering problem. Constraints identified. Failure modes listed. Then I started running small, low-drama experiments that were easy to approve and hard to argue with. No grand pitch. Just proof and facts.

The first change was where I aimed. Instead of selling themes, I picked one number the business already cared about—something like the drop-off on a specific screen. I built the tiniest shippable change that could move that number in a couple of weeks. I wrote a one-pager anyone could read in five minutes: the customer friction in one sentence, what we were changing this week, and what we’d watch next. I sent it to my manager first and asked, “Anything here that makes you nervous?” Most of the time, the answer was no. He didn’t have to defend a “vision.” He just had to approve a concrete fix.

The second change was my surface area. If my manager kept the lens narrow, I needed context from the people who lived with the pain. Two short coffees a week with adjacent teams—analytics, support, sales ops. One question: “What’s a recurring task you wish just…worked?” That’s where the real friction shows up. I built a small script that shaved a day off a monthly report. I didn’t announce it. I sent it over, asked for corrections, and moved on. A week later that analyst mentioned it in a call my manager attended. That’s sponsorship without ceremony and a cleaner read on what “the right thing” looks like outside your lane.

The third change was visibility. Great work dies when it’s too hard to parse. I made demos the center of the conversation—real software running in the real environment. When a director can click a button and see the friction disappear, the politics quiets down. Opinions give way to “how soon?”

I also put growth on a calendar instead of vibes. I booked a calm check-in with my manager: “What outcomes in the next six months would make a raise or title change obvious? Which reviews will those show up in? Who needs to see what?” I wrote down every word and sent a short recap the same day. Not a trap—a record. If the targets stayed stable, great. If they drifted, that told me the environment wasn’t going to reward the work, and I could act without turning it into a scene.

And yes, quitting was on the table. It always is. But that’s the easy lever most people pull first, and not everyone can carry the mental and financial load that comes with switching jobs on principle. I’ve never judged someone who stays; staying can be the strong move when you’re early in your career and still building reps. My default has always been to make the system work if I can—break the problem down, ship value in small pieces, widen the circle of people who see it—then keep an exit ramp warm in case the ceiling holds. Options make you calmer. Calmer makes you better.

What changed? We shipped a handful of tiny fixes on a path nobody loved owning. Support tickets on that flow dropped. Time-to-ship improved because we weren’t relitigating the same issues. My manager didn’t transform, but he started routing certain problems my way because they got solved without noise. Other leaders noticed and pulled me into reviews when customer details mattered. No heroics. Just steady work that paid the bills and built trust.

The belief I dropped was that you need a big stage to do the right thing. You don’t. You need clear problems, small bets, and artifacts busy people can say “yes” to quickly. The belief I kept is that quitting is a tool, not a personality trait. Use it when the evidence says the room won’t reward real work. Until then, act like an engineer: test, measure, learn, repeat.

If you’re in this spot now and you’re early in your career, you won’t always read the room perfectly. You won’t always know whether the pushback is wisdom or fear. That’s fine. Trust your gut enough to run the experiment. Pick one measurable customer pain you can improve in a quarter without a re-org. Write the one-pager. Ship the smallest change. Ask for edits before airtime. Build two quiet relationships by fixing something real for them. Put your growth goals in writing with dates. Save your demos and before/after notes so your story doesn’t depend on anyone’s memory.

And if the environment keeps punishing range and avoiding real work, believe it. Take the evidence you’ve gathered and go where building the right thing the right way isn’t treated like a risk. Until then, don’t shrink. Make it useful. Make it legible. Keep going.

Buy at https://amzn.to/4o2a4aC

What It's About

Matt Watson spent twenty years learning what most CTOs figure out too late: your best engineers can ship flawless code on time and still build the wrong thing. Product Driven tackles the gap between technical execution and business impact—the space where teams deliver features nobody needs while the competition figures out what customers actually want.

The book’s central argument is simple but uncomfortable. We’ve spent decades teaching engineers to write better code, adopt better practices, and ship faster. But speed doesn’t matter when you’re running in the wrong direction. Watson argues that engineering teams need to think like product owners, not ticket processors. That means understanding business context, owning outcomes instead of outputs, and having the judgment to push back when requirements don’t make sense.

What makes the book relevant right now is the AI angle. As code generation gets commoditized, the teams that win won’t be the ones who can build faster—they’ll be the ones who know what to build and why. Watson’s “Product Driven Model” is his framework for making that shift, built from his experience scaling two companies to successful exits and watching plenty of smart teams fail along the way.

This isn’t another book about Agile transformation or OKRs. It’s about changing how engineers see their role—from implementers waiting for specs to problem solvers who understand the business deeply enough to make good decisions without constant handholding.

Why I Recommend It

I’ve spent 25 years watching talented engineering teams build themselves into irrelevance. They hit every sprint goal, their pipelines stay green, their code reviews are thorough—and then they wonder why the business isn’t growing or why their best people keep leaving for companies where they get to own real problems.

Watson nails what I learned the hard way: you can’t scale impact by just scaling team size and velocity. I’ve inherited teams that could ship features at impressive speed but had no idea whether those features mattered. The disconnect wasn’t a process problem or a communication problem. It was an ownership problem. Engineers treated themselves as a service organization, and management let them.

What I appreciate about this book is it doesn’t preach product thinking as some abstract ideal. Watson comes from the same place I do—he’s built teams, shipped products, dealt with the mess when things don’t work, and had to figure out why smart people with good intentions still miss the mark. His framework isn’t academic theory. It’s the pattern recognition that comes from doing this work long enough to see what actually moves the needle.

The timing matters too. I’m watching AI change what engineering work means, and not everyone sees it coming. When anyone can generate working code, the value shifts to knowing what code to write. That judgment—understanding user problems, business constraints, and technical trade-offs well enough to make good calls—that’s what separates high-performing teams from high-activity teams.

If you’re leading engineers who complain they never have enough context to make decisions, or if your roadmap is full but your business impact is empty, this book will show you what you’re missing. It’s not a fix-everything solution, but it’s a clear articulation of a problem I see everywhere and a practical path toward fixing it.

High-performing delivery isn’t a vibe; it’s measurable and it correlates with stronger organizational outcomes. You don’t control the whole org, but you absolutely control your personal flow. Treat your work like a tiny production system: items arrive, you select the next one, you work it, you finish. The science here is your friend.

A cornerstone you can bank on is Little’s Law: in any stable flow, WIP = Throughput × Cycle time. Hold WIP constant and your cycle time becomes predictable; let WIP balloon and cycle time drifts, then slips. That’s not a framework—it’s a theorem proved in 1961 and used everywhere from manufacturing to software.

If you’ve ever felt busier while finishing less, you’ve met the enemy: excess WIP. Research in software teams has found that higher WIP correlates with longer lead times; when teams—and individuals—cut WIP, flow gets faster.

And while you’re at it, stop feeding the context-switching monster. Cognitive science shows that switching tasks incurs real performance costs, and interruptions stretch the time it takes to get back on track—often measured in tens of minutes, not seconds. Guard your attention like it’s production capacity—because it is.

The Prioritization Ladder: Five Rungs You Climb Every Week

This isn’t a ritual for show. It’s a short loop you’ll run Monday morning and revisit mid-week. The steps stack: economics first, then flow, then psychology to keep you executing.

1) Price Your Options with Simple Economics (Cost of Delay → WSJF)

Backlogs are options. Options lose value while you wait. The cleanest way for an IC to rank options is Cost of Delay (CoD) divided by duration, a ratio popularized as WSJF. You don’t need perfect numbers—relative scores are enough to get the order roughly right. Estimate three things for CoD: 1) user/business impact if delayed, 2) time criticality, 3) risk reduction/opportunity enablement. Divide that by a quick size proxy (ideal: effort in days). Highest score wins your focus.

Why this works: you’re making the economic tradeoff explicit. Two similar tasks? Do the one whose value decays faster or removes more risk. This is how product folks should sequence portfolios; it scales down beautifully to the individual.

A 10-minute way to score your week

This table isn’t the law; it’s a lens. Adjust the factors for your context (e.g., compliance risk). The point is to rank by economic loss per unit time, not opinion.

2) Set a Ruthless Personal WIP Limit (Usually 1–2)

Now make the math work for you. Cap how many items you actively work. My default: WIP=1 for deep work, WIP=2 only if one item is waiting on someone else. Little’s Law guarantees that lower WIP shortens cycle time; queuing theory further warns that as utilization approaches 100%, wait times explode—so leave slack to absorb variability.

If you need a second push: empirical work in software teams ties lower WIP to shorter lead times. That’s the difference between “done this week” and “still in progress next sprint.”

3) Defend Focus from Switch Costs and Interruptions

Multitasking isn’t a badge; it’s an invoice. Classic lab studies show switching-time costs rise with rule complexity; field studies on knowledge workers show it often takes ~23 minutes to fully resume after an interruption. Two calendar blocks of 90 minutes beat six slices of 30. Use chat “office hours,” snooze non-urgent notifications, and bundle shallow tasks. (PubMed)

4) Forecast Your Own Throughput (Stop Guessing, Use Your Data)

Skip fantasy estimates. Track your cycle times for the last 20–30 finished items (calendar days from “started” to “done”). Use simple percentiles to set expectations: “Most tasks like this finish in 2–4 days.” If you want extra credit, feed your historical cycle times into a Monte Carlo simulation to answer, “How many can I finish by Friday with 85% confidence?” It’s simpler than it sounds and far more honest than story points.

5) Keep Motivation High with “Progress Beats Everything”

People produce more when they see daily progress in meaningful work. That’s not just anecdote; diary studies across thousands of entries nailed this effect years ago. Use it: finish something visible every day, however small, and log it. Ending the day with a tiny shipped improvement fuels the next one.

The Weekly Operating Rhythm (What I Do When I’m Under Fire)

Monday 30 minutes: Economic ordering. I collect all candidates, score WSJF fast, and pick the top one. Everything else is in a “Not Now” bucket, even good ideas. I state the “cost of not doing this now” in one sentence for each top item to keep myself honest.

Daily start: If-then kickstart. There’s a simple trick from motivation science: decide the trigger and the first action ahead of time—“If it’s 9:00 and I’ve opened the doc, then I write the failing test for scenario X.” It reduces the friction of starting and boosts follow-through.

Two deep blocks: Focus, then oxygen. I reserve two maker blocks (90–120 minutes) with a short reset between. Everything that can wait, waits. If I get interrupted, I deliberately leave a clear “next step” note before switching, to shorten the re-entry later. The research says the re-orientation tax is real; your note is the antidote.

Mid-week: Flow check. If my WIP has crept above 2, I stop pulling new work. I either finish or—I say the quiet part out loud—I explicitly drop something and reset. That’s not failure; it’s queue management backed by the same science that keeps factories from clogging.

Friday 20 minutes: Forecast and journal. I capture cycle times for the week, note blockers I created for others, and do a quick Monte Carlo run or percentile read to calibrate next week’s capacity. I also log one “progress win”; it keeps the engine warm for Monday.

Handling the Real World: Fire Drills, Meetings, and “Quick Questions”

Fire drills. Not all interrupts are equal. I use a simple rule: does this interrupt carry a higher Cost of Delay than the item I’m on? If yes, I switch—but I leave a breadcrumb (timestamped next step) to reduce the restart penalty later.

Meetings. Pack status into one async note tied to outcomes, not activity. Negotiate for fewer—but longer—maker blocks by showing the economic loss of fragmentation (higher WIP, longer cycle times, slower delivery). Leaders respond to weighted tradeoffs, not complaints.

“Got a minute?” You do, just not now. Offer your next office-hours window or a crisp “send me the doc; I’ll look at 3pm.” This isn’t grumpy; it’s protecting throughput. The science on switch costs protects you here.

What to Track

Personal flow metrics you can explain to anyone

1. WIP (now). Count active items. Lower is better for speed and predictability. This is Little’s Law in practice.

2. Cycle time (per item). Start→Finish days. Track the 50th and 85th percentile; they make honest commitments.

3. Throughput (per week). How many items finished. Don’t game it with tiny shards; keep items customer-relevant.

4. Interrupt rate. How many unscheduled switches per day. If it rises, renegotiate boundaries. Research shows the cost is real.

If you’re wondering why these matter beyond your week: teams that sustain fast, stable flow tend to perform better, and that performance links to stronger org outcomes. Your personal flow is the smallest unit of that system.

When Everything Is #1: Tie-Breakers That Don’t Lie

• Time criticality: Will value materially decay if I start this next week instead of today? If yes, it jumps the queue. WSJF captures this.

• Risk burn-down: Does doing a thin slice now unlock or de-risk larger work? This is value—count it.

• Dependency unblock: If three teammates wait on you, the aggregate Cost of Delay likely beats your solo task. Reorder accordingly.

A Minimal Toolkit You Can Adopt Today

• Board: “Options → Selected → In-Progress → Review/Blocked → Done,” with a big WIP limit printed over In-Progress. I use 1; 2 only with a waiting item. Little’s Law rewards the brave here.

• WSJF worksheet: The small table above, filled in weekly. Ten minutes, tops.

• Focus protocol: Two daily deep blocks, notifications off, with an “if-then” trigger sentence on the task.

• Forecast note: Keep a simple list of cycle times. Once a week, pull percentiles or run a Monte Carlo tool using your own data.

• Progress log: One sentence per day: “Shipped X; unblocked Y.” The psychology here is well-documented.

What I Got Wrong Earlier in My Career

I used to equate “fast” with “starting early.” That packed my WIP, stretched every cycle time, and increased bugs. When I finally cut WIP and sequenced by Cost of Delay, throughput climbed, quality improved, and—most important—people could rely on my dates. Science beats instincts here: fewer concurrent items and deliberate sequencing win, week after week.

Monday Morning Starter Kit (Copy/Paste)

• Define the win: In one sentence, write the outcome you’ll deliver by Friday.

• Rank options: Score WSJF for your top 5. Pick one. Park the rest.

• Set WIP: Move exactly one card into “In-Progress.”

• If-then trigger: “If it’s 9:00, then I run the failing test for feature X.”

• Protect focus: Two calendar blocks, notifications off, office-hour window posted. The interruption tax is real.

• End-of-day note: Log cycle time and a one-line progress win.

Why This Works

In Plain English:

You’re applying economic prioritization to pick the next right thing, queuing math to finish it faster, and habit science to actually do it every day. That mix turns “busy” into reliable delivery—and reliable delivery is what earns trust, autonomy, and the best work.

If you apply only one idea this week, make it WIP=1. If you add a second, make it WSJF before you pull. The rest will follow.

Buy at https://amzn.to/4oueqHs

What It's About

Patrick Lencioni frames team dysfunction as a pyramid of interconnected problems. At the base is trust—or rather, the absence of it. When team members won’t show vulnerability, won’t admit mistakes or ask for help, everything else falls apart.

That lack of trust makes people avoid conflict. Not the toxic kind, but the productive disagreement that every good decision needs. Teams end up in fake harmony where nobody really says what they think.

Without real debate, you get weak commitment. People nod in meetings but don’t actually buy in. Then nobody holds anyone accountable because they never truly agreed to the plan in the first place. And at the top of the pyramid, the ultimate failure: team members care more about their own goals than collective results.

The book delivers this through a business fable about a CEO fixing a dysfunctional executive team at a struggling tech company. It’s a quick read—you can knock it out in a few hours—but the ideas stick with you.

Why I Recommend It

I’ve seen every one of these dysfunctions play out in real teams. The “trust” problem hit me hardest because I used to think trust meant believing your colleagues were competent. Lencioni argues it’s actually about vulnerability—being willing to admit when you’re wrong or don’t know something.

That reframing changed how I ran leadership meetings. I started admitting my own uncertainties first. “I’m not sure this architecture will scale, and I need your honest take” opened up conversations that “What do you think of my proposal?” never did. The quality of our technical debates improved within weeks.

The conflict section resonates because I’ve watched too many teams mistake politeness for professionalism. We’d leave meetings with “alignment,” then executives would quietly pursue their own agendas. The book gave me language to call out that behavior and permission to push for real disagreement in the room.

What makes this book valuable isn’t some breakthrough framework—it’s that Lencioni names dynamics every leader has experienced but struggled to articulate. The fable format makes it accessible without dumbing it down. You can hand this to a new engineering manager or a board member and they’ll both get something from it.

The limitation? It’s light on the “how.” Lencioni tells you what’s broken and why it matters, but you’ll need to figure out the specific interventions for your context. When I had an executive team that wouldn’t hold each other accountable, the book helped me diagnose the problem. Fixing it required six months of uncomfortable conversations and one firing.

But that diagnostic clarity matters. Half the battle is recognizing which dysfunction you’re actually dealing with. I’ve seen leaders try to solve commitment problems by demanding accountability, when the real issue was three levels down at trust. This book helps you see the foundation you’re missing.

If you lead a team that feels stuck—hitting deadlines but not really performing, agreeing in meetings but not executing, talented individually but weak collectively—read this. Then pick one dysfunction to address and give it three months. You’ll know pretty quickly if you’re working on the right problem.