AI became the most convenient scapegoat in modern corporate history.

From a communications standpoint, it is perfect.

"We are eliminating 8,000 roles as we transition to an AI-first operating model" sounds inevitable. It sounds strategic. It sounds visionary. It sounds like something that would have happened no matter who was sitting in the executive seats.

"We hired 8,000 people we did not actually need between 2020 and 2022, and now the interest rate environment has changed, and investors want profitability" sounds like what it actually is: a business that overextended during a historic capital bubble and is now paying the bill.

One of these narratives is much easier to put in a press release.

It also conveniently removes accountability from the executives who made the hiring decisions in the first place.

Calling layoffs an “AI transformation” makes cost reduction sound visionary instead of reactive.

The Actual Numbers

In 2025, AI was cited as the official reason for approximately 55,000 tech layoffs, according to Challenger, Gray & Christmas.

That number gets repeated constantly.

What gets repeated much less often: 55% of companies conducting layoffs in 2025 cited economic uncertainty as the primary driver, according to Resume.org. And separate analyses found that many of the roles being eliminated, recruiters, project managers, customer support teams, and middle management layers, are not roles AI is currently capable of replacing in any meaningful way.

So two things are happening simultaneously.

Some AI displacement is absolutely real and measurable, particularly in junior development, QA, and certain support functions.

But most of the headline layoff numbers are the delayed correction from a hiring binge that ran from 2020 through 2022, when capital was cheap, and growth was the only metric that mattered.

Blaming AI for all of it avoids the much more uncomfortable question:

Why were all those people hired in the first place?

How the Hiring Binge Happened

During the pandemic years, tech companies hired at a pace that made very little long-term sense.

Interest rates were near zero. Capital was cheap. Venture funding was everywhere. Every investor wanted growth. Every board wanted expansion. Every executive team wanted to prove they were capturing market share faster than competitors.

Nobody wanted to explain to investors why their company was growing slower than everyone else during the easiest capital environment in more than a decade.

So companies expanded aggressively:

• more recruiters
• more managers
• more experimental product teams
• more parallel initiatives
• more hiring simply because competitors were hiring too

The binge lasted roughly two years.

Then the Federal Reserve started raising interest rates.

The cost of capital increased. Growth-at-any-cost stopped being a convincing investor story. Profitability suddenly mattered again. Operational efficiency became the mandate. And thousands of roles that only made sense inside a zero-interest-rate growth bubble no longer had a defensible business case attached to them.

That is not AI.

That is a market cycle behaving exactly the way market cycles always behave.

What AI Is Actually Doing to Employment

None of this means AI is not affecting employment.

It absolutely is.

The data on junior developer hiring is particularly stark. Employment for developers aged 22 to 25 fell nearly 20% from its 2022 peak. That is real displacement documented across multiple credible data sources.

But the honest picture is more layered than the press releases suggest.

AI is genuinely automating repetitive and highly structured tasks:

• boilerplate code
• basic QA scripting
• structured data entry
• repetitive documentation
• certain categories of content generation

Roles built primarily around those tasks are shrinking.

That part is real.

But in many organizations, AI is not replacing entire roles. It is compressing the amount of labor required for specific categories of work.

Those are related ideas.

They are not the same thing.

What AI is generally not replacing is:

• engineering judgment
• architecture decisions
• stakeholder management
• organizational knowledge
• client relationships
• operational leadership
• cross-functional coordination

In other words, most of the work happening in senior-level technical roles.

When a company lays off 200 senior engineers and cites AI productivity gains, that is almost never literally about AI replacing those engineers.

It is about headcount reduction being the fastest lever available when margins need to improve.

The AI explanation sounds cleaner.

It is also usually incomplete.

Why the Narrative Sticks Anyway

Companies benefit enormously from the AI framing.

It makes difficult business decisions sound like inevitable technological transitions instead of executive miscalculations.

"We made aggressive hiring decisions during a zero-interest-rate bubble and now need to reverse them" sounds reckless.

"We are restructuring around AI" sounds innovative.

Nobody made mistakes.

The AI just happened.

There is also a real phenomenon happening in parallel that makes the narrative believable: AI tools are genuinely increasing the productivity of experienced developers. One senior engineer with strong AI tooling can absolutely produce more output today than the same engineer could two years ago.

That changes headcount math.

It just does not explain most of the 127,000 tech workers who lost jobs in 2025.

Wall Street historically rewards cost reduction much faster than it rewards long-term organizational stability. Companies know this. Executives know this. Investors know this.

So layoffs framed as “AI transformation” often receive a much more favorable reaction than layoffs framed as “we overexpanded during a growth bubble.”

Employees also do not push back very hard on the AI framing because it feels plausible. AI anxiety already exists. Productivity gains are visible. Entry-level hiring really is collapsing in some areas. The industry already feels unstable.

So the explanation feels emotionally true even when it is only partially true.

And once the outcome is unemployment, most people stop arguing about the wording.

The story stays simple even when reality is not.

What This Actually Means

If you are a developer or tech professional trying to read the market right now, the useful frame is this:

Not everything labeled as AI disruption is actually AI disruption.

The structural risk from AI is real in specific areas:

• entry-level development
• QA
• support
• repetitive operational work
• highly standardized task-based roles

Those are worth paying attention to and preparing for.

The skills gap between people who use AI tools effectively and people who do not is widening and will probably continue widening for years.

But most senior engineers laid off over the last three years did not lose their jobs because a language model replaced them.

They lost their jobs because their companies overhired during a historic growth cycle and eventually had to correct.

That is a different problem with a different solution.

The solution to “companies overhire during boom cycles” is:

• building financial runway
• maintaining portable skills
• understanding that boom periods are temporary
• not mistaking two good years for permanent stability

The solution to “AI is actively compressing my role category” is understanding which parts of your work are vulnerable to automation and adapting toward the parts that are not.

Conflating those two realities produces bad career decisions.

The tech layoff narrative of 2025 has a villain.

And the villain is AI.

It is a convenient story.

It is not the whole story.

Most of what happened was boring old business: companies that grew too fast, operated as though cheap capital would last forever, and eventually had to reverse decisions that only made sense inside a temporary economic environment.

AI is changing the industry.

That part is real.

But a lot of executives discovered something else at the same time:

“AI transformation” sounds much better in an earnings call than “we massively overhired and now need to cut costs.”

One of those stories sounds inevitable.

The other sounds avoidable.

If this hit close to home, subscribe to the newsletter for more honest conversations about software development, leadership, AI, and the realities nobody likes putting in investor decks.

You can also find me on LinkedIn and Instagram.

Every time a company loses good people, the post-mortem sounds the same.

Compensation wasn't competitive. The role lacked growth opportunities. The culture wasn't a fit. The remote work policy changed.

All reasonable explanations.

All too often, covering for the same underlying problem.

The data keeps pointing at something simpler and more uncomfortable: most people don't leave companies. They leave managers. And the tech industry has spent years optimizing for everything except the quality of the people it puts in charge of other people.

A 2025 tech worker sentiment survey from Lenny's Newsletter, covering a large cross-section of developers and tech professionals, found that workers with ineffective managers are 4.3 times more likely to be actively looking for a new job. Not slightly more likely.

4.3 times.

Those same workers reported 31% more burnout and 62% less job enjoyment than peers with effective managers.

That's not a compensation problem.

That's a management quality problem that companies are trying to solve with snack bars and unlimited PTO.

What the Numbers Actually Say

The same survey found that only 26.6% of tech workers rated their manager as highly effective.

Read that again.

Less than one in three people in tech think their manager is doing the job well.

And that manager, the one most people do not think is doing the job well, is the single biggest lever on whether those people stay, perform, disengage, or burn out.

People with great managers are:

• 48% more engaged
• 63% more likely to feel belonging
• 8.2 times more likely to feel committed to their role

The difference between a good manager and a bad one is not marginal.

It is enormous.

It shapes how people feel about showing up to work every morning.

And yet when retention numbers slip, the instinct is still to look at compensation bands. Run another salary survey. Add a flexible Friday policy. Expand the wellness budget.

None of that fixes a bad manager.

How Bad Managers Stay in Place

The uncomfortable part is not that bad managers exist.

Every organization has them.

The uncomfortable part is how they stay.

Tech companies have a long tradition of promoting their best individual contributors into management. The logic sounds reasonable: great engineer, probably capable of leading engineers.

Except that those are genuinely different jobs.

Writing good code requires focus, precision, technical depth, and autonomy. Managing people requires almost the opposite instincts:

• patience
• communication
• emotional awareness
• conflict resolution
• the ability to prioritize someone else's growth over your own output

Most companies do not train people for that transition. They announce the promotion, hand someone a slightly bigger laptop stand, add meetings to their calendar, and assume the rest will work itself out.

It usually does not.

Bad managers also do not always look bad from the outside.

They hit milestones.

They sound polished in leadership meetings.

They know how to explain delays in ways that feel reasonable.

Meanwhile, the damage shows up elsewhere:

• 1-on-1s that quietly stop happening
• feedback that never gets delivered
• priorities that constantly change
• team members disengaging one at a time
• people quietly polishing their resume at 11 PM

One of the most dangerous things bad managers create is organizational blindness.

Leadership thinks the team is healthy because the dashboards are green and the deliverables are technically shipping. Meanwhile, the actual team mentally checked out three quarters ago.

By the time the attrition numbers finally register, the best people are already gone.

The Promotion-Driven Trap

There is another layer to this problem that does not get talked about enough.

A lot of companies promote visibly ambitious people over people who are actually good at leadership.

The ambitious ones know how to manage upward. They know how to present their work, position themselves in important conversations, and stay visible to senior leadership. That is a career skill.

It is not the same thing as developing other people.

Many organizations conflate visibility with leadership potential. The loudest person in the room is often perceived as the most capable.

Those are not remotely the same thing.

Some of the best managers I have seen in tech were people who stayed in their lane, did excellent work with no drama, and quietly made everyone around them better. They listened well. They coached well. They created calm instead of noise.

They usually did not get promoted the fastest.

In some organizations, they did not get promoted at all because they were not running the political game.

Meanwhile, the person who dominates every meeting and makes sure leadership always knows their name ends up managing a team of twelve.

Then the organization pretends to be surprised when turnover increases.

What Good Management Actually Looks Like

This is not a mystery.

The survey data is remarkably consistent across years and companies.

Good managers give real feedback. Not performance review language. Not vague encouragement. Honest and specific input that a person can actually use to improve.

They protect their team's time and attention.

They fight for resources when resources are needed and tell the truth when the answer is no.

They create space for people to do their best work and then get out of the way.

Good managers create leverage.

Bad managers create friction.

Teams end up spending enormous amounts of energy compensating for leadership problems instead of solving engineering problems.

Good managers also show up consistently.

Not in a performative way.

In a "I genuinely understand what is happening with this person's work, goals, frustrations, and career trajectory" kind of way.

The workers in Lenny's survey who rated their managers as highly effective were dramatically more likely to feel understood and actively supported in their growth.

That is not complicated.

It is just rare.

Mostly because it requires consistency, attention, humility, and emotional maturity more than charisma.

Strong managers also create environments where people feel safe being honest.

Teams with weak managers stop taking risks. People stop challenging bad ideas. Honest conversations disappear because employees learn that visibility creates problems instead of support.

That silence spreads until the entire team starts optimizing for self-protection rather than great work.

What This Means for Organizations

If your retention is struggling, start with your managers before you start with your compensation study.

Look carefully at who you promoted and why.

Were those people selected because they are good at developing others?

Or because they were good at developing their own career?

Those are very different skills.

Invest in manager training that is more meaningful than a one-day HR workshop. Have real conversations about leadership expectations, conflict management, accountability, communication, and what healthy team environments actually look like.

Manager evaluations should also include meaningful feedback from the people they manage.

Not a 360 review that gets filed away and forgotten.

Actual feedback that affects how managers are evaluated, coached, promoted, and retained.

And organizations need to become more comfortable acknowledging an uncomfortable truth:

Some excellent engineers should never become managers.

That is not a failure.

Management is a completely different discipline, not a reward tier for strong technical performance.

Companies should normalize removing people from management roles when the fit is wrong, rather than quietly moving them into another leadership title to avoid awkward conversations.

Because when organizations protect ineffective managers from accountability, everyone notices.

Including the people quietly deciding whether to stay.

The retention conversation in tech is mostly noise.

Ping pong tables, snack bars, wellness stipends, and flexible Fridays are nice.

None of them fixes a bad manager.

The data has been clear for years, and many organizations avoid the conversation because the solution requires candid assessments of current leadership.

Your best engineers are probably not leaving because of the remote work policy.

They are leaving because someone is not doing right by them.

And that someone probably has a calendar full of one-on-ones they are not really running.

Organizations spend enormous amounts of money trying to retain talent while avoiding the conversation most likely to solve the problem:

The quality of the people managing that talent.

Eventually, employees stop waiting for leadership to notice.

They just leave.

If this hit close to home, subscribe to the newsletter for more honest conversations about software development, leadership, and the realities that nobody likes to talk about openly.

You can also find me on LinkedIn and Instagram.

The code worked.

It passed the tests. It even looked reasonable in the PR review. Nobody flagged anything because everyone was moving fast, and the AI had done most of the work.

Then production happened.

Production always tells the truth eventually.

And suddenly, the engineers responsible for that system were staring at a failure they couldn't fully explain, in a codebase they didn't fully understand, trying to debug logic that nobody had actually written with intention.

This is the vibe coding hangover.

It arrived right on schedule.

What Vibe Coding Was Supposed to Be

The term was coined by AI researcher Andrej Karpathy in early 2025. Collins English Dictionary named it their Word of the Year. The idea is simple: describe what you want, accept what the AI generates, paste the next error message, repeat.

You're not reviewing the code deeply.

You're trusting that the AI probably handled it correctly.

For side projects and prototypes? Completely reasonable. You're learning, experimenting, and optimizing for speed while the stakes are low.

For production systems at scale?

You're gambling.

The problem was that the line between "prototype energy" and "production code" got blurry very quickly. Companies started tracking lines-of-code output and sprint velocity. Executives saw demos and immediately started asking why entire teams were not moving that fast. The pressure to ship created pressure to use AI tools aggressively, and the warnings about code quality got quieter because they were slowing things down.

By the end of 2025, 41% of global code was being generated by AI.

By early 2026, the consequences were showing up in production.

What the Data Actually Shows

Here is the part that got far less attention than the productivity headlines.

In August 2025, Final Round AI surveyed 18 CTOs about vibe coding. Sixteen of them reported production disasters directly caused by AI-generated code. These are not junior developers experimenting on side projects. These are the people responsible for keeping critical systems running.

A July 2025 randomized controlled trial by METR asked experienced open-source developers to work on real issues with and without AI tools. The developers predicted they would be 24% faster with AI. Afterward, they believed they had been roughly 20% faster.

They were actually 19% slower.

That perception gap matters.

People felt more productive. They moved with more confidence. They shipped things faster. And the output was worse by objective time measurement on realistic production tasks.

GitClear analyzed 211 million lines of code changes from 2020 to 2024 and found that AI adoption correlated with a fourfold increase in code duplication. Security vulnerabilities in AI-generated code ran at 2.74 times the rate of human-written code.

The speed is real.

The quality cost is also real.

Most companies were only measuring the speed.

Why "Working Code" Is Not the Same as Good Code

This is the part of the conversation the industry keeps skipping.

Working code means it passes tests and does not immediately fail. It does not mean it is secure. It does not mean it is maintainable. It does not mean another developer can open it six months later and understand what they are looking at. It does not mean it will survive traffic spikes, operational edge cases, or business requirements that evolve over time.

A lot of AI-generated code is, as one developer put it, "fast but flawed."

The AI produces something that covers 90% of the solution quickly. The remaining 10%, the edge cases, the security considerations, and the architectural fit with the existing system, require human judgment and domain knowledge that the AI does not actually possess.

The dangerous part is that the 90% looks finished.

It compiles.

It runs.

It gets merged.

The 10% shows up later as:

• a production incident at 2 AM
• a security audit finding
• a scaling failure under real traffic
• or a codebase that becomes increasingly fragile until eventually nobody wants to touch it anymore

One of the hidden dangers of AI-assisted development is the ownership gap it creates. Engineers can merge code they conceptually understand without fully understanding how the implementation behaves under stress, at scale, or in failure conditions.

That becomes a massive problem during debugging.

Writing code quickly is valuable.

Understanding failures quickly is more valuable.

Production systems are usually judged by the second one.

The Junior Developer Parallel

There is a useful analogy here that connects directly to the junior hiring problem.

You would not take a junior engineer's pull request and deploy it to production without review. You would read it carefully. You would ask questions. You would push back on decisions that did not fit the system.

Not because the junior developer is incompetent.

Because they are new.

They lack context about the specific architecture, the business constraints, the operational history, and the failure modes that the team has already learned the hard way.

AI-generated code has the same problem, except AI is not new. It is drawing from billions of lines of public code:

• some excellent
• some terrible
• some outdated
• some actively dangerous

When you ask it to generate authentication logic, there is a very real possibility that the output is vulnerable, outdated, or architecturally wrong for your environment.

If you do not have the knowledge to recognize that, you have directly converted confidence into technical debt.

Treat AI like a very fast junior developer who has read everything and worked on nothing specific to your system.

Review it accordingly.

The Responsible Version of AI-Assisted Development

None of this means AI coding tools are bad.

They are genuinely useful.

They are excellent at:

• scaffolding
• accelerating research
• handling repetitive boilerplate
• generating initial implementations
• surfacing patterns developers can evaluate and adapt

The question is never whether to use AI.

The question is whether you are using it with or without surrendering your judgment.

The companies using AI effectively tend to have a few things in common:

• code review standards that apply just as rigorously to AI-generated code as human-written code
• developers with enough system depth to recognize when suggestions do not fit the architecture
• explicit awareness that speed is only one engineering metric among many
• strong operational maturity around testing, observability, and debugging

And most importantly, they still treat engineering understanding as mandatory.

Imagine an AI-generated authentication flow.

The tests pass.

Login works.

The API returns tokens correctly.

But the AI quietly implemented token validation in a way that allows replay attacks under certain conditions. Or it skipped proper rate limiting. Or it introduced a subtle privilege escalation issue because the examples it learned from were outdated.

Nothing looks broken during development.

The problem only appears when somebody intentionally abuses the system.

Or imagine the AI generates a database query that works perfectly in staging with ten thousand records, but collapses in production because nobody noticed the missing indexing strategy or the risk of query explosion under real traffic.

Again, the code technically worked.

Until reality showed up.

Traditional code review assumed the developer writing the code understood why major implementation decisions were made. AI-assisted development changes that assumption. Reviewers increasingly have to verify not only whether the code works, but whether the developer merging it actually understands what the AI generated.

That is a fundamentally different review process from the one most teams were trained for.

That is also why experienced engineering judgment still matters more than ever.

That relationship with AI is very different from vibing your way through production work.

It is also how you avoid the 2026 hangover.

The Bill Is Coming Due

In 2025, the narrative was about how fast AI let teams ship.

In 2026, the narrative is starting to shift toward what "fast" actually cost.

Production instability in systems nobody fully understands.

Security vulnerabilities that survived review because no human had deeply analyzed the implementation.

Technical debt accumulating not in slow motion, but at the pace of AI-assisted sprint cycles.

This was predictable.

A lot of people predicted it.

The industry does this repeatedly. A new tool appears, skepticism gets labeled as resistance, the early excitement sets expectations, and then the operational consequences arrive later while everyone acts surprised.

Vibe coding is not the problem.

Vibing your way to production without understanding what you shipped is the problem.

AI can generate code at extraordinary speed.

Accountability still moves at human speed.

And eventually, somebody has to own what ships to production.

If this hit close to home, subscribe to the newsletter for more honest conversations about software development, leadership, AI, and the realities nobody likes putting in investor decks.

You can also find me on LinkedIn and Instagram.

Nobody in tech is surprised by burnout anymore.

That should terrify leadership teams.

We've normalized it so thoroughly that people are apologizing for being exhausted. Senior engineers are withdrawing from collaborative work and framing it as "setting boundaries." Mid-level leads are going quiet in meetings, and everyone assumes it's just their personality. The team still delivers, but the energy behind the delivery has been gone for six months.

That is part of what makes burnout dangerous in engineering organizations. The work often continues long after the people doing it have mentally checked out.

According to LeadDev's 2025 Engineering Leadership Report, 22% of engineering leaders and developers are experiencing critical burnout. Another 24% are moderately burned out. That means nearly half of the people running technical work at your company are operating somewhere between "running on empty" and "one bad sprint away from quitting."

This is not a wellness problem.

This is a structural leadership failure that the industry keeps rebranding as a culture initiative.

What Burnout Actually Is (And Isn't)

Burnout is not stress.

Stress is temporary. You feel it before a deadline, during a difficult project, in the middle of a bad week. It resolves when the pressure eases.

Burnout is chronic. Psychologists define it across three dimensions: emotional exhaustion, depersonalization (the cynicism, the detachment, the "I just don't care anymore"), and reduced personal efficacy, the feeling that your work doesn't actually matter.

In tech, it shows up as senior engineers who stop volunteering for anything. Developers who used to push back on bad decisions and now just say "sure." Leaders who have stopped fighting for their teams because they've lost confidence that it will make a difference.

It shows up in the emotional flatness of people who used to care deeply about the quality of their work.

It differs from stress because you don't push through it.

It pushes through you.

Why Tech Teams Are Especially Vulnerable

The always-on culture in tech is structural, not accidental.

Software systems don't care what day it is. Production doesn't pause for holidays. On-call rotations bleed into personal time. Incidents happen at 2 AM regardless of what's on the calendar. And over time, the expectation that you're always available becomes indistinguishable from the expectation that you're never fully off.

Layer on top of that: the AI efficiency push.

Executives saw productivity demonstrations and started asking why teams couldn't move twice as fast. Roadmaps became more aggressive. Headcount became leaner. The same number of people, sometimes fewer, were now expected to deliver more, faster, with the implicit assumption that AI tools would make up the difference.

AI tools were marketed as productivity multipliers. In many organizations, leadership interpreted that as permission to permanently increase workload without increasing recovery time, staffing, or operational maturity.

What got lost in that math is human cognitive capacity.

Context-switching is expensive. The mental overhead of holding five active priorities simultaneously doesn't scale linearly. When everything is labeled critical, people lose the ability to focus. Productivity drops. Quality drops. And burnout sets in quietly, until the point when key people start leaving, and everyone acts surprised.

The Leadership Response Has Been Almost Entirely Wrong

Here is where it gets frustrating.

Most companies have responded to the burnout crisis with programming. Wellness apps. Mental health days. Mindfulness workshops. "Take care of yourself" messaging in the all-hands.

None of that addresses the workload.

If your team is burned out because they have too much to do with too little support, adding a meditation app to the benefits package does not change the structural problem. It signals that the company has noticed the symptoms and chosen to treat them cosmetically rather than address the cause.

A meditation app does not help much when the underlying problem is that the organization has built a system in which people are expected to sprint forever.

The cause is almost always one or more of the following:

• chronic understaffing
• unrealistic delivery expectations
• poor prioritization that puts everything at the same urgency level
• leadership that confuses visible effort with actual progress
• organizational processes that generate noise without producing decisions

These are fixable problems.

They require leadership to make hard calls about scope, staffing, deadlines, what actually matters, and what gets cut. That is harder than deploying a wellness app. It requires leaders to have uncomfortable conversations with their own leadership about what the team can realistically deliver.

Most leaders skip that step.

They offer the wellness app instead.

What Actually Reduces Burnout

The things that work are mostly boring.

Realistic capacity planning. Sprints built on historical velocity instead of optimism. Pushing back on stakeholder demands that cannot be absorbed without compromising team health. Actually protecting focus time instead of putting it on the calendar and immediately filling it with meetings.

Healthy engineering teams also need slack capacity.

Time to think. Time to improve systems. Time to document processes. Time to mentor junior developers. Time to recover after difficult incidents. Organizations operating at maximum capacity are effectively redlining human beings, just as they would redline production infrastructure.

Nobody would intentionally run a critical production system at 100% resource utilization twenty-four hours a day and expect it to remain stable forever.

For some reason, companies regularly expect that from people.

One-on-ones matter too, but only when they involve real conversations.

Not "how are you doing?" as a formality.

Leaders should be listening for the signals: withdrawal, cynicism, disengagement, irritability, silence from people who used to contribute heavily, or the developer who suddenly stops caring about things they once fought hard to improve.

Burned-out teams stop communicating honestly. People stop escalating risks early because they no longer believe transparency will lead to support. Problems go unnoticed until they become unavoidable because everyone is too exhausted to have another difficult conversation.

That is not a communication issue.

That is an organizational trust issue.

Prioritization also has to mean something real. Not a backlog where everything is P1. An honest conversation about what matters most and what can wait, communicated clearly so the team can focus without constantly second-guessing priorities.

And recovery time has to be treated realistically.

Teams that spend three days fighting a production incident and are still expected to deliver the exact same sprint commitments afterward are not being managed realistically. You cannot absorb operational chaos without adjusting expectations somewhere else.

Eventually, the math catches up.

Then there is the operational friction everyone learns to tolerate because "that's just how things work here."

The test suite that breaks every third run.

The deployment process that takes six hours because nobody ever had time to fix it.

The documentation nobody trusts because it hasn't been updated since 2022.

These are not just technical debt.

They are morale debt.

Technical debt slows systems down.

Morale debt slows people down.

Eventually, one becomes the other.

Every time a developer has to work around a known broken process, it costs energy that does not show up in a sprint report but absolutely shows up in burnout levels six months later.

The Part Nobody Wants to Hear

The industry has been talking about burnout as though it's a developer problem.

It isn't.

Developers are not burning out because they lack resilience, self-awareness, or the right journaling habit. They are burning out because the systems they work inside are poorly designed, and the people responsible for those systems are not being held accountable for fixing them.

Twenty-three percent of tech workers cite poor leadership as the main source of burnout at their organization. Nineteen percent cite work overload.

Both of those are leadership problems.

The wellness app didn't cause burnout.

The wellness app also won't fix it.

The thing that fixes it is leaders who are honest about what their teams can actually handle, who protect that capacity even when it's inconvenient, and who make the unglamorous structural changes that allow people to do good work without breaking down in the process.

Burnout is not the cost of doing business in tech.

It is usually the cost of leadership decisions.

And leaders who treat exhausted teams like an unavoidable industry norm are eventually going to discover that burned out organizations stop building great things.

If this hit close to home, subscribe to the newsletter for more honest conversations about software development, leadership, and the realities nobody likes putting in investor decks.

You can also find me on LinkedIn and Instagram.

The tech industry finally figured out how to solve the junior developer problem.

The solution, apparently, was to stop hiring junior developers entirely.

Entry-level hiring at the fifteen largest tech companies has dropped over 50% in three years. Software developer employment for workers aged 22 to 25 has fallen nearly 20% since ChatGPT launched. Internship postings are down 30% since 2023. CS graduates are sending hundreds of applications and landing almost nothing.

Meanwhile, every company has a press release about their AI transformation.

Nobody is connecting those two sentences out loud. So let's do it here.

Why This Is Happening (And It's Not an Accident)

The math is not complicated.

A senior developer with GitHub Copilot or Cursor now ships what used to require a senior developer plus a junior developer. Companies figured this out around 2024 and started quietly freezing junior headcount while loudly announcing “AI efficiency initiatives” in earnings calls and investor decks.

One senior developer plus an AI subscription costs roughly $180,000 a year.

One senior developer plus one junior developer costs roughly $265,000 a year.

That is an $85,000 gap per team. Multiply that across 200 teams and suddenly you have a $17 million “optimization opportunity” that looks fantastic in a quarterly review deck.

That math wins almost every budget meeting.

The problem is that the math only works in the short term.

It completely ignores what you lose.

What Junior Roles Actually Did

Junior developer roles were never just cheap labor. They were the training ground for the entire industry.

You learned how production systems actually behave. Not the happy path. The 2 AM pages, the upstream dependency that silently breaks every six months, the business requirement that contradicts itself by page three. You learned to communicate with non-technical stakeholders without sounding like a Wikipedia article. You learned to take feedback without treating it as a personal attack.

You learned how to estimate work badly, then slightly less badly, then eventually well enough that people trusted your judgment. You learned that technical skill alone is not enough when priorities change mid-project and nobody agrees on what “done” actually means.

You learned how to fail on things that did not matter yet, so you knew how to handle it when something real was on the line.

That experience does not transfer from an AI coding assistant. It accumulates through repetition, ownership, debugging, mistakes, awkward conversations, production incidents, and having someone more experienced nearby who is willing to explain why your solution technically worked but was still the wrong decision.

Companies have stopped providing that environment.

They just expect everyone to arrive fully formed.

Software Development Was Always an Apprenticeship

The industry does not like admitting this because engineering culture loves pretending everything is purely meritocratic and self-taught, but software development has always functioned like an apprenticeship model.

A junior developer joins a team and slowly absorbs the invisible parts of the job.

How to navigate ambiguity.

How to debug systems you did not build.

How to communicate during outages without making things worse.

How to review code without sounding like a jerk.

How to disagree professionally.

How to recognize when a quick fix is about to become six months of technical debt.

None of that comes from tutorials.

None of that comes from asking ChatGPT to explain Kubernetes for the fifteenth time.

Those skills develop through exposure, repetition, feedback, and mentorship over years of real work.

Software development was never supposed to be a solo activity where someone graduates on Friday and independently designs production systems on Monday. The industry functioned for decades on apprenticeship, whether we formally admitted it or not.

Now companies are quietly removing the apprenticeship stage while still expecting senior-level outcomes later.

That is not how human skill development works in any profession.

The Senior Developer Problem Nobody Is Talking About

Here is the thing nobody wants to say at the all-hands.

The senior developers companies rely on today are the junior developers somebody hired ten years ago.

If companies stop hiring juniors in 2025 and 2026, they will not magically have enough senior developers in 2033 and 2034. The pipeline does not refill itself. Experience does not spontaneously generate because a recruiter increased the salary range.

The judgment takes years to calibrate.

The communication skills take years to refine.

The instinct for recognizing dangerous decisions before they explode in production takes years to develop.

You cannot fast-track that with a prompt window.

One AWS executive said it plainly in 2025:

“How's that going to work when ten years in the future you have no one that has learned anything?”

He was talking about the junior hiring freeze.

He was ignored.

AI Did Not Remove the Work

There is another reality most engineering leaders quietly know but rarely say publicly.

AI did not remove complexity.

It shifted complexity.

Senior engineers are now expected to:

• ship faster
• own larger systems
• review more code
• validate AI-generated output
• mentor fewer but more overwhelmed juniors
• attend more meetings
• handle more architectural responsibility
• move faster with fewer people

Companies are treating AI like it permanently increases engineering capacity. In practice, many senior developers are simply absorbing additional expectations while leadership assumes productivity gains are infinite.

That works right up until burnout shows up.

And burnout always shows up eventually.

The Career Ladder Now Has a Missing Bottom Rung

There is another problem here, and it is more human than financial.

A generation of people went to school specifically to work in tech. They were told, reasonably, that software development was a stable career with strong long-term demand. They graduated into a market that quietly removed the entry-level positions while they were still in their final semesters.

The unemployment rate for recent US computer engineering graduates is currently 7.5%. Computer science graduates are at 6.1%. Both are well above the overall US unemployment rate.

This is not a skills gap.

These are qualified people struggling to get interviews because the industry changed the rules halfway through the game.

And before someone comments “just learn AI tools,” most of them already have.

AI fluency is now table stakes, not a differentiator. It did not solve the structural hiring freeze. It simply raised the expectations while the openings continued disappearing.

The ladder still exists.

It just does not have a bottom rung anymore.

What Responsible Companies Are Actually Doing

Not every company is handling this the same way.

Some engineering leaders have pushed back directly against the idea that AI should replace junior hiring. Not because they are anti-AI. Because they understand how organizations survive long term.

Responsible companies are treating AI as a force multiplier for learning, not a replacement for learning.

The best engineering organizations are using AI tools to help junior developers ramp up faster while still pairing them with experienced engineers who can provide context, judgment, and mentorship.

Because the goal was never just generating code faster.

The goal was developing engineers capable of making good decisions.

Companies that maintain healthy junior pipelines tend to do a few things differently:

• structured mentorship instead of “figure it out”
• collaborative code reviews instead of silent rejection
• gradual ownership increases
• clear feedback loops
• protected learning opportunities
• realistic expectations around growth timelines

They understand something many executives currently do not.

Training junior developers is not charity.

It is succession planning.

It is institutional stability.

It is long-term risk management.

Companies eliminating junior pipelines are effectively betting they can hire experienced talent later from organizations that continued investing in people.

That strategy only works if someone else keeps doing the hard part.

The Uncomfortable Conclusion

The industry made a short-term financial decision and branded it as strategic transformation.

Cutting junior developer headcount because AI tools improve individual productivity is roughly equivalent to a hospital shutting down its residency program because experienced surgeons already exist.

Technically defensible in a spreadsheet.

Obviously catastrophic once you think longer than two quarters ahead.

The pipeline matters.

The people currently locked out of the industry are not failed engineers.

They are future senior developers who never got the chance to become one.

And the companies refusing to invest in them today may eventually discover they optimized themselves directly into a talent shortage they can no longer fix.

If this hit close to home, subscribe to the newsletter for more honest conversations about software development, leadership, and the realities nobody likes putting in investor decks.

You can also find me on LinkedIn and Instagram.

There is a certain image people have in mind when they think about technology leadership.

Perfectly polished LinkedIn posts.
Corporate buzzwords.
Endless meetings where people somehow talk for thirty minutes without actually saying anything.

Nick Mullins does not fit that mold. Intentionally.

After more than a decade in the software industry, moving from developer to leadership while building teams, mentoring engineers, and navigating the chaos that comes with modern tech, he has developed a reputation for being honest, practical, sarcastic when necessary, and unapologetically authentic.

No fake executive personality.
No motivational-speaker act.
No pretending the industry is perfect.

Just real conversations about software development, leadership, burnout, AI, and the reality of working in tech.

Ironically, this interview started with AI.

I asked AI to read through my blog posts, understand my tone and opinions, and then interview me about technology, leadership, burnout, authenticity, AI, and the modern software industry.

What came out of it felt less like a polished corporate interview and more like the kinds of conversations developers and leaders actually have behind closed doors.

Not the polished version of leadership people post online.

The real version.

The messy version.

The human version.

“I purposely chose not to fit the mold.”

Q: You’ve been in tech for over a decade now and worked your way into leadership, but you don’t really present yourself like the stereotypical tech executive. No blazer. No ‘synergy.’ No LinkedIn influencer energy. Was that intentional?

Absolutely.

I purposely chose not to fit the mold. I have had leaders who were balls of corporate fluff, and I did not like that. Speaking a lot of words, but saying very little.

It is not my style.

Once I developed my own style, I went with it. I embraced it.

I have had this personality and style for a long time, and I have been promoted numerous times, so something is clearly working.

There is this weird pressure in tech leadership where people feel like they need to transform into a completely different person the moment they become a manager or director. Suddenly, they start dressing differently, talking differently, acting differently. Every sentence becomes corporate jargon.

People notice that.

Teams notice when someone stops sounding human.

That does not mean professionalism is not important. It absolutely is. But professionalism and authenticity are not opposites.

You can be kind, honest, direct, supportive, and still sound like yourself.

Too many people think leadership means performing.

I think leadership works better when people trust that you are genuine.

“The industry tries to treat everyone the exact same.”

Q: What do you think the tech industry gets completely wrong about leadership?

The industry tries to treat everyone the exact same.

You need to treat people equally, but every individual is different, so you need to adjust your leadership style to fit their needs.

Some people need encouragement. Some need clearer direction. Some need autonomy. Some need help managing priorities. Some need confidence.

Leadership is not copy-and-paste.

I also think a lot of tech leaders drink the company Kool-Aid a little too hard.

No company is perfect.

None.

Every company has flaws, bad processes, communication problems, technical debt, and decisions that do not make sense. Pretending otherwise just destroys trust.

Some leaders treat criticism of the process as a personal attack on the company. Meanwhile, the engineering team is drowning in problems everybody can clearly see.

The best leaders I have worked with were honest about reality.

Not negative. Not cynical. Just honest.

There is a huge difference.

Burnout, Pressure, and the Myth of the 10x Developer

Q: Do you think the industry has gotten worse when it comes to burnout and unrealistic expectations?

I do.

Companies are always chasing the mythical 10x developer or whatever the buzzword is now.

There is constant pressure to deliver faster, faster, faster.

And now AI and vibe coding have entered the conversation, which adds even more pressure because executives start wondering why everything cannot happen instantly.

But you do not need 10x developers.

You need solid developers who consistently get things done.

The industry romanticizes rockstar engineers, but most successful teams are not built on superheroes. They are built on dependable people who communicate well, solve problems, support teammates, and deliver consistently.

That matters way more than people think.

A lot of burnout comes from companies constantly trying to squeeze more output from fewer people while pretending it is innovation.

There is a limit to how much context-switching, pressure, and unrealistic expectations people can handle before they mentally check out.

Developers are not machines.

Even the really good ones.

“AI is just another tool in the toolbox.”

Q: What’s your actual opinion on AI in software development?

I think AI will absolutely help developers get things done faster, but only if it is used the right way.

A lot of people think AI is a replacement for developers.

It is not.

It is another tool in the toolbox.

AI can help speed up research and documentation, handle repetitive tasks, and even help brainstorm solutions. That is valuable.

But developers still provide the context.

Developers understand use cases, business requirements, deadlines, edge cases, constraints, technical debt, stakeholder concerns, and the weird real-world problems that arise in software systems.

Software development is not just about generating code.

Real systems are messy.

Requirements change constantly. Businesses contradict themselves. Legacy systems exist. Deadlines shift. Priorities change.

AI does not walk into a meeting and realize:
“This feature request is going to break three downstream systems and make accounting furious.”

Experienced developers understand that context.

That matters more than people realize.

I think AI will make good developers faster.

I do not think it eliminates the need for developers.

The Problem With How Companies Promote Leaders

Q: What actually gets people promoted in tech leadership?

Honestly, it depends entirely on the company.

Some companies promote people who drink the company Kool-Aid.

Some promote based on tenure.

Some promote developers into leadership because they were strong individual contributors.

But far fewer companies promote someone because they are genuinely a great fit for leadership.

That is a huge issue in tech.

Being a great engineer and being a great leader are not the same skill set.

One role is heavily technical.

The other is heavily human.

You are suddenly dealing with communication, motivation, conflict resolution, prioritization, burnout, trust, expectations, business strategy, and team dynamics.

Some people love that transition.

Some hate it.

Some never should have been pushed into it in the first place.

Leadership should not be treated as just the next level of engineering progression.

It is a completely different job.

“Rarely do people need help with the tech.”

Q: Was there a moment where leadership really clicked for you?

I think it happened when the number of people reporting to me kept growing, and I stepped further outside the technology itself.

That is when I realized that people rarely actually need help with the tech.

They need help managing everything around the tech.

That changes your perspective.

Much of leadership is about removing chaos.

Helping people prioritize.

Helping communication.

Reducing unnecessary stress.

Creating an environment where people can actually focus and do good work.

Most engineers are capable of figuring things out technically.

The harder part is navigating everything surrounding the work.

There Is No Such Thing as Perfect Code

Q: What’s something you believed earlier in your career that you completely disagree with now?

At some point, I probably believed perfect code existed.

Or that bug-free software existed.

I do not believe that anymore.

There are many different ways to solve problems.

Some may be more efficient or optimized, sure, but optimization is not the only thing that matters.

Now I realize software development is about solving problems in the best way possible while considering all the variables:

• deadlines
• budget
• team capacity
• maintainability
• business needs
• technical debt

You can build the most elegant system imaginable and still fail because it missed the business need entirely.

Perfection is not the goal.

Solving the right problem effectively is.

That mindset changes how you approach development over time.

You stop trying to win architecture beauty contests and start focusing on outcomes.

“You do not need to become a fake version of yourself.”

Q: What would you say to people in tech who feel like they need to completely change their personality to be taken seriously?

If you change your personality, you are no longer you.

And honestly, people can usually tell when someone is faking it.

Embrace your personality.

Maybe tone it down slightly if needed in certain situations, sure, but you do not need to become a fake corporate version of yourself to lead effectively.

You need to:

• be kind
• be honest
• genuinely care
• communicate clearly
• treat people well

That matters far more than pretending to be some polished executive stereotype.

People trust authenticity.

Especially in tech.

Most teams are exhausted from fake positivity and performative culture.

They want honesty.

They want leaders who sound human.

What Younger Developers Should Actually Focus On

Q: What should younger developers focus on more?

Many younger developers already focus heavily on the technical side.

Sometimes too heavily.

There is this pressure online where people think they need to know every framework, every language, every trend.

That is impossible.

I think developers should spend more time improving the less technical skills:

• explaining technical concepts to non-technical people
• writing good documentation
• reading logs effectively
• understanding systems
• communicating clearly

Those skills matter enormously in real-world development.

Software engineering is not just writing code.

A huge part of the job is understanding problems, communicating solutions, and navigating complexity.

Honestly, learning how to read logs and documentation properly will probably put someone ahead of a surprising number of developers.

A lot of software development is basically detective work.

“Everyone has a little impostor syndrome.”

Q: What do you hope people take away from your writing on mullins.io and LeadDontCtrl.com?

I want people to know that there are leaders out there who genuinely care about both people and work.

Not everyone is a corporate shill.

There are leaders who want healthy teams, honest communication, sustainable workloads, and realistic expectations.

I also want people to realize that the stress and concerns they feel are not unique to them.

Everyone, if they are honest with themselves, has at least a little impostor syndrome.

Even experienced people.

Even leaders.

Most people are figuring things out as they go more than they admit publicly.

That is normal.

I think the industry would be healthier if people talked about that more honestly.

Final Thoughts

Technology changes constantly.

Frameworks come and go.
AI evolves.
Trends explode overnight.
Buzzwords cycle endlessly.

But the human side of the industry remains surprisingly consistent.

People still want:

• meaningful work
• supportive leadership
• realistic expectations
• growth opportunities
• trust
• honesty
• balance

Maybe that is why authenticity matters so much.

Because in an industry full of noise, people can still recognize when someone is real.

And maybe that is the entire point.

If this resonated with you, feel free to connect with me on LinkedIn or explore more writing at mullins.io and LeadDontCtrl.com.

The tech industry does not need more corporate noise.

It needs more honest conversations.

AI Is a Tool. Stop Treating It Like a Replacement for Thinking.

Everybody wants the shortcut.

That is the real story behind the AI boom.

Not innovation.
Not productivity.
Not transformation.

Shortcuts.

People want faster code. Faster content. Faster debugging. Faster delivery. Faster promotions. Faster startups. Faster everything.

And honestly? I get it.

Software development has always been a pressure cooker. Deadlines pile up. Requirements change halfway through implementation. Leadership wants estimates you cannot realistically provide. Production incidents appear at 2:13 AM because somebody somewhere decided Friday at 4 PM was the perfect time for a deployment.

Now generative AI shows up, and suddenly developers can scaffold APIs in seconds, generate tests instantly, summarize logs, write SQL queries, build documentation, and explain obscure frameworks without opening fifteen Stack Overflow tabs.

Of course, the industry exploded.

The tools are genuinely useful.

That part is true.

But somewhere along the way, a dangerous mindset began to creep into engineering culture.

People stopped treating AI like a tool.

They started treating it like a substitute for understanding.

That is where things start going sideways.

Because AI can absolutely help you write software.

It can also help you build an unmaintainable dumpster fire faster than ever before.

And the scary part?

Some developers cannot tell the difference anymore.

AI Is the New Calculator Problem

When calculators became common in schools, people panicked.

"Kids will never learn math."

Then Google arrived.

"People will never remember anything anymore."

Then Stack Overflow exploded.

"Developers are just copying code they do not understand."

Now that AI has entered the room, we are hearing the same argument again.

Some of those concerns are exaggerated.

Some are absolutely valid.

Here is the reality:

Good developers use AI the same way good developers use Google.

As leverage.

Not as a replacement for judgment.

The problem is not using AI.

The problem is surrendering your brain to it.

There is a massive difference between:

“I used AI to help brainstorm an architecture pattern.”

…and

“I pasted code into production because the robot sounded confident.”

Confidence is cheap.

LLMs are extremely good at sounding correct.

That does not mean they are correct.

Sometimes they are brilliant.

Sometimes they hallucinate entire libraries.

Sometimes they introduce security vulnerabilities that would cause a junior engineer to fail an internship review.

And sometimes they produce code that technically works while quietly setting your future team on fire.

That last one is the dangerous category.

Because broken code gets caught.

Fragile systems often survive just long enough to become everybody else’s problem.

"Vibe Coding" Is Not Engineering

There is a trend floating around the industry right now where people brag about barely touching code anymore.

They prompt.

They regenerate.

They copy.

They paste.

They call it "vibe coding," as if it were some revolutionary evolution in software development.

Listen.

Are you experimenting with side projects? Fine.

If you are prototyping? Cool.

If you are learning? Totally reasonable.

But if you are building production systems without understanding the code being generated, you are not engineering.

You are gambling.

And eventually the house wins.

The problem with blindly trusting AI-generated code is not just technical debt.

It is intellectual debt.

You slowly stop developing problem-solving skills.

You stop learning why systems behave the way they do.

You stop understanding tradeoffs.

You stop recognizing bad patterns.

Then one day, production breaks.

The AI output no longer works.

And suddenly you are standing in the middle of a burning system trying to debug logic you never actually understood.

That is not an AI problem.

That is a craftsmanship problem.

Working Code Does Not Mean Good Code

One of the biggest misconceptions in software engineering is the idea that if code works, it must be acceptable.

No.

Absolutely not.

A surprising amount of terrible software technically works.

Until scale happens.

Until traffic increases.

Until security reviews begin.

Until edge cases appear.

Until another developer has to maintain it.

AI is very good at producing code that appears functional.

That does not mean it is secure.

That does not mean it is maintainable.

That does not mean it is readable.

That does not mean it aligns with your architecture.

And it definitely does not mean it fits your organization’s operational standards.

A lot of AI-generated code feels like somebody speedran Stack Overflow from 2017.

Because in many ways, that is exactly what happened.

The model learned from billions of lines of public code.

Some excellent.

Some terrible.

Some outdated.

Some are outright dangerous.

So if you ask an AI to quickly generate authentication logic, there is a very real chance it gives you something vulnerable, outdated, or architecturally messy.

And if you do not know enough to recognize the problem?

Congratulations.

You just merged technical debt with confidence.

Treat AI Like a Junior Developer

This is probably the healthiest mental model.

AI is an extremely fast junior developer.

Sometimes brilliant.

Sometimes concerning.

Always requiring review.

You would never take a junior engineer’s pull request and immediately deploy it to production without inspection.

So why are people doing exactly that with AI?

A responsible engineer reviews AI-generated code the same way they review human-generated code.

Actually, more aggressively.

Because AI does not truly understand your business context.

It does not take your operational constraints into account.

It does not understand your customers.

It does not understand regulatory requirements.

It predicts.

That is fundamentally different.

The strongest developers I know use AI constantly.

But they use it intentionally.

They ask questions.

They compare approaches.

They validate assumptions.

They challenge outputs.

They use AI to accelerate thinking.

Not to replace it.

Responsible AI Starts With Accountability

There is one rule that matters more than all the others.

You own what you ship.

Not the AI.

Not the prompt.

Not the tooling.

You.

If insecure code reaches production because you copied AI output without understanding it, that is still your responsibility.

If customer data leaks because somebody pasted proprietary information into a public model, that is still your responsibility.

If your AI-generated feature discriminates against users because nobody tested edge cases, that is still your responsibility.

The industry needs to stop acting like AI somehow changes accountability.

It does not.

The keyboard changed.

Responsibility did not.

Bias Is Not Just a Social Problem

When people hear the word "bias" in AI conversations, they often immediately think about politics.

But bias in software systems is broader than that.

Bias appears anywhere systems unfairly favor one outcome over another.

And AI absolutely inherits bias from training data.

Because humans created the data.

Humans are messy.

So the models become messy too.

This matters far beyond social media arguments.

It matters in hiring systems.

Loan approvals.

Healthcare recommendations.

Insurance calculations.

Educational software.

Criminal justice systems.

Search rankings.

Recommendation engines.

Anywhere software influences decisions about people.

A famous example involved the COMPAS recidivism algorithm.

The system attempted to predict which defendants were most likely to reoffend.

The controversy was not just about prediction accuracy.

It was about how errors disproportionately impacted different groups.

That is the kind of thing developers cannot afford to casually ignore.

And before somebody says, “Well, I just build APIs,” remember this:

Every system eventually affects humans.

Even internal tooling.

Especially at scale.

Responsible engineering means testing systems beyond happy paths.

It means questioning outputs.

It means recognizing that data is not magically objective just because a machine processed it.

AI Can Absolutely Create Security Problems

Here is the uncomfortable truth.

AI-generated code can look polished while quietly introducing severe vulnerabilities.

Sometimes it uses outdated libraries.

Sometimes it invents insecure implementations.

Sometimes it recommends practices abandoned years ago.

And sometimes developers accept it all because the syntax looks clean.

Attackers do not care whether vulnerable code came from a human or a model.

A SQL injection vulnerability still works.

Weak authentication is still weak.

Exposed secrets are still exposed.

The industry already struggles with shipping secure software written by humans.

Now we are dramatically increasing development velocity without a proportional increase in review discipline.

That should concern everybody.

Every AI-generated output should be treated as untrusted until verified.

That means:

• Static analysis
• Security scanning
• Dependency validation
• Architecture review
• Penetration testing
• Edge case testing
• Human inspection

All of it.

Because AI does not magically remove engineering responsibility.

It increases the need for mature engineering practices.

Stop Pasting Sensitive Data Into Public Models

This should not need to be said again.

And yet.

People keep doing it.

Developers paste proprietary code into public AI tools.

Internal documents.

Customer information.

Production logs.

Database exports.

Confidential meeting notes.

Entire architectures.

Then, everybody acts shocked when organizations start locking down tools.

Samsung engineers famously leaked sensitive internal information into ChatGPT.

Multiple times.

That incident alone should have been a giant wake-up call.

If you paste data into an external model, you need to understand exactly where that data goes, how it is stored, whether it is retained, and whether it could influence future training.

Responsible AI usage requires discipline.

Sanitize information.

Use placeholders.

Strip secrets.

Never expose real customer data.

And for the love of all things holy, stop pasting production credentials into prompts.

Yes.

People have actually done this.

Transparency Matters More Than People Think

A weird thing happens when AI generates complex logic.

Developers sometimes skip documentation because they did not fully build the mental model themselves.

That becomes a disaster later.

If your team cannot explain how a system works, your team does not control the system.

The system controls you.

Every engineer should be able to explain AI-assisted code line by line.

Not vaguely.

Not conceptually.

Actually explain it.

If you cannot explain it, you should not merge it.

And honestly?

Your pull requests should say when AI significantly influenced the implementation.

Not because AI usage is bad.

Because transparency matters.

Future maintainers deserve context.

Debugging deserves context.

Security reviews deserve context.

There is no shame in AI-assisted development.

The shame comes from presenting generated code as your own work, even though no one understands how it works.

The Black Box Problem Is Real

Some AI-generated systems become black boxes incredibly fast.

Especially when developers repeatedly regenerate sections until something finally works.

That workflow creates systems nobody intentionally designed.

Think about that for a second.

The architecture becomes accidental.

Logic chains become inconsistent.

Patterns drift.

Abstractions stop making sense.

Then, eventually, the system encounters an edge case.

Now your team is reverse-engineering production behavior like digital archaeologists trying to understand an ancient civilization.

This is one reason senior engineering judgment matters more than ever.

AI can generate solutions.

It cannot reliably generate coherent long-term architecture without strong human guidance.

Systems need intentionality.

That still comes from people.

High-Risk Industries Cannot Afford Carelessness

Some sectors simply carry higher consequences.

Healthcare.

Finance.

Education.

Government.

Defense.

Infrastructure.

If your software influences patient outcomes, financial calculations, legal decisions, or public systems, responsible AI usage becomes even more critical.

You cannot shrug off mistakes with “the AI suggested it.”

Imagine a healthcare system that uses AI-generated logic and mishandles dosage calculations.

Or a financial platform introducing rounding issues into transactional systems.

Or educational software confidently teaching students incorrect information because hallucinations slipped through the validation process.

These are not hypothetical concerns.

The stakes become very real very quickly.

And this is where tech culture sometimes frustrates me.

Too many people still approach AI discussions with startup-energy optimism instead of operational realism.

“Move fast and break things” sounds fun until the broken thing is healthcare software.

Or financial reporting.

Or infrastructure.

Responsible engineering means understanding consequences.

Not just velocity.

Organizations Need Actual AI Standards

Telling developers to “use common sense” is not a strategy.

Organizations need real guidance.

Not performative policy PDFs nobody reads.

Actual operational standards.

Good engineering organizations should establish AI usage frameworks covering:

• What tools are approved
• What data can be shared
• What systems require additional oversight
• How AI-generated code is reviewed
• Documentation expectations
• Security requirements
• Ownership expectations
• Escalation procedures

And importantly:

These standards should be built with engineers.

Not dumped onto them by disconnected leadership teams who barely understand the technology.

The fastest way to create resentment is writing restrictive policies without involving the people doing the work.

Responsible AI adoption works best when teams collaborate on guardrails.

Because good engineers generally want to do things correctly.

They just need clarity.

Code Review Needs to Evolve

Traditional code review processes were designed around human mistakes.

AI introduces different problems.

Now reviewers need to watch for:

• Hallucinated dependencies
• Outdated security patterns
• Overengineered abstractions
• Hidden performance problems
• Inconsistent architectural decisions
• Phantom functions
• Generated code bloat
• Logic nobody can explain

That changes the review process.

Reviewers need more context.

Teams need better tooling.

Security scanning becomes more important.

Documentation becomes more important.

And honestly?

Teams probably need to slow down a little.

I know.

Nobody likes hearing that.

But speed without quality eventually leads to reduced productivity.

Every engineering team eventually pays its debt.

The only question is whether you pay gradually or in response to catastrophic production incidents.

AI Should Make You Better at Thinking

This is where I think a lot of people are using AI incorrectly.

The best usage patterns are interactive.

Exploratory.

Educational.

Not passive.

Instead of saying:

“Write the code for me.”

Try:

“Explain the tradeoffs between these approaches.”

Or:

“Generate pseudocode so I can implement it myself.”

Or:

“What edge cases am I missing?”

Or:

“Challenge this architecture decision.”

Those kinds of prompts sharpen thinking.

They force engagement.

They improve understanding.

They create better engineers.

AI becomes dangerous when developers stop thinking critically.

Because software engineering has never really been about syntax.

Syntax is the easy part.

Engineering is judgment.

Tradeoffs.

Systems thinking.

Communication.

Risk management.

Understanding people.

AI can assist with many things.

But judgment still matters.

A lot.

Testing Matters More Than Ever

AI dramatically increases output speed.

That means testing discipline has to increase, too.

You cannot accelerate code generation while keeping the same validation rigor.

That math does not work.

If AI helps you build software twice as fast, your review and testing strategies need to mature accordingly.

Especially around edge cases.

AI is usually decent at happy-path implementations.

But weird conditions?

Null handling.

Concurrency.

Massive datasets.

Race conditions.

Operational failures.

Unexpected state transitions.

Those are the areas where fragile systems get exposed.

Aggressive testing is not optional anymore.

It is survival.

Junior Developers Still Need Foundational Skills

This part matters a lot.

Especially for newer engineers.

AI can absolutely accelerate learning.

But it can also stunt development if used incorrectly.

If every difficult problem immediately gets outsourced to AI, foundational problem-solving muscles never develop.

And those foundational skills matter.

Data structures.

Algorithms.

Debugging.

Architecture.

Reading documentation.

Understanding systems.

Learning how to think through problems.

The strongest engineers are not the ones who memorize syntax.

They are the ones who can reason through uncertainty.

AI should help build those abilities.

Not replace them.

Honestly, I think one of the healthiest habits early-career developers can build is alternating between AI-assisted workflows and fully manual workflows.

Sometimes, force yourself to solve things independently.

Struggle a little.

That discomfort is where growth happens.

Metrics Actually Matter

A lot of organizations adopted AI because everyone else was.

That is not a strategy.

That is fear.

If teams are going to integrate AI into engineering workflows, leadership needs to measure outcomes honestly.

Did delivery improve?

Did incident frequency increase?

Did code quality decline?

Did onboarding improve?

Did recovery times worsen?

Did technical debt spike?

Because velocity metrics alone are dangerous.

Shipping more code faster means nothing if reliability collapses six months later.

And some organizations are absolutely heading toward that cliff right now.

The real value of AI is not measured in lines of code.

It is measured in sustainable engineering effectiveness.

That is much harder to quantify.

But it matters infinitely more.

Responsible AI Is Bigger Than Code

This conversation extends beyond software engineering.

AI impacts hiring.

Healthcare.

Education.

Creativity.

Journalism.

Finance.

Public policy.

Human behavior.

And eventually society itself.

Developers cannot hide behind “I just build the systems.”

That mindset stopped working a long time ago.

Technology shapes lives.

Sometimes dramatically.

That means ethical thinking cannot be separated from engineering anymore.

And no, this does not mean developers suddenly need philosophy degrees.

It just means responsibility matters.

Consequences matter.

Intentionality matters.

You do not need perfection.

You need awareness.

You need discipline.

You need humility.

AI Is Not Going Away

Some people are still trying to fight AI as if it were a temporary trend.

It is not.

The tooling will only improve.

The workflows will evolve.

Organizations will continue integrating it.

And honestly?

Many developers who learn to use AI responsibly will become dramatically more effective.

That is reality.

But the future does not belong to people who blindly automate everything.

And it does not belong to those who refuse to adapt.

It belongs to engineers who can combine human judgment with powerful tooling.

That combination is incredibly valuable.

Because AI still lacks something important.

Wisdom.

Context.

Ethics.

Taste.

Responsibility.

Long-term thinking.

Human understanding.

Those things still matter.

Probably more than ever.

You Are Still the Pilot

There is a phrase I keep coming back to.

AI is the copilot.

You are still the pilot.

That distinction matters.

A copilot can help navigate.

A copilot can assist with execution.

A copilot can reduce workload.

But the pilot remains responsible for the flight.

Software engineering works the same way.

Use AI.

Experiment with it.

Learn it deeply.

Leverage it aggressively.

But do not surrender your judgment to it.

Do not outsource your thinking.

Do not stop learning fundamentals.

Do not ignore security.

Do not abandon craftsmanship.

And definitely do not mistake generated output for engineering wisdom.

Responsible AI use is not really about the AI.

It is about the humans using it.

The developers.

The leaders.

The organizations.

The choices.

The accountability.

That is the real story.

The developers who thrive in this next era will not be the ones who type prompts the fastest.

They will be the ones who understand when not to trust the machine.

And honestly?

That has always been the job.

Good engineering was never just about writing code.
It was always about judgment, accountability, and thinking clearly under pressure.

That part has not changed.

March is Colon Cancer Awareness Month.

You will see the blue ribbon.
You will see reminders to get screened at 45.
You will see statistics shared across social media.

You should.

The numbers matter.

But this month is not abstract to me.

I had colon cancer.
And I had it before 45.

The Numbers Are Not Small

Colorectal cancer is the third most commonly diagnosed cancer in the United States.

It is the second leading cause of cancer-related death when men and women are combined.

More than 150,000 Americans will be diagnosed this year.

Over 50,000 people will die from it.

Rates in adults under 50 have been rising for years. That shift is significant enough that screening guidelines were lowered from age 50 to 45 for average-risk adults.

That change happened because the data demanded it.

I was not 45.

The Part That Took Three Years

I had symptoms for over three years before a doctor recommended a colonoscopy.

Three years.

When you are under 45, colon cancer is not high on the list of assumptions. It gets categorized as something else. Stress. Diet. Hemorrhoids. Something minor.

And most of the time, it is something minor.

But sometimes it is not.

Colon cancer often develops from polyps that grow slowly and quietly. Early stages may not cause dramatic symptoms.

When symptoms do appear, they can look ordinary:

• Changes in bowel habits
• Blood in the stool
• Persistent abdominal discomfort
• Fatigue
• Unintended weight loss

All things that can be rationalized.

The phrase “you are too young” creates a delay.

Delay changes outcomes.

I was fortunate that mine was eventually caught.

Not everyone gets that timing.

This Is Not Rare. It Is Visible.

Colorectal cancer has affected many people we recognize.

• Chadwick Boseman died at 43 after a private battle with colon cancer.
• James Van Der Beek died at 48 from colorectal cancer.
• Kirstie Alley died from colorectal cancer at 71.
• Jamie Samuelsen, a longtime Detroit sports radio host, died at 48 after publicly encouraging listeners to get screened.

Different ages. Different careers. Different visibility.

Same disease.

Famous or not, local or national, the biology does not change.

Why Screening Matters

Colon cancer is one of the most preventable cancers.

Most colorectal cancers begin as polyps. During a colonoscopy, those polyps can be identified and removed before they become cancerous.

That is prevention in action.

When colon cancer is caught early and confined to the colon, the five-year survival rate is around 90 percent.

When it spreads to distant organs, survival rates drop dramatically.

Early detection does not just improve outcomes. It transforms them.

Screening is not about fear.

It is about probability.

What Statistics Do Not Show

Statistics measure incidence, mortality, and trends.

They do not measure the uncertainty of living with unexplained symptoms.

They do not measure the moment a routine appointment becomes something else.

They do not measure the conversations with your family.

They do not measure how long you replay prior years in your head.

Numbers are clean.

Cancer is not.

I am here because mine was detected and treated.

That fact does not show up in a graph.

But it is the difference between survival and something else.

Why I Am Saying This During March

Awareness months can fade into background noise.

A ribbon.
A post.
A reminder that gets scrolled past.

Colon Cancer Awareness Month exists because this disease is common, because it is serious, and because in many cases it is preventable or highly treatable when caught early.

If you are 45 or older and have not scheduled a screening, do it.

If you are younger and experiencing symptoms, advocate for yourself.

If something persists, ask harder questions.

Three years is a long time to normalize something that is not normal.

If you are going through this or are worried about something and do not know who to talk to, you are welcome to reach out.

I am not a doctor. I will not give medical advice.

But I understand what it feels like to sit with uncertainty, and I am willing to listen.

Before March Ends

Do one practical thing.

Schedule an appointment.
Ask a question.
Encourage someone close to you to stop postponing theirs.

Colon cancer is not rare.

It is increasing in younger adults.

And when caught early, it is often highly treatable and sometimes preventable.

This month is not just about awareness for me.

It is a reminder that the numbers are real.

I was one of them.

And I am still here.

Sources

• American Cancer Society – Cancer Facts and Figures 2024
• U.S. Preventive Services Task Force – Colorectal Cancer Screening Recommendation
• National Cancer Institute – SEER Cancer Statistics Review
• Centers for Disease Control and Prevention – Colorectal Cancer Statistics
• Associated Press reporting on colorectal cancer cases involving Chadwick Boseman and James Van Der Beek

Most leadership advice focuses on what’s visible.

Meetings
Decisions
Presentations
Metrics
Roadmaps

That’s the work people can point at and say, “That’s leadership.”

But the part that actually drains you rarely looks like any of that.

It looks like holding context across five conversations.
Remembering why a decision was made three weeks ago.
Noticing tension in a meeting and deciding whether to intervene or let it play out.
Catching problems early and quietly redirecting before they turn into fires.

None of that is flashy.
None of it ships.
And almost none of it gets acknowledged.

This is the invisible work.

Why leadership feels heavier than expected

When people move into senior or lead roles, they often expect the work to get harder.

More complexity.
Bigger decisions.
Higher stakes.

What they don’t expect is how mentally expensive the job becomes.

The difficulty isn’t that the problems are unsolvable.
It’s that they’re ill-defined.

There is no ticket for:

• “Decide whether this tension matters yet”
• “Figure out which problem actually deserves attention”
• “Hold space so the team can focus”

So leaders compensate the only way they know how.

They carry it.

They keep it in their head.
They replay conversations.
They maintain mental maps of who knows what, who’s blocked, and what might break next.

And over time, that mental load becomes the job.

The myth of “just delegate more”

When leaders feel overloaded, the default advice is predictable:

Delegate more
Trust your team
Let go

That advice isn’t wrong, it’s just incomplete.

You can delegate tasks.
You can delegate decisions.
You cannot fully delegate context.

Someone still has to:

• understand how decisions connect
• see the tradeoffs across teams
• hold the narrative when priorities shift

That work doesn’t disappear when you delegate.
It just changes shape.

The mistake is assuming that if you’re still tired, you must be failing at leadership.

In reality, you may just be doing leadership without a system.

When your brain becomes the bottleneck

The fastest way to burn out as a leader is to become the place where everything lives.

Every decision.
Every exception.
Every “we’ll deal with that later.”

When your head is the operating system:

• everything slows down
• decisions feel heavier
• and stepping away feels impossible

Not because you’re indispensable, but because nothing is written down.

This is where many capable leaders quietly struggle.

They’re not overwhelmed because they lack skill.
They’re overwhelmed because they’re running an undocumented system.

The quiet fix most people skip

The fix isn’t another productivity hack.
It’s not a better calendar.
And it’s definitely not “just try harder.”

It’s externalizing the invisible work.

Writing down:

• decisions and why they were made
• assumptions that shaped those decisions
• tradeoffs you accepted knowingly

Not for performance.
Not for optics.
But so your brain can stop being the single point of failure.

This is how leaders create leverage without burning themselves out.

Clarity compounds when it’s visible.

What leadership output actually is

Early in your career, output looks like things you can ship.

Code
Documents
Features

Later, output becomes harder to point at.

Alignment
Momentum
Confidence
Focus

Those don’t show up neatly on a dashboard.
But teams feel them immediately when they’re missing.

If leadership feels vague, heavy, or exhausting, it’s not because you’re doing nothing.

It’s because you’re doing work that doesn’t announce itself.

The invisible work still counts

Just because the work isn’t obvious doesn’t mean it’s optional.

And just because it isn’t recognized doesn’t mean it should live only in your head.

The goal isn’t to eliminate invisible work.
It’s to give it structure.

That’s how leadership becomes sustainable.
That’s how teams move faster without pressure.
And that’s how leaders stay effective without disappearing under the weight of “everything else.”

This is the work no one sees.
But everyone feels it.

When invisible work has no structure, it becomes weight

Most leaders don’t struggle because they don’t know what to do.

They struggle because everything lives in their head.

Decisions get revisited.
Context gets lost.
Mental load compounds quietly.

What actually helps isn’t more motivation or better habits.
It’s having a place for leadership work to go.

That’s why I built the Tech Lead Operating System.

Not as a productivity system.
Not as a management philosophy.

But as a practical way to:

• capture decisions so they don’t need to be re-litigated
• externalize context instead of carrying it
• reduce the mental drag that comes from invisible work

It’s the structure I wish I had earlier, when leadership started feeling heavier, but no one could explain why.

If this piece resonated, that’s probably not an accident.

You don’t need to do less leadership work.
You need to stop doing it all in your head.

Over the past few years, many companies have begun implementing return-to-office policies, often framed around a familiar set of justifications. The most common one is collaboration. The idea is simple and intuitive: if people are physically together more often, collaboration will naturally improve.

In practice, that logic doesn’t always hold. Many organizations now employ people who live both within and far outside a reasonable commuting distance to an office. Teams are already distributed by default. Meetings still happen over Zoom, Slack, or Teams. Decisions are still documented asynchronously. Being in the same building doesn’t necessarily mean being in the same conversation.

Other reasons are often cited as well. Some leaders point to the value of more face-to-face time with clients, which may make sense for certain client-facing roles. But a large portion of modern tech work is not client-facing at all, and many clients are no longer showing up to offices with any regularity. In those cases, the connection between office presence and business outcomes becomes less clear.

Sometimes the justification is even simpler: a competitor has already done it. An RTO policy becomes a defensive move, a way to signal seriousness or discipline, rather than the result of internal analysis.

What’s noticeably absent in most of these announcements is hard data. Very few companies publicly explain what problem they are trying to solve, how they measured it, or why physical presence is the most effective lever. There may be organizations that have done this work, but they are rarely the ones setting the tone of the broader conversation.

At the same time, the cost of these decisions is felt immediately by employees. Some people were hired explicitly into remote roles and structured their lives around that assumption. Others no longer have reliable transportation or live far from offices that were downsized or relocated. Commutes incur real financial costs, including fuel, vehicle wear, childcare, and pet care. They also introduce a less visible cost: the loss of time and mental energy that could otherwise be devoted to rest, focus, or family.

These impacts don’t show up on dashboards. But they show up in stress, distraction, and quiet disengagement.

Taken together, this creates a gap between the stated goals of return-to-office policies and the lived reality of how work is actually getting done. That gap is where most of the confusion, anxiety, and resentment around RTO begins.

The Official Story vs. the Real Incentives

Most return-to-office policies are presented as neutral or even positive changes. Collaboration will improve. Culture will strengthen. Alignment will happen more naturally. These are not unreasonable goals, and in isolation, none of them are inherently wrong.

But they avoid a more uncomfortable conversation about incentives and tradeoffs.

For the company, an RTO mandate is relatively cheap to implement. It does not require rethinking how work is scoped, how outcomes are measured, or how accountability flows through the organization. It does not require better documentation, clearer ownership, or improved cross-team coordination. It is a policy change, not a systems change.

For employees, the costs are immediate and measurable.

Returning to an office often means getting paid less to do the same work.

Childcare costs increase. Pet care becomes necessary. Transportation costs are reflected in fuel, parking, vehicle wear, and public transit fees. Time once spent resting, exercising, or with family is converted into commuting time. None of these costs are typically offset by increased compensation.

In practice, many employees view RTO as a pay cut.

This is especially true for people who were hired into explicitly remote roles and made life decisions based on that arrangement. Selling a car, moving farther from an office, or choosing a specific childcare setup were rational choices under the original terms of employment. When those terms change without a corresponding adjustment in pay or support, the economic impact is real, even if it is not formally acknowledged.

What makes this dynamic harder to discuss is that these costs do not appear on company balance sheets. They are externalized. From an organizational perspective, nothing looks more expensive. From an employee’s perspective, everything does.

This is where incentives quietly diverge. A policy that seems administratively simple to leadership can feel destabilizing to the people doing the work. And because the costs are borne individually rather than collectively, they are often dismissed as personal inconvenience rather than recognized as a structural change to compensation and working conditions.

Seen through this lens, RTO is not just about collaboration or culture. It is also about shifting where the friction lives. Instead of investing in clearer outcomes and better systems, organizations absorb less of the cost, and employees absorb more.

That imbalance sets the stage for the confusion and resentment that often follows.

Why Presence Feels Safer Than Outcomes

When leaders talk about collaboration, culture, or alignment, they are often pointing to real discomfort.

The kind of work most tech teams do is difficult to measure in real time. Progress is uneven. Impact is delayed. Cause and effect are rarely obvious in the moment.

Outcomes, especially in software and tech-adjacent work, tend to show up late. A decision made today may not reveal its consequences for months. A team can look busy while building the wrong thing, or appear slow while quietly eliminating risk. This makes outcome-based management cognitively demanding and politically risky.

Presence, by contrast, is immediate and legible.

People are either there or they are not. Offices are full or empty. Badges swipe. Desks are occupied. These signals are easy to observe, easy to report, and easy to defend upward. They create a sense of control, even when it is largely symbolic.

This is not a moral failing. It is a predictable response to uncertainty.

When leaders lack confidence in their ability to define, track, and explain outcomes, they reach for proxies. Presence becomes one of those proxies. Not because it reliably produces better results, but because it reduces ambiguity. It answers the question “are people working?” without forcing a harder question: “are we measuring the right things?”

The problem is that presence and productivity are not the same signal. They were never meant to be.

In distributed teams, collaboration already happens through shared documents, written decisions, and asynchronous communication. The effectiveness of that collaboration depends on clarity, ownership, and trust, not physical proximity. Without those systems in place, putting people in the same room does not fix the underlying issue. It simply makes the work more visible.

This is why return-to-office policies often appear alongside other forms of visibility theater. More meetings. More status updates. More metrics that track activity rather than progress. These tools create the illusion of motion while leaving the more intensive work untouched.

At a system level, RTO is appealing because it shifts the burden. Instead of investing in better definitions of “done,” clearer accountability, or more durable feedback loops, organizations rely on presence to signal seriousness. The cost of that choice, as we’ve seen, is largely absorbed by employees.

Seen this way, RTO is not primarily about collaboration. It is about managing uncertainty in environments where outcomes are difficult to articulate and even harder to defend.

Until that underlying measurement problem is addressed, the cycle repeats.

What the Data Actually Shows

Employee Cost Realities

Multiple surveys make clear that the financial and time costs associated with commuting and office presence are very real for many workers.

• A recent analysis reported that hybrid workers can save roughly $51 per day simply by avoiding in-office commuting costs, which adds up quickly when multiplied over weeks or months. Avoiding the commute also saves money on fuel, parking, vehicle wear and tear, meals, and other incidental expenses associated with being in the office.

• Separate research shows that remote employees save significant amounts of time, on average, about 72 minutes per day that would otherwise have been spent commuting. Time savings of that magnitude translate directly into either more productive hours or more personal time, both of which contribute to work-life balance and overall well-being.

• In a broader survey of hybrid or remote workers, 48 % said they would accept an 8 % pay cut to keep working remotely, highlighting how many employees value the flexibility and reduced costs even at a direct compensation trade-off. Additionally, a large share of employees say they would consider seeking a new job if forced to work full-time in the office.

• Another survey tied commuting expense concerns to lower office attendance and reduced perceptions of well-being, with higher commuting costs correlated with poorer sleep quality and negative feelings about RTO policies.

Taken together, this data supports the idea that returning to an office often leads to increased financial and time burdens for employees. Burdens that are not offset by higher pay or compensation adjustments.

Productivity and Collaboration Evidence

When companies talk about RTO improving collaboration and productivity, the empirical picture is more mixed.

• Broad industry data from the U.S. Bureau of Labor Statistics shows that increases in remote work were positively associated with total factor productivity growth across a wide range of industries, even after adjusting for pre-pandemic trends. This suggests that remote work has not systematically undermined productivity at the macro level.

• Independent surveys continue to show that many employees feel at least as productive, if not more so, when working remotely or in a hybrid environment. In one recent report, 61% of workers said they’re more productive at home, while another 34% said they’re as productive as in the office. Only a small minority felt less productive.

• Large-scale studies of remote and hybrid workplaces have found that productivity holds steady or improves across diverse company cultures — in one two-year study of more than 800,000 employees, productivity was stable or up after a shift to remote work.

At the same time, evidence does not point to a simple universal law that remote work always increases output. Some academic work suggests that hybrid arrangements often produce productivity comparable to office work, rather than dramatically higher or lower results.  The key takeaway is that remote work in itself does not appear to consistently degrade productivity, and in many environments, it supports it as well as the traditional office does.

There is also a human factor: employees working remotely or in hybrid roles often report greater flexibility and a better quality of life, which can indirectly support engagement and retention, factors that matter for long-term collaboration, even if they don’t show up as immediate output metrics.

Taken together, the data suggest:

• RTO is not a guaranteed productivity booster
• Remote and hybrid setups can maintain or improve productivity
• Collaboration quality depends on systems and norms, not proximity alone

What to Do With This Reality

Once return-to-office policies are understood as responses to uncertainty rather than as a proven productivity strategy, the question becomes less ideological and more practical. What should people actually do with this information?

The answer depends on where you sit in the system.

For Employees

If you’re an individual contributor or a non-managerial employee, the most important thing to internalize is this: RTO is rarely a direct signal about your individual performance. It is a signal about how the organization is managing ambiguity.

That distinction matters because it changes what’s worth worrying about.

Instead of trying to infer intent from policy changes, focus on the things that remain durable regardless of work location:

Make your impact legible.
When outcomes are slow to show themselves, clarity matters. Document decisions. Write down what changed because of your work. Make it easy for someone outside your immediate context to understand why your contributions mattered.

Anchor on results, not visibility.
Presence is a weak proxy. Results travel further. If you can clearly articulate what you shipped, what risk you reduced, or what problem you unblocked, location becomes less central to the conversation.

Separate anxiety from signal.
RTO announcements tend to trigger worst-case thinking, especially for remote employees. In many cases, the policy reflects leadership uncertainty rather than a prelude to layoffs. Panic often leads people to make rushed career decisions based on incomplete information.

Decide deliberately, not reactively.
For some people, the additional costs of returning to an office are manageable. For others, they are not. Treat this as a decision about tradeoffs, not loyalty. Understanding the economics of your situation gives you leverage, even if you choose to stay.

The goal here is not to comply quietly or rebel loudly. It’s to stay grounded, informed, and intentional.

For Companies and Leaders

For leaders, the uncomfortable truth is that RTO is often doing work that measurement systems should have been doing all along.

If collaboration, alignment, or productivity feels fragile, proximity alone is rarely the solution. It’s clarity.

That starts with asking harder questions before reaching for visible fixes:

What problem are we actually trying to solve?
Is it slow decision-making? Missed handoffs? Conflicting priorities? If the problem isn’t clearly named, office presence won’t resolve it.

How would we know if collaboration improved?
Without a definition of success, policies become symbolic. If improvement can’t be observed or measured, it’s worth questioning whether the intervention matches the problem.

What costs are we shifting, and to whom?
RTO externalizes financial and cognitive costs to employees. Ignoring those costs doesn’t make them disappear; it just moves them out of sight. That has downstream effects on engagement, trust, and retention.

Where could systems replace supervision?
Better documentation, clearer ownership, fewer meetings with clearer purpose, and stronger feedback loops do more for collaboration than shared office space alone.

The organizations that navigate this well tend to treat presence as optional and outcomes as mandatory. They invest in making work understandable, not just observable.

Closing the Loop

Return-to-office policies persist not because they are clearly effective, but because they feel decisive in environments where progress is hard to see.

Understanding that doesn’t solve the problem outright. But it does remove a layer of confusion.

For employees, it replaces fear with clearer decision-making.
For leaders, it replaces symbolic control with the opportunity to build better systems.

Until outcomes become easier to define and defend, presence will continue to be mistaken for progress. Recognizing that distinction is the first step toward changing it.

The sources below include government labor data, large-scale surveys, and independent research on productivity, commuting costs, and employee sentiment. Findings vary by role and organization, but consistently show real employee costs associated with return-to-office mandates and no clear universal productivity advantage tied to office presence alone.

Sources – Return to Office, Employee Cost, and Productivity

Employee Cost, Commuting, and Financial Impact

OfficeRnD – Hybrid Work Statistics
https://www.officernd.com/blog/hybrid-work-statistics/
(Estimates daily commuting cost savings for hybrid and remote workers)

The Interview Guys – State of Remote Work
https://blog.theinterviewguys.com/state-of-remote-work-2025/
(Average daily commute time saved by remote workers)

Archie – Return to Office Statistics
https://archieapp.co/blog/return-to-office-statistics/
(Employee willingness to accept pay cuts to remain remote, intent to leave if forced back)

HealthEquity – Path Forward: How Commuting Impacts Return to Office Experience
https://ir.healthequity.com/news-releases/news-release-details/path-forward-how-commuting-impacts-return-office-experience
(Commuting cost concerns, impact on sleep, stress, and employee sentiment)

U.S. Census Bureau – American Community Survey (Commuting Data)
https://www.census.gov/programs-surveys/acs
(Baseline data on commute times, transportation modes, and geographic spread of workers)

Productivity, Output, and Remote / Hybrid Work

U.S. Bureau of Labor Statistics – Remote Work and Productivity
https://www.bls.gov/opub/btn/volume-13/remote-work-productivity.htm
(Macro-level productivity trends during increased remote work)

Archie – Remote Work Statistics
https://archieapp.co/blog/remote-work-statistics/
(Self-reported productivity comparisons: remote vs office)

Great Place to Work – Two-Year Study on Remote Productivity
https://www.greatplacetowork.com/resources/blog/remote-work-productivity-study-finds-surprising-reality-2-year-study
(Large-scale productivity stability across remote and hybrid environments)

WFH Research (Barrero, Bloom, Davis) – Working from Home Studies
https://wfhresearch.com/
https://wfhresearch.com/wp-content/uploads/2025/07/BTOS-WFH-Barrero-et-al-2025.0605.pdf
(Academic research on hybrid productivity, firm outcomes, and labor market effects)

The Guardian – Hybrid Working and Employee Outcomes
https://www.theguardian.com/business/article/2024/jun/16/hybrid-working-makes-employees-happier-healthier-and-more-productive-study-shows
(Summary of research linking hybrid work to well-being and productivity)

Employee Engagement, Retention, and Preferences

Gallup – State of the Global Workplace / Hybrid Work Reports
https://www.gallup.com/workplace
(Engagement, burnout, and flexibility preferences)

Pew Research Center – Work From Home and Hybrid Trends
https://www.pewresearch.org/topic/economy-work/work-at-workplace/
(Employee attitudes toward remote and hybrid work)

• FlexJobs – Remote Work & Flexibility Surveys
  https://www.flexjobs.com/research
  (Employee preference data, turnover risk tied to RTO)

There is no compiler for leadership.

You don’t get a green checkmark when you make a decision.
You don’t get a warning when you’re about to ship a bad one.
And you almost never get immediate feedback.

Most leadership decisions take weeks or months to play out.

By the time the outcome is clear, something else has already moved on.

That’s where things get dangerous.

Your memory is not a neutral observer. It edits. It smooths. It lies.
You’ll convince yourself that you “knew this would happen all along,” even when you didn’t.

Not because you’re dishonest.
Because that’s how the brain works.

Without a feedback loop, learning turns into storytelling.

The Invisible Work

A lot of leadership work is invisible.

The context you weighed.
The tradeoffs you considered.
The pressure you felt.
The reasons you made the call when you did.

None of that shows up in the outcome alone.

When things go well, you get credit.
When things go poorly, you get hindsight.

What you don’t get is a clear signal about whether your decision-making was sound.

The Missing Loop

Engineers have feedback loops everywhere.

Code compiles or it doesn’t.
Tests pass, or they don’t.
Systems tell you when something is broken.

Leadership doesn’t work like that.

So if you want to get better, you have to manufacture your own loop.

The simplest way I’ve found is boring and uncomfortable.

Write the decision down.
Write what you think will happen.
Set a date to come back.
Then actually come back.

Not every week. Not forever. Once.

That moment, the reckoning, is where learning happens.

Outcomes Over Hours

This isn’t about productivity.
It isn’t about working harder or tracking time.

It’s about outcomes over hours.

Did the decision do what you thought it would do?
If not, why?

Were you wrong about the problem?
The constraints?
The people?

Or were you right and just unlucky?

You can’t answer those questions if the original thinking is gone.

A Simple Tool

I got tired of pretending I’d remember all of this.

So I built a simple decision log to force the habit.

It’s a printable journal and a Notion template.
Same structure. Same questions. No fluff.

If this resonates, you can find it here:
👉 https://mullinsnick8.gumroad.com/l/bihzpk

Use it or don’t. The tool isn’t the point.

The point is closing the loop.

Closing

Leadership without feedback feels like intuition.
Sometimes it’s skill. Sometimes it’s luck.

If you don’t track your decisions, you’ll never know which is which.

I hate the word networking.

It sounds like a transaction.
Like you’re trying to extract value from another human being.

And most of the time, you are.

We’ve all been to those events.
You stand in a room with warm beer and cold pizza.
You scan name badges.
You look for someone “important.”

It feels gross because it is gross.

Here’s the truth about building a career in tech:
the best opportunities don’t come from a stranger you met for five minutes.
They come from people who actually like you.

I’ve written before that the right attitude is worth more than knowing everything.
That rule applies here, too.

If you’re the smartest person in the room but you treat people like rungs on a ladder,
you’ll climb alone.

Stop trying to network.
Start trying to make friends.

The person you ignore at a conference because they look junior
might be the hiring manager you work with in five years.

The quiet developer you helped debug a nasty issue
will remember you when their company opens a lead role.

This industry is smaller than you think.
Your reputation enters the room before you do.

If you want a career that lasts ten or twenty years, you need allies.
You don’t get allies by handing out business cards.
You get them by being helpful when there’s no immediate payoff.

Respect is given by default.
Don’t burn it by being transactional.

Go make some friends.
The rest tends to take care of itself.

If networking makes your skin crawl…

If reaching out to people feels awkward or forced, I put together a small set of outreach templates designed for people who hate networking.

They’re simple, respectful, and focused on building real relationships.
No scripts. No tricks. No pressure.

You can find it here:
👉 https://mullinsnick8.gumroad.com/l/jyrcbp

Most people don’t struggle when they become tech leads because they suddenly forget how to do their job.

They struggle because the job quietly changes in ways no one explains.

You’re still expected to deliver.
You're still expected to be reliable.
You're still expected to know what’s going on.

But the signals that used to tell you “you’re doing well” become slower, subtler, and harder to read.

And that can be deeply unsettling.

The Job Didn’t Get Harder. It Got Different.

As an individual contributor, feedback loops are short.

You write code.
It works.
It ships.

Success is visible and often immediate.

Leadership doesn’t work like that.

As a tech lead, your impact shows up indirectly:

• in how others make decisions
• in how work flows when you’re not involved
• in problems that don’t happen

That shift alone can make capable, experienced engineers feel off balance.

Not because they’re failing.
But because the rules changed.

Skill Isn’t the Problem

Most tech leads are promoted because they’re good at what they do.

They understand the system.
They care about quality.
They can be trusted.

The struggle that follows isn’t about competence.

It’s about orientation.

You’re suddenly responsible for things you weren’t before:

• direction instead of output
• clarity instead of speed
• decisions instead of execution

And almost no one sits you down and explains what that actually means day-to-day.

What Happens When the Shift Isn’t Clear

When the role change isn’t well understood, most people respond in predictable ways.

They work harder.
They take on more.
They stay closer to the work than they should.

Not because they’re controlling.
Because they’re trying to regain a sense of certainty.

Over time, this often leads to:

• becoming the bottleneck
• carrying work that no longer belongs to you
• feeling constantly “on”
• burning out quietly

None of that means you’re doing leadership wrong.

It usually means you were never given a way to operate the role deliberately.

What Actually Helps (At a High Level)

What helps isn’t motivation or hustle.

It’s clarity.

Understanding:

• What the role is centered on now
• What you should stop optimizing for
• How to think in weeks and months instead of tasks
• How to distribute responsibility instead of absorbing it

That kind of clarity doesn’t come from a single blog post.
It comes from having a system you can return to when things feel heavy.

A Practical Next Step

If this resonates, I put together something more structured.

The Tech Lead Operating System is a practical guide for people who stepped into leadership without a playbook.

It focuses on:

• What actually changes when you become a tech lead
• How to operate week to week without becoming the bottleneck
• How to lead sustainably instead of grinding yourself down
• How to reflect and adjust over time

It’s calm, text-first, and designed for real weeks, not ideal ones.

You can find it here:
👉 The Tech Lead Operating System

Final Thought

If leadership feels heavier than you expected, that doesn’t mean you’re behind.

It usually means you’re early in a role that rarely comes with instructions.

Clarity doesn’t remove the pressure.
But it does make the pressure manageable.

And that’s often enough to change everything.

Early in my developer career, advice was everywhere.

Learn more.
Move faster.
Say yes.
Be indispensable.

None of it was wrong. But most of it was incomplete.

What I did not realize at the time was that advice tends to optimize for survival, not growth. It helps you get through the early years, but it rarely tells you how to move beyond them.

Here is the advice I wish someone had given me sooner.

Working Hard Is Not the Same as Growing

I was told to work hard, and I did.

I took on extra work. I fixed things quickly. I made myself useful. For a while, that created momentum.

Eventually, it created a ceiling.

Hard work helps you earn trust. It does not automatically expand your role. Growth happens when your judgment improves, not just your output.

No one explained that distinction early on.

Being Busy Can Hide the Wrong Problems

Busyness feels productive. It also hides stagnation.

I mistook constant activity for forward motion. I rarely stopped to ask whether the work I was doing actually changed my trajectory.

Looking back, I should have asked:

• Am I solving new kinds of problems?
• Am I being trusted with broader decisions?
• Am I learning from outcomes, not just completing tasks?

Staying busy kept me comfortable longer than it should have.

Learning Without Direction Is Not a Strategy

I was told to always be learning.

So I did. New tools. New languages. New approaches.

What I was not told was that learning needs context to matter.

Much of what I learned early on had no immediate application. It made me feel productive but did little to increase my impact.

The learning that mattered most came from:

• Solving real problems
• Following work through its consequences
• Understanding why decisions existed before challenging them

No one told me that finishing things mattered more than starting new ones.

Visibility Is Not the Same as Ego

This one took the longest to learn.

I assumed good work would speak for itself. I avoided talking about what I was learning or improving because it felt self-promotional.

In reality, silence does not signal humility. It signals absence.

Sharing progress, asking thoughtful questions, and framing impact are not about ego. They are about clarity.

If you do not help others see your growth, they cannot factor it into opportunities.

Progress Feels Slower Right Before It Accelerates

This is the part no one warns you about.

As you grow, decisions take longer. Problems feel heavier. Certainty decreases. Confidence quiets down.

It feels like regression.

It is not.

It is the transition from execution to judgment. From speed to responsibility. From answers to tradeoffs.

That phase feels uncomfortable because it stretches parts of you that were never exercised before.

What I Would Tell an Early-Career Developer Now

If I could go back, I would not tell myself to work harder.

I would say:

• Learn fewer things more deeply
• Ask why more often than how
• Finish work thoughtfully, not just quickly
• Reflect on outcomes, not just effort
• Pay attention to how your thinking is changing

Careers are shaped less by intensity and more by intention.

The Quiet Truth

Most developer careers do not stall because people stop trying.

They stall because people keep doing what worked early, long after it stopped helping.

Growth rarely announces itself. It shows up as discomfort, hesitation, and better questions.

If you are feeling those things, you may be closer than you think.

If this reflection resonated, I’ve written a few short, practical guides for developers navigating growth, burnout, and career plateaus.
They are designed to support thoughtful progress in real-world tech work.

You can find them here:

Subscribe to Nick Mullins on Gumroad

I am Nick, a technology leader who believes leadership should feel practical, not performative. I write for engineers who are leading people, juggling priorities, and still want to keep their technical edge. My focus is simple systems, trust, and outcomes, not vanity metrics. You will find clear fra

Gumroad