Q1 2026. App Store releases are up 84% on iOS year over year. April pushed even higher... 104% across both stores combined. More apps shipped in the last three months than in any comparable period in App Store history.

This number should stop you cold.

For twenty years, speed was the advantage. Get to market before the other guy. Ship first, iterate later. "Move fast and break things" became the founding religion of tech. If you shipped faster than your competitors, you won market share, user mindshare, and funding conversations.

AI coding tools changed the equation. Not gradually. Overnight.

When Everyone Ships Fast, Speed Stops Being an Advantage

Vibe coding tools didn't increase speed for the fastest builders. They gave speed to everyone else.

Here's the shift. When a solo non-technical founder ships 80% of what a funded team ships, the competitive gap closes. When a weekend hobbyist builds a functional app in a day using Replit or Lovable, the bar drops for everyone.

Speed stops being a differentiator and becomes a baseline expectation.

The Appfigures data reported by Digital Trends confirms it: global app releases up 60% year over year in Q1 2026. iOS alone up 84%. By April, new releases were up 104% across both App Store and Google Play compared to last year.

Speed got commoditized. And commodities don't build moats.

I wrote about this dynamic in Stop Benchmarking. Start Shipping.... the model you use matters less and less as every model closes the gap. The same logic applies to the tools for building. When everyone has the same tools, the tools stop being the advantage.

The Replit Irony

Replit hit a $9 billion valuation in March 2026. Tripled in six months. The company making it easier for everyone to build fast is worth $9 billion.

The people using Replit to build fast? Most are fighting for attention in an 84%-more-crowded market.

The tool for speed is the moat. The speed itself isn't.

This mirrors every gold rush in history. The people who got rich in the California gold rush were mostly the ones selling picks and shovels. Levi Strauss didn't mine gold... he sold denim to the miners. The AI coding gold rush has the same shape.

Replit, Cursor, Lovable, Bolt... these companies captured the value of the speed wave. Now they're multi-billion-dollar businesses. Founders using those tools to ship apps are competing in a market flooded by the same wave.

Apple Said Enough

Apple's response to the app flood tells you everything about where value has shifted.

According to WinBuzzer and TNW, App Store review times stretched to 30 days as vibe coding tools swamped the submission queue. Apple pulled AI-generated apps violating its self-containment rules. Enforcement tightened noticeably across March and April.

The platform said no to quantity. It started prioritizing quality.

When every market fills with AI-generated products, the thing standing out is depth. The thing users stick with is trust. The thing enterprise buyers pay for is domain knowledge baked into the product.

Speed got you through the door. Now you need a reason to stay.

What Defends Your Product Now

Three things create durable advantage in 2026. None of them are speed.

1. Domain Depth

The moat is now the knowledge you bring to the problem, not the code you write to solve it.

Any decent founder with a vibe coding tool ships a basic HR survey tool in a weekend. What they don't ship is five years of understanding how managers avoid difficult feedback conversations, why 360-degree reviews often fail, or what makes behavioral assessment data actionable versus decorative.

I've been building StepUp2Bat for years. The competitive advantage isn't the code. It's understanding the behavioral assessment market deeply enough to build something working for the actual problem... not an idealized version of it. The bad boss research. The behavioral framework. The specific patterns of how feedback breaks down at the team level. No one vibe-codes their way to years of domain expertise in a weekend.

A Substack piece on startup defensibility put this well: "Domain expertise baked into the product: Years of domain knowledge encoded as guardrails, playbooks, and system prompts... hard to replicate."

The question to ask yourself honestly: if you removed all the AI-written code from your product and kept only the thinking behind it... how much is left? If the answer is "not much," you're competing on speed. Speed is now everyone's starting point.

2. Distribution

Building is table stakes. Distribution is the game.

Forbes reported in April 2026: VCs are now pricing distribution moats into early-stage valuations. Not technology moats. Not IP. Distribution.

When AI compresses building costs to near zero and floods every market with new products, the question isn't who built the best thing. It's who gets it in front of the right people first, and who those people already trust.

An audience of 50,000 HR professionals trusting your take on leadership and management... no well-funded competitor ships their way past it. They'd have to earn it the same way you did. Earning it takes years. No amount of funding compresses it.

This is the best thing I see independent founders doing in 2026. Building audience before they build product. Writing, posting, speaking, and showing up consistently in the spaces where their target customers already spend time. By the time they launch, they have distribution no amount of funding replicates.

3. Trust and Data

A product running inside real organizations for two years has something no new competitor has: history. Real data about what worked. Where the product failed. What users asked for. What the edge cases look like.

History creates trust... and trust creates stickiness.

In the age of AI agents and automated tools, enterprise buyers are becoming more careful, not less. When tools touch sensitive employee data or influence management decisions, the question isn't "does this ship fast?" The question is "do we trust this?"

Track records answer trust questions. Speed doesn't.

The product shipped fastest rarely wins in enterprise. The product with the longest track record and the deepest integration into existing workflows... renewal rates above 90% tell you which one wins.

What This Means for How You Build

I'm not saying stop shipping. Fast shipping still matters. The cost of waiting is real.

Shipping fast is now the entry ticket, not the prize. You need speed to stay in the game. You need depth, distribution, and trust to win it.

Three questions worth sitting with seriously:

What domain knowledge does your product encode? Strip out the code entirely. What expertise remains? What problems do you understand better than anyone else building in your space? If the answer is thin, start there. Build the knowledge before you build the next feature.

Who trusts you before you even launch? Email list, community, followers, partners... who comes to you because of what you know, not because of what you've shipped? If the answer is "nobody yet," your next project isn't a product. It's an audience.

What data does your product generate, compounding over time? If your product gets smarter and more valuable with each user and each cycle, you have a genuine moat. If your v1 and your competitor's v1 start on equal footing, your moat isn't the product. It's what surrounds it.

The speed game is over. Or more precisely: speed has become necessary but no longer sufficient.

The founders winning the next five years won't be the ones shipping fastest. They'll be the ones knowing something nobody else knows, getting it in front of the right people, and earning the trust to stay there.

All three of those compound. None of them sprint.

Start on them today.

Earlier this year, economists started noticing something odd about the formula behind Trump's "Liberation Day" tariffs. The numbers had a distinct pattern. Someone ran the same prompt through ChatGPT, then through Gemini, then through Grok. According to TechRepublic, every major AI model produced the same formula the White House used to calculate billions of dollars in trade policy.

Nobody confirmed AI wrote the tariffs. The White House denied it. But the story spread because it was believable. Because everyone who works with executives has seen a version of it: the slide deck built from AI bullet points, the strategy document feeling generic, the email no human seems to have written.

This story is a leadership warning. And the warning has nothing to do with politics.

The Machine Is Designed to Pull You Back

My friend Ben Morton spent years as a military officer before becoming a leadership coach. When I talked to him about AI, he made a point worth sitting with: AI tools are built on the same psychological architecture as social media. Variable reward schedules. Intermittent reinforcement. The same mechanics keeping you scrolling at midnight keep you asking the chatbot one more question.

Social media hijacks the brain's dopamine pathways by delivering unpredictable rewards. Sometimes the post gets 200 likes, sometimes three. The unpredictability is the feature, not a bug. AI does something similar: sometimes the answer is brilliant, sometimes mediocre, but you keep going back because it's fast, frictionless, and good enough.

Ben's warning wasn't "don't use AI." It was: understand what you're dealing with. You're not using a neutral tool. You're engaging with a system designed to make you return. Built on the same psychology as the slot machine.

What Happens to Your Brain

Here's where it gets uncomfortable.

A 2024 study published in the journal Societies found frequent reliance on AI tools weakens critical thinking skills. The mechanism is cognitive offloading: when you delegate thinking to an external system, your brain stops building the mental muscles doing the thinking. PsyPost reported people who used AI tools more frequently showed lower performance on structured critical thinking tasks.

This is not science fiction. This is the same pattern we saw with GPS navigation. People who stopped using a physical map got measurably worse at spatial memory and wayfinding. Your brain prunes pathways it doesn't use. When you stop using a muscle, your body stops investing in it.

And in March 2026, Harvard Business Review published something worth pinning to every executive's wall. A BCG study of 1,488 US workers found overuse of AI causes what researchers now call "AI brain fry." Mental fatigue from excessive use or monitoring of AI tools beyond your cognitive capacity. Workers described a "buzzing" feeling, difficulty focusing, slower decision-making.

You thought AI would free up your mental bandwidth. For many leaders, it's consuming it.

I've Felt This Myself

I'll be honest. There have been days recently where I noticed myself reaching for the chatbot before spending two minutes thinking about the problem. Not out of laziness. Because the tool is frictionless and my brain is looking for shortcuts.

This is the trap. Not evil intent. Not stupidity. The steady, quiet erosion of a habit.

I've caught myself asking AI to draft an email I've written a thousand times. Asking it to summarise a document I should read myself. Asking it to generate options for a decision I've been paid to make. And each time I do it, I get the output I needed in the moment, but I've practised a little less, wrestled a little less, owned a little less.

The leaders I worry about aren't the ones who refuse to use AI. They're the ones who've stopped noticing the difference between "AI helped me think through this" and "AI thought through this for me."

The Patterns Showing Up

There are some specific patterns I've started noticing in leaders who've drifted too far down the dependency curve.

They struggle to think out loud. Put them in a room without a screen and ask them to reason through a problem verbally. It's harder than it used to be. The ideas feel foggier. The confidence is thinner.

Their writing sounds like everyone else's. Because it was written by the same tool everyone else uses. The voice is gone. The opinions are muted. Leadership communications start feeling like press releases.

They defer on their own domain. A CTO who's been writing software for twenty years starts second-guessing their own instincts because the AI said something different. A senior HR leader runs every policy decision through a chatbot before trusting their own experience. This is a red flag. Your twenty years of experience is worth something. Use it.

Their reasoning is invisible. Ask them why they made a particular call and they're vague. Because the AI made it and they rubber-stamped it. They didn't internalise the reasoning, so the explanation isn't there.

The Tariff Problem at Scale

Go back to the tariff story. Whether AI was used or not is almost beside the point. The story spread because it was believable. And when leaders outsource their judgment, they don't get worse answers. They lose accountability.

If the AI made the call, who owns the outcome?

Forbes covered this tension in April 2026, noting AI requires "human-led, AI-powered strategies" where leaders maintain agency over ethical decisions. The framing matters. AI-powered means AI is the tool. AI-led means you've handed over the wheel.

What You're Losing

Let me be direct about what cognitive offloading costs you as a leader.

Your judgment. Good leadership judgment comes from wrestling with hard problems over time. Pattern recognition, risk assessment, reading people: these are built through repetition. When you outsource the wrestling to AI, you atrophy the muscle.

Your accountability. If you're unable to articulate why you made a decision in your own words, you don't own it. You're executing someone else's output.

Your credibility. Your team knows. They tell the difference between a leader who's thought something through and one briefing from a chatbot. The people who've been in your organisation for years especially.

Your instincts. This is the long-term risk nobody mentions. Instinct isn't mystical. It's compressed pattern-matching from thousands of past decisions. When you stop making decisions, wrestling with them, owning them, you stop feeding the system. The instinct atrophies too.

This Isn't About Not Using AI

I use AI every day. It's useful for first drafts, for surfacing research, for challenging my thinking when I'm stuck. Ben Morton doesn't say avoid AI. He says AI should inform your decisions, not make them. Deloitte's 2026 research on AI-powered decision-making makes the same point: the goal is "quality decisions anchored in human agency."

The distinction matters. AI as a thinking partner is fine. AI as a replacement for thinking is the problem.

One test I use: before asking AI anything important, I spend five minutes writing down my own position. Then I ask. Then I see how much the AI answer shifts my view. If I'm changing my mind based on AI output without being able to articulate why, something's off. I'm not learning. I'm outsourcing.

Another test: would you be comfortable explaining your reasoning to your team without mentioning AI at all? If the answer is no... if the decision only makes sense because the AI said so... go back and do the thinking yourself.

The Question Worth Sitting With

What's the last important decision you made... about a person, a strategy, a risk... where you did the thinking yourself? No AI summary. No chatbot draft. You, the problem, and some time.

If you're struggling to remember, you might already be further down the dependency curve than you thought.

The risk isn't AI replacing your job. The risk is letting AI replace your judgment, and then wondering why your career has stalled.

Think first. Then ask the machine.

Apple has the best silicon on the planet. The most loyal user base in consumer tech. Margins that make every other hardware company weep. And after three years of trying, they still haven't shipped a working AI assistant.

Not a technology problem. A culture problem.

Let me walk you through what happened at Apple, and why it should make every tech leader think hard about their own organisation.

Three Years of Broken Promises

Cast your mind back to WWDC 2024. Apple took the stage and announced Apple Intelligence. A smarter Siri. Context-aware, able to take action across apps, integrated with ChatGPT for the things it couldn't handle alone.

The crowd responded. The press responded. Stock responded.

Then came the first delay. Spring 2025. Internal testing showed "high error rates." Not ready.

Then another delay. Target shifted to 2026.

Then, this month, a story emerged: Apple sent roughly 200 of its Siri engineers to a multi-week AI coding bootcamp. Not to ship AI... to learn how to use AI tools to write code. Because the Siri team had earned a reputation inside Apple as "a laggard" for resisting the very tools they were supposed to be building.

Let it land.

The team building AI products didn't use AI tools. And Apple spent years not noticing, or not caring enough to fix it.

Two Teams. One War.

Apple's AI problems don't come from a shortage of talent or capital. They come from two powerful teams inside the same company pulling in opposite directions.

On one side: Craig Federighi's software engineering group. Tight, opinionated, ships products. They've delivered macOS and iOS on a clockwork annual cycle for over a decade.

On the other: John Giannandrea's AI/ML group. Giannandrea came from Google in 2018, hired specifically to close Apple's AI gap. His team brought different management styles, different priorities, and a different culture.

The two groups never meshed.

The Information's investigation... which Apple's own leadership didn't publicly dispute... described "long-running tensions" and "contrasting management styles and work cultures" leading to "growing dysfunction." During one voice control project, senior leaders in Federighi's group "openly expressed frustration" with their counterparts in the AI group, who were seen as "hesitant and risk-averse."

In December 2025, Giannandrea stepped down as AI chief. Apple began breaking up the AI/ML organisation entirely, scattering pieces to other parts of the company.

Not a restructuring. An admission.

Two teams sharing a company didn't share a culture. When the pressure came, they broke instead of building.

The Privacy Problem Nobody Names

There's a deeper tension buried in all of this. Worth naming.

Apple built its brand on privacy. "What happens on your iPhone, stays on your iPhone." Not a slogan. A genuine engineering philosophy and a meaningful differentiator from competitors.

AI needs data. Good AI needs a lot of it, processed in large data centres, with feedback loops improving models over time. Privacy and AI's data appetite pull against each other.

Apple's original plan was a privacy-respecting two-model system: a small on-device model for sensitive tasks, a larger cloud model for everything else. Clean. On-brand.

It didn't work. Technical complexity too high. Error rates unacceptable.

So Apple pivoted to a single large cloud model. Then, by some accounts, struck a deal with Google to run Gemini under the hood... the same Google they compete with in search, browsers, and nearly everything else.

A painful pivot for a company whose identity was built on not being Google.

The culture resisted. Of course it did.

Fifty Thousand Outdated GPUs

Here's a detail from the reporting. It didn't get enough attention.

While OpenAI and Google were scaling AI on infrastructure running hundreds of thousands of GPUs, Apple's data centres reportedly contained "only about 50,000 outdated GPUs." Leadership only approved partial funding for newer GPU upgrades.

This isn't a company short of money. Apple generates more profit in a quarter than most companies generate in a decade.

This is a company whose culture didn't treat AI infrastructure as a priority until it was too late. The budget decisions reflect what leadership valued. And for years, what they valued wasn't AI.

You get the roadmap your culture builds... not the one your strategy deck promises.

What Your Organisation Should Learn

I'm not writing this to pile on Apple. They have smart people working on hard problems. They'll get there.

I'm writing this because I see the same patterns in smaller organisations constantly.

Two teams with different management styles, forced to collaborate on a product neither fully owns. A leadership culture that says "yes" to a strategic direction while budget decisions quietly say "no." An engineering team resisting the tools it's supposed to be building. An identity assumption... "we're the privacy company," "we're the enterprise company," "we do things properly"... that slows down change faster than any technical challenge.

These aren't Apple problems. They're organisational problems. Apple has the scale to make them visible.

If you're leading an AI initiative right now, here are the questions worth sitting with:

Are your teams aligned on what matters? Not on paper. In practice. Shared incentives, shared metrics, shared working rhythms. Or are they nominally collaborating while guarding territory?

Do your budget decisions match your stated priorities? If AI is the future and the infrastructure budget stays flat, you've told your team the truth by accident. They'll act on what you do, not what you say.

Is your culture's identity in conflict with what AI requires? Some organisations are built on a model AI will undermine. Acknowledging this openly, and making deliberate choices about it, is far better than pretending the conflict doesn't exist.

Are your people using the tools they're supposed to be building? The Siri team not using AI coding tools isn't irony. It's a signal. If your team doesn't believe in what they're building enough to use it themselves, you don't have a technology problem. You have a culture problem.

The Question Worth Asking

Peter Drucker's line gets repeated so often it's become wallpaper: "Culture eats strategy for breakfast." People nod and go back to updating their roadmaps.

Apple's AI story is what it looks like when you ignore it at the billion-dollar scale.

The question for you isn't whether your roadmap is ambitious enough. Most roadmaps are ambitious. The question is whether your culture will let you ship it.

If your AI initiative feels stuck... don't look at the technology first. Look at the meeting where two teams stopped talking to each other. Look at the budget line that didn't move. Look at the engineer who rolled their eyes when the pilot was announced.

Your roadmap is being eaten. And it started well before the first delay.

---

I've spent years helping organisations close the gap between strategy and culture, through Step It Up HR. If this sounds familiar in your organisation, that's where I'd start.

What's the biggest culture gap you've seen slow down a technology rollout? I'd genuinely like to hear.

Here is a number worth sitting with.

A software company ran an AI system through rigorous testing. F1 score: 0.94. Near perfect. They shipped it to production. In production, the score collapsed to 0.07.

A 13-fold drop. Between controlled testing and the real world.

If you are evaluating AI tools based on benchmark scores, you are buying the test result, not the product. Those are two different things.

The Benchmark Number Is Everywhere

AI vendors lead with benchmark scores. Model leaderboards update weekly. Press releases cite MMLU, SWE-bench, and HumanEval as though these numbers explain what the AI will do inside your business.

The implication is clear: higher number means better tool. Buy accordingly.

This logic has a flaw. Benchmark scores measure performance in controlled conditions on predetermined datasets. They do not measure performance in your environment, on your data, with your users. The conditions during the test and the conditions during production are almost never the same. The score does not transfer.

Engineers know this. Business buyers often do not. That information asymmetry is expensive.

What Benchmarks Actually Test

A benchmark is a controlled environment. A fixed dataset. Clean questions. A defined answer space. Consistent formatting.

The real world is none of those things.

When an AI scores 90% on a benchmark, it means the model answered 90% of questions drawn from a specific dataset correctly. It tells you almost nothing about performance on your data, in your environment, on your actual use cases.

This gap shows up everywhere. Across industries. Across model types. And the gap is large.

Analysis from multiple enterprise deployments shows AI systems typically drop 20-30 percentage points between benchmark scores and production performance. Models scoring 80-90% in controlled conditions frequently fall below 60% in actual deployment. Enterprise AI pilots fail at a stunning rate: some analysts estimate 95% do not survive beyond proof of concept.

The Failure Cases Nobody Highlights

Epic Systems built a sepsis prediction model now used by over 100 health systems. It performed well in testing. Then a JAMA Internal Medicine study examined what happened in actual clinical settings. The model failed to identify two-thirds of sepsis patients who needed treatment, while simultaneously generating thousands of false alerts. Physicians started ignoring it. The tool created noise, not signal.

Google's diabetic retinopathy AI received significant attention when it matched specialist accuracy in controlled trials. Deployed to rural clinics in Thailand, the system rejected 89% of images. The cameras, lighting, and equipment in rural clinics did not match the training data. The model worked correctly on data it had seen. It did not generalize to data it had not.

Legal AI shows the same pattern. Hallucination rates for major legal AI tools run at 17% for Lexis+ and as high as 34% for some implementations. Attorneys have faced court sanctions for citing AI-generated cases with no existence in legal databases. These systems score well on legal reasoning benchmarks. The benchmarks do not test for confidently fabricated citations.

In each case, the benchmark looked great. The deployment did not.

Why This Keeps Happening

Three structural problems drive the gap between benchmark performance and production results.

Contamination. Many widely used benchmarks draw from datasets predating the model's training cutoff. The model has encountered the answers, or problems structurally identical to them, during training. This is benchmark overfitting. SWE-bench Verified, one of the most cited coding benchmarks, uses GitHub issues from before 2023. Models with training cutoffs after that date have often seen these problems. The scores are inflated, not earned.

Distribution shift. A benchmark test environment is clean and controlled. Production environments are messy. Inputs arrive in unexpected formats. Edge cases appear. User behaviour is unpredictable. When the data distribution in production differs from training data, performance degrades. Google's clinic problem was not a capability failure. It was a distribution failure.

Misaligned incentives. AI labs compete publicly on leaderboards. Higher benchmark scores attract investment, press coverage, and enterprise customers. This creates direct pressure to optimize specifically for the benchmark task rather than for general capability. Goodhart's Law at scale: when a measure becomes a target, it ceases to be a good measure.

The Developer Community Is Catching On

r/programming, one of the largest programming communities online with more than 5 million members, ran a trial ban on LLM-generated content in April 2026. This was not an anti-AI stance. It was a response to a specific problem: AI-generated posts and answers were confident, well-structured, and wrong on anything non-trivial.

Developers using AI coding tools daily are discovering the gap between demo performance and production performance. The benchmark says the model resolves 80% of real GitHub issues. The developer in the seat finds a much narrower band of problems where the tool reliably delivers.

LiveCodeBench tests models against fresh competitive programming problems not found in training data. Top models score around 53% on medium-difficulty problems. On the hardest problems, where human experts do well, the top models score 0%.

The same models score 90%+ on older benchmarks.

Math Olympiad problems tell a similar story. AI models score under 5% accuracy on unseen Olympiad problems despite performing strongly on standard math benchmarks. The benchmarks test recall and pattern recognition. Novel problems require reasoning. Those are different skills.

What to Measure Instead

Benchmark scores tell you what a model scored on someone else's test. They do not tell you what the model will do on your work.

Here is what to measure instead.

Build your own evaluation set. Draw it from your own data, your own edge cases, your own failure modes. Run candidate AI systems against those. A model scoring 95% on a public benchmark and 60% on your actual tasks is a liability dressed as an asset.

Test confidence calibration. A well-calibrated model knows what it does not know. Models producing high-confidence wrong answers are dangerous in any domain where errors carry consequences. Track whether high-confidence outputs are accurate on your specific data.

Look at the tail. Average performance hides the failures worth worrying about. A model scoring 90% overall and 0% on a specific input type or user group is a risk, not an efficiency gain. Find where performance collapses before your users do.

Red-team before you ship. Actively try to break the system using domain knowledge specific to your context. Find the failure modes in testing. Your users will find them in production if you do not.

Update your evaluations regularly. Benchmarks go stale. Your evaluation set should reflect current data distributions and current failure modes, not a snapshot from 18 months ago.

Ask Vendors the Hard Question

Next time an AI vendor leads with benchmark scores, ask one question: how does this perform on data we collected in the last three months, on our specific tasks, in our environment?

If they cannot answer, the number they showed you is a marketing figure. Not a performance figure.

The benchmark problem is not going away while labs compete on leaderboards. Your job is to look past the score and test what matters: whether the tool works, in your context, on your problems.

What AI deployment failure caught you off guard after a promising demo?

There's a study you need to read. Not because it's comfortable. Because it should change how you're making decisions right now.

In July 2025, METR, a non-profit AI safety research organisation, ran a randomised controlled trial with 16 experienced open-source developers. Not beginners. People working in their own mature codebases, averaging five years on each project. The researchers gave half of them AI tools, primarily Cursor Pro with Claude 3.5 and 3.7, and measured what happened.

The developers using AI took 19% longer to complete their tasks.

Here's what should keep you up at night: those same developers believed they were working 20% faster.

A 40-percentage-point gap between perception and reality. Not a rounding error. A measurement crisis.

How We Ended Up Here

The AI productivity narrative didn't come from nowhere. In 2023, Microsoft Research published results from a controlled experiment with GitHub Copilot. Developers completed tasks 55.8% faster with the AI pair programmer.

The number travelled fast. Across blog posts, boardroom decks, LinkedIn feeds. It became the figure justifying six-figure AI tool subscriptions. "55% faster." Who wouldn't sign off on it?

What didn't travel as fast was the fine print. The Microsoft study asked developers to implement an HTTP server in JavaScript, from scratch, in isolation. No existing codebase. No accumulated technical debt. No legacy code to understand before touching anything. No other developers whose work needed respecting.

Not what software development looks like. More like a coding challenge. The equivalent of measuring how fast a chef cooks when you hand them a single perfect ingredient and ask them to do one thing with it, then claiming you've measured restaurant kitchen throughput.

Real software development involves reading code you didn't write. Understanding systems grown over years. Debugging errors introduced by AI-generated code which looked right but wasn't. Reviewing pull requests filled with AI output where your job is now to figure out what the AI did, not simply confirm something happened.

None of it shows up in a controlled lab task.

The Measurement Trap

So why doesn't anyone notice? Because the metrics most engineering teams track don't detect it.

Lines of code written. Number of commits. Pull requests merged. Tickets closed. AI tools push all of those numbers up. More commits? AI delivers. More lines of code? No problem. More PRs? Easily done.

Meanwhile the real work, delivering reliable and maintainable features at a sustainable pace, gets harder to see. Code review cycles lengthen because AI-generated code requires more scrutiny. Bug rates climb because the AI made plausible-looking but wrong decisions at the edges. Senior engineers spend more time untangling AI output than they'd have spent writing the code themselves.

According to Forbes Research data, 39% of C-suite executives cite measurement challenges as the key obstacle to quantifying AI's business impact. More than a third of the people who approved these tools cannot tell you whether they're working.

And according to analysis by BBN Times, 73% of companies are measuring AI ROI incorrectly.

Billion-dollar decisions based on metrics already questionable before AI arrived. AI made them worse.

The Feeling Is the Problem

The METR finding, developers felt faster even while being slower, is the most important part of this story. It explains why the measurement problem persists.

AI tools create a sensation of momentum. Code appears. Suggestions flow. The cursor moves. You feel productive in a way staring at a blank screen never achieves. The feeling is real. The speed is not.

The same trap catches leaders who measure activity instead of outcomes. The manager scheduling twelve meetings a week and calling it leadership. The executive generating slide decks at volume and calling it strategy. The engineer closing twenty tickets and shipping nothing reliable in production.

Speed of output is not quality of outcome. We knew this before AI. AI is making it more obvious, and more expensive to ignore.

What to Measure Instead

Outcome-based measurement is the answer. Not what your team produced, but what it delivered.

Cycle time: How long does a feature take from first commit to production? AI tools should shrink this if they're helping. If cycle time isn't falling, speed gains are happening somewhere immaterial.

Deployment frequency: Are you shipping more often? More reliable code reaching users faster is a genuine signal.

Change failure rate: Of the things you shipped, how many caused incidents or required rollbacks? AI-generated code breaking production is negative productivity.

Mean time to restore: When things break, how quickly do you recover? A team generating more volume with more failures and slower recovery isn't gaining anything.

These are the DORA metrics, and they've existed for years. AI makes it more urgent to use them. Without outcome metrics, the illusion of productivity becomes expensive to maintain.

The Question Worth Asking

If you're a CTO, an engineering manager, or anyone who approved an AI tooling budget in the last two years, the METR study is pointing at a question you need to answer honestly:

What would you see if you measured what your team is delivering, not what it's generating?

Not commits per week. Not lines of code. Not pull requests merged. What reached users, worked reliably, and moved the business?

If you haven't stopped to ask the question since rolling out AI tools, you're making the same mistake as the developers in the METR study. You're feeling fast. You're not necessarily getting anywhere.

The measurement problem in AI productivity is solvable. It's the same problem we've always had with measuring knowledge work. AI stripped away the excuses for ignoring it.

Fix what you measure and you'll know what you're getting. Until then, you're flying by feel in the dark, and feeling confident about it.

Ninety-five percent of generative AI pilots at companies are failing.

Not because the models are bad. Not because the integrations are hard. Because of the people running them.

The number comes from Fortune, via research cited in Harvard Business Review, and it stings. The tech industry has collectively spent hundreds of billions of dollars on AI infrastructure, tooling, and model training. And yet most of it isn't producing results. Organizations are buying the most advanced tools ever created... then watching them gather dust.

The technology is not the problem.

The Numbers Don't Lie

According to the 2026 State of AI Agents Report, when organizations were asked what's blocking them from scaling AI agents, the top three answers were integration challenges (46%), data quality (42%), and change management (39%).

The first two get all the attention. Teams hire more engineers, buy better data pipelines, and invest in architecture reviews. The third one gets a line in the project plan and a two-hour all-hands.

Research from LSE and McKinsey puts a harder number on it: 70% of AI adoption challenges come from people and process issues, not from technology. And yet leaders spend the bulk of their time and budget on the tech side.

A Writer.com survey of enterprise organizations in 2026 found:

• 79% of organizations face challenges adopting AI
• 75% of executives admit their AI strategy is "more for show" than actual guidance
• 54% of C-suite executives say AI adoption is "tearing their company apart"

Tearing it apart. These are billion-dollar companies with access to the best tools available, and over half their executive teams say AI adoption is ripping them in two. What went wrong?

Leaders Are Blaming the Wrong People

McKinsey's research on AI scaling found something uncomfortable: "The biggest barrier to scaling AI is not employees who are ready, but leaders who are not steering fast enough."

Read it again. Employees are ready. Leaders aren't steering.

Most leaders I talk to frame their AI problem as a skills gap, a tech gap, or a budget gap. They look at their teams and see resistance. They run surveys asking "Are you comfortable using AI tools?" and they're surprised when the answers disappoint them.

The real question to ask is: have you created the conditions for your team to safely experiment, fail, and share what they're learning?

In most organizations, the answer is no. And the data backs it up. The same Writer.com survey found 29% of employees admit to actively sabotaging their company's AI strategy. Among Gen Z workers, it's 44%.

Employees aren't lazy. They're scared. And fear is a leadership problem.

The Shadow AI Epidemic

Here's what's happening in your organization right now, whether you know it or not. Your team is using AI. They've been using it for months. But they're not telling you.

Psychology Today, citing Amy Edmondson's research on team learning, describes this as the "shadow AI problem": employees run their own experiments, get useful results, but never share the learnings because they don't feel safe doing so. Organizational learning stops at the individual level.

Why don't they share? Two reasons, and both trace back to leadership.

First, they're afraid of being seen as the person who's been doing things "wrong" by using an unapproved tool. Second, they're afraid of being seen as the person who's making their own role easier to automate. Those fears don't exist because your team is irrational. They exist because leadership hasn't made it safe to be transparent.

When people don't trust their leaders, they don't trust the tools their leaders are rolling out. Harvard Business Review puts it plainly: "Employees won't trust AI if they don't trust their leaders."

The Iceberg Nobody's Talking About

There's a reason AI rollouts look fine from the top and feel chaotic at team level.

The visible problems get attention: the API integration, the model output quality, the security review. These get assigned to engineers and architects, tracked in Jira, reported to the board.

The invisible problems sit deeper. Leaders who approved the AI budget but haven't touched a single AI tool themselves. Managers who frame AI adoption as a performance pressure rather than a learning opportunity. Organizations where being wrong or slow to adapt gets noticed and punished, so people stay quiet.

Dr. Dorottya Sallai from LSE's Department of Management described it: "AI adoption is a cultural transition," one requiring leaders to overcome "psychological and leadership barriers more than technical ones."

In many organizations, the capability is there. The model exists. The integration works. But nobody's communicated the business case. The "why" is absent. And when people don't understand the why, they write their own story... and it's rarely a good one.

What Good Looks Like

I've spent years working in tech and HR leadership, and I've seen AI rollouts succeed and fail. The difference isn't the tool. It's always the environment the leader creates.

At Step It Up HR, we work on the 3 A's: Awareness, Acceptance, Action. You don't get Action from a team who hasn't worked through Awareness and Acceptance. Forcing an AI rollout on a team who's scared isn't change management. It's coercion. And coercion creates sabotage.

A few things I've seen work:

Make it safe to be a beginner. The fastest way to kill AI adoption is to celebrate the super-users and ignore everyone else. If your AI "champions" get praised in all-hands while slower adopters feel shame, you've built a two-tier culture. Two-tier cultures breed resentment, not adoption.

Show your own failures. If you're in a leadership role and you're not showing your team where AI gave you a rubbish output or where you got the prompt completely wrong, you're missing the most effective culture signal available. Vulnerability from leaders is what makes it safe for everyone else.

Slow down to go faster. McKinsey found effective AI leaders grow revenue 1.5 times faster than their peers. But they didn't get there by rushing. They invested in the culture infrastructure first. Teams running experiments win. Teams mandating adoption lose.

Four Questions to Ask Yourself

Before you buy another AI tool, run another rollout, or write another policy, sit with these:

1. Does your team feel safe telling you when an AI tool isn't working?
2. Do you know which team members are quietly using AI tools you haven't approved?
3. Have you shown your team your own AI learning journey, including the failures?
4. When someone raises concerns about AI adoption, do you treat it as a technical problem or a human one?

If you winced at any of those, start there.

Reddit has been full this week of workers sharing their unease about agentic AI doing more of the task layer. The anxiety is real. What your team needs from you isn't a policy. It's a conversation.

The Leadership Variable

The 2026 AI adoption data is unambiguous. Organizations with strong leadership culture around psychological safety, transparent communication, and genuine employee voice are adopting AI faster and getting more out of it. Organizations with mandates, monitoring, and fear are producing shadow AI users and saboteurs.

If your AI rollout is struggling, look at the leadership culture before looking at the tech stack.

What would it look like if people in your organization felt safe enough to tell you the truth about how AI is landing? Start there.

Every week I talk to leaders who say the right things. AI agents are on the roadmap. The budget is allocated. The pilot is done. But the rollout is stuck.

They blame the tech. The integrations are complex. The data is messy. The tools keep changing. All of this is true to some extent. But here is what the data shows: the number one barrier to AI agent adoption at scale is change management. And change management is a leadership problem, not a technology problem.

The Numbers Every Leader Needs to Face

According to Anthropic's 2026 State of AI Agents Report, the top three barriers to scaling AI agents across organizations are:

• Integration challenges: 46%
• Data quality requirements: 42%
• Change management needs: 39%

Integration and data are real engineering problems. But change management? Change management is not an IT ticket. Change management is a leadership failure.

And it gets worse. McKinsey's Superagency in the Workplace report found C-suite leaders are more than twice as likely to cite employee readiness as the barrier to AI adoption than to examine their own role in it. Meanwhile, the employees they're blaming? Already using AI at three times the rate leaders think.

Sit with it. Employees are using AI three times more than their leaders estimate. And leaders are pointing at employees as the problem.

The Patterns I Keep Seeing

I've been in and around technology leadership for a long time. The patterns of failure in AI adoption are not new. I've watched the same film before -- with ERP rollouts, with agile transformations, with cloud migrations.

Here is what leadership failure looks like in practice.

The manager who doesn't use the tool. You do not lead your team through a change you refuse to participate in. If you're asking your people to adopt AI agents into their workflows but you personally haven't opened the tool in a week, your team sees through you immediately. You're not a sponsor of this transformation. You're a passenger.

The rollout without a why. Someone above you said deploy AI agents. You handed it to a project manager. The project manager handed it to IT. IT deployed it. Nobody told the team why it matters, what problem it solves, or what success looks like. This is how you get a 32% stall rate after pilot -- which is exactly what research into AI agent deployments found. One in three companies never gets past the proof of concept because nobody made the case for change.

Measuring the wrong thing. You added AI to an existing process and measured whether the AI performed the old steps. AI agents are not a faster typewriter. If you're retrofitting them onto a broken process, you'll get a broken process with an AI in it. The BCG/MIT Sloan 2025 Agentic Enterprise report identifies this as one of four critical tensions leaders face: process retrofitting versus reimagining. Most leaders choose retrofitting because reimagining requires courage.

The Leadership Blindspot Is Real

The McKinsey finding about C-suite leaders blaming employees is not a one-off. It's a pattern.

When I look at the 99.5% of people who have had at least one bad boss in their career, the failure mode is almost always the same: the leader exempted themselves from the standards they set for others. They talked about accountability and avoided it themselves. They talked about growth and stopped learning. They talked about change and resisted it.

AI adoption is the same story playing out with a new cast.

Right now on Reddit, people are watching AI agents book flights, compare prices, and manage their calendars -- and the conversation oscillates between amazement and deep unease. The technology is working. The employees experimenting with it at home, on their own time, are not the problem. What they're waiting for is a leader who believes in it enough to model it.

This is on you.

The Four Decisions Leaders Are Avoiding

BCG and MIT Sloan identified four tensions defining whether organizations succeed with agentic AI. Every single one is a leadership decision, not a technical decision:

Scalability versus adaptability. Do you build fast or build flexible? There's no right answer -- but someone has to make the call and own it.

Investment versus employment. If AI agents absorb 30% of a team's work, do you cut headcount, redeploy people, or do both? Waiting for the answer to appear is not a strategy.

Supervision versus autonomy. How much do you trust the agents? How much oversight is required? This requires someone to decide what acceptable risk looks like in your organization.

Process retrofitting versus reimagining. Do you make AI fit your current process or redesign the process around AI's strengths? This is the biggest one, and most leaders dodge it entirely.

These aren't API configuration questions. They're strategy, governance, and culture questions. They sit on the leader's desk. Nobody else gets to answer them.

What Good AI Leadership Looks Like

I'm not going to pretend this is easy. It's not. The pace of change in AI tooling is relentless. Models update weekly. New agents appear before you've finished evaluating the last ones. The pressure to show ROI before you've built genuine competence is real.

But here is what I've seen work.

Use the tools yourself. Every day. Not as a demo. Not to show your team. As a genuine part of your own workflow. Ask an AI agent to help you prepare for your next board meeting. Have it summarize your week's worth of emails. Use it to draft your next strategy update. You'll understand the limitations, the prompting discipline required, and where it genuinely saves time. You don't lead something you haven't lived.

Fix the process before you add AI to it. If a process is broken, AI will do the broken thing faster. Before any AI deployment, ask your team: what problem are we solving? If the answer is "we're told to use AI," start over. The answer has to be a real bottleneck, a real pain point, a real inefficiency. Fix it first. Then introduce AI into the fixed process.

Be honest about what scares you. Some leaders resist AI because they're worried it will expose gaps in their own thinking. Some worry about job displacement -- including their own. These are legitimate fears. Name them. Teams respect honesty far more than false confidence. "I'm figuring this out alongside you" is a stronger leadership statement than a polished rollout deck.

Give your team the mandate to experiment. Not permission -- mandate. Set aside time. Protect it from other work. The 62% of enterprises without a clear starting point are stuck not because they lack tools but because nobody gave the team structured space to experiment safely.

The Tech Is Ready. Are You?

35% of companies are already deploying agentic AI, and 44% plan to follow. The models are good enough. The tooling is mature enough. The business cases exist.

What isn't ready in most organizations is the leadership layer above the technology.

If your AI rollout is stuck in pilot hell, if your team is unconvinced, if the ROI projections are not landing -- don't blame the integration complexity or the data quality. Ask yourself honestly whether you've led this change or only announced it.

There's a difference. Your team sees which one you're doing.

What's the biggest leadership obstacle you're seeing in your own AI adoption? I'd genuinely like to know.

Every week a new AI model tops the benchmark charts. Every week, engineers argue about it on Reddit. Every week, product teams sit in meetings debating whether to switch models.

And every week, real users are waiting for working software.

This is the benchmarking trap. Most tech teams are inside it, and few of them know it.

The Leaderboard Is Not Your User

GPT-5.4 scores 92 on BenchLM. Claude Opus 4.6 scores 85. Gemini 3.1 Pro hits 87. SWE-bench, MMLU, ARC-AGI scores go up every month. The numbers are relentless, and the announcements are breathless.

I noticed this week on Reddit's r/MachineLearning and r/artificial: the benchmark debate is hotter than ever. Threads with thousands of comments, people drawing conclusions about which model is "smarter." It's genuinely interesting if you're a researcher. It is noise if you're building a product.

Your users do not know what MMLU is. They do not care about FrontierMath scores. They care about one thing: does this thing work when I need it to?

The benchmark leaderboard is entertainment for engineers. It is not product strategy.

Why Benchmark Scores Don't Mean What You Think

Benchmarks look scientific. They feel objective. They are neither.

A Google Research study accepted at AAAI-26 found standard AI benchmarks use only 3 to 5 human raters per test example. The researchers found you need more than ten raters for statistically sound results. With 3 to 5 raters, you get noise dressed up as data. A narrow 3-2 split in rater opinion looks identical to near-unanimous agreement when you collapse it to a single label.

The problem compounds when you add research incentives. A detailed analysis of ML research papers found 79% of papers claiming breakthrough performance were using weak baselines. When researchers reran the same comparisons on fair footing, the supposed advantages often vanished entirely.

The numbers are not measuring what engineers think they are measuring.

The Gaming Is Real

Here is what makes it worse: some benchmarks are being actively gamed.

Meta's Llama 4 became a case study in this. Internal reports surfaced suggesting the model's post-training phase involved blending test sets from various benchmarks to hit metric targets. Despite outperforming on Meta's own evaluations, Llama 4 underperforms older models on LiveBench, an independent evaluation platform. Meta's VP of AI Research, Joelle Pineau, departed shortly after the allegations became public.

OpenAI's o3 model scored an impressive 25% on FrontierMath, a mathematics reasoning benchmark designed to be extremely difficult. The announcement didn't lead with this detail: OpenAI had funded FrontierMath's development, without initial disclosure. The benchmark creator had a financial relationship with the company being benchmarked.

These are not isolated incidents. They are symptoms of a system where companies are evaluated on metrics they influence or control. The incentives point in one direction: make your benchmark numbers look good, regardless of what happens when users touch the product.

What Happens in Production

Real teams run into this pattern constantly.

One security startup upgraded from an older Claude model to Claude 3.5 Sonnet and saw genuine improvements. Good. Then came the follow-on releases, each claiming significant benchmark gains. Each new version delivered what the team described as "negligible real-world benefits." The benchmark scores climbed. The user experience stayed flat.

This is not a story about Anthropic. It is a story about the gap between what benchmarks measure and what users experience. A model trained on benchmark patterns scores well on benchmarks. The problems your users bring to your product are messy, context-dependent, domain-specific problems. No lab's test suite captures your specific use case.

I run into this myself building StepUp2Bat. The models vary considerably depending on the specific task. The one scoring highest on a general coding benchmark is not always the right pick for generating structured feedback analysis or parsing survey data into actionable patterns. You find this out by testing, not by reading leaderboards.

The Metric Worth Caring About

Your users are your benchmark.

Not in a vague, philosophical sense. In practice. Task completion rate, time on task, re-engagement, error rate, support ticket volume. None of these appear on any AI leaderboard. All of them predict whether your product survives.

A GrowthBook analysis on real-world AI model selection found the optimal solution for most production workloads is not the top-scoring model. It is a portfolio approach: routing different query types to different models based on cost, latency, and domain fit. This approach reduces costs by 80% while matching or exceeding the quality of a single expensive frontier model.

The top benchmark model is rarely the right choice for your specific workload. The right model is the one your users tell you is working, through the behaviour data they generate every time they use your product.

A Framework for Choosing Your Model

Stop asking "which model scores highest?" Start asking:

What specific tasks does my product need to do well? Write them down. Five specific tasks, not categories. "Summarise support tickets from angry customers" is a task. "Language understanding" is not.

Which model handles those tasks best with your actual data? Test them. Use your prompts, your edge cases, your worst examples. Not the benchmark questions from a paper.

What are your real constraints? Latency, cost per call, context window size, safety requirements for your use case. These matter for shipping. They rarely appear in leaderboard comparisons.

What does your error analysis say? When your model gets it wrong in production, what does wrong look like? The failure mode tells you more about model fit than any composite score.

Iterate. The model right for your product today might not be right in six months. Keep testing against real user data, not synthetic evaluations.

The Trap Teams Fall Into

Benchmarks feel safe. They feel like due diligence. If you picked the top-scoring model, you made the defensible choice. If something goes wrong, you covered yourself.

But "defensible" and "right" are different things.

The best engineering decisions I have ever seen came from teams who shipped fast with a good-enough model, collected real signal from real users, and iterated from there. The worst came from teams who spent weeks paralysed by benchmark analysis and shipped late with something their users still didn't want.

Your users are not reading the AI leaderboard. They don't know whether your underlying model scores 85 or 92 on some composite measure nobody references outside of press releases. They know whether your product works when they need it to.

The Real Race

The teams who will win with AI are not the ones who waited for the perfect model score. They are the ones who shipped with what they had, learned from users, and adapted when the data told them to.

The benchmark obsession is understandable. It feels like progress. It feels like rigour. But reading leaderboards is not shipping. Analysing scores is not building. Debating which model is "smarter" generates zero value for anyone except the model labs whose marketing it amplifies.

Pick a model. Ship something. Measure what your users tell you.

Your users are your benchmark. They are the only one worth watching.

Companies spend real money making offices look like places people want to be. Foosball tables. Standing desks. Cold brew on tap. Dogs in the office. The works.

Then they're confused when their best engineers quit.

None of it is culture. Not one bit of it.

Culture is what happens when a junior developer stands up in a planning meeting and says, "I think we're building the wrong thing." Culture is whether the developer gets thanked for the honesty... or quietly removed from the distribution list for the next planning meeting.

This is the whole test.

The Question Reveals Everything

Lee Woollsey, who has spent years studying how organisations learn and perform, put it bluntly: culture isn't the ping pong table. It's whether you say "this process is dumb" and still get promoted.

I grew up in the US Army, where the stakes of silence are far higher than missing a sprint deadline. But the mechanism is the same. In units where soldiers felt safe flagging problems up the chain, those problems got fixed before they became crises. In units where people stayed quiet to avoid trouble, trouble had a way of finding everyone.

I've seen tech teams repeat the same pattern. The outcome is different. The dynamic is identical.

I've also worked in places where you said it and got shot. Where the unspoken rule was: surface problems and become the problem. Where people learned to smile, nod, and vent on Slack to their trusted inner circle.

Those organisations didn't fail because they lacked ping pong tables. They failed because they trained their best people to be silent. And silence is expensive.

What the Research Found

In 2015, Google ran an internal study called Project Aristotle to figure out why some teams crushed it and others didn't. They looked at everything: individual talent, experience, complementary skills. None of it reliably predicted team performance.

The number one factor? Psychological safety. Teams where people felt safe taking interpersonal risks... disagreeing, asking questions, admitting they didn't know something... consistently outperformed teams packed with brilliant people who were afraid to speak.

This built on work Amy Edmondson had done at Harvard Business School since 1999. One of her most counterintuitive findings: high-performing medical teams reported more errors than lower-performing ones. Not because they made more mistakes... because they felt safe enough to report them. The weaker teams were hiding their failures.

Think about it in a software context. Your team isn't making fewer mistakes. You're making the same mistakes. The question is whether you find out in sprint review or in production.

The APA's 2024 Work in America survey found 89% of workers in toxic workplaces also reported lower psychological safety. Workers with higher psychological safety reported greater satisfaction across every metric measured: manager relationships, coworker relationships, growth opportunities, and inclusion policies.

And data from HR Daily Advisor in early 2026 is sharp: only 36% of HR representatives say employees in their organisations feel safe expressing criticism. Yet MIT Sloan research shows teams building psychological safety skills see 25% revenue increases. And workers with low psychological safety are 2.15 times more likely to be actively looking for another job.

You're burning people out and chasing them off. The ping pong table isn't helping.

The Silence Tax

Here's how silence compounds.

An engineer spots a flaw in the architecture during planning. She's seen what happens when people push back... the last person who did got labeled "difficult." So she says nothing.

Three months later, the architectural flaw is in production and it takes six weeks to fix. The postmortem is full of "we should have caught this earlier." Nobody says the obvious: the team built a system punishing early warning.

A product manager notices a key feature nobody wants keeps getting prioritized because it's the CTO's pet project. He raises it once in a one-on-one and gets told to "trust the vision." He stops raising it. The feature ships. Nobody uses it.

The thing about the silence tax is you never see the invoice. You see the churn. You see the mediocre retrospectives. You see the features nobody wanted. You never connect those dots back to the meeting three months ago where someone kept their mouth shut.

Research on the cost of silence shows when employees stay quiet, organisations miss critical feedback preventing costly mistakes. When people feel unheard long enough, they stop trying... or they leave.

What Psychological Safety Is Not

Psychological safety doesn't mean everyone feels comfortable all the time. It doesn't mean no accountability. It doesn't mean your team sits around validating each other's ideas.

Edmondson is clear on this: it's about taking interpersonal risks without fear of punishment. You disagree, you admit a mistake, you ask the obvious question. And you don't lose your job or your reputation for doing it.

This is different from feeling happy. Some of the most psychologically safe environments I've been in were also the most demanding. The difference is the challenge came through honest feedback... not through fear of saying the wrong thing.

What It Takes to Build It

Psychological safety doesn't come from a wellness Wednesday email or a Slack channel called #good-vibes. It comes from leaders who do two specific things consistently.

First, they model the behavior they want. They say "I was wrong about it" in public. They ask "what am I missing?" in meetings and wait for an honest answer. They say "I don't know" without qualifying for five minutes first. When the leader is visibly human, it gives everyone else permission to be.

Second, they respond to honesty without punishing it. This is harder than it sounds. Honest feedback is uncomfortable. Someone tells you the process is broken. Your first instinct is defensive. You want to explain why it's not broken. The leaders building psychological safety resist this instinct and ask a follow-up question instead.

At Step It Up HR, the pattern is consistent: leaders who reward honest feedback get more of it. Not because people suddenly become braver, but because the risk calculus changes. Speaking up used to cost something. Now it doesn't.

Start Here

If you want to build psychological safety in your team, three things work consistently.

Ask "what am I missing?" at the start of every major decision. Not as a formality. Ask it and wait. Let the silence sit for five seconds. People will fill it. At first they'll say "nothing" or offer something small. Keep asking. Over months, they'll learn you genuinely want to hear.

Thank the bearer of bad news. Every time someone brings you a problem, your response sets the next person's expectations. "Thanks for flagging this, let's fix it" builds safety. "Why didn't you tell me sooner?" destroys it. Pick your response deliberately.

Admit a mistake publicly. Not as self-flagellation. As permission-granting. Say "I got this wrong, here's what I'd do differently" in a team meeting. Watch what happens. People start doing the same. Not immediately, but over months.

None of this requires a budget. None of it requires HR approval. It requires deciding safety is your job, not someone else's.

The Perks Illusion

The reason ping pong tables persist is they're visible. You photograph them for your careers page. They say "we're fun, we're modern, we care."

Psychological safety is invisible. You build it in the moment after someone tells you something you don't want to hear, and you thank them for it. You build it in the meeting where the most junior person asks the most obvious question... and instead of the room going quiet, someone says "great question."

A 2026 report put it directly: the perks era is over. Employees don't want table tennis at 3pm. They want to feel seen, trusted, and useful.

High-trust cultures outperform their peers by over 40% in innovation. Not because they hired smarter people. Because they stopped punishing the smart ones they already had.

The Test

Forget the ping pong table. Ask yourself this:

What's the last piece of bad news someone brought you... something you genuinely didn't know? Not a problem you'd already spotted. Something your team knew and you didn't, and they were brave enough to bring forward.

If you're struggling to think of an example, silence is your data.

The teams winning aren't the ones with the best perks. They're the ones where someone says "this is broken" on a Thursday afternoon, and by Friday morning, it's been addressed... and the person who raised it is quietly glad they did.

Build it. The ping pong table is optional.

The Problem No One Tells You About

You got promoted because you were good at solving technical problems. You wrote clean code, designed solid systems, shipped on time. You communicated clearly... in pull request comments, in Jira tickets, in architecture docs.

Then you became a manager and kept communicating the same way.

Now your team gives one-word answers in your one-on-ones. Your check-ins feel like stand-up meetings. People come to you only when something's on fire.

Your leadership sounds like a robot. Not because you're a bad person. Because no one trained you to communicate differently once you crossed the management line.

Why Engineers Default to Machine-Mode Communication

Think about what got rewarded in your engineering career. Precision. Brevity. Clarity. If you asked someone a question, you wanted a direct answer... not a story. If you gave feedback, you pointed to the line of code with the problem and said why.

This style works brilliantly for code review. It's terrible for a conversation where you're trying to understand why your most experienced engineer is quietly updating their resume.

The patterns I see most often in technical leaders:

The Status Ticker. Your one-on-one consists entirely of: "What are you working on? Any blockers? OK, thanks." Three sentences. Meeting over. You got your status update. You learned nothing about how your person is feeling, what they're struggling with, or what they're excited about.

The Question Bombardment. You have something to address, so you ask five questions in a row without pausing. "Have you looked at the performance issue yet? What's the status? Did you talk to the backend team? What's your plan? When will this be done?" The person on the receiving end doesn't know which to answer first. They feel interrogated, not supported.

The Ticket Brain. You frame every conversation as a task. "I need you to go and..." rather than "I'm wondering what you think about..." You assign work when you mean to build ownership. You give answers when you should ask questions.

These patterns don't make you a bad manager. They make you a manager who was trained as an engineer. There is a difference.

I watched a CTO I respect lose three senior engineers in one quarter. Not to better pay. To a competitor who gave them a manager who asked different questions. The technical work was nearly identical at both companies. The conversations weren't.

The Irony of the AI Parallel

Here's something I've been thinking about, given how much time I now spend working with AI tools: the way you improve an AI's output is the same way you improve your leadership communication.

Prompt an AI with something vague, you get something vague back. Fire questions at it in rapid succession, you get confused results. Phrase your request as a command without context, and you get the literal minimum... not the thoughtful response you were after.

The fix, when working with AI: - Give context, not commands - Ask one thing at a time - Frame what you're trying to achieve, not what you want done - Iterate based on what comes back

Leadership communication works the same way. When you give your team context, ask focused questions, and frame the outcome rather than the task... you get better output. More nuanced thinking. More ownership. More trust.

You already know how to do this. You do it every time you sit down to refine a prompt. You're not applying it to the conversations worth most to your team's success.

The Numbers Aren't Flattering

The Association for Talent Development surveyed 239 talent development professionals in 2024. Over 90% said their organization has a leadership skills gap. And the top skill leaders are missing? Communication.

Not systems design. Not strategy. Not technical depth. Communication.

This is the skill we tell ourselves comes naturally... the one we'll pick up on the job... the one requiring no formal attention. And then 90% of the people responsible for developing leaders say it's the biggest hole they see.

I've worked with technical leaders for years. I've seen brilliant architects unable to give feedback without it landing as an attack. I've seen senior engineers running one-on-ones like Jira reviews and acting surprised when their team didn't feel supported.

The talent is there. The intent is there. The communication style is stuck in engineer mode.

The Standard Worth Aiming For

I'm not asking you to become a therapist. You don't need to get touchy-feely. You need to get curious.

The best technical leaders I've seen treat their one-on-ones like a discovery process, not a reporting process. They go in wanting to learn something they didn't know before. Not about the code... about the person.

Questions worth asking: - "What's taking more energy than it should right now?" - "Is there a decision sitting with someone else, slowing you down more than it should?" - "If you owned this product completely, what's the first thing you'd change?"

These questions get you information you need to be a useful manager. They also signal something clear: I'm interested in you, not only your output.

Four Things to Change Starting This Week

1. Add one non-task question to every one-on-one.

Before you get into work topics, ask something like: "How are you feeling about things generally right now?" Or: "Is there anything you wish you had more of... or less of... this week?" These aren't soft questions. They're intelligence-gathering. You want to know before someone has already decided to leave.

2. Ask one question at a time.

If you have five things to cover, start with the most important one. Wait for a full answer. Then move to the next. Your conversation will feel like a conversation... not a cross-examination.

3. Lead with context, not conclusions.

Instead of: "The API design needs to change."

Try: "I've been talking to the product team about where this product is heading, and I'm wondering if our current API design will scale with it. What do you think?"

Same outcome. Completely different effect on the person you're talking to. The second version makes them a partner in the thinking, not a recipient of a decision.

4. Slow down and wait.

Technical people often treat silence as a system failure. Someone goes quiet in a conversation and you rush to fill it. Don't. Give people space to think. If you asked a real question, wait for a real answer. The silence isn't awkward. It means the other person is thinking about what you asked... which is exactly what you wanted.

The Iteration Loop

Here's the thing about communication: you're never done improving it. It's not a skill you learn once and tick off. It's a feedback loop.

You try something. You notice how it lands. You adjust. You try again.

Exactly like refining a prompt. Exactly like debugging. Exactly like every other iterative process you've spent your career getting good at.

Your technical skills got you into management. Your communication skills will determine whether you stay effective there.

Start treating them the same way you treat your engineering skills: as something worth deliberate practice, honest feedback, and regular iteration.

Good engineering applied to the right problem.

So... what's one conversation this week where you've been communicating like a machine? Start there.

The meeting is running. Someone asks the CEO for a decision. He doesn't pause to think. He doesn't consult his team. He opens his laptop, types the scenario into an AI tool, and reads out whatever comes back.

If this feels like an exaggeration, you're about three years behind.

A 3Gem market research study of 200 UK business leaders found 62% use AI to make "most decisions." Not as a reference point. Not as a second opinion. As the decision engine itself.

This number should alarm you. Not because AI is unreliable. Because 62% of leaders have stopped doing the work.

The Numbers Don't Lie

The same study found 70% of those leaders second-guessed their own judgment when AI gave a conflicting answer. Nearly half (46%) said they rely on AI more than their own colleagues.

Read it again: almost half of senior leaders trust a language model over the people who know their business, their customers, and their team.

Carnegie Mellon and Microsoft published research showing workers who trust AI outputs demonstrate a lower propensity for critical thought. The pattern repeats wherever researchers look. Delegate your thinking, and you stop thinking.

This isn't a new problem. It's a new flavour of an old one. In 2025, 27% of those same executives used AI to make termination decisions. Think about the person on the receiving end of one of those. Their livelihood, decided by an algorithm, delivered by someone who abdicated the weight of the decision entirely.

What You're Losing

The MIT Media Lab published a study warning of cognitive atrophy from excessive reliance on AI-driven solutions. Your brain weakens in the areas you stop exercising.

Karen Thornber, a professor at Harvard, drew the parallel with GPS navigation. We travel more than ever, yet our spatial memory has declined because we never need to build it. The Harvard Gazette described it clearly: skills like discernment, evaluation, and reflection become more valuable as AI proliferates... precisely because they're the skills most at risk.

Your judgment works the same way. Wrestle with hard problems and you sharpen. Skip the wrestling by delegating to a language model, and your ability to wrestle deteriorates. Not more efficient. Worse.

I've seen this in engineering teams. Engineers who use AI to write all their code eventually stop being able to read it critically. They lose the intuition for what looks wrong. When something breaks and the AI doesn't have the answer, they're stuck. The tool removed the need to develop the skill, and now the skill is gone.

Leaders face the same atrophy. Stop forming your own views and you lose the judgment needed for decisions no AI handles well: the ambiguous calls, the interpersonal situations, the ethical grey areas where character and context matter more than pattern-matching. When you need it most, it won't be there.

The Leadership Problem Is Bigger Than You Think

Leaders who stop thinking independently stop leading. They broadcast.

I wrote about a related pattern in a post on prompts and leadership: the quality of your AI output reflects the quality of your thinking. Vague prompts produce vague output. Poor framing produces poor answers.

The deeper version of the same problem: when you hand a decision to AI before forming any view yourself, you've stopped leading. You're not thinking through the situation. You're transcribing a response.

Your team reads you. They know when you've genuinely thought something through versus when you're reciting output. This difference matters for trust. It matters for credibility. It matters because your team's willingness to execute a direction depends partly on whether they believe you understood the situation before deciding.

When a leader changes direction mid-project because "the AI suggested it," without any explanation of the context or reasoning, the team doesn't follow. They comply. There's a difference. Compliance without understanding is fragile. It collapses under pressure.

Leadership consultant Ben Morton frames it this way: if you outsource your thinking, the decisions coming back belong to whoever designed the model. Not to you.

You're not the decision-maker. You're the distribution channel.

The 99.5% Problem

My research found 99.5% of survey respondents said they've experienced one or more types of bad boss. The number one thing bad bosses have in common? They don't engage with the people they lead.

Outsourcing your thinking to AI is a new form of the same disengagement. It looks productive. You're moving fast, processing information, generating answers. But the people around you don't feel led. They feel processed.

The trust gap this creates compounds over time. Teams stop bringing you real problems because they sense you're not genuinely engaging with them. They work around you. They escalate past you. They check out.

AI Is a Tool, Not a Brain Transplant

AI is genuinely useful. I use it every day. It catches errors I miss, summarises material faster than I read, and surfaces options I might not have considered. All of it is legitimate.

The problem isn't using AI. It's using AI instead of thinking.

The difference is sequence. Bring your own perspective first. Form a view. Then use AI to stress-test it, find gaps, or speed up execution. The thinking happens before the tool, not in place of it.

Think of it as a research assistant, not an oracle. You still need to understand the question before you ask it, evaluate the answer before you use it, and own the decision before you announce it.

Three Habits Worth Building

Write your view first. Before using AI for any significant decision, write your position in one sentence. One sentence. If you're unable to produce it, you need more thinking time, not a faster tool. The inability to articulate a position is a signal, not a prompt to skip ahead.

Treat AI output as a first draft. AI gives you a starting point. Your job is to edit, challenge, and improve it. If you read the output and nod along, you've handed over your role. The value is in the push-back you bring, not the content it generates.

Keep human decisions human. Any decision affecting a person directly stays with you. Performance conversations, restructures, team changes... these belong to the people accountable for them. AI should inform, not decide. The person on the receiving end deserves a human who understood the situation, not an algorithm dressed up in leadership clothes.

What the Best Leaders Are Doing

The leaders I respect most use AI aggressively for leverage... but they engage deeply on things worth engaging with. They've set a clear rule for themselves: AI handles the volume, humans handle the weight.

They use AI for research, draft generation, summarisation, and option generation. They don't use it to avoid the uncomfortable cognitive work of forming a view, weighing trade-offs, and sitting with uncertainty long enough to develop genuine judgment.

The result: they're faster on the low-stakes work and better on the high-stakes decisions. Their teams trust them. They keep getting sharper.

The leaders who outsource everything get the opposite result. Faster on everything, worse on the things where it counts.

The Real Risk

The tools will keep improving. Your judgment won't improve on its own. You have to exercise it. Make calls without AI input. Build your own view before asking for a second opinion. Stay with a problem long enough to genuinely think it through.

The leaders who come out of the AI era with sharp judgment are the ones who used AI as a tool without letting it atrophy the muscle.

What's the last decision you made where the thinking was entirely yours?

Nobody reads the handbook. We've always known this.

HR teams spent months writing those documents. Benefits summaries. PTO policies. Performance review procedures. All of it sitting on an intranet loading slowly, looking like 2009, requiring three clicks before you realize you're looking at the wrong version.

Employees figured out long ago it's faster to ask a colleague. Or a manager. Or... increasingly... ChatGPT.

The Shift Nobody Is Talking About

Here's what's happening in your organization right now.

Someone wants to know how parental leave works. They don't open the intranet. They open ChatGPT, type "how does parental leave usually work," and get an answer in 10 seconds.

Is it your answer? No. Is it accurate for your company? Rarely. Does the employee know the difference? They don't care.

According to SHRM's 2026 State of AI in HR report, 39% of organizations have deployed AI in HR functions officially. The unofficial number is far higher: every employee with an internet connection is already using AI for workplace questions, and they're not waiting for HR to approve it.

I write a lot about the gap between what leaders think is happening and what's happening at the desk level. This is a big one.

The Questions HR Never Sees

The frustrating part isn't employees using AI. It's HR having no idea what questions are being asked, what answers are being received, or whether those answers align with company culture.

If 50 people asked ChatGPT about your parental leave policy last month, you'd never know. No ticket in your system. No email trail. No Slack message. The employee got an answer from a general-purpose AI trained on millions of documents... knowing nothing about your specific company, your specific values, or how your specific manager interprets the policy.

For simple factual questions? Fine. But what about the employee who asked ChatGPT whether to report their manager for inappropriate behavior? What answer did they get? Was it aligned with your actual process, your psychological safety culture, your specific HR team's approach... or was it a generic response based on average corporate practice?

You don't know. Not knowing is the problem.

The Same Shift Happened to Google

Think about what happened to web search.

For 20 years, you needed to rank on Google to be found. Companies invested in SEO. They built content, acquired backlinks, optimized metadata. Page one was the goal.

Then large language models arrived. Millions of people now get their answers directly from AI... and never visit the underlying source. Your carefully crafted web pages? Bypassed entirely.

The same shift is happening inside your organization. Your intranet is Google. Your employees abandoned it for AI. The question is: what is AI telling them?

Uber engineers reduced time spent searching internal documentation by over 40% after implementing AI-powered internal knowledge systems. Internal AI, trained on internal data. The answers those employees get are about Uber's processes, Uber's culture, Uber's way of doing things.

Your employees are getting similar efficiency... from a tool trained on the general internet. The answers are generic. Your culture, your policies, your values are nowhere in them.

The Culture Risk Nobody Measures

Here's what worries me about the current state.

When an employee asks ChatGPT "how should I handle a conflict with my manager," they're getting the internet's average answer. An average answer based on millions of workplaces, thousands of HR policies, and no knowledge of your specific culture.

Your culture is not average. Or it shouldn't be.

If you've spent years building psychological safety, you want employees to understand your specific process for raising concerns. If you've built a feedback culture, you want employees to know what "good feedback" looks like in your organization specifically.

Generic AI answers flatten all of this. "Here are five steps to handle conflict at work" is not your five steps. It's everyone's five steps. Some of those steps might actively contradict the culture you've built.

This is especially true for organizations with strong cultures... the ones with unusual onboarding, unconventional management structures, or values going against industry defaults. Those cultures are the hardest to communicate, and the most damaged by generic AI answers.

The Organizations Getting This Right

Some organizations figured this out. They're not fighting the AI wave. They're feeding it.

Microsoft Copilot, Glean, Guru AI... these platforms let you build an AI layer answering employee questions using YOUR data. Your policies. Your culture documents. Your values statements. When an employee asks "how do I request time off," they get YOUR answer, not a generic one.

87% of HR professionals using AI report meaningful efficiency gains, per SHRM's 2026 research. The organizations seeing those gains aren't the ones blocking AI. They're the ones integrating it deliberately, on their own terms.

The organizations doing this well are treating internal knowledge as a product. They ask "what questions are our employees asking?" and make sure AI has the right answers before employees go looking elsewhere.

This isn't complicated in principle. It is complicated in execution, because it requires HR and tech teams to sit in the same room and genuinely agree on what the source of truth is. Most organizations skip this conversation entirely.

What Bad Leaders Don't Want You to Know

Here's something worth saying directly.

Transparency through AI is uncomfortable for bad leaders. If an employee asks ChatGPT "is my manager required to give me regular feedback," they'll get a yes. If they ask "what are my rights if my manager is creating a hostile environment," they'll get a clear answer.

Bad leaders benefit from information asymmetry. They rely on employees not knowing their rights, not knowing the process, not knowing what normal looks like. When employees don't know what good leadership is, bad leadership goes unchallenged.

AI is dismantling this asymmetry. Employees are better informed than ever. I don't see this as a problem to manage. I see it as a feature of a healthy workplace.

At Step It Up HR, the data we see consistently shows bad manager behavior thrives in environments where employees don't know what good looks like. My research found 99.5% of survey respondents had experienced one or more types of bad boss. For most of them, the barrier wasn't courage... it was information. They didn't know what they were experiencing wasn't normal.

AI is changing this. Every employee now has access to a baseline of "what should this look like?" Your job as a leader is to make sure your organization shows up in their AI answers... not as an afterthought, but as the authoritative source.

What You Should Do

A few things, in order of importance.

Audit the gap first. What questions are your employees most likely to ask AI about? Start with the obvious ones: benefits, leave, performance, pay, disciplinary procedures. Then check whether your internal documentation answers them clearly. Most organizations have documentation which is technically accurate but practically useless. Bureaucratic language. PDFs from 2018. Links going to pages no longer there. Plain-English answers to real employee questions are scarce.

Feed the machine deliberately. If you're not yet investing in an AI layer over your internal knowledge base, start scoping it now. Microsoft Copilot for enterprise, Glean, Notion AI... there are options at every budget level. The goal is simple: when your employee asks, they get your answer, not a generic one. This requires good source material. If your documentation is weak, no AI tool fixes it.

Treat documentation as a product, not a chore. Your internal knowledge base needs the same attention a good product gets: regular updates, user testing, someone who owns it. Most intranets have an owner on paper and nobody in practice. Change this.

Stop treating the handbook as finished. Your internal documentation is a living thing. Employees are asking questions you haven't thought to answer. The only way to know which ones is to ask. Run a quarterly review. Ask your managers what questions they hear most often. Then answer those questions in plain English and make sure your AI system knows about them.

Use the discomfort. If AI transparency is uncomfortable in your organization... find out why. The answers employees are getting from ChatGPT are often more honest than the answers they're getting from their managers. Name why this feels threatening. Then fix it.

---

The intranet isn't coming back. Employees found something faster, cleaner, and always available.

The question for every HR leader and tech leader reading this is simple:

Are you the source of truth for your employees... or is ChatGPT?

Only Amateurs Think Leadership Is About Having the Answers

When you got promoted into leadership, something strange happened.

You started thinking your job was to know things.

Not everything. Not the answer to every question. But enough. Enough technical depth. Enough domain expertise to justify your seat at the table.

Most of us walk straight into this trap.

You spent years being the person who solved problems. You built a reputation on knowing how things worked. You got recognised for being right. Then someone handed you a team and said, "You're in charge now."

So you kept doing what worked before. You kept being the one with answers.

That was the mistake.

The Confidence Trap

Here's what happens in most tech organisations: the people who get promoted are the ones who look like they know what they're doing. Not the ones who do.

Dr. Tomas Chamorro-Premuzic, professor of business psychology at Columbia University, has spent years studying why so many leaders are incompetent. His finding: we consistently mistake confidence for competence. The person who speaks first, speaks loudest, and radiates certainty gets mistaken for the best leader in the room.

In tech, this problem compounds. We have a cultural worship of the "10x engineer." The person who knows everything, writes the most code, solves the hardest problems. When you promote someone like that, they often become the single point of failure for every decision the team makes.

Not leadership. A bottleneck with a title.

What Google Found Out

In 2012, Google launched a multi-year study called Project Aristotle. The goal: identify what made their best teams outperform the rest. They studied 180 teams across the company, tracking 250 different attributes.

Most people guess it's a combination of the smartest individuals, an experienced manager, and ample resources.

Wrong.

The single biggest predictor of team performance was psychological safety. Whether people felt safe enough to speak up, raise concerns, flag problems, and challenge each other.

Individual expertise ranked way down the list. Having the sharpest people in the room didn't matter nearly as much as whether those people felt free to use their brains.

Think about what that means. You hire ten brilliant engineers. You install an expert-leader above them. The expert-leader has most of the answers, so they dominate every technical discussion. The brilliant engineers learn to defer.

You have built a team that performs at a fraction of its capacity. And your expert-leader will never know, because they'll attribute every win to their own decisions.

The Ego Bug

A piece published on Medium in late 2025 described it well: "In many tech organisations, technical expertise quietly turns into perceived superiority. Questions about cost, coordination, users, or timing get treated as distractions, while code becomes the unquestionable centre of every decision."

I've watched this play out more times than I'd like to admit.

A senior engineer gets promoted to team lead. Excellent at solving problems individually. Now in meetings, they're already formulating a better answer before the previous speaker has finished. They cut across ideas. They finish other people's sentences. They have the solution before the question is even fully stated.

The team picks this up fast. They stop raising half-formed ideas. They stop flagging concerns early. They show you what you want to see, not what's true.

Then you wonder why your retrospectives are so quiet.

The ego isn't always arrogance. Sometimes it's habit. A deeply ingrained habit of being the most technically capable person around and acting accordingly. The engineer-turned-leader doesn't think they're shutting down conversation. They think they're being efficient.

They're being efficient at producing the wrong outcomes.

The Code Review Trap

Code reviews are where this failure mode shows up most clearly.

A leader who needs to be right turns code reviews into lectures. They comment on every deviation from their preferred approach, even when the alternative works fine. Junior engineers stop submitting ambitious code and start submitting safe code. The thing you thought was quality control becomes a monoculture factory.

Great technical leaders treat code reviews differently. They ask: "Why did you approach it this way? What trade-offs were you weighing?" They're genuinely curious. Sometimes the junior engineer's approach is better. Sometimes it isn't, but the explanation reveals a gap in documentation or shared understanding worth addressing.

Either way, you learn something. Either way, the engineer feels respected.

The expert-leader who skips the question and jumps to the correction loses both outcomes.

What Effective Leaders Do Instead

Chamorro-Premuzic made a point worth sitting with. AI commoditises technical knowledge faster every year. Want to know how something works? Ask an AI. The knowledge gap which used to justify expert-leaders is narrowing fast.

What's left is the ability to create conditions where your team does its best thinking. The ability to ask questions that open up possibilities rather than close them down.

Forbes calls this "inquisitive leadership". It's not a soft skill. It's the hardest shift a technical person makes: from performer to enabler.

Here's what it looks like in practice:

Replace declarations with questions in your next meeting

Instead of "we should use microservices here," ask "what are the trade-offs we'd see with microservices versus a monolith for this use case?" You'll hear things you didn't know. Your team will feel heard. And on the days when they propose something genuinely wrong, they'll have articulated the reasoning, which makes the correction land better.

Stay quiet for ten seconds after someone stops speaking

This is brutal if you think fast and talk faster. Ten seconds feels like forever. But the pause signals you're processing, not queuing your rebuttal. It changes the dynamic in the room completely. People start to finish their thoughts properly, knowing they won't be interrupted before the point lands.

Say "I don't know" out loud, then ask who does

This feels like weakness. It isn't. Leadership coach Ruth Wooderson puts it plainly: "Don't trust a leader who never says, 'I don't know.'" When you admit not knowing, two things happen. Your team stops pretending to know things they don't. And they trust you more, not less.

The follow-up matters as much as the admission. "I don't know... who in the team is closest to this?" You're redistributing authority in real time. You're signalling whose expertise matters.

Stop making decisions alone that the team should make together

Every time you make a decision in isolation that your team was equipped to make, you do three things: you miss the information they held, you deprive them of the growth that comes from making the call, and you reinforce their belief that thinking for themselves is optional.

The best leaders I've worked with sit in meetings where they know the answer... and ask the question anyway. They want to see the team get there. When the team does, the decision is theirs, which means the execution is theirs too.

The Real Performance Lever

The technical leaders who build the best teams over time share one trait. They're more interested in what the team knows than in what they know themselves. They see their role as creating conditions for good decisions, not making all the decisions themselves.

This isn't idealism. The data backs it up. Research consistently shows leaders who ask better questions and build psychological safety outperform those who invest in demonstrating their own expertise.

And the opposite? The leaders who prioritise being right over being effective are the bad bosses people remember for the rest of their careers. In our research on workplace experiences, 99.5% of respondents said they've had at least one of those. The story they tell about those leaders is almost never about incompetence. It's about ego. The boss who couldn't admit they were wrong. The boss who made every meeting about proving their own intelligence.

What you're building, one meeting at a time, is a team where people bring their thinking. Not a team performing deference to yours.

Your team is smarter than you give them credit for. Give them the room to prove it.

What's one question you've been answering, when you should have been asking it instead?

I've sat in both chairs.

As an employee, I've walked into December review season wondering if the promotion I earned in March was still on the table, or if the mistake I made in October had quietly buried it. As a manager, I've stared at a year's worth of notes and tried to write something honest and useful about work from six months ago.

It's a ritual satisfying nobody and changing almost nothing.

Adobe research found only 14% of employees feel performance reviews inspire them to improve. Fourteen percent. We spend enormous time and management energy on a process failing to motivate 86% of the people sitting through it.

There's a better way. It takes six minutes.

The Annual Review Is Broken by Design

The core problem is timing. You do something brilliant in February. I don't tell you. I make a mental note. Six months later, I'm trying to reconstruct what happened and why it mattered, while you've forgotten the context and moved on.

Feedback arriving months after the fact isn't feedback. It's archaeology.

The system was built for a workplace where work moved slowly... where a year of output was genuinely hard to assess in real time. Those days are gone. Your engineers ship code every week. Your salespeople hit or miss quota every month. Your project managers hit walls and find workarounds constantly. The work itself is no longer slow enough to justify a once-a-year review cycle.

Waiting until December to tell someone what they did wrong in April isn't protecting them from criticism. It's denying them the chance to improve.

Recency Bias Is Writing Your Reviews

Even when managers try to do annual reviews well, their brains work against them.

Recency bias is the cognitive tendency to weigh recent events more heavily than older ones. In practice, whatever happened in October and November shapes the December review far more than anything from February through August. One bad sprint before review season tanks an otherwise strong year. One strong sprint before review season papers over months of mediocrity.

Neither outcome is fair. Neither is useful.

This isn't a character flaw in managers. It's how human memory works. If you want accurate assessments of performance over time, you need feedback loops happening over time. Not one snapshot at the end.

The annual review doesn't measure the year. It measures the last two months and pretends it measured twelve.

What Works Instead

Gallup research cited by Lattice found employees who received meaningful feedback in the past week were nearly four times more likely to feel engaged than those who didn't. Not somewhat more likely. Four times.

Betterworks' 2024 State of Performance Enablement report found employees who receive ongoing feedback are three times more likely to feel they perform their work well... and significantly more likely to see a path for internal career development.

The pattern is clear. Frequent, timely feedback doesn't replace performance management. It is performance management.

The annual review, when it exists at all, should be a formality. A summary of ongoing conversations, not a substitute for them. If your employee is surprised by anything in their annual review, you've already failed them. The review should contain nothing new.

The Six-Minute Rule

Here's the practical version. After any notable event... a good piece of work, a missed deadline, a tricky client conversation, a solid bit of problem-solving... take six minutes.

Not six hours. Not a scheduled meeting. Six minutes, as close to the event as possible.

Two minutes to say what you observed. Be specific. Not "good presentation" but "the way you handled the technical objections in the Q3 demo was sharp... you didn't get defensive, you asked questions first."

Two minutes to say what impact it had. On the team. On the project. On the client. On you.

Two minutes to say what you'd like to see more of, or what to do differently next time.

No forms. No scoring. No HR portal.

This is the core of the SBI framework: Situation-Behavior-Impact, which has been around for decades. The idea isn't complex. The failure is in not doing it.

"But We Need Documentation"

I know the objection. HR needs records. Promotions need evidence. Legal needs paper trails.

Fine. Write it down in a shared doc after you have the conversation. Three minutes. Send the employee a note: "After the client call today... you handled the pushback well. Logging it." Done.

What you're building is a living record of actual performance throughout the year. When review season comes, you're not guessing. You have evidence. Your employee has context. The conversation becomes confirmation, not revelation.

66% of employees say they'd consider leaving a job where they felt unappreciated... and among millennials, 76%. Regular, specific feedback is one of the most direct ways to show someone their work is seen. It costs nothing but attention.

The Real Cost in Tech

In software teams, the stakes are higher than most people admit.

A developer who gets unclear feedback in December about a pattern they started in March has been writing bad code, building bad habits, or solving the wrong problems for nine months. The annual review didn't save anything. It baked the problem in.

Real-time feedback in technical teams isn't soft-skills theater. It's engineering quality control. The same discipline you'd apply to a code review... catching problems at the point of origin, not six months downstream when they're load-bearing... applies to everything else people do.

Feedback is a form of testing. Annual reviews are testing in production.

Start Monday

Pick one person on your team. Think of the last time they did something worth noting... good or bad. Have a six-minute conversation about it this week.

Don't announce a new feedback system. Don't run it by HR. Don't wait for the right moment or the right format.

Do it once. See what happens.

My strong suspicion is you'll find two things: it takes almost no time, and it changes the relationship more than you'd expect. People don't need to be managed into compliance. They need to know where they stand. Real-time feedback gives them the clarity they need... and frees you from the December scramble of trying to do a year's worth of managing in one awkward hour.

Six months from now, your annual review conversation will be the easiest one you've had. Because it won't contain any surprises.

Every few weeks, another frontier AI model drops. GPT-something new, Claude whatever-next, Gemini 4-point-something. And every time, engineering teams across the world do the same thing: they stop what they're doing, pull up the leaderboard, argue about MMLU scores, run a few quick tests, write up a comparison doc, and then... keep evaluating.

Their competitors ship.

I've watched this pattern destroy momentum at companies I've led and companies I've advised. The engineering team spends three weeks building a model evaluation framework. By the time the framework is done, two new models have dropped and the whole comparison is stale. Meanwhile, a smaller team with a "good enough" model has shipped a working product, gathered real user feedback, and started iterating.

The benchmark obsession is a real problem. And it's getting worse.

The Benchmarks Are Broken

Here's something the leaderboards don't advertise: the benchmarks don't mean what you think they mean.

MMLU and GSM8K are two of the most widely cited tests for AI model quality. Top frontier models now score 91%+ on MMLU and 94%+ on GSM8K. At those numbers, the scores tell you nothing. You cannot differentiate between models. You're looking at a ranking table where everyone is tied at the top.

According to research on benchmark saturation, roughly 45% of benchmark data overlaps with model training sets. Models aren't demonstrating capability. They're demonstrating memory.

The clearest proof: researchers tested GPT-4 by hiding answer choices in MMLU questions. A model with no prior exposure should guess the right answer about 25% of the time... by pure chance. GPT-4 guessed correctly 57% of the time. More than double chance. The model had memorised the test.

This is Goodhart's Law in practice. When a measure becomes a target, it ceases to be a good measure. AI labs optimise their models to score well on benchmarks, not to be genuinely more useful. The leaderboard is, in many cases, a marketing document.

In March 2026, MIT Technology Review ran a piece on exactly this problem. Their conclusion: standard benchmarks test narrow, idealised scenarios. Enterprise use cases are not idealised scenarios.

The Number Your Team Should Actually See

Here's a real-world result worth paying attention to.

One organisation switched to an AI model with a benchmark score 3% higher than its predecessor. Their customer support escalations went up 12%.

Read it again. Better benchmark score. Worse product outcome.

This is the real-world gap. In medical AI research, models showed a 20% performance drop with genuinely unseen test images. Training never saw those images, so the model never learned the task... only the test set.

The problem isn't unique to AI. I've seen software teams spend months choosing a database because one scored better on a synthetic workload benchmark... then deploy it to production where the benchmark metric was completely irrelevant to their actual query patterns. The benchmark answer was technically correct. The business decision was wrong.

What You Lose While You Benchmark

The loss from endless evaluation isn't visible on any project tracker. Nobody writes "competitor gained 400 users while we compared leaderboards" in the sprint retrospective.

Every week of evaluation is a week without user feedback. Every week without user feedback is a week you're making product decisions blind. Your competitor who shipped the "good enough" version three weeks ago has already fixed the things your benchmark wouldn't have surfaced anyway.

I've been in rooms where engineering teams spent six weeks building a comprehensive model evaluation framework. Rigorous testing. Multiple dimensions. Proper statistical analysis. By the time the framework was complete, the model in first place had dropped six weeks earlier and was already on its second version. The framework arrived outdated before anyone acted on it.

The irony: the evaluation process itself was well-engineered. The problem was the belief a benchmark score would tell them something their own production data wouldn't.

The One Benchmark Worth Running

Fortune has written about how Salesforce handled this. Instead of relying on academic benchmarks, they built internal evals for CRM-specific tasks... prospecting, lead nurturing, account management. The generic MMLU score told them nothing. Their own eval told them everything.

You don't need Salesforce's budget to do this.

Pick 50 real examples from your production data or your intended use case. Be specific. If you're building a code review tool, use 50 real pull requests. If you're building a customer support bot, use 50 real support tickets. If you're automating a data extraction workflow, use 50 real documents.

Write a scoring rubric for each example. What does "correct" look like? What does "acceptable" look like? What's a failure?

Run every model candidate against your 50 cases. Score them.

You'll learn more in four hours than you would in four weeks of benchmark research. And you'll learn things the benchmarks genuinely won't tell you: how the model handles your edge cases, your specific formatting requirements, your domain language.

Build your own eval. It's the only benchmark worth running.

A Note on Precision vs Direction

There's a legitimate version of careful model evaluation. If you're embedding AI into a regulated product... medical, legal, financial... you need rigorous testing before you ship. This isn't benchmark obsession. It's proper due diligence.

Most teams aren't in regulated industries. Most teams are building SaaS tools, internal workflows, or developer tooling where the appropriate quality bar is "does it work well enough to get user feedback?" and the appropriate evaluation method is "ship a working prototype and see."

The benchmark comparison taking two engineers three weeks to build is almost never the right tool for this decision. A working prototype with real users is.

How I Think About Model Selection Now

After years of watching this pattern, here's my current approach.

Start with a shortlist. The major frontier models from Anthropic, OpenAI, and Google are all capable for most use cases. Pick two or three based on price, API terms, and any hard constraints like data residency, context window, or latency requirements. This takes an afternoon, not a sprint.

Build your own eval. Fifty real examples, a simple rubric, four hours. Run your shortlist against it. Pick the best performer.

Ship it. Get real users on it.

Iterate. Your users will surface the failure modes the benchmark wouldn't have. Fix those. Run your eval again with new examples from production. Repeat.

This isn't "move fast and break things." It's moving at the speed your learning requires. You learn from users. You don't learn from benchmarks.

The Best Benchmark Score Doesn't Win

The AI labs will keep releasing models. The benchmark tables will keep updating. Someone will always hold the highest MMLU score this week and lose it next week.

None of this matters to your users. Your users care whether the product does the job.

Ship something. Make it better. The only eval worth running is the one your users run for you.

What's stopping you from shipping the "good enough" version today?

Most 1:1s I've seen follow the same script. The manager asks "How's the project going?" The employee runs through a list. The manager nods, makes a note, unblocks something. The meeting ends. Repeat next week.

This isn't a 1:1. It's a walking stand-up.

The problem isn't the questions themselves. "What are you working on?" is fine. "Any blockers?" is useful. But these questions put the manager in observation mode. You're watching the employee's work, not leading them.

According to Gallup's 2025 State of the Global Workplace report, only 21% of employees worldwide are engaged at work, down from 23% the year before. Manager engagement dropped too, from 30% to 27%. The trend lines are clear: 1:1s are happening, but something isn't working.

Why Most 1:1s Miss the Point

There are five signs a 1:1 has gone wrong. The manager comes in unprepared and wings it. There's no clear objective for the meeting. The manager does most of the talking. Nobody follows up on last week's commitments. The whole thing stays on the surface of work rather than the experience of doing it.

Most of these failures share one root cause: the meeting is structured around the manager's needs, not the employee's. The manager needs to know project status. The manager needs to identify risks. The manager needs to check the box on "having 1:1s."

The employee needs something else. They need to feel seen, heard, supported, and equipped to do good work. A status update gives them none of those things.

The Question Most Managers Skip

Here's the shift: stop asking about their work and start asking about your performance as their manager.

Lee Woollsey put it precisely: "The three magic words every 1:1 should ask are 'What aren't you getting from me?'"

It sounds simple. It isn't.

Most managers are trained to see themselves as the evaluator in a 1:1. They're assessing, coaching, guiding. But the employee is looking for something specific from you... and too often they don't get it because you never ask.

"What aren't you getting from me?" flips the entire dynamic. Now you're the one being evaluated. You're signaling you want to serve them, not supervise them. You're giving explicit permission to tell you where you're falling short.

This matters because the answer will be true. Employees know what they're not getting from their manager. They think about it. They talk about it with their peers. They don't tell you because nobody asked, or because asking felt pointless, or because previous attempts to give feedback went nowhere.

A Gallup study on leadership trust found only 14% of employees feel their leaders actively seek their feedback. Fourteen percent. Meaning 86% of your team are sitting in 1:1s with feedback they're not sharing, because nobody created the space for it.

Why Tech Leaders Need This Most

If you lead a software team, this question matters even more.

Engineers are trained to be precise. They solve problems with information and specification. When they don't get what they need from a manager, they often won't say so. They'll work around it. They'll make do. They'll assume the manager knows what they're doing.

Then they leave.

The research on knowledge worker disengagement is consistent: people don't leave companies, they leave managers. And most managers have no idea what they're doing wrong, because they never asked.

"What aren't you getting from me?" asks.

What You'll Hear

The first few times you ask this question, you'll hear something vague. "No, I think we're good." Fine. Trust needs to build before someone tells their manager the truth.

Keep asking. Ask every few weeks. Make it part of your regular 1:1 rhythm.

When people start answering honestly, here's what comes up:

"I don't get enough context on why we're building this."

Engineers want the reasoning behind decisions, not only the decisions. When they don't get it, they fill the gap with assumptions... and wrong assumptions make wrong code. You fix this by sharing more: send the document before the decision is final, invite them to the conversation earlier, explain the trade-offs you weighed.

"I never know how I'm doing until performance review time."

Your feedback loop is broken. Engineers want signals along the way, not a verdict at the end of the year. Feedback delayed is feedback denied. Fix this by making one piece of specific feedback a weekly habit, not a quarterly event.

"I feel like I'm on my own when things get political."

They need air cover. They need to know you'll go to bat for them when a product manager or stakeholder pushes back on scope, timelines, or technical decisions. Without it, they protect themselves by saying less, taking fewer risks, and shipping safer work. A disaster for a team trying to do anything meaningful.

"I don't know what 'good' looks like here."

No clarity on how you define success for them. They're flying blind and trying not to crash. Fix this by writing it down. A clear, shared definition of what good looks like for their role removes enormous amounts of anxiety.

Each of these is something a manager controls. Not the employee. The manager.

Do Something With the Answer

Ask the question. Write down what they say. Then act on it.

The worst thing to do is ask "What aren't you getting from me?" and change nothing. Do it twice and you've taught them the question is performative. They stop answering honestly. And now you've made things worse, not better.

If they say they need more context, start sharing more. Bring them into the room earlier. Send them the reasoning, not only the decision. If they say feedback is missing, make it weekly instead of quarterly. Find one thing each week to name and respond to.

If they say something unexpected... thank them. Don't get defensive. Don't explain why you did what you did. Listen, write it down, and come back next time with evidence of what's changed.

Roy Rapoport describes this well: before someone improves, they need to agree there's a problem, want to fix it, own their role in it, have a plan, and execute. The same applies when the person improving is you. You have to agree you're the blocker, want to change, own it, plan it, and follow through.

Creating the Conditions for Honest Answers

"What aren't you getting from me?" only works if the environment is safe enough for a real answer.

If your 1:1s have historically felt like performance checkpoints, people won't answer honestly at first. If previous feedback has been met with defensiveness or excuses, people won't try again. If you only ask once and never follow up, nobody will take it seriously.

The way to build safety is small and consistent. Show up to every 1:1 prepared. Follow up on last week's commitments before starting new topics. When someone shares something uncomfortable, thank them specifically for saying it. When you act on their feedback, name it out loud: "You said you weren't getting enough context on decisions, so I've started sending these summaries. Is it helping?"

Visibility closes the loop. It teaches people your question was real.

The Trust Payoff

Lee Woollsey says it plainly: "Wanna speed up your team? Build trust. Nothing else comes close."

Low trust is a hidden productivity tax. Your team spends energy managing around gaps in leadership instead of building great software. They hesitate before bringing problems forward. They don't ask for help when they're stuck. They write overly defensive code reviews because they don't trust the environment.

Three words in a 1:1 won't fix all of this overnight. But they open the door to fixing the right things.

Ask the question in your next 1:1. Write down what you hear. Come back the time after with one thing you've changed. See what happens to the quality of the answers.

What are your people not getting from you?

Seventy-seven percent of employees globally are either not engaged or actively disengaged at work.

Not distracted for a day. Not having a bad week. Structurally, chronically checked out.

The cost sits at $8.8 trillion in lost productivity every year. Nine percent of global GDP. Gone. Because people are sitting at desks, staring at screens, doing the minimum... or worse, making things actively worse for everyone around them.

Most companies know the number. Few of them find it uncomfortable enough to change anything important.

We Decided It's the Employees' Fault

Here's the standard corporate response to a disengagement crisis:

• Launch an engagement survey
• Announce a committee
• Roll out a wellness app
• Put a ping-pong table in the break room

Then wonder why nothing shifts.

We treat disengagement as though it were a character flaw in the workforce. "These people don't want to work." "Nobody wants to put in the effort anymore." "Gen Z doesn't care."

Wrong. The data says so clearly.

70% of the Problem Is Sitting in Your Management Chain

Gallup has tracked this for decades. Their conclusion: managers account for at least 70% of the variance in employee engagement across business units.

Read it again.

Seventy percent. Not the product. Not the pay. Not the office perks. The manager.

If your team is disengaged, the first place to look isn't at your employees. It's at the person they report to.

I've written about this on Step It Up HR more times than I care to count. The disengagement problem is a leadership problem. It always has been. We've dressed it up in employee experience language, launched wellbeing programmes, handed out branded tote bags... and the number stays stuck near the same catastrophic level.

We treat the symptom while ignoring the source.

Who Gets Promoted -- and Why It Kills Engagement

My research found 99.5% of respondents have had one or more types of bad boss. Not a mediocre boss. Not an imperfect-but-trying one. A genuinely bad one.

Not bad luck. A systemic selection problem.

McKinsey research on why bad bosses keep rising to the top points at a hard truth: we don't promote based on leadership ability. We promote based on confidence, visibility, and technical skill.

The person who ships the most features becomes the engineering lead. The top salesperson becomes the sales manager. The loudest voice in the room gets taken for the most capable one.

Dr. Tomas Chamorro-Premuzic at Columbia University puts it plainly: "We don't select leaders on the basis of talent, merit, or potential." What gets selected for, again and again, is narcissism, overconfidence, and low emotional intelligence. Not because anyone wants those traits... but because they're easy to mistake for leadership when you're watching someone across a conference table.

The people who would make genuinely good managers -- the ones with empathy, self-awareness, and emotional maturity -- often don't look like "leadership material" because they're not performing it. They're doing the work.

I've seen this pattern repeat across decades in tech. The person who talks most in meetings gets promoted. The one who builds visibility with senior leadership moves up. Check the exit interviews from the people who quietly left and you'll find out what their managers were doing while climbing.

What Engaged Teams Look Like

When leadership works, the numbers shift dramatically.

Gallup's meta-analysis of over 112,000 business units found engaged teams show 23% higher profitability, 18% higher productivity in sales, and 43% lower turnover in low-turnover industries.

Twenty-three percent more profitable. Not from a new product strategy. Not from a restructure. From people who give a damn about what they're doing.

And what creates the conditions for engagement? Managers who give people a reason to show up fully.

The research points to the same ingredients every time: trust, autonomy, purpose, and someone who treats you like an adult. Not performance management theatre. Not quarterly reviews where the rating was already decided before the meeting. Not surveillance dressed up as a productivity tool.

A manager who listens. Follows through. Removes obstacles. Tells the truth.

Simple, because it is. We've made it complicated to avoid dealing with the real problem.

AI Makes This More Urgent, Not Less

Here's something worth sitting with. As AI handles more of the knowledge work -- the answers, the lookups, the code suggestions, the first drafts -- what's left for managers to do?

The McKinsey researchers make this point well. For decades, technical expertise gave people in leadership roles their authority. "I've been doing this for fifteen years. I know the answer." AI is eroding it fast. The people who will lead well in the next ten years won't lead by knowing more. They'll lead by building conditions where other people do their best work.

Emotional intelligence. Trust. Clarity. Psychological safety.

Those are not soft skills. They are the core skills. The ones AI doesn't replace. The ones most of our current managers were never evaluated on before being handed a team.

The 77% disengagement figure hasn't meaningfully moved in years. As AI takes over more of the transactional work, the gap between good leadership and bad leadership will get wider, not narrower. Teams with engaged, psychologically safe cultures will adapt faster. Teams led by low-EQ managers who rely on authority and technical knowledge for credibility will fall apart.

The window to fix this is now. Not when the next engagement survey comes back with the same numbers.

Three Things Worth Doing

No framework. No six-step model. Here's what moves the needle.

Stop promoting on technical merit alone. Your best engineer becoming an engineering manager is a choice, not an inevitability. And it's often the wrong choice. Leadership is a separate skill set. Someone who writes excellent code has zero guarantee of interest in -- or aptitude for -- managing people dynamics, having difficult conversations, or helping someone grow. Before you hand someone a direct report, ask: do they want to lead people? Do they have evidence of doing it well, not once under good conditions, but consistently under pressure?

Invest in the managers you already have. Gallup's 2025 data shows only 44% of managers have received formal management training. Over half of the people responsible for 70% of your engagement variance were handed the job with no preparation at all. This is not a surprise. It's a choice. An expensive one. Coaching, mentorship, structured development -- whatever form it takes -- developing your managers is the highest-return investment in your business. Not only because it's the right thing to do, but because the math says so.

Make leadership performance visible and consequential. Most organisations measure employee performance religiously. Quarterly reviews. Rating scales. Performance improvement plans. Few measure manager effectiveness with the same rigour. If your managers' teams are chronically disengaged, the signal should show up somewhere meaningful. If it doesn't, you've told everyone watching what people leadership is worth to you. What gets measured gets managed. If you're not tracking how managers lead, you're choosing not to know.

The Question Worth Asking

Seventy-seven percent won't go down on its own.

It won't be fixed by another engagement survey or another set of values printed on a wall. It comes down when organisations get serious about who they put in charge of people... and what happens when those people fail at the job.

If you lead a team, the question isn't whether your people are engaged. The question is: what are you doing, specifically, to earn it?

If you're not sure, start there. Not next quarter. Now.

On August 1, 2012, Knight Capital deployed new trading software. Within 30 minutes, the firm lost $440 million. The stock dropped 75% in two days. The company never recovered.

The post-mortem didn't point to bad code. It pointed to management pressure creating unrealistic deadlines, which caused the team to push test code into production.

A leadership failure dressed up as a technical one.

And it happens every single day. Not at the $440 million scale. But in your standup. In your sprint planning. In the architecture decisions being made by people who haven't written a line of code in years.

The False Dichotomy

We love sorting problems into neat buckets. "People problem" goes to HR. "Technical problem" goes to Engineering. And the root cause sits in the gap between the two, grinning.

Andrew Graham-Yooll nailed this in his piece The False Dichotomy. He calls the separation of people problems from engineering problems "one of the most persistent and counterproductive myths in software engineering."

He gives the example of a database performance issue traced to indexing decisions made years earlier under different constraints. The fix wasn't technical. It was coordination. Understanding the stakeholder contexts and preventing future misalignments.

Here's the pattern I see over and over: engineers raise concerns. Leadership ignores them. The system fails. Leadership blames the engineers. New engineers are hired. The cycle repeats.

As the team at piechowski.io wrote: "Every time, leadership decides it's a people problem. So they reorganize, add process, sometimes let people go. Then the next team hits the same wall. Because it was never the people. It was the codebase."

One company they documented cycled through six engineering teams over ten years without solving the underlying code quality issue. Six teams. Ten years. The same problem. Leadership kept looking at the people instead of the system.

The Graveyard of "Technical" Failures

The history of technology is littered with projects killed by leadership, not by code.

The FBI's Virtual Case File burned through $379.8 million and 700,000 lines of code before being scrapped entirely. The root cause? Poorly defined requirements, an overly ambitious schedule, and 400+ change requests. Management failures, every one.

FoxMeyer Drug tried to implement an ERP system with an 18-month timeline decided by executives, not engineers. They assigned junior consultants instead of seniors. The new system processed 10,000 orders a night versus 420,000 on the old one. The company went bankrupt. A $500 million lawsuit followed.

The Airbus A380 racked up $6 billion in corrections and a two-year delay because dispersed global teams used incompatible CAD software. The parts designed by different divisions didn't fit during assembly. This wasn't an engineering failure. It was a communication failure between leadership silos.

And government tech? The Standish Group found government technology projects over $6 million succeed only 13% of the time. Not because governments hire bad engineers. Because governance structures make failure the path of least resistance.

Your Team Already Knows

Here's what leaders don't want to hear: your people already see the problems coming. They see them months before the deadline. They raise them in retros, in one-on-ones, in Slack messages flagged with yellow triangles.

DDI's Frontline Leader Project found 57% of employees have left a job specifically because of their manager. Not because of the tech stack, not because of the product, not because of the salary. Because of the boss.

A Perceptyx study showed 24% of employees currently work for the worst boss they've ever had. These employees are three times more likely to be disengaged and four times more likely to quit within 12 months.

My own research found 99.5% of survey respondents said they've had one or more types of bad bosses. Ninety-nine point five percent. The bad boss isn't the exception. It's the norm.

And 70% of frontline managers didn't expect to be promoted to leadership. They were thrown into the role because they were good at the previous one. Good engineers don't automatically become good leaders. We all know this. We promote them anyway.

It's Not a Tools Problem Either

The latest version of this mistake is the rush to adopt AI. MIT's 2025 "GenAI Divide" report, cited by CIO.com, found a 95% failure rate for enterprise generative AI pilot projects... those without measurable financial returns within six months.

Ninety-five percent.

Nick Kramer of SSA & Co. told CIO.com: "I have seen more projects fail because of poor change management than poor technology implementations."

A METR 2025 study found experienced developers were 19% slower when using AI coding tools. Not faster. Slower. Because typing was never the bottleneck. Understanding the system was. Understanding the people was.

Dan McKinley's classic essay "Choose Boring Technology" argued every business gets three "innovation tokens." Choosing shiny technology is a leadership decision disguised as a technical one. Most teams have already spent their tokens before breakfast.

What To Do About It

I'm not going to tell you to "communicate better" or "build a culture of trust." You've heard all of it. Here's what I'd do instead:

Stop promoting your best engineers into management without training. 70% of new managers didn't expect the role. Give them the skills before you give them the title. Stephanie Neal at DDI put it well: "We should stop using the term 'soft skills' to describe what are critical leadership skills."

When a project is late, ask "who decided the deadline?" before asking "who missed it?" In almost every case study above, the timeline was set by executives, not the people doing the work.

Listen to the engineers warning you. If three people on the team are raising the same concern, treat it like the fire alarm it is. Do not cover your ears.

Measure the real cost of leadership decisions. Knight Capital's $440 million loss started with a deadline decision. FoxMeyer's bankruptcy started with a timeline decision. The Airbus A380's $6 billion overrun started with an organizational decision.

The worst technical decision you'll make this year won't be about which database to pick, which framework to adopt, or whether to use AI. It will be about who decides, who listens, and who gets ignored.

And by the time you realize it was a leadership failure, you'll have already blamed the engineers.

Your Stress Isn't Yours Alone

Here's a question nobody wants to hear: Is your burnout making your team sick?

I've spent years talking to leaders about bad bosses. My research found 99.5% of survey respondents said they've had one or more types of bad bosses. But one specific type gets overlooked... the leader who doesn't mean to be bad at all.

The Burnout Spreader.

You're not yelling. You're not micromanaging. You're working hard, staying late, answering Slack messages at midnight. Every single one of those behaviours sends a signal your team reads loud and clear.

The Science Says You're Contagious

This isn't pop psychology. A peer-reviewed study published in BMC Public Health tracked manager stress and employee well-being in a large Danish municipality over several years. The findings were blunt: approximately 10% of a manager's stress increase transfers directly to their employees within one year.

Ten percent doesn't sound like much. Until you consider how it compounds. Your stress infects your direct reports. Their stress infects their peers. And the effect persists for a full year before it starts to fade. The researchers called managers "nerve centres" for entire job teams... and they weren't being complimentary.

I've seen this play out dozens of times in my own career. A VP goes through a rough quarter. They start running hotter... shorter emails, tighter deadlines, less patience in meetings. Within weeks, their whole department shifts tone. People stop taking risks. Creativity dries up. Sick days increase. Nobody connects it back to the VP's stress, because the VP never talked about it. They didn't need to. Their body language did the talking for them.

The transmission happens two ways. First, through direct emotional contagion... your facial expressions, your tone, your body language. Research from Wharton found less than 10% of emotional communication happens through words. Your team reads your stress before you open your mouth.

Second, through behavioral changes. Stressed managers withdraw. They stop planning ahead. They provide less support. They make reactive decisions instead of thoughtful ones. Your team notices all of it.

The Numbers Are Brutal

Let's look at leadership burnout right now.

56% of leaders experienced burnout in 2024, up from 52% in 2023. Not a trend... an acceleration.

73% of C-level executives work without adequate rest. 43% of organizations lost at least half their leadership teams to turnover.

On the employee side: 52% of workers reported burnout in 2024. Mid-level managers... the people caught between senior leadership and the front line... hit the highest rate at 54%.

What connects these numbers: burned-out leaders create burned-out teams. It flows downhill. The people in the middle get crushed from both directions.

Five Signs You're Spreading Burnout

Most burnout spreaders don't know they're doing it. Check yourself against these:

1. You Wear Exhaustion Like a Badge

"I was up until 2am finishing the report." If your team hears this regularly, they're learning one lesson: the boss doesn't value rest. You think you're showing dedication. They hear a mandate.

2. Your Calendar Is a Weapon

Back-to-back meetings from 8am to 6pm. No breaks. No white space. Your team sees this and concludes: if the boss has no margin, I definitely don't have permission for margin.

3. You Respond to Messages at All Hours

You send a Slack message at 11pm. "No need to respond now!" you write. It doesn't matter. The notification landed. The anxiety landed with it. Your team now knows you're watching... even when you say you're not.

4. You've Stopped Asking How People Are

When you're drowning, small talk feels expensive. So you skip the check-ins. Go straight to the task list. Your team reads this as: my well-being doesn't matter here.

5. Your Default Answer Is "Push Through"

Someone tells you they're struggling. Your instinct is to motivate: "We've all got a lot on our plates right now." Translation received: your pain doesn't count.

Why the Best Leaders Are the Worst Spreaders

Here's the painful irony. The leaders most at risk of spreading burnout are the ones who care the most.

Adam Grant's research on givers, takers, and matchers shows givers end up at both the top AND the bottom of success rankings. They give until there's nothing left. And because givers rarely ask for help when overwhelmed, they burn in silence... while their stress leaks out in every interaction.

Dr. Tomas Chamorro-Premuzic, writing for McKinsey, noted a related problem: low-EQ bosses create enormous stress for their teams. But high-EQ leaders face a different trap. They absorb everyone else's stress on top of their own. They become emotional sponges. And when they hit their limit, the fallout hits harder because nobody saw it coming.

The leader who "has it together" is often the one closest to breaking. And when they break, their team breaks with them.

I've watched it happen. A CTO I know prided himself on never complaining. He absorbed every escalation, shielded his team from politics, and carried the weight of three roles after layoffs. His team loved him. They also noticed he'd stopped laughing. Stopped eating lunch. Started cancelling one-on-ones. Within six months, three of his best engineers quit. They told HR they were "burned out." Nobody pointed the finger at the CTO, who was also burned out. The stress had spread like a virus, invisible until the damage showed.

What to Do About It

I'm not going to tell you to meditate or take a bubble bath. Structural problems need structural solutions.

Model Recovery, Not Grind

Take visible time off. Close your laptop at a reasonable hour. Talk about your weekend. When your team sees you rest, they get permission to rest too.

Build a Stress Dashboard for Yourself

You track revenue, velocity, and uptime. Track your own stress signals with the same discipline. Sleep quality. Exercise. How often you snap at small things. Make it data, not feelings.

Ask the Uncomfortable Question

In your next one-on-one, try this: "Is there anything about my behaviour making your job harder?" Then shut up and listen. Don't defend. Don't explain. Write it down. Act on it.

Create Buffer Zones

Block two hours a week with no meetings. Protect lunch hours for your team. Set explicit "no Slack" windows. These aren't perks... they're infrastructure.

Get Your Own Support

If you're a senior leader, find a coach, a mentor, or a peer group outside your organization. You need somewhere to process your stress before it leaks onto your team.

The Real Test

Here's the question I want you to sit with: If I surveyed your team anonymously and asked "Does your manager's stress level affect your own?"... what would they say?

If the answer makes you uncomfortable, good. Discomfort is the first step toward change.

Your burnout is your responsibility. But its impact on your team is your leadership problem. The same contagion effect works in reverse, too. Leaders who model calm, boundaries, and recovery create teams who do the same.

Kelly Swingler, who first posed this "burnout spreader" question, puts it sharply: your stress is contagious, and if you're not managing it, you're normalizing it for everyone around you.

Stop spreading burnout. Start spreading something worth catching.

I've been using AI tools daily for over a year now. And I've noticed something about the people who complain AI "doesn't work" for them.

Their prompts are awful.

Not in a technical sense. In a leadership sense. They give AI the same vague, context-free instructions they give their teams. And they get the same mediocre results in both cases.

Garbage In, Garbage Out Is a Leadership Problem

Computer scientists coined "garbage in, garbage out" decades ago. Feed a system bad data, get bad results. Simple enough.

But here's what nobody talks about: this principle applies to every single interaction you have as a leader. Every email. Every brief. Every one-to-one. Every strategy deck.

Gallup's 2024 data shows U.S. employee engagement dropped to 31% in 2024... a ten-year low. The element with the biggest decline? Clarity of expectations. Only 46% of employees say they know what's expected of them at work. Down from 56% in 2020.

Read those numbers again. More than half your team doesn't know what "good" looks like. And if you're a leader reading this, I'd bet money you think your team is the exception. They're not.

The Prompt Is the Mirror

When I write a prompt for Claude or ChatGPT, the output quality depends entirely on my input quality. If I type "write me something about leadership," I get bland corporate filler. If I provide context, constraints, examples, and a clear outcome... I get something useful.

The AI doesn't have a motivation problem. It doesn't need a pep talk. It responds to the quality of the instruction it receives.

Your team works the same way.

Ben Morton, a leadership coach and former military officer, puts it bluntly: garbage in, garbage out applies to both AI and leadership communication. If your prompt stinks, your leadership stinks too. The tool isn't the problem. The input is.

I've had this conversation with dozens of tech leaders over the years. They'll spend hours tweaking an AI prompt to get the perfect output, then fire off a two-sentence Slack message to their team and expect brilliance. The asymmetry is staggering.

The Perception Gap Is Enormous

Here's where it gets uncomfortable. Axios HQ's 2025 research found 80% of leaders believe their internal communications are "clear and engaging." Only 50% of employees agree.

Let me put this differently. Half your workforce thinks your communication is unclear or disengaging. And you have no idea.

It gets worse. 27% of leaders think their teams are "entirely aligned with business goals." Only 9% of employees say the same. Leaders are operating with a dangerously distorted view of their own effectiveness.

This is the same problem bad prompt writers have. They hit "send" and assume the AI understood what they meant. When the output is wrong, they blame the tool. Never the instruction.

69% of managers report feeling uncomfortable communicating with their staff, according to Harvard Business Review. Let it sink in. More than two-thirds of the people responsible for giving direction are uncomfortable doing so. No wonder the outputs are bad.

Five Bad Prompts and Their Leadership Equivalents

I see the same patterns in AI prompting and bad management. Here are five:

1. The Context-Free Command

Bad prompt: "Write a report."

Bad leadership: "Get me the numbers by Friday."

Which numbers? For whom? In what format? To support what decision? The leader who sends this email and gets frustrated by the result is the same person who types "write me a blog post" and wonders why AI produces garbage.

2. The Moving Target

Bad prompt: Sending five follow-up messages, each contradicting the last.

Bad leadership: Changing priorities every week with no explanation.

Research from High5 shows 28% of employees attribute missed deadlines directly to poor communication. When your instructions shift constantly, people stop trying to hit the target. They wait to be told again. And again.

3. The Assumption of Telepathy

Bad prompt: "Make it better."

Bad leadership: "This isn't what I wanted."

If you didn't specify what you wanted, you don't get to be disappointed. The best AI prompt engineers know you need to state your expected output format, tone, audience, and constraints. The best leaders know the same thing about delegation.

4. The Information Hoarder

Bad prompt: Withholding context and expecting AI to guess the situation.

Bad leadership: Keeping strategic context to yourself, then wondering why your team makes poor decisions.

74% of workers report feeling excluded from company information due to communication gaps. You're asking people to make good decisions with bad data.

5. The Feedback Void

Bad prompt: Never iterating. Never refining. One shot and done.

Bad leadership: Annual performance reviews as the only feedback mechanism.

The best AI users iterate. They review output, refine the prompt, try again. The best leaders do the same with their teams... continuous feedback, course correction, improvement loops. Not once a year. Every day.

How to Debug Your Leadership Communication

Here's the practical bit. If you want to test your own communication quality, try this exercise:

Step 1: Write your next team request as an AI prompt. Include the context, the desired outcome, the constraints, the format, and the audience. If you struggle to be this specific for AI, you're definitely not being this specific for humans.

Step 2: Read back your last five emails to your team. Would an AI produce useful output from these instructions? Or would it hallucinate because you gave it nothing to work with?

Step 3: Ask your team the Gallup question. "Do you know what's expected of you at work?" Don't assume you know the answer. Ask. Then sit with whatever they tell you.

Step 4: Close the feedback loop. After giving an instruction, check understanding. Not "do you understand?" (everyone says yes). Instead: "Walk me through how you'd approach this." Then listen.

Step 5: Iterate like a prompt engineer. When results disappoint, don't blame the person. Examine the instruction. Was it clear? Did it have enough context? Did you specify what success looked like? Refine and try again.

The $1.2 Trillion Prompt Problem

This isn't soft skills theory. SHRM estimates the U.S. economy loses $1.2 trillion annually to poor workplace communication. 63% of employees who leave cite poor leadership communication as a primary reason.

My research into bad bosses found 99.5% of survey respondents said they've had one or more types of bad boss. Communication is always in the top three complaints. Always.

We've spent decades building communication training programmes, leadership development courses, and feedback frameworks. None of it matters if the person sending the message doesn't recognise their message is the problem.

AI has given us a mirror. When you type a bad prompt and get a bad response, there's nobody else to blame. No team dynamics. No personality clashes. No "they should have known what I meant."

The machine did exactly what you asked. Nothing more, nothing less.

If your prompt stinks, your leadership does too. The fix starts with the same question in both cases: What do I need to say more clearly?

Next time you're about to fire off a vague instruction to your team, pause. Write it as if you were prompting AI. Add the context. Specify the output. Define success. Your team deserves at least as much clarity as a machine.

If you need to approve everything your team does, you don't have a team. You have hostages.

I've seen it dozens of times. A well-meaning engineering leader creates an approval process for "quality." Then another. Then another. Before long, nothing moves without a signature, a thumbs-up in Slack, or a 30-minute "alignment meeting." The team sits idle. The leader drowns. And everyone pretends this is normal.

It's not normal. It's a trust deficit wearing a process costume.

The Approval Queue From Hell

Here's a question worth asking yourself: how many decisions does your team make in a day without asking you first?

If the answer is "not many," you've built an approval bottleneck. Every feature, every deployment, every tiny design choice funnels through one brain. Yours. And your brain, no matter how good it is, has a fixed throughput.

The result? Your team waits. They check Slack for your green light. They context-switch while you're in your third meeting of the morning. They lose momentum, energy, and eventually... interest.

A 2024 study on micromanagement put it plainly: "A manager who needs to approve every detail causes a bottleneck, and makes tasks and projects take much longer than necessary." Micromanaged teams become risk-averse and dependent. They stop proposing ideas because they know ideas need approval, and approval takes forever, so why bother?

The Numbers Are Getting Worse

Gallup's 2025 State of the Global Workplace report dropped some numbers worth sitting with:

• Global employee engagement fell to 21% in 2024. The lowest since the pandemic.
• Only 28% of employees strongly agree their opinions count at work.
• 51% are actively looking for or monitoring new job openings.
• The cost? $438 billion in lost productivity globally.

And here's the number I keep coming back to: 70% of the variance in team engagement comes directly from the manager. Not the company. Not the perks. Not the mission statement on the wall. The manager.

When managers received coaching training, their own engagement rose by 22% and their teams' engagement by 18%. But when managers disengage... well, manager engagement dropped from 30% to 27% globally. For managers under 35, it fell 5 points. For female managers, 7 points.

The people responsible for 70% of engagement are themselves disengaged. No wonder teams feel held hostage.

Garry Ridge Figured This Out at WD-40

Garry Ridge led WD-40 as CEO for over 20 years. During his tenure, the company grew into a multi-billion dollar global brand. His engagement scores crushed industry averages. And his philosophy was refreshingly simple.

"People don't want to have to quack up the hierarchy every time they need to make a decision," Ridge told Forbes. His solution? Clear values, arranged in a hierarchy, with "doing the right thing" at the top.

Values replaced approvals. When your team knows what "the right thing" looks like, they don't need to ask permission. They act. They decide. They own the outcome.

Ridge didn't treat mistakes as failures. He called them "learning moments". No blame. No punishment theatre. The message was clear: if you made a decision in good faith and it didn't work out, we'll learn from it together. The result was confident, autonomous teams who solved problems instead of escalating them.

His book title says it all: Any Dumb Ass Can Do It. Leadership isn't genius. It's getting out of the way.

I wrote about the connection between trust and business results a few weeks ago. Ridge is living proof. Trust isn't fuzzy. It's operational. It scales. And it frees up the bottleneck... which is you.

The Bottleneck Is a Trust Deficit

Let's be honest about why leaders hold onto approvals. It's not about quality. It's about control. And control is often about fear.

Fear of looking bad if a report makes a wrong call. Fear of being blindsided by a decision you didn't sign off on. Fear of being irrelevant if your team doesn't need you for every choice.

Paula Davis, writing for Wharton, identifies lack of autonomy as one of six core drivers of chronic stress and disengagement. She breaks autonomy into six dimensions: schedule, task, decision-making, creative, career, and social. Most approval-obsessed leaders are throttling at least three of those.

The fix isn't complicated. Davis recommends a simple decision framework. Three categories:

1. Decisions your team owns outright. No check-in needed.
2. Decisions they make and notify you about. You hear about it, but after the fact.
3. Decisions requiring discussion first. Reserved for big, irreversible calls.

Most of the decisions your team asks you about right now? They belong in category one. You're holding onto them out of habit, not necessity.

What Letting Go Looks Like

I've been in engineering leadership for a long time. I've been on both sides of this. I've been the bottleneck. I've been stuck behind one. Neither is a good place.

Here's what works when you stop approving and start trusting:

Set the guardrails, not the route. Define what good looks like. Spell out the non-negotiables (security, data privacy, user impact). Then let your team figure out the how. If you've hired engineers, trust them to engineer.

Make "learning moments" the norm. Borrow from Ridge. When something goes wrong, skip the blame. Ask: what did we learn? What would we do differently? This builds a culture where people take smart risks instead of playing it safe to avoid your disapproval.

Kill the unnecessary approval steps. Audit your processes. Every PR review, every deployment gate, every design sign-off. Ask: does this exist because it adds value, or because someone once made a mistake and we built a process around it? If it's the latter, rip it out.

Check yourself. When you feel the urge to weigh in on something, pause. Ask: would this decision matter in a week? If not, let it go. Your job is to be useful on the decisions worth discussing, not present for every choice.

My research found 99.5% of survey respondents said they've had one or more types of bad bosses. The approval-obsessed leader is a variant of the bad boss. Not the most dramatic one. Not the screamer or the credit-stealer. But the quiet kind. The one who kills your momentum with a thousand small delays.

Your Team Is Waiting

Right now, someone on your team has an idea they haven't shared. Not because it's bad. Because the effort of getting it approved exceeds the energy they have left after their third status update of the week.

Someone else finished a task two hours ago but is waiting for your thumbs-up before moving on.

A third person is updating their CV. Not because they hate the work. Because they hate feeling like they need permission to do it.

Garry Ridge built a multi-billion dollar brand by letting people make decisions. Gallup's data shows engagement craters when managers hold too tight. And your own experience, if you're honest about it, tells you the same thing.

Stop being the bottleneck. Define the values. Set the guardrails. Then get out of the way.

Your team doesn't need a gatekeeper. They need a leader who trusts them enough to let them lead.

Here's something uncomfortable.

Right now, while you're deciding whether or not to "allow" AI in your organization, your team is already using it. At their desks. On their phones. On company devices. Most of them aren't telling you.

A global study cited by Business Insider found 57% of employees admit to hiding their AI usage from their employers. More than half the people using AI at work are keeping it from you.

Ivanti's 2025 Technology at Work Report, surveying over 6,000 office workers, found 1 in 3 employees who use generative AI keep it secret from their employer.

So if you're sitting in the executive suite convinced your "no AI" policy is working... you're not protected. You're the last to know.

Why Leaders Default to "No"

The instinct to ban things you don't understand is old as leadership itself. New tool shows up, risks aren't clear, lawyers get nervous, IT raises concerns, and the easiest decision is to say "not yet."

The problem is "not yet" became permanent for too many organizations. While leadership deliberated, employees stopped waiting.

They downloaded ChatGPT. Signed up for Copilot. Started using Gemini to draft emails, debug code, summarize reports, and do in an hour what used to take a day. All of it without asking, because they figured someone would say no.

Gartner found 67% of employees use AI or machine learning solutions without explicit organizational approval. Software AG research puts it higher: 75% of knowledge workers are already using AI, and many say they'd keep using it even if told to stop.

This isn't rebellion. It's adaptation. Your people are trying to do their jobs well. You've left them to figure it out alone.

The Ban Creates a Worse Problem

Banning AI doesn't eliminate the risk. It concentrates it and hides it from view.

When employees use unauthorized tools openly, there's at least a chance someone notices and starts a conversation about governance. When they use those same tools in secret, nobody knows. Data flows into public AI systems without oversight. Sensitive customer information gets pasted into ChatGPT prompts. Code gets reviewed by models trained on who-knows-what. You won't find out until something breaks.

63% of companies have no AI usage policy at all. Not a considered "no." No policy. A vacuum. And employees fill vacuums with their own judgment.

Some of it is fine. Much of it introduces legal, compliance, and data security risk the organization has no visibility into.

The ban didn't prevent the risk. It made the risk invisible.

What This Looks Like in Practice

Let me tell you what happens when organizations try to lock down AI.

The engineers use GitHub Copilot on personal devices and commit the output. The HR team uses ChatGPT to draft job descriptions because it's faster than the internal process. Customer success uses AI to summarize support tickets before escalating. Sales uses it to prep for calls.

All of it happening. None of it visible to leadership. All of it carrying risk the organization never approved, because the organization never bothered to create a policy.

The employees hiding their AI use aren't bad actors. Ivanti's research identified three common reasons people conceal it: they want a competitive edge, they fear looking like they're relying on a crutch, or they're worried about job security. They're not trying to cause problems. They're trying to survive in an organization not keeping pace with the tools available to them.

The Right Move

Your AI strategy shouldn't be "yes" or "no." It should be "here's how."

You don't need to become an AI expert overnight. You don't need to deploy an enterprise AI platform or hire a Head of AI or write a 50-page governance document. Start with something honest and simple.

Tell your team what's allowed. Pick a few approved tools. Put them in writing. If you're comfortable with people using ChatGPT for non-sensitive tasks, say so. If company data should never go into external AI systems, say so. Clear rules beat no rules every time.

Ask what people are already using. You'll be surprised. And you'll learn more in one honest team conversation than in six months of enforcement theater. Your people have already run the experiments. Let them tell you what works.

Build a reporting norm, not a blame culture. The fastest way to drive AI underground is to punish people for using it without permission. The fastest way to bring it into the open is to treat AI tool usage as a normal topic in team conversations.

Set the data boundaries clearly. This is where the real risk lives. It doesn't matter which AI tool someone uses, as long as they know which data categories are off limits. Personal data. Financial records. Customer information. Internal code. Define the lines and make them easy to remember.

Lead by example. If you're a leader who's never tried an AI tool, start. Not to become a power user, but to have an informed opinion. Your team deserves an informed opinion from you.

The Fear Underneath the Policy

I think the real fear isn't the technology. It's loss of control.

If your team is using AI to do more in less time... what does this mean for headcount conversations? If AI writes the first draft... whose work is it? If errors appear in AI-assisted output... where does accountability land?

These are real questions. They deserve real answers. But "no AI" doesn't answer them. It postpones them while the gap between your policy and your team's reality widens every month.

Ben Morton, a leadership coach who works with organizations on exactly these challenges, makes the point directly: if your only AI strategy is "don't," you're not making people safer. You're making yourself less informed.

There's also the reverse error worth naming. Outsourcing your thinking to AI and accepting its outputs without judgment is its own kind of leadership failure. The goal isn't to ban AI or surrender to it. It's to lead your organization through it with clear thinking and honest conversation.

I've written about the trust side of this on Step It Up HR before. When employees feel they have to hide what they're doing to get their work done, the organization has a problem going deeper than any tool or policy. It has a trust gap. And trust gaps don't close with bans.

The Leaders Getting This Right

The organizations doing AI well right now aren't the ones with the most sophisticated technology. They're the ones who started the conversation early. They named the risks, set the boundaries, and gave their teams permission to experiment inside a defined space.

Their employees aren't hiding anything. Their data governance is intact. Their risk exposure is known. And they're compounding productivity gains month over month while competitors are still debating whether to write a policy.

The gap between those two groups is going to widen, not close.

So here's the question: do you want to be the leader who found out what your team was doing with AI... or the one who shaped what they did with it?

The first one learns too late. The second one still has choices.

Someone on your team is absolutely brilliant. They ship clean code. They solve hard problems. They're the first person everyone goes to when things break at 2am.

So you promote them.

Three months later, the team is disengaged, delivery has slowed, and your best engineer is drowning in meetings they hate and performance reviews they don't know how to write.

You didn't reward someone. You sabotaged your business... twice.

We've Confused Reward With Role

Here's what most organisations do: when an engineer is outstanding, the instinct is to promote them into management. It feels like recognition. It feels fair. It's also completely wrong.

The skills required to be a brilliant individual contributor, things like deep technical knowledge, pattern-matching, and solo problem-solving, differ entirely from the skills required to manage people. Research from the Institute for Strategy and Complexity Management is direct about it: these skill sets are "diametrically opposed."

The best coders work with deterministic systems. Write the right code, get the right output. Management is the opposite. People are unpredictable. Progress is slow and hard to measure. The feedback loop is months long, not milliseconds.

When you force a technical mind into a human systems role without real preparation, something breaks. The engineer fails to transition. The team suffers under someone learning on the job. And the organisation loses the one thing it was counting on... the technical output.

It's not even a new observation. Laurence J. Peter described it in 1969 in The Peter Principle: "In a hierarchy, every employee tends to rise to their level of incompetence." We've known about this for over fifty years. We're still doing it.

What Google Spent Years Proving

Google ran a years-long internal study called Project Oxygen to understand what makes managers effective. They identified eight key behaviours.

Technical expertise ranked last.

Dead last.

The top two behaviours were being a good coach and empowering the team rather than micromanaging. These are skills built through practice, feedback, and people experience... not through being the best in code review.

There is also the question of whether we're good at predicting who will make a great manager in the first place. Economist Daniel Kahneman studied this directly with the Israeli military, testing soldiers over two weeks to predict future leadership performance. His conclusion: the forecasts were "largely useless." Google's own internal research found zero correlation between their standard evaluations and long-term leadership performance.

Yet here we are, still promoting on the basis of the skill scoring lowest and relying on intuition research tells us doesn't work.

The Numbers Are Ugly

I've spent years managing engineering teams and mentoring individual contributors into leadership roles at companies like Curve. What I've seen matches what the data says.

According to Gallup research, 82% of companies pick the wrong manager every time they fill a management role. Not occasionally. Every time. Only one in ten people has high natural talent for management.

The CEB puts the new manager failure rate at 60% within the first twelve months. For individual contributor-to-manager transitions specifically, humanr.ai estimates the failure rate between 40 and 50% within eighteen months.

My own research into bad management found 99.5% of survey respondents said they've experienced one or more types of bad boss at some point in their career. Not most. Not some. Near enough everyone. Many of those bad bosses were, once, perfectly good engineers promoted beyond their preparation.

Gallup puts the cost at $360 billion per year in the US alone, in lost productivity and turnover. A single bad manager placement generates up to $2 million in losses when you factor in replacement costs and lost product velocity.

You're Paying Twice

Here is what most organisations don't track: when you promote your best engineer into management and it doesn't work, you pay twice.

First, you lose a high-performing individual contributor. An engineer spending 80% of their time on management tasks is no longer doing engineering. The technical output you relied on is gone.

Second, you now have a struggling manager. The team loses direction and confidence. Delivery slows. Good people start looking elsewhere.

Justin Leader, CEO of Human Renaissance, put it plainly: "You traded a known asset (high-velocity code output) for an unknown liability (untested management capability)."

There's also a third cost, one even less visible. Research published in Management Science in 2025 by Brittany Bond at Cornell found high performers passed over for recognition are at least 34% more likely to leave voluntarily within eighteen months. So if you don't promote your best engineer, they leave. If you promote them badly, both they and the team suffer.

This is the trap. Organisations walk into it every single time.

What Works in Practice

At Curve, I mentored seven engineers into leadership roles. Not all of them went into management. The distinction mattered enormously.

The engineers who became great managers weren't the most technically brilliant. They were the ones already curious about people, asking questions in one-to-ones, noticing when teammates were struggling, talking about team delivery as something shared rather than their own output.

The technically brilliant engineers who stayed as individual contributors didn't get less recognition. They got senior individual contributor roles with real seniority, real pay, and real influence, without anyone forcing them into work they'd hate doing.

I've written about the patterns behind great and bad leadership in Bad Bosses Ruin Lives, and the same structural failure shows up repeatedly: organisations promote on technical output, skip leadership development, and then wonder why engagement drops and good people leave.

The answer isn't to stop promoting engineers. The answer is to build two tracks.

Two Tracks, Not One Ladder

The traditional career ladder looks like this: junior engineer, engineer, senior engineer, tech lead, manager, senior manager. Leadership is the only path upward.

This is the design flaw.

A principal engineer should have the same seniority, pay, and organisational authority as an engineering manager. The path to the top of your organisation should not require anyone to stop doing the work they're brilliant at.

Companies doing this well include Google (with its Staff, Principal, Distinguished, and Fellow individual contributor tracks), Spotify, and a handful of scale-ups I've watched closely. They recognised the core problem: if the only way up is through management, you keep promoting the wrong people.

Build a technical leadership track. Invest in it properly. Pay it properly. Respect it properly. Make it a genuine path to the top, not a consolation prize for someone who didn't want to manage people.

Three things to do now:

• Audit your current ladder. Is management the only route to senior seniority and senior pay? If it is, fix the ladder first.
• Ask the question directly. Before promoting anyone into management, ask them: do you want to manage people, or do you want this title and salary? Those are different things. The conversation is worth having.
• Invest in preparation. If someone does want to move into management, don't throw them in cold. Coaching, mentoring, structured transition time... the failure rate drops significantly when organisations treat first-time management as a skill to develop, not a reward to hand out.

The Question Worth Asking

Before your next senior promotion, ask yourself: does this person want to manage people, or do they want the salary and the title?

Those are not the same thing. The answer to the question is worth more than all their code review history combined.

The best engineering organisations I've seen don't promote their best engineers to get them out of the way. They build systems where brilliant engineers stay brilliant, and where the people who want to lead people get the development first, not the job title.

If you want to dig into building the kind of engineering culture where both tracks thrive, Step It Up HR is where I write about exactly this. The leadership patterns I cover there apply whether you're in HR, engineering, or somewhere between the two.

Here's a situation I've seen play out more times than I care to count. A senior leader calls a status update meeting for something worth a Slack message. The Gen Z employees on the team attend, say nothing, and immediately go back to doing what they were already doing. Nothing changes. The leader thinks the meeting went well. The team thinks the leader is out of touch.

They're both right.

The Generational Shift Nobody Prepared For

In 2024, Gen Z overtook Baby Boomers in the full-time US workforce. Not news anymore... but the implications still haven't landed for most organisations.

Gen Z didn't grow up adopting technology. They grew up inside it. Smartphones arrived before they did. Google was always a verb. The internet isn't a tool they picked up somewhere along the way. It's the water they swim in.

Millennials are different. Many are genuinely good at technology... but they remember the transition. They learned HTML because it was interesting. They adopted social media because everyone else did. They remember when email was modern.

Gen Z doesn't remember the transition. There was no transition for them.

The difference isn't a personality quirk. It changes how they expect to work, how they process information, how they give and receive feedback, and what a competent leader looks like to them.

The Workplace They Walk Into

The World Economic Forum reported in early 2025: Gen Z expects tech tools at work to match the ease of use of social media apps. Not "decent tools." The same ease. The same responsiveness. The same immediacy.

When a Gen Z employee encounters a clunky internal tool unchanged since 2015, they notice. When handed a printed form, they notice. When told to send an email rather than use the messaging system already in place, they notice. None of these things feel "traditional" to them. They feel broken.

I've seen leaders shrug this off as entitlement. It isn't. It's like complaining a new hire expects the company WiFi to work. Digital fluency isn't a preference for Gen Z. It's the starting point.

The wider challenge is the scale of the shift. Gen Z's entry into the workforce isn't a trickle. The generation born between 1996 and 2010 now outnumbers Baby Boomers in full-time employment. These aren't edge cases in your team any more. They're likely a significant portion of it.

The AI Dividing Line

Here's where the gap stops being cultural and starts being a competitive problem.

According to Deloitte's 2025 Gen Z and Millennial Survey, 74% of Gen Zs believe generative AI will impact the way they work within the next year. They're not worried about it. They're planning for it. A large portion are already using AI tools as part of their daily routine.

Meanwhile, Nash Squared's 2025 Digital Leadership Report... the largest and longest-running survey of technology leadership in the world... found AI jumped from the 6th most scarce technology skill to number one in 18 months. The steepest jump recorded in the report's 26-year history.

Read those two things together. Your Gen Z team members are actively integrating AI into their work, treating it as a natural extension of how they operate. And your senior leaders are scrambling to hire anyone who understands it at all.

I've sat in meetings where a team member quietly used an AI tool to summarise the previous hour of discussion, handed it to the leader, and watched the leader act as though they'd performed a minor miracle. The team member had been doing this routinely for months. The leader had no idea.

The analog brain, in action.

What Your Team Sees

There's a brutal clarity to how Gen Z evaluates leadership. They grew up with instant feedback loops. They know within seconds whether an app works well or badly. They apply the same lens to the people managing them.

When a leader calls a meeting for something belonging in a Slack thread, Gen Z employees don't see "thoroughness." They see inefficiency. When a leader forwards an email chain rather than summarising the key point, they don't see "transparency." They see noise. When a leader asks for a status report without checking the project management tool where everything is already tracked... they don't see oversight. They see disconnection.

None of this is malicious. It's the gap between two different minds organising information differently.

The consequence is measurable. Only 12% of companies report confidence in the strength of their leadership bench, according to research published in late 2024. And Gen Z is increasingly reluctant to step into management roles they see aren't working. They're watching their managers... and opting out.

What Real Catching Up Looks Like

Catching up isn't about downloading TikTok or dropping Gen Z slang into team meetings. Nobody's impressed. Nobody reads it as authentic.

Catching up means changing how you think about work, not which tools you've downloaded this week.

Default to async. Before calling a meeting, ask whether a message would do. If yes, send the message. Your Gen Z team already knows the answer is usually yes. Defaulting to synchronous communication when you don't need to signals you haven't thought it through.

Get genuinely comfortable with AI tools. Not "aware of." Not "open to." Comfortable. Use them yourself. See what they do and don't do well. Your team already has an opinion. You should have one too, formed through use, not through reading articles about use.

Trust the systems you've invested in. If you've got a project management tool, a shared doc, a team dashboard... use them as the source of truth. Don't ask people to separately report the thing already in the system. It's friction, not oversight. It signals you don't trust the tools, which signals you don't trust the team.

Shorten your feedback loops. Gen Z didn't grow up on annual reviews. They grew up on immediate, iterative feedback. If you've something to say about someone's work, say it close to the work. Waiting six months for a formal appraisal doesn't feel thorough to them. It feels cruel.

Be honest about what you don't know. Gen Z has finely-tuned detectors for inauthenticity. If you're still figuring out where AI fits in your workflow, say so. They'll respect genuine uncertainty far more than a confident performance of knowledge you haven't got.

Ask, don't assume. One of the most effective moves with a Gen Z team: ask "what's working well for you and what isn't?" Not as a formality. With the genuine intention of changing something when you hear the answer. They've got a dozen ideas and are waiting to see whether sharing them will lead anywhere.

The Question Worth Sitting With

If a 24-year-old joined your team next week, what would they see? A leader who thinks digitally, moves at digital speed, uses digital tools as naturally as breathing... someone they'd want to learn from?

Or someone they'd have to manage around?

Not a comfortable question. An honest one. And honest is exactly what your Gen Z team is expecting from you.

What's one thing you're changing this month to close the gap?

Everyone is asking the wrong question about AI agents.

"Which tool should we use?" "Should we build or buy?" "What's the ROI model?"

These are fine questions. They're not the right ones.

The right question is: do your people trust you enough to go through a messy learning curve with you?

If the answer is no, it doesn't matter which AI agent you pick. It won't stick.

The Number Nobody Talks About

The 2026 State of AI Agents Report asked enterprise leaders about their biggest scaling challenges. The headline results:

• 46% cite integration with existing systems
• 42% point to data access and quality
• 39% cite change management needs

Technology gets the top two spots, and everybody nods along. Makes sense. Integration is hard. Data is messy.

But 39%, the change management figure,deserves more attention than it gets.

Integration and data problems are solvable with engineers and budget. Change management is a leadership problem. You don't fix it with a vendor contract.

And it understates the real scale of the issue. Employee resistance doesn't show up cleanly in survey data about "challenges." It shows up as AI licenses nobody opens, tools deployed once and abandoned, pilots ending before they reach production.

Your Employees Are Using AI While Fearing It

According to HBR's February 2026 analysis, 86% of employees believe AI will improve their work. Yet 80% carry what the researchers call "AI angst": significant personal concerns about what AI means for them.

People are using the tools and fearing them simultaneously.

What does this produce? Compliance, not engagement. Employees going through the motions because a manager mandated it, not because they see genuine value. Compliance-driven adoption delivers none of the ROI you're projecting.

The same research found 88% of companies report regular AI use but struggle to convert it into measurable ROI. The tools are deployed. The results aren't there.

The gap between deployment and results? Leadership owns it.

Why People Resist

Kyndryl's research found 45% of CEOs say their employees are reluctant or outright hostile toward AI adoption. When researchers dug into why people resist organizational change, the top reason wasn't fear of technology:

• 41% said lack of trust in leadership
• 39% said they didn't understand why the change was happening
• 38% said fear of the unknown
• 27% worried about changes to their job roles

Notice what's not on the list: "the technology was too complicated."

People follow leaders they trust into uncomfortable territory. They don't follow mandates. If your team doesn't know why you're introducing AI agents, or doesn't believe you're being straight with them about what it means for their roles, no amount of tooling investment will move the needle.

What Bad AI Leadership Looks Like

I've watched this pattern play out in technology teams for years. The failure modes are predictable.

Mandate without explanation. "We're moving to AI agents by Q2." No why. No explanation of what changes. No space for questions. The team nods and goes back to the old way whenever nobody's watching.

Measure adoption by licenses. 200 Copilot seats purchased. 40% active users. Leadership declares success. The active 40% are using autocomplete on emails. The vision of transformed workflows is nowhere in sight.

Don't use the tools yourself. If you're asking your team to rethink how they work with AI, and you haven't done it yourself, they know. You lose credibility the moment someone asks you a specific question about your own workflow and you deflect.

Treat mistakes as failures. AI agents fail. They hallucinate. They miss context. They produce outputs needing heavy editing. If the first time someone on your team uses an agent and it goes wrong they get embarrassed in a meeting... they won't experiment again. Experimentation shuts down. The learning curve never gets climbed.

What Good AI Leadership Looks Like

The leaders getting real value from AI agents right now are doing something different.

They're building trust before deploying tools. Being honest about what AI adoption means for roles and workload. Admitting they don't have all the answers. Creating enough psychological safety for people to say "this didn't work, here's what I tried."

They're explaining the why. Not "because AI is the future"... not a reason. A reason sounds like: "Our support queue takes 4 hours to triage manually. An agent does it in 20 minutes, and I want our team working on the hard cases needing real human judgment."

They're modeling the behavior. The best AI adopters I know spend time each week going through what went wrong with their agents. They share failures openly. They treat it like a skill under construction, not a switch they've flipped.

They're not measuring seat licenses. They're measuring workflows changed, hours reclaimed, problems solved. And they're measuring the feedback loop: are people learning? Are they getting better?

The Feedback Loop Problem

Here's what I keep coming back to, from my work on Step It Up HR and the BAT framework: AI agent adoption is a team performance problem. And team performance lives or dies on feedback culture.

A team with strong feedback habits (where people speak up when something isn't working, where managers listen and adjust, where failure is treated as data) adapts to new tools faster. They iterate. They share what works. They build collective capability instead of isolated pockets of competence.

A team where feedback is dangerous, or where managers take criticism personally, freezes when change happens. Problems with AI tools don't get surfaced. Adoption stalls.

My research found 99.5% of survey respondents have experienced one or more types of bad bosses. The behaviors defining a bad boss: avoiding hard conversations, managing by fear, taking credit and assigning blame... are precisely the behaviors making AI adoption fail.

The Technology Is Ready

To be clear: the technology works. The 2026 State of AI Agents Report notes 80% of organizations already report measurable economic impact from AI agents. 88% expect ROI to continue growing. The tools have moved beyond proof-of-concept. The era of "let's run a pilot" is ending.

The question isn't whether AI agents deliver value. They do. The question is whether your organization is set up to capture it, and it's a leadership and culture question, not a technology one.

The companies pulling ahead on AI adoption right now aren't the ones with the best tooling. They're the ones with the strongest feedback cultures. The ones where people feel safe saying "I tried this and it failed, here's what I learned."

Cisco's CHRO Kelly Jones put it directly: "Soft Skills are the New Hard Skills." Emotional intelligence, clear communication, and the ability to build trust aren't nice-to-haves when scaling AI. They're the foundation everything else rests on.

The Question Worth Asking

Before you decide which AI agent platform to standardize on, ask yourself this:

Does my team trust me enough to look stupid in front of me while they learn something new?

If yes, almost any tool will work. If no, the tool doesn't matter.

AI adoption isn't a technology problem. It's a leadership problem wearing technology's clothes. The sooner your organization figures it out, the sooner you start getting real results.

What does your team's feedback culture look like? Is it ready for the pace AI requires?

Every engineering leader has sat through some version of the "build trust with your team" talk. It sounds like a workshop topic. It sounds soft. It sounds like the thing you say and then move on from so you get to the real stuff... velocity, deployment frequency, technical debt.

The data disagrees. Trust IS the real stuff.

Google Spent Two Years Looking for the Secret to Great Teams

Starting in 2012, Google's Project Aristotle studied 180 of their own teams (115 engineering, 65 sales). They examined 250 different attributes over two years. They expected to find the obvious answer: hire brilliant people, give them a strong manager, and the team performs.

Wrong.

The #1 factor for high-performing teams was psychological safety. Not raw talent. Not co-location (whether people work in the same building turned out to be irrelevant). Not seniority. Not individual performance ratings. The factor mattering most was whether people felt safe enough to speak up, take risks, and admit mistakes without fear of punishment.

Google's researchers put it plainly: "Even the extremely smart, high-powered employees at Google needed a psychologically safe work environment to contribute the talents they had to offer."

Psychological safety is trust. Trust in the team. Trust in the leader. Trust in the system.

DORA Measured It at Scale

The DevOps Research and Assessment team has been studying software delivery for over a decade. Their 2024 State of DevOps report drew on responses from more than 39,000 professionals globally.

Their finding is consistent year after year: generative culture (high cooperation, shared risk, blameless failure inquiry, active cross-boundary collaboration) directly predicts software delivery performance. Organizations with the highest trust ship faster, fail less often, and recover faster when things go wrong.

The numbers are telling. Elite-performing teams spend 50% of their time on new, high-value work. Low-performing teams spend only 30% there. Elite performers spend 10% of their time fixing user-identified defects. Low performers spend 20%.

Not a skill gap. Not a tooling gap. An environment gap. Low-trust teams lose time to rework, defect remediation, and second-guessing. High-trust teams spend the same time building.

Low Trust Breaks Your Ability to See Reality

This is the part nobody talks about enough, and it is the insight changing how I think about the whole problem.

John Cutler, in his newsletter piece "Trust lets you observe reality", makes a point worth sitting with: when trust is low, organizations lose their ability to understand what is genuinely wrong with them. They reach for oversimplified metrics. Those metrics become targets. And when a measure becomes a target, it ceases to be a good measure. Goodhart's Law, applied to teams.

In a low-trust environment:

• Engineers optimize for what is measured, not what matters
• Problems get hidden until they are too big to ignore
• Post-mortems quietly blame individuals rather than systems
• Your dashboards look fine right up until they do not

Research from Adaptavist found 74% of knowledge workers do not consistently understand the "why" behind their workplace tasks. Of those, 45% report reduced motivation. In a low-trust engineering organization, nobody explains the reasoning behind decisions. The "why" disappears. People stop caring. Velocity drops. You measure velocity harder. Trust drops further.

The cycle feeds itself.

What Low Trust Looks Like Day to Day

You might not recognize your team in phrases like "low trust." Here is what it looks like on the ground.

Code reviews go adversarial. Engineers write defensive comments. Junior developers stop asking questions. PRs sit for days because nobody wants to make the first move.

Incidents get vague write-ups. "A deployment caused an outage." Not "the deployment process allowed this error through." Not "we need to change our rollout strategy." The post-mortem exists to satisfy a process, not to learn anything.

Technical debt accumulates without discussion. Engineers know it is there. They do not raise it because the last time someone raised it, they were told to "focus on features." So the debt grows. Eventually it eats a sprint.

Good people leave. They cite "better opportunities." What they mean is: I trust my next employer more.

What High Trust Looks Like

High-trust engineering teams are not teams without problems. They are teams where problems surface fast.

Engineers speak up early when something is going wrong. Post-mortems examine systems, not people. Technical debt gets named and prioritized. Deployment frequency is high not because people are reckless, but because they trust the safety net... and trust each other to fix things when they break.

DORA's research describes this through the Westrum model. Generative organizations are characterized by high cooperation, shared risks, and active encouragement of cross-silo collaboration. Compare to pathological cultures (information hoarded, failure punished, cross-team collaboration discouraged) and the performance gap is not marginal. It is the difference between elite and low-performing.

Where to Start

I am not going to tell you to run a team retrospective on trust. A trust workshop gives you a nice sticky-note session and zero lasting change.

Here is what moves the needle.

Fix the post-mortem first. If your incident reviews end with blame (explicit or implicit), nothing else you do will stick. Make it institutional: the goal of a post-mortem is to find the system failure, not the human failure. When your people see you mean it, the culture begins to shift.

Explain the reasoning behind decisions. Every time a major architectural, process, or product decision gets made, write one paragraph explaining why. Not a press release. A real explanation. 74% of knowledge workers lack this context, and it drains motivation at a scale most leaders do not notice.

Make safety explicit in code review. A comment asking a question beats a comment passing judgment every time. "I'm thinking about X... what was your reasoning for Y?" is different from "this is wrong." It models the behavior you need from your whole team.

Admit your own failures publicly. In front of your team. When you make a call and it does not work out, name it. Describe what you would do differently. Not weakness. It is the foundation of a culture where your engineers do the same.

Stop measuring things nobody understands. If your team does not know what a metric measures or why it matters, drop it. Metrics without context become weapons in low-trust environments. Someone gets blamed for them eventually.

---

Trust is not a workshop. It is not a vibe. It is the infrastructure on which your engineering performance is built.

Google measured it. DORA measured it across 39,000 practitioners and a decade of research. The teams shipping the most, with the fewest defects, recovering the fastest... those teams built trust first.

What would it cost you to calculate the trust deficit on your own team?

Every week another company announces it's deploying AI agents. Thousands of them. Automating workflows, writing code, managing tickets, processing invoices. The demos look slick. The press releases are breathless.

Then six months later, the project gets quietly shelved.

I've watched this pattern play out across tech teams for thirty years. The tool changes. The failure mode doesn't. Right now, the failure mode is AI agents, and it's costing companies millions.

The data makes this clear. Gartner predicts 40% of enterprise applications will embed task-specific AI agents by end of 2026, up from less than 5% today. An enormous wave of adoption. And Gartner also predicts 40% of those agentic AI projects will be canceled by end of 2027.

Do the math. Half the deployments, gone.

The Stat Nobody Wants to Hear

The 2026 State of AI Agents report from Anthropic, drawing on 500+ technical leaders, found the top three barriers to AI agent adoption are:

1. Integration with existing systems: 46%
2. Data access and quality: 42%
3. Change management: 39%

Number three. Change management.

Not a technology problem. A leadership problem.

Here's what stings: integration challenges and data quality are engineering problems. Throw people and time at them and they get better. Change management doesn't work like this. You won't sprint your way through a culture afraid of AI, or a team terrified of what it means for their jobs. There's no hotfix for fear.

Gartner found 78% of CHROs agree workflows and roles must fundamentally change to get value from AI. 78%. And yet most of the conversation is still about which agent framework to pick, not how to bring people along.

Three Ways Leaders Blow This

I've seen this fail in three predictable ways.

1. Treating AI as a Tool Upgrade, Not a Transformation

The mindset goes like this: "We got new software. People will adapt." It works fine for a new CRM or a different ticketing system. It doesn't work for AI agents, because AI agents change how people think about their own role.

When an AI agent handles ticket triage, the person who used to do it has to answer a question: what's my job now? If leadership doesn't answer first... clearly, honestly, with a real path forward... the team answers it themselves. Their answer is usually: "I'm being replaced."

The result isn't resistance. It's sabotage. Passive sabotage, the kind where nobody overtly objects. They simply don't use the thing.

I've seen this play out with a team deploying an AI coding assistant. The rollout was technically perfect. Licenses provisioned, training documentation ready, Slack channels created. What nobody did was sit with the senior engineers and ask how they felt about a tool writing code at the speed they write documentation. Three weeks in, adoption was 8%. The tool sat unused, not because it didn't work, but because nobody answered the question underneath: "Does this mean I'm less valuable?"

2. Skipping the Fear Conversation

I've sat in AI rollout sessions where the leader went straight to demos and ROI projections. Not one word about fear. Not one acknowledgment of how unsettling this shift is, or how some roles might change.

Infosys and MIT Technology Review research found 83% of business leaders report psychological safety has a measurable impact on AI adoption. The number-one predictor of whether your team uses AI isn't the quality of the tool. It's whether they feel safe enough to try it, fail at it, and talk about what's not working.

Skip the fear conversation and you pay for it in adoption. Every time.

3. Confusing Announcement with Alignment

Leadership announces the AI initiative. Sends the all-hands deck. Does a lunch-and-learn, perhaps. Then wonders why adoption sits at 12%.

Announcement is not alignment. Alignment is when your team understands why you're doing this, what's in it for them, and what the new normal looks like. Getting there takes conversations, not slides. It takes leaders willing to say "I don't have all the answers yet" without losing credibility.

The leaders who do this well frame AI adoption as something happening with the team, not to them.

What Good Looks Like

I've seen this work too. It looks nothing like the failure pattern.

One CTO I know did something simple before rolling out an AI agent platform. She spent two weeks in one-on-ones with every senior individual contributor on her team. She didn't pitch the initiative. She asked: what would need to be true for you to be excited about this? She answered every concern in writing, shared it with the team, and started the rollout with the people who were most nervous first. Adoption hit 70% in the first month. The technology was identical to what three other teams in the company had failed with.

The leaders who succeed at AI adoption do a few things consistently.

They answer the fear before it's asked. In the first meeting, they acknowledge directly this changes things. They name the fear. They don't pretend AI is consequence-free, and their credibility goes up because of it.

They start with small wins the team sees first. Not the grand enterprise vision. One use case, done well, with real feedback from the people using it. The first win builds trust in the technology and in leadership's judgment.

They redefine roles before people redefine them in their heads. If an AI agent is taking over part of someone's job, the conversation about what comes next happens before the agent goes live. Not after adoption fails and everyone points fingers.

They stay curious. The best AI-adopting leaders ask their teams what the AI is getting wrong. They treat feedback as signal, not complaint. They share what they're learning. They make it safe to say "this isn't working for me" on week two, not month six when the project is already circling the drain.

The Real Cost of Getting It Wrong

Gartner's cancellation prediction... 40% of agentic AI projects gone by end of 2027... isn't a tech failure number. Most of those projects will be canceled because nobody built the human infrastructure to support them.

An empty terminal in a dark office is expensive. Not only the vendor contract and the implementation hours. The cost is also the cynicism your team carries into the next initiative. "Remember when they tried AI agents? Went nowhere." Once you've burned trust, the next project starts at a disadvantage.

We talk about AI ROI constantly. We don't talk enough about the cost of the failed attempt: demoralized engineers, a leadership credibility gap, teams who learned not to get their hopes up.

Those things don't show up on a project postmortem. They show up six months later when you're trying to run your next transformation and nobody believes you.

Where To Start

If you're leading an AI adoption effort right now, start here.

Before you pick a framework, before you write a scope document, sit with the people who will be affected and ask: what worries you about this? Don't defend the initiative. Don't correct their concerns. Listen. Then go answer those concerns in your implementation plan.

The technology is ready. It was never the limiting factor.

Are you?

Tech loves this story about itself. The best engineers rise. The smartest ideas win. Your code speaks for you. Pull requests are your CV.

I believed this for years. The numbers changed my mind.

The research doesn't just challenge the meritocracy story in tech. It shows the story itself makes things worse.

The Paradox You Need to Know About

In 2010, researchers Emilio Castilla (MIT Sloan) and Stephen Benard published findings in the Administrative Science Quarterly worth sitting with.

They ran controlled experiments with 445 MBA students reviewing employee performance profiles. When managers were told their organization valued meritocracy, male employees received average bonuses of $418.80. Equally performing female employees received $372.40.

A $46 gap. Identical performance. Different outcomes.

When the meritocracy label was removed, the gap reversed. Women averaged more.

The researchers named this the "paradox of meritocracy." When people believe the system is fair, they stop scrutinizing their own decisions. They give themselves permission to follow gut instinct, because of course they work in a meritocracy.

Harvard's Digital Data Design Institute confirmed the pattern: consulting firms achieved gender balance at entry level over 20 years ago. Less than 20% of managing directors and partners are women today. Two decades of full pipeline. Same leadership profile at the top.

What the Numbers Say About Tech

Pew Research surveyed over 2,300 STEM workers in 2017. The findings are uncomfortable.

74% of women in computer jobs reported experiencing discrimination because of their gender. Among men in the same roles: 16%.

In 1990, women held 32% of computer occupation roles. By 2022, the number had dropped to 24%, per US Department of Labor data.

50% of women leave tech careers by age 35. In other industries, the figure is 20%.

For every 100 men promoted to manager, 81 women advance. For Black women, the number drops to 54.

McKinsey estimates full gender parity in tech leadership is 50 years away at current trajectory.

These aren't the numbers of a meritocracy. They're the numbers of a system where the meritocracy label does heavy lifting to prevent anyone from looking at outcomes.

What Actually Rises to the Top

Dr. Tomas Chamorro-Premuzic, professor of business psychology at Columbia University and University College London, spent years researching why leaders rise. His conclusion: we select for confidence, not competence.

We mistake charisma for capability. We reward people performing certainty. We penalize those expressing doubt or seeking input. The traits making someone look like a leader, loudness, self-promotion, projecting unearned authority, correlate weakly with the traits making someone an effective one.

Tech amplifies this. The heroic lone engineer working all weekend. The founder who builds the deck without asking anyone. The architect whose vision is always clear and never needs other perspectives. These figures get celebrated. The collaborative, self-aware engineer building trust across teams? Less often promoted. Wrong template.

The McKinsey research Chamorro-Premuzic contributed to found the traits correlating with effective leadership are empathy, self-awareness, integrity, and humility. None of these are the traits we instinctively reach for in hiring or promotion discussions.

My own research found 99.5% of survey respondents have had one or more types of bad bosses. The meritocracy myth is part of how they kept getting promoted.

The Language Keeps Bias Invisible

"Cultural fit." "Executive presence." "Gravitas." "We need someone who will own the room."

These phrases are everywhere in tech hiring and promotion. They sound like merit. They aren't. They're subjective descriptors without measurable criteria, creating space for bias to operate without accountability.

When "cultural fit" means someone whose communication style, educational background, and professional journey feels familiar to the people making the decision, you're building a system replicating the existing leadership. Not selecting for capability.

Carol Edwards at Diversity Dashboard makes this plain: "Merit is rarely assessed in isolation. It is filtered through perception, expectation, familiarity, and networks."

Advancement requires more than strong results. It requires self-promotion, strategic networking, and visible confidence. These behaviors show up unevenly across demographic groups, not because of inherent differences, but because of decades of structural signals about who is expected to display them.

The AI Angle

There's a new dimension worth noting. AI is increasingly used in hiring and performance evaluation. When companies use AI to select leaders, researchers found the algorithms nominate men 80% of the time and women 20%.

The AI isn't biased. The training data is. The AI learned from decades of promotion decisions and replicated them. If your underlying process is biased and you add AI on top, you aren't removing bias. You're systematizing it.

The meritocracy story gets a technological veneer and becomes even harder to challenge.

What to Do About It

I'm not writing this to assign blame. I'm writing it because the meritocracy story is preventing tech from building better systems.

If you believe your process is fair, you won't audit it. If you believe the best people rise, you won't question why your leadership team looks the same decade after decade. The belief itself is the problem.

Castilla and Benard's proposed fix is practical: reduce managerial discretion, increase transparency, define competency criteria clearly and measurably. Run regular audits on outcomes by demographic. If the numbers show a gap, the "meritocracy" label is hiding something worth knowing.

Four things worth pushing on in any tech organization:

Audit promotion outcomes. Not intentions. Not process descriptions. Actual outcomes, by demographic. The gap is usually there when you look.

Kill subjective criteria. If you cannot measure it, and two different managers would not consistently apply it the same way, it isn't a selection criterion. It's a preference.

Watch who gets high-visibility work. Research consistently shows high-visibility assignments show up unevenly. The people receiving them develop faster and get promoted more often. This is where much of the gap develops, long before any formal promotion decision.

Stop treating confidence as competence. Competent people often express uncertainty. Overconfident people rarely do. Structuring hiring and promotion to reward certainty will consistently select for confidence over capability.

The Story Is the Problem

Tech will keep believing in meritocracy because it's a flattering story. It tells people at the top they earned it. It tells people passed over they simply weren't good enough.

But when a system produces consistently skewed outcomes despite claiming to reward merit, the story needs challenging. Not to make anyone feel guilty. To build systems doing what the story promises.

The data is clear. The outcomes are measurable.

The question is whether you're willing to look at them.

What would your organization find if it audited who rises, and why?

There's a belief floating around leadership circles. It goes something like: "Why invest in training? They'll leave and take the knowledge somewhere else."

I've heard it from CTOs. I've heard it from engineering managers. I've thought it myself.

But a nastier reality hides behind the fear... one nobody talks about at board meetings or quarterly reviews.

Trained people leaving isn't the real cost. Untrained people staying is.

The People Who Stay, Broken

Gallup's research on what they call "The Great Detachment" puts it in hard numbers. Only 30% of employees feel connected to their company's mission, down from 38% in 2021. And 55% of employees don't know what's expected of them at work.

These aren't people who've checked out and handed in their notice. They're still showing up. Still collecting their salary. Still attending standups, grinding through tickets... and mentally, they've already moved on.

This is the slow rot untrained, stagnant teams produce. Not sudden exits. Gradual decay.

I've managed teams where this was the problem we weren't naming. Engineers in the same role for three years, doing the same work, with no new challenges, no growth pathway, no indication their skills mattered beyond the next sprint. They weren't bad people. They were people told, through action rather than words, their development wasn't worth the investment.

So they stopped developing. And they stayed.

Why Managers Don't Train

The arguments against L&D investment are familiar:

"We don't have the budget." Training is usually the first line item cut when things tighten. It's a soft number. Easy to defer. The business won't immediately collapse without it, so it becomes the sacrifice.

"We don't have the time." The team is underwater. Three critical deliveries and a migration are hanging over everyone. This isn't the right moment for training.

"They'll leave anyway." The fear underneath. What if we train them and a competitor snaps them up?

All three make a certain kind of short-term sense. None of them hold up past the next 12 months.

The "no budget" argument ignores what non-training costs. According to Hone HQ, training programs reduce employee turnover by an average of 43%. A 1,000-person company saves around $5.9 million from the turnover reduction alone. The question isn't whether training costs money. It's whether skipping it costs more.

The "no time" argument is self-sealing. Teams always underwater are usually teams without the skills to get ahead of the work. Cutting training to save time in the short term guarantees being underwater again next quarter.

I'll come back to the "they'll leave anyway" fear.

The Actual Cost of Stagnant Teams

Here's what no one puts in the spreadsheet: the cost of a mediocre team staying.

A disengaged engineer who stays is expensive in ways not showing up on the P&L. They introduce technical debt. They slow the onboarding of newer team members. They resist change... not because they're obstinate, but because change feels threatening when you haven't been growing alongside it. They drag standups. They produce work technically passing review but lacking creative energy.

And they hire in their own image when they get the chance.

Hone's research shows companies investing in training see profits rise by 23% and productivity go up 18%. The difference isn't incidental. It's the gap between a team operating at baseline and a team growing.

The irony is managers often stifle growth while trying to protect the business. There's a well-documented pattern in tech leadership where being overly solution-focused, jumping in with answers because it feels efficient, robs your team of the development they need. The instinct to protect feels safe. It isn't.

"What If They Leave?"

Right. Back to the fear.

If you train your engineers and they leave for a better role elsewhere, good. Here's why.

First, you built something. An engineer leaving after growing under your leadership is an ambassador for your team culture. They'll refer talent. They'll remember you well. Tech is a small world.

Second, the alternative isn't "they stay and are loyal." The alternative is they stay and are disengaged. You've lost the productivity either way... except in the disengaged version, you're still paying for it.

Third, a team culture investing in people attracts people who want to grow. Those are the people you want to hire. People wanting to grow are the ones shipping things, questioning assumptions, and staying engaged when the work gets hard.

The fear of training people who leave is a fear of investing in your people at all. And the fear costs you more than the investment ever would.

What Good Development Looks Like in Tech

Not sending engineers to a two-day conference and calling it done. It's a tick-box exercise and everyone knows it.

Good development in engineering teams looks like this:

Making space for deliberate practice. Not every sprint is a race. Carving out time for engineers to learn new patterns, experiment with new tools, or pair on something outside their comfort zone produces engineers who grow.

Treating learning as a team practice, not a solo activity. The teams growing fastest are the ones where knowledge sharing is part of the rhythm. Not formal training sessions... informal lunch-and-learns. Engineers teaching engineers. Curiosity treated as a professional skill.

Giving people work stretching them, not work fitting their current profile. The easiest path is assigning work to whoever already knows how to do it. The most effective path is assigning work slightly above what someone knows, with support behind them.

Being honest about career pathways. Engineers not seeing a future on your team will start looking for one elsewhere. The conversation about where this is going? Have it. You don't lose people to the conversation. You lose them to not having it.

The Manager's Real Job

There's a version of engineering leadership built around protecting delivery: hit the dates, keep the lights on, clear the blockers. This version produces delivery in the short term and stagnation in the long term.

The better version treats team capability as a product needing ongoing investment. Your engineers' skills are the asset. If you're not growing the asset, you're depreciating it.

I've seen this pattern at every scale, from small start-up engineering teams to large enterprise departments. Managers who never "had time" for development were the ones dealing with the most chaos 18 months later. Managers treating development as non-negotiable had teams looking different... more confident, more capable, quicker, and yes, sometimes smaller because some of those people got promoted or moved on.

Good. Healthy. Worth aiming for.

One Question

Before your next sprint planning, ask yourself honestly: am I growing the people on my team, or am I extracting from them?

If your answer is closer to "extracting"... look hard at what the cost will be 12 months from now. Because the bill for skipping development doesn't arrive immediately. It arrives when you're wondering why your best engineers are emotionally checked out, your delivery is slower than it should be, and your team feels stuck.

The invoice was always coming. You chose when it would land.

The Thing Stopping AI Agents at Your Company Isn't the Technology

Every week I talk to leaders who are frustrated with AI. They bought the tools. They paid for the subscriptions. They announced the initiative at the all-hands. Six months later, nothing moved.

Most of them have the same diagnosis: the technology isn't ready. The models need more work. The integrations are too complex.

My diagnosis is different. The technology is fine. The leadership isn't.

The Numbers Are Uncomfortable

The 2026 State of AI Agents Report lists the top three blockers to enterprise AI adoption:

1. Integration challenges: 46%
2. Data quality requirements: 42%
3. Change management needs: 39%

Read those again. All three are people problems.

Integration challenges aren't solved by better APIs. They're solved by leaders who get the right people in a room and make a decision about architecture. Data quality issues don't fix themselves. They require someone with authority to say "this is a priority and we're resourcing it." Change management? It's leadership, full stop.

MIT's State of AI in Business 2025 found 95% of enterprise AI pilots fail to deliver measurable business impact. Not because the technology broke. Because the organizations weren't ready to use it.

Only 11% of organizations are running agentic AI in production today. 38% are still piloting. The rest are stuck at "exploring." The gap between piloting and production is not a technical gap. It never was.

What Leadership Failure Looks Like in Practice

I've seen this pattern enough times to name it:

The CTO picks a vendor, signs a contract, and announces AI is coming. The team gets a demo. Someone spins up a trial account. A few early adopters use it with enthusiasm for two weeks. Then the energy fades and everyone returns to what they were doing before.

Why? Because nobody asked:

• What process are we changing?
• Who needs to work differently, and how?
• What does success look like in 90 days?
• Who is accountable for the result? One person, not a committee.

Brent Collins at Intel said it well: "Don't simply pave the cow path." Most companies deploy AI agents on top of broken processes. The agent automates the dysfunction. Then leaders wonder why the metrics are flat.

Harvard Business Review's research found 45% of executives reported AI ROI below expectations. Only 10% exceeded them. The barriers weren't technical. They were:

• Uncertainty: employees lack foundational knowledge, which creates two useless camps: people who think AI is magic and people who think it's worthless. Neither group uses it well.
• Fear of replacement: workers drag their feet on AI training when they suspect the tool is there to eliminate their jobs. Nobody explained the real purpose.
• Status loss: senior engineers hide their AI usage because it feels like admitting weakness. Experience-based authority gets threatened when a junior with the right tools outperforms a veteran.
• Resource hoarding: successful divisions keep their models and datasets locked down instead of sharing.

Not one of those is a technical problem. All of them are solvable with deliberate leadership.

The Change Management Trap

When most organizations hear "39% cite change management as a blocker," they translate it to "we need better communication." So they run a few lunch-and-learns and call it change management.

It isn't.

Real change management for AI adoption means:

Redesigning the workflow before the agent arrives. If you automate a bad process, you get a faster bad process. The ROI evaporates. Deloitte referenced Henry Ford on this point: many organizations are busy finding better ways of doing things they shouldn't be doing at all. AI amplifies this problem if you skip the design phase.

Making AI use visible and rewarded. When people hide their tool use out of shame or fear, the organization loses the feedback loop needed to improve. Celebrate what works. Name it. Share it.

Giving people permission to fail while learning. A team trying new things will make mistakes. Leaders who punish those mistakes get teams who stop trying. You will not get adoption without psychological safety around experimentation.

Connecting the initiative to outcomes employees care about. Not "the board wants AI ROI." Something like: "we want to eliminate 400 hours of data entry per month so you have time for work worth doing." The framing lands differently.

The Engineer's Role Here

If you're in an engineering leadership role, there's a specific trap worth naming: the tool-selection trap.

It's easy to spend your energy evaluating models, comparing APIs, and benchmarking latency. The work matters. But it's not the reason your AI initiative will fail or succeed.

I've worked through building AI agents with clients and partners. In roughly half the cases, the first thing a client wanted to automate was not the most valuable thing to automate. The technology was ready. The business thinking wasn't. The real work was a two-hour whiteboard session figuring out what the actual problem was... and whether an AI agent was the right solution for it at all.

It's a leadership conversation. Not an engineering one. Engineering leaders who learn to run it get far better results than those who go straight to implementation.

What the Teams Getting It Right Do Differently

The organizations getting real results from AI agents share a few things in common. None of these are difficult to understand:

They start with a problem, not a product. Not "let's use AI." Instead: "we spend 400 hours a month on X and it's costing us." Then they ask whether AI is the right solution for X.

They make the process legible before they automate it. If only one person fully understands how something works, an agent will fail inconsistently and nobody will know why. Document the process. Test it manually. Then automate.

They set specific targets. Not "use AI more." Something like: "By Q3, 80% of customer intake forms go through the agent without human review." A target you measure toward.

They assign a single owner. Not a committee. One person. Committees hold meetings. People ship.

Before You Buy Another Tool

Ask yourself one question: does your team know why you're doing this, who owns it, and what success looks like in 90 days?

If the answer involves a pitch deck and a Slack channel, you're not ready to scale. You're ready for more failed pilots.

Deloitte estimates over 40% of agentic AI projects will fail by 2027. The reason won't be the models or the APIs. It will be organizations automating the wrong things, with unprepared teams, no clear owner, and no shared definition of what winning looks like.

The technology is not your bottleneck.

If you're an engineering leader, this is your moment to step out of the tool-selection role and into the organizational design role. The teams winning with AI are the ones whose leaders asked hard questions before signing the contract.

What questions haven't you asked yet?

Agile was created to cut through bureaucracy. Somewhere along the way, it became the bureaucracy.

The Ritual Nobody Reads the Manual For

Monday morning. 9am. Your team logs into the standup. Someone goes first: "Yesterday I worked on the payment service. Today I'll continue on the payment service. No blockers." Thirteen minutes later it's over. Everyone goes back to their desks and does exactly what they were doing before.

You've run your Agile ceremony. You haven't done a single thing the people who wrote the Agile Manifesto intended.

What the Manifesto Says

In February 2001, seventeen software developers met at a ski lodge in Utah. They were fed up with heavyweight, document-heavy processes crushing engineering teams. They wrote four values:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

Read those slowly. Now look at your sprint process.

How much of your ceremony is about processes and tools? How much of your definition-of-done is comprehensive documentation? How often do engineers wait for a refinement session instead of picking up the phone and talking to a customer?

The manifesto's twelve principles include: "Working software is the primary measure of progress." And: "Simplicity... the art of maximizing the amount of work not done... is essential."

Story points. Velocity charts. Capacity planning spreadsheets. Sprint burn-up graphs. None of those are in there.

How We Got Here

I've led engineering teams for years. I've watched the same pattern at every organisation claiming to have "adopted Agile."

Step one: hire a Scrum Master or Agile Coach. Step two: set up Jira. Step three: run two days of training. Step four: start doing two-week sprints with all the ceremonies. Within six months, the team has more meetings than they had before. The ceremonies multiply. A daily standup becomes a standup plus refinement plus sprint planning plus a demo plus a retrospective plus an ad-hoc sync because the planning went sideways.

A methodology created to cut through bureaucracy has become its own bureaucracy.

I spoke to a senior engineer recently who told me their team spends roughly one full working day per week in Scrum ceremonies. Twenty percent of engineering time before anyone writes a single line of code. Their deployment frequency? Once every six weeks. Their lead time from idea to production? Four months.

Not Agile. Scrum theatre.

The Stats Are Uncomfortable

A 2024 study of 600 software engineers in the UK and USA, reported by The Register, found software projects adopting Agile practices are 268% more likely to fail than those without it. The same research found 65% of Agile projects fail to deliver on time, within budget, and to an acceptable quality standard.

These numbers shock people. They shouldn't.

The problem isn't Agile. The problem is what passes for Agile in most organisations. Strip away the mindset, keep only the ceremonies, and you get all the overhead with none of the benefit.

The same research showed projects with clearly defined requirements before development started were 50% more likely to succeed. Requirements... documented in advance. The same thing the Agile world called waterfall thinking.

The lesson isn't "go back to waterfall." The lesson is: know what you're building, talk to the people who need it, and then move fast. Agile thinking, in other words. The sprint ceremony calendar is not.

What Real Agility Looks Like

I've been in teams with genuine agility. They looked nothing like the textbook.

They talked to customers constantly... not in formal quarterly reviews, but in Slack threads and five-minute calls when something was unclear. They shipped small changes often... not because they had a release train scheduled, but because they cared about getting feedback. They changed direction mid-sprint without drama... not because they ignored planning, but because they treated the plan as a starting point, not a contract.

The most effective team I ever worked with had a process describable in one sentence: build something small, show it to someone who'll use it, learn, repeat. No Jira. No velocity tracking. No Scrum Master. A Trello board with three columns. They shipped every week without fail.

Where to Start If Your Agile Has Gone Wrong

Cut the ceremony time in half. Your daily standup should take fifteen minutes maximum... and only when it's genuinely useful. If it's a status report to the manager, cancel it. The manifesto says face-to-face conversation is the most effective way to share information. A round-robin status update isn't a conversation.

Measure outcomes, not process compliance. How often do you deploy? How fast do you respond to a customer request? How long from idea to production? Those numbers matter. Velocity and story points are internal theatre.

Put engineers in direct contact with users. Not via a product manager acting as a translator. Direct contact. This one change does more for agility than any ceremony redesign.

Take "maximising the work not done" seriously. Your backlog isn't a commitment. It's a hypothesis list. Most of what's in there doesn't need building. The most productive decision your team makes in a sprint might be the feature they reject.

The Question Worth Sitting With

Before your next sprint planning, ask your team: are we practising Agile, or are we running Scrum ceremonies while calling it Agile?

The answer might be uncomfortable. Uncomfortable answers are where improvement starts.

Your team's agility isn't measured by how faithfully they follow the Scrum Guide. It's measured by how fast they learn, how quickly they respond to change, and how much working software lands in front of real users.

Everything else is overhead.

What does your team's Agile practice look like in reality? Are you building things... or running meetings about building things?

I've watched it happen a dozen times.

Your best engineer ships feature after feature. They debug problems nobody else sees coming. The team respects them. Leadership notices.

So you reward them. You make them a manager.

And within six months, you've lost your best engineer... and gained your worst manager.

The Peter Principle Is Thriving in Engineering

Laurence J. Peter named this phenomenon back in 1969. People get promoted based on their performance in their current role, not their ability to do the next one. They rise until they reach a role they're bad at. Then they stay there. The concept has its own Wikipedia page, and researchers who simulated it even won an Ig Nobel Prize for proving random promotions outperform merit-based ones in Peter Principle organisations.

In software engineering, this pattern is everywhere.

Gallup's research puts hard numbers on the problem. Only 1 in 10 people naturally possess the talent to manage others. Companies pick the wrong person for management roles 82% of the time.

82%.

Think about what this means. In a company with 50 managers, 41 of them should not be doing the job they're doing. Not because they're bad people. Because they were promoted for the wrong reasons.

Managers account for 70% of the variance in employee engagement. Half of all employees have left a job specifically to escape their manager. US companies spend $1.5 billion a year on engagement programmes, and average engagement levels haven't moved in 20 years.

My own research backs this up. In surveys I've run through Step It Up HR, 99.5% of respondents said they've had one or more types of bad boss. Not 50%. Not 80%. Ninety-nine point five percent.

The system is broken. And the engineering industry keeps feeding the broken system by turning great coders into reluctant managers.

The Double Loss

Here's what happens when you promote your best engineer into management.

Loss number one: You remove your strongest technical contributor from the work they do best. The person who spotted architectural flaws before they became production incidents. The person who mentored junior developers by sitting next to them and pairing on hard problems. The person whose code reviews taught the whole team something. Gone. Replaced by someone less skilled, or by nobody at all.

Loss number two: You install a manager who doesn't want to manage. They sit in meetings wishing they were coding. They struggle with conflict resolution because they've spent a decade solving problems with logic, not emotions. They avoid difficult conversations about performance. They micromanage the technical decisions they used to own, because it's the only part of the job they understand. Their team feels the tension. Morale drops. Your best people start looking elsewhere.

I've lived this. I've been the engineer who got promoted. The first time I became a CTO at a startup, I didn't want the title. They needed it for their fundraising deck. As the tech founder, you're the "CTO" with invisible quote marks. And the skills required to be a real CTO... strategic business leadership, managing managers, budgets, cross-department communication... none of those are the skills you got hired for.

The transition from engineer to engineering manager requires learning to let go of writing core code, negotiating with product managers, building cohesive teams, and handling conflict. Those are entirely different muscles. And the higher you go, the further you get from the work you loved. By the VP of Engineering level, coding is a crime. You have more important things to do.

Management as the Only Way "Up"

The root problem is simple. Most companies have one ladder. Write code, become a senior engineer, then... manage people. There's nowhere else to go.

If you want a raise, a better title, more influence... you take the management job. Even if every fibre of your being says you'd rather be designing systems.

Engineers are logical. They look at the incentive structure. Higher pay goes to managers. More decision-making authority goes to managers. The org chart points up through management. So they take the management role. Not because they want to manage. Because the system leaves them no other choice.

This is organisational design failure. Not a personal failing.

Build Real Career Tracks

The fix isn't complicated, but it does require organisations to rethink what they value.

Pat Kua's Trident Model describes three distinct career paths:

1. Management Track — 70-80% of time spent on people, organisation, and enabling others. This is for people who genuinely want to develop and support teams.

2. Technical Leadership Track — 70-80% of time on technical vision, risk management, architecture decisions, and growing team knowledge. Leadership without people management.

3. Individual Contributor Track — Deep specialist work. Execution, expertise, and impact through technical depth.

All three tracks should reach the same level of seniority, compensation, and respect. A Staff Engineer should earn as much as an Engineering Manager. A Principal Engineer should sit at the same table as a VP of Engineering.

The traditional dual-track model (IC vs Manager) is a step in the right direction, but it often fails. As Kua points out, the IC track tends to overemphasise individual contribution when most organisations need technical leadership. The Trident Model fills the gap by recognising the role of the person who shapes architecture, sets technical direction, and mentors... all without managing anyone's holiday requests.

What Good Looks Like

Before promoting anyone into management, ask these questions:

Do they want it? Not "would they accept it if offered?" Do they actively seek out people problems? Do they volunteer to run retrospectives, mentor others, and mediate disagreements? Or do they do those things reluctantly because nobody else will?

Do they already manage? The best managers are doing the work before they get the title. They're coaching peers. They're having tough conversations. They're thinking about the team's health, not their own output.

Would you trust them with a firing? Management isn't all team lunches and stand-ups. Sooner or later, a manager has to deliver bad news. Have a performance conversation. Let someone go. If you wouldn't trust this person with the hard parts, don't hand them the role.

What will you lose? Be honest about the cost. If promoting your best architect into management means your system design quality drops, the trade-off has to be worth it. Often, it isn't.

Stop Calling It a Promotion

Management is not a step up. It's a step sideways into a different profession.

An engineer who becomes a manager isn't doing the same job with more authority. They're doing a completely different job. The skills transfer is minimal. The daily experience changes entirely. The feedback loops are different. The satisfaction comes from different places.

The best thing you do for your strongest engineer might be to give them a raise, a Staff Engineer title, and the authority to shape your technical direction... while keeping them far away from one-on-ones and performance reviews.

Build three ladders. Pay them equally. Respect them equally. And stop assuming "up" means "managing people."

Your best engineer deserves better than a job they'll hate.

Lots of books, studies, talks, think groups, consultants and more have tried to figure out why software as a business is hard...but they seem all try to look at it from a single viewpoint.

I'm going to give you the secret to why writing software as a business is difficult.  Hard.  Nigh-on impossible.

Why?  Perspective.  Multiple points of view (PoV).

I've attempted to show you why in this chart.  Value from one's point of view tops out at 10 here.  The units are arbitrary.
​
The business folks start this chart on the left.  The absolute best thing they could get is an app that does everything their heart desires and get it /right now/. The longer the project drags on, the farther to the right and down the blue line goes. Why can't developers ever deliver anything?

Either the market opportunity will dry up because a competitor did release an imperfect but on-time project, the sales won't materialise, or the project will run out of money before delivering.

Note that the blue line continues below zero. A below zero value is a very real prospect...it means that the project is losing money for the business.

The developers enter this from the right.  There's almost zero value in giving something to the business on the first day.  We've not had time to scope, research, analyse, plan, divide into user stories, write tests for, fail, refactor, meet, discuss, and eventually deliver some software. Why do the business types always demand software before it's ready?

If the business demands it at the beginning it will have a near-zero value.  As time goes on, the value delivered (red line) slowly ascends.  At the far right, we've hit the perfect software: small, easy to maintain, well documented, maybe multi-platform and a joy to behold...and entirely too late.

By the time we've gotten that far our company has gone out of business.

The real value that a software project delivers is represented by the green line. The maximum value is the MINIMUM of either the red or blue lines.

The best we can hope for is to find the optimal mix: 'enough' software to scratch a business need, delivered fast enough to capitalise on the opportunity.

Admittedly not perfect software, and clearly not delivered on day 1.

There are ways to try to manage both lines to enlarge or prolong the sweet spot.  

You could throw more money at a project (whether that shows up as hardware, software, people, facilities, resources, campaigns, publicity, influencers, whatever...at the end of the day, it's all money) to give you a longer time period before the blue line starts to descend.  However, the farther to the right you go, the less effect throwing money at a project will have.

You can try reuse (internally with code or externally with libraries), or better tech, hardware or people to move the red line to the left.

No matter how passionately I argue that we *must* refactor code or that the project must deliver by Tuesday (even if the software isn't ready), I'm not going to be helping the business.

At the end of the day, we need to swap our points of view. 

If a dev looks at this from the pov of the biz guy, they'll be thinking how to move their bar to the left.  Descope, suggest alternatives, innovate to do things in quicker ways.

If a business guy uses the pov of a developer, he'll see that the quick win never really existed because it wasn't obtainable in the first place, and trying for it might have actually cost us the opportunity that really was obtainable, even if it were smaller.

This is the challenge that makes software difficult, and yet keeps things so painfully interesting.

---

---

Okay, enough's enough.  Why create yet another category?

Well, from time to time I'll have random musings about digital stuff that doesn't seem to fit in anywhere else.
​

---

Leaders always want the people on their teams to be more productive, more efficient, and perform better at their jobs.

In software, we're constantly trying to improve performance, with all sorts of metrics used to eke just a little more speed out of a team. Here's a few examples for the record in no particular order: agile, scrum, lean development, DevOps, Six Sigma, waterfall, extreme programming, kanban, CI/CD, lean Six Sigma, crystal, feature driven development, rapid application development, capability maturity model, lean startup, design thinking, ITIL, DevSecOps, Lean UX, Six Thinking Hats. (Links explaining these methodologies below.)

Seems lots of people, teams, companies have tried...but have they succeeded?

From the companies I've worked at, the answer seems to be a firm "no".  Companies are focusing on how "hard" people are working. That might be useful when doing a time/motion study on an assembly line, but it doesn't apply when doing creative work like software engineering.

I'd like to propose something radical...but before we talk about that, it's useful to know what an engineer needs to feel "engaged".  

By engaged I mean an engineer who is committed to the work.  They are passionate about the job and care about the success of the projects. More than half of the motivation must come from a desire to learn, grow and contribute to the engineering effort.  They take on new challenges, think creatively, and problem solve in innovative ways.  In short: that's the kind of engineer I want on my team!

To keep that going, an engaged engineer requires care and feeding: Meaningful work, professional development, positive environments, autonomy, work-life balance, recognition, and a diverse work place.  I won't go into those in this article, but they are all key.

Here's the radical bit though: they aren't enough.

An engineer needs to have a bit of breathing room...a bit of time to day-dream.  A bit of time, to...well...be bored.

Yes, that "are we there yet?" kind of boredom.  

I can hear the over-pressured organisations screaming now: "What!?!  We can't have expensive highly-paid engineers GOOFING OFF!?!"

Well, my shouty imaginary organisation...that's *exactly* what I'm proposing.  

Why?  Simple, really.

Boredom (as a tool used by engaged engineers):
1. can spark creativity
2. reduces stress
3. promotes self-discovery
4. encourages movement
5. helps with learning and memory
6. improves sleep
7. enhances mood
8. improves focus

I'm really smart...just take my word for it!  

(Not convinced?  Fair enough...I probably wouldn't be either.  If you want to learn more I mention the "why" for each of these below, and provide references for the studies to back each point up.)

Note that "engaged" part.  This is advanced engineering here.  If your organisation screams "FASTER!" at the teams on a regular basis, you'd probably get more bang for your buck by improving your company culture in the first place.  The engineers have to want to be productive.

Long->short: Make sure you've got the engineers engaged and then let them start to daydream.  Just a little.

Imagine what they'll be coming up with next!

=====================================
A bit of a deeper dive...

Again, I hear the more bellicose companies out there girding for war at the very thought.  Let's talk about each one of these in a little detail, and I'll provide references to studies where people smarter than I figured out each of these items.

Boredom can spark creativity: Research has shown that boredom can lead to creative thinking and problem-solving. A study(S1) published in the Academy of Management Discoveries found that employees who had more boredom in their jobs were more creative and generated more original ideas than those who had less boredom. Encouraging your engineers to take breaks and pursue hobbies or side projects can promote creative thinking and lead to new innovative ideas for your company.

Boredom reduces stress: Chronic stress can have a negative impact on employee well-being and productivity. A study(S2) published in the Journal of Occupational Health Psychology found that brief periods of boredom during the workday can help reduce job-related stress and fatigue. Allowing your engineers to take breaks and participate in activities that help them relax and de-stress can lead to improved job satisfaction, higher productivity, and overall better health.

Boredom promotes self-discovery: Giving your engineers the time and space to reflect on their personal and career goals can have a positive impact on job satisfaction and retention. A study(S3) published in the Journal of Vocational Behavior found that self-reflection can help employees better understand their values and goals, leading to higher job satisfaction and improved performance. Encouraging your engineers to take breaks and explore new interests and hobbies can lead to a more motivated and engaged workforce.

Boredom encourages movement and self-care: A sedentary work environment can have a negative impact on employee health and productivity. A study(S4) published in the American Journal of Preventive Medicine found that taking short breaks during the workday to engage in physical activity can lead to improved mood, reduced fatigue, and increased productivity. Encouraging your engineers to take breaks and engage in physical activity can lead to improved overall health and better productivity.

Boredom helps with learning and memory: Research has shown that boredom can lead to improved cognitive function and memory retention. A study(S5) published in Consciousness and Cognition found that participants who engaged in a boring activity for a short period of time performed better on a subsequent creative task than those who did not engage in the boring activity. Allowing your engineers to take breaks and engage in non-work-related activities that challenge their cognitive abilities can improve memory retention and lead to more efficient and effective problem-solving.

Boredom can improve sleep: Adequate sleep is essential for employee health and productivity. Research has shown that boredom can help promote relaxation and better sleep quality. A study(S6) published in BMC Public Health found that engaging in activities that promote relaxation, such as reading or listening to music, can lead to improved sleep quality. Encouraging your engineers to take breaks and engage in relaxing activities can lead to better sleep quality and improved productivity.

Boredom enhances mood: Positive mood is essential for employee motivation and productivity. Research has shown that boredom can help promote positive mood and reduce negative affect. A study(S7) published in the Journal of Personality and Social Psychology found that engaging in non-demanding activities can lead to improved mood and reduced negative affect. Encouraging your engineers to take breaks and engage in activities that promote positive mood can lead to a more motivated and engaged workforce.

Boredom improves focus: Multitasking and distractions can have a negative impact on employee productivity. Research has shown that boredom can help improve focus and concentration. A study(S8) published in Psychological Science found that exposure to natural environments, which can promote feelings of boredom, can lead to improved focus and cognitive function. Encouraging your engineers to take breaks and engage in activities that promote relaxation and focus, such as meditation or spending time in nature, can lead to better focus and higher-quality work.

=====================================
Methodology links (hover to see link first):
Agile Methodology 
Scrum 
Lean Development 
DevOps 
Six Sigma
Waterfall Methodology
Extreme Programming (XP)
Kanban
Continuous Integration/Continuous Delivery (CI/CD)
Lean Six Sigma
Crystal Methodology
Feature Driven Development (FDD)
Rapid Application Development (RAD)
Capability Maturity Model Integration (CMMI)
Lean Startup
Design Thinking
ITIL
DevSecOps
Lean UX
Six Thinking Hats

=====================================
S1 - "Bored at Work? Try These 3 Things" by Anne Fisher, Fortune, March 15, 2017 - This article discusses a study published in the Academy of Management Discoveries that found that employees who had more boredom in their jobs were more creative and generated more original ideas than those who had less boredom.

S2 - Trougakos, J. P., Hideg, I., Cheng, B. H., & Beal, D. J. (2014). Lunch breaks unpacked: The role of autonomy as a moderator of recovery during lunch. Journal of Occupational Health Psychology, 19(2), 91-103. - This study found that brief periods of boredom during the workday can help reduce job-related stress and fatigue.

S3 - Kooij, D., Jansen, P. G., Dikkers, J. S., & De Lange, A. H. (2014). The influence of age on the associations between self-reflection and work-related outcomes. Journal of Vocational Behavior, 84(2), 235-246. - This study found that self-reflection can help employees better understand their values and goals, leading to higher job satisfaction and improved performance.

S4 - Alkhajah, T. A., Reeves, M. M., Eakin, E. G., Winkler, E. A., & Owen, N. (2012). Sit-stand workstations: A pilot intervention to reduce office sitting time. American Journal of Preventive Medicine, 43(3), 298-303. - This study found that taking short breaks during the workday to engage in physical activity can lead to improved mood, reduced fatigue, and increased productivity.

S5 - Baird, B., Smallwood, J., & Schooler, J. W. (2011). Back to the future: Autobiographical planning and the functionality of mind-wandering. Consciousness and Cognition, 20(4), 1604-1611. - This study found that engaging in a boring activity for a short period of time can improve cognitive function and lead to more efficient and effective problem-solving.

S6 - Kang, J., & Chen, M. H. (2009). Effects of an irregular bedtime schedule on sleep quality, daytime sleepiness, and fatigue among university students in Taiwan. BMC Public Health, 9(1), 248. - This study found that engaging in activities that promote relaxation, such as reading or listening to music, can lead to improved sleep quality.

S7 - Weinstein, N., & Ryan, R. M. (2010). When helping helps: Autonomous motivation for prosocial behavior and its influence on well-being for the helper and recipient. Journal of Personality and Social Psychology, 98(2), 222-244. - This study found that engaging in non-demanding activities can lead to improved mood and reduced negative affect.

S8 - Berman, M. G., Jonides, J., & Kaplan, S. (2008). The cognitive benefits of interacting with nature. Psychological Science, 19(12), 1207-1212. - This study found that exposure to natural environments can lead to improved focus and cognitive function.

---

​Have you felt a pain in your company, but when you looked, you couldn't find a significant cause? Medicine has a concept called "referred pain" that might offer an insight.

Two weeks ago I had a laparoscopic cholecystectomy.  For those like me who don't know what that is, it's a gall bladder removal.  It turns out a Gall Bladder has similarities to an Appendix.  You can live without one just fine.

Not going for sympathy here; the staff at the hospital were absolutely great in all respects. Two weeks later my wife and I just went for a 7-mile hike, with me feeling better than I have in years. If you are ever in the market for such a procedure and live anywhere near Coventry in the UK, I can highly recommend the team that performed it on me.  Feeling such an improvement got me thinking…

I've had a dodgy back for a long time now.  Sometimes okay, but sometimes very not.  A few times, for up to a month.  I couldn't do anything significantly physical, sometimes I could hardly move and certainly couldn't get comfortable.  Exercises, yoga, pilates, diet changes, going alcohol-free for a year, nothing seemed to improve it. This surgery seems to have sorted it out to a great extent.

In discussing this with my surgeon, he mentioned something called "referred pain".  I'm not qualified to try to explain it, but here's one definition I found: 
"Referred pain is a fascinating phenomenon where pain is felt in one part of the body due to the convergence of nerve pathways, even when the source of pain is elsewhere. It highlights the complexity of our nervous system's pain processing."

Hrm…'fascinating'.  Not the word I'd have used, actually.

At any rate, I feel this has applicability in our day jobs as well.  How often have you had a problem and started looking for the cause?  When you found one, it didn't feel like the prime mover cause; it felt like a symptom.  You keep looking, and then you find a cause for that one. Hopefully, you can finally find the root cause of the issue and create a plan to stop it from reoccurring in the future.

The idea is not to treat the symptom but rather the cause.  Many people have heard of "The Five Whys" (or maybe the 5Ys).  According to MindTools: 
Sakichi Toyoda, the Japanese industrialist, inventor, and founder of Toyota Industries, developed the 5 Whys technique in the 1930s. It became popular in the 1970s, and Toyota still uses it to solve problems today.
Toyota has a "go and see" philosophy.
I expect most teams would benefit from this sort of "go and see" thinking.  I feel it applies to all teams such as Finance, HR, Customer Support, and any other department in the organisation.

In other words, don't react to symptoms; go and see what's really causing the problems and fix *those*.

---

So, I had a problem.

Like every mobile project before, this project was suffering.

The views (UIViewControllers on iOS or Activities on Android) lifecycles were wreaking havoc with the logic.  The views were like waves....they'd arrive causing my logic to start, and they'd go tearing down the logic sandcastles as they left.

The code invariably had train wrecks scattered throughout: object.attribute.field.method().  On Android it would all crash horribly in a nullPointerException fire.  On iOS, it would just quietly disappear like a mafia hit.

The code was so tightly integrated, you needed testing magic, mocking doubles, stubs, libraries, Robolectric or such to try to test the code.  These often came with limitations that were worse than the untested code.

So, we're back at manual testing bug whack-a-mole: knock one bug down, and another one rises.  Knock the second bug down, and the first one returns.  Squish both, and a yet-undiscovered bug pops up.

The UI state for each view was this flexible thing...when a button was clicked, the textfield was enabled.  Except when the 'Bad Password' screen was showing, because then the cursor would show through.  So we had to special-case that.  Of course, when the requirement came down to show a 'forgotten password' dialog, that had to be catered for as well, and...

​Enough!

I had to be missing something fundamental here.  

At a previous company, I was floundering towards a solution...   

I had a class called a 'Brain'.  This Brain was a wrapper for the logic states, while the views were the OS-specific visible part.  The brain could be in a different state, and the corresponding views would be shown.

Oh, this raised issues to be sure.  Both iOS and Android want their framework to be the center of your application.  After all, it makes an iOS app near-impossible to translate to Android, and vice-versa, unless you're using a multi-platform framework (Zen, PhoneGap, etc).  I had these states, but the interface was more than 3 methods (it had 5 per state) that people coming to learn it thought it was crazy.

Hrm...time for more research, I guess...  

I ran across this article(http://hannesdorfmann.com/android/model-view-intent) by Hannes Dorfmann.  Brilliant article, and it felt like I was on to something.  It's for Android, obviously, but I'm sure the concepts will translate with a bit of work.

Then I downloaded the code...and felt trapped back in the same box.  Not being completely up-to-speed on RXJava, it felt like there were things just out the corner of my eye that I didn't understand or couldn't even completely see.  I didn't see how it would handle the lifecycle issues I'd been facing.

So, then, I thought: why not rewrite it using the most boring, stupid java possible? 

That's when I arrived at 'Circus'.  (Think Piccadilly, not Big-Top)

Before I tell you what Circus is, let me ask you a question:  What /is/ your app?  

Is it the views?  Is it the database?  Is it the network?

I'd say it's the *logic* of your app that makes it special.  How you choose to do whatever it is your app does.

What are the features I'm looking to implement?
1) Eliminate lifecycle gyrations from my logic.
2) Isolate the storage, network, and all other library calls I'm not writing.
3) Provide an easy event-recording mechanism.
4) Ensure that all of my UI, my logic, and my plugins can be written using TDD /without/ having to use crazy testing frameworks.
5) On Android, ensure that my tests run in the JVM, so they're crazy fast, enabling real TDD again.
6) Split the UI, Logic, and Plugins into pieces so that multiple people can work on the same codebase in a *clean* way.

Sound too good to be true?
​Okay, so lots of lines.  How's this really a solution for anything?

Well, let's simplify the views...the views only ever do two things: they send an event to the back end, and they render new states.  They do *not* alter global state.  They could be killed, and reconstituted, and still be just as good as before, as they do not maintain their own state.

Okay, let's also simplify the back end things.  In fact, let's break the back-end things into component parts.  There's a 'network' plugin that provides the 20 or so network calls we'll make to the backend.  There's a 'database' call that handles all storage of temporary state.  And so on.  Any code that we aren't writing gets wrapped in a plugin.  All of it.

What's left?  Our logic, of course.  This is the thing that makes each view of our app a view of OUR app.

How do these all talk to each other?  In true Uncle-Bob fashion, though Interfaces (or your language-equivalent).  This means that there's one (and only one) way from a view to send an event to our logic.  There's only one way for our logic to send a new state to the front end for rendering.  There's only one way for our logic to kick off a network call, or for that network call to return its result.

This means that testing is a doddle, as we can simply write any old object that implements this interface, and all of a sudden, it's that kind of object.  We don't need Mockito, Robolectric or any other framework to test...it's all just Our Code!

Our tests can accept events, and send new states to the UI through the UI Interface.  Our tests can send events to the Back classes and see what states pop out.  The plugins can be tested using the Plugin Interface.

And threading?  The UI reports events through a single call.  It receives new states through a single call. When UI events are reported, they're simply put onto a background thread, and when a new state is sent to the views to be rendered, it's shifted to the foreground thread.  That means that our code *never* needs to bother with foreground/background, etc.  Our logic can simply block and wait, as we're by definition on a new background thread for each event, and always on the foreground thread for all UI changes.

Will this be a solution for all ills?  I don't know.

In my next few articles, I'm going to demonstrate these principles, and how I might implement all this and more.  What I'm aiming to deliver is a simple framework that we can use to get our jobs done in a way that allows for full (and easy) TDD in a mobile context.

My needs are a fairly simple Android application, so I'll be writing it in Java.  The concepts would hold on iOS as well with slight variations.

In fact, if I manage the abstractions cleanly enough, the logic won't care a bean what the UI is doing, nor will the UI care what the backend is...

So, enough for today.  Read my next article for first implementations...

-Ken

---

Sometimes the most important thing is to tilt your head and look at the problem differently.  

I usually end up feeling foolish when this happens.  The only thing to do is to own it and move on, lesson learned.

I work on a big app in my day job.  As delivered, it's currently 45MB.

As you can imagine, some size could be sliced off if we could use /this/ technique, or /that/ procedure. Sadly real life doesn't seem to work that way.  Apps, like people, seem to be the sum total of all the events (and corresponding scars) made over their lifetimes.  There are /reasons/ why we can't use app bundling, or other methods to slim down like some other apps might.

So, when I was tasked with creating a carousel effect, though my first thought was to use the 'Android-CoverFlow' library from https://github.com/crosswall/Android-Coverflow, I balked because of the size.

I don't have anything against the code or the library, we just needed the lightest implementation possible.

So I started trying to build the coverflow effect by hand.

I found that the ViewPager is distinctly odd in the Android world.  If you luck into the right point of view, it's a no brainer.

If you, like me, make invalid assumptions, it's a nightmare of code smells: machine-specific code, hooking into the global layout of the widget, strange unexplained offsets being required, etc.

So, instead of being very long winded, I'm going to show you a git repo.  

One branch, "BadCoverflow", is the original code.  It works okay-ish on one size phone (I used the emulator's Nexus s here), but good luck getting it to work across phone sizes (try it on a Nexus 5x for example), or being able to control scrolling, or resizing elements. I couldn't get the scrolling to be reliably 1 page wide on all phones, and strangely the magnification of the transformer wasn't centered and also varied between phones.

I had a simple idea that a 'ViewPager' would fit the full width of the diplay, and it would just somehow 'know' to center the current item, etc.

I am embarrassed to say I lost 3 days to this mess.  To find what was causing the issues for me, I had to completely comment out all the code and uncomment it, bit by bit, to explain to myself what is going on.

In the other branch, "BetterCoverflow", is the simplified code.  Slightly smaller in size, platform-independent, and with fewer code smells.

Note that there's not much difference code-wide between these examples.  The biggest change came in my shifting point of view.

The viewPager is not expected to go the full width of the display and yet manage only a subset.  It's not expected to manage centering etc.  That's the job of the enclosing View.

Many of the smells have been removed (addOnGlobalLayoutListener? Trying to 'kick' the ViewPager as the transformer wasn't, somehow, being used when first laid out...
though I'm sure not all...no tests?  I mean really...).

As with most libraries we automatically reach for, Android-CoverFlow wasn't actually needed in the end, just a better understanding of how ViewPagers work.

I hope this article helps some other poor, lost soul struggling with a ViewPager-based coverflow implementation.

---

Don't be an Idiot (like me...)

Oh boy.

I don't feel particularly intelligent this evening.

For the last several work days, I've been fighting a bug.  A pernicious bug based around security...which I couldn't find.

I'd go forwards over my code, and then backwards.  Up and down.  I'd check web headers, recompile and run all my tests, etc...  No joy, still couldn't see the bug.

What was it?

Picture that you've got a class like this:

​Later on, in another object I instantiated one of these bad boys:

​What would you expect to see in the console?  Obviously:

​What I'd meant is for the output to be:

​Can you see where I went wrong?



The getName method should have been "protected"", at least, or maybe even "public", with a friendly and handy @Override annotation to indicate that we're overriding a method in the ancestor.


I said to myself, "Self," I says, "you done stepped on your crank."


This is an obvious bit of code, right?
​
But what if you had this:

​Now, the output is:

​How can you tell if that's any different to 
    c2l4OGMzMTk3NmItNWE4MC00YzVlLWE4NmYtOTU3MTJkMjY5OGFk
...or...
    c2V2ZW44NjQzMGI0Zi02MmMwLTQ1NDctOTk2MC1iOWQ2MTY2NGRiMmE=

The fun thing is that there was a third party library handling encryption (that has caused us issues before), as well as a web API that is (by design) rather uncommunicative.

All it would say in this instance is "Bad signature."  Exactly accurate, but not terribly helpful.

All the web request headers, as well as the other 6 arguments as well as those of the other 8 involved web calls were all correct.

The biggest cause (of my stupidity, I'll admit) is that everywhere else in the code, I did this:

​You'll notice that I refer back to a common definition of what getRealName is supposed to do.  There were three different encryption methods (each of which overrode getRealName()), and lots of other variables involved...but this was the cause.

Instead of using the common name manufacturing functions, I'd reimplemented them marking them private, for some reason.  Private methods aren't, of course, overridden.  Why would they be?

To make matters worse, I'd done it in a place where I was almost guaranteed to not find the issue.

Damn, another few grey hairs.

Don't be an Idiot (like me)...invent your own way.  This one's mine.

---

I gave a talk to our department at work a week or two ago, and thought that I'd make the talk available here.

The talk is purposefully abstract and simplistic, as I feel that the Circus architecture is simple and applicable to other platforms as well as Android.  I simply didn't want people to get too hung up on the platform-flavour for the talk.

If you have any questions, comments or suggestions, feel free to contact me at [email protected].

---