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

One of the hardest parts of growing as a developer is that progress rarely feels like progress.

You are still unsure.
You still get stuck.
You still see gaps in your knowledge.

That can make it feel like nothing is changing, even when it is.

Here are five signs you are progressing, even if it does not look impressive on the surface.

1. Problems Take Less Emotional Energy Than They Used To

Early in your career, getting stuck feels personal.

A bug feels like a failure.
A confusing system feels overwhelming.
A mistake feels permanent.

As you grow, the problems do not disappear, but your reaction to them changes.

You pause instead of panic.
You investigate instead of spiral.
You trust that you will figure it out.

That emotional resilience is progress.

2. You Ask Better Questions, Not Fewer Ones

Growth does not mean you stop asking questions.

It means your questions change.

Instead of:

• “What should I do?”
  You ask:
• “Does this approach make sense?”
• “What tradeoffs should I be aware of?”
• “What happens if this fails?”

Better questions signal better thinking. That matters more than speed or confidence.

3. You Notice Issues Before They Become Fires

Early developers react to problems.

Growing developers start to anticipate them.

You begin to notice:

• Patterns that lead to bugs
• Assumptions that will break later
• Decisions that increase risk

Even if you cannot always prevent issues yet, seeing them earlier is a clear sign of growth.

4. Your Work Creates Less Confusion for Others

One quiet sign of progress is how often people need clarification on your work.

As you grow:

• Your code is easier to follow
• Your changes are easier to review
• Your intent is clearer without explanation

If teammates can build on your work with less friction, you are doing something right.

5. You Are More Aware of Your Limits

This one feels backward, but it matters.

Early confidence is often based on not knowing what you do not know.

As you grow, you become more cautious with certainty. You recognize complexity faster. You ask for time to think.

That is not insecurity.
That is judgment forming.

The Common Thread

Progress does not always look like promotion, speed, or mastery.

Often, it looks like:

• Better thinking
• Calmer reactions
• Clearer communication
• Fewer avoidable mistakes

If you are seeing these shifts, even subtly, you are not stuck.

You are progressing in ways that compound quietly.

If this helped put your own progress in perspective, I’ve written a few short, practical guides for developers navigating growth, burnout, and career plateaus.
They are designed to support real-world progress, not surface-level motivation.

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

One of the most complex parts of an early or mid-career developer role is knowing whether you are actually growing.

You are busy.
You are learning.
You are shipping work.

And yet, the question lingers.

Am I progressing, or just staying afloat?

Growth in tech rarely announces itself. It shows up quietly, often long after the effort that created it.

Here is how to tell if it is happening.

1. You Handle Ambiguity Better Than You Used To

Early in your career, unclear tasks feel paralyzing.

You want precise requirements. Clear steps. Exact answers.

As you grow, ambiguity becomes less threatening. You may still dislike it, but you can move forward anyway. You ask better questions. You make reasonable assumptions. You unblock yourself.

That is not confidence.
That is experience taking root.

2. You Solve Problems Beyond the Immediate Ticket

Early growth looks like completing tasks.

Later growth looks like preventing problems.

You start noticing:

• Patterns that cause repeat issues
• Decisions that will create maintenance pain
• Edge cases others miss
• You are no longer just responding to work. You are shaping it.

That shift is subtle, but it is one of the clearest signals of progress.

3. You Need Less Direction, Not Because You Know More, But Because You Think Better

Growth is not memorizing more syntax.

It is understanding how systems behave.

If you:

• Ask fewer “what should I do?” questions
• Ask more “Does this approach make sense?” questions
• Can explain tradeoffs instead of just solutions

You are growing in judgment. That matters far more than raw knowledge.

4. Your Work Is Easier for Others to Build On

Early work often works.

Growing work lasts.

As you progress, your code becomes:

• Clearer to read
• Easier to extend
• Less surprising
• Better documented by structure alone

If teammates trust your work even when you are not around, that trust was earned through growth.

5. You Are More Aware of What You Do Not Know

This one feels backward, but it is crucial.

Early confidence is loud. Growing confidence is quieter.

If you are more cautious with certainty, more curious about context, and quicker to say “I need to think about that,” you are not regressing.

You are seeing the field more clearly.

6. Your Feedback Has Changed

Pay attention to feedback patterns.

Early feedback focuses on:

• Syntax
• Style
• Basic correctness

Later feedback focuses on:

• Approach
• Tradeoffs
• Impact
• Communication

When feedback shifts upward, so does your level.

7. You Feel Uncomfortable for Better Reasons

Growth does not eliminate discomfort. It changes its source.

Instead of feeling lost, you feel stretched.
Instead of feeling confused, you feel challenged.
Instead of fearing failure, you fear stagnation.

That discomfort is a sign you are operating at the edge of your ability, not behind it.

The Hard Truth

You will rarely feel like you are growing while it is happening.

Growth usually feels like uncertainty, slower decisions, and questions without clean answers.

In hindsight, it looks obvious.

If you are thinking more deeply, asking better questions, and taking responsibility more seriously, you are not stuck.

You are growing in ways that compound quietly.

If this helped you assess your own progress, I’ve written a few short, practical guides for developers navigating growth, burnout, and career plateaus.
They are designed to support intentional progress, not just motivation.

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

Speed is one of the first things developers are praised for.

You ship faster.
You close tickets quickly.
You respond immediately.

Early on, it feels like proof that you are good at your job.

Over time, that same speed can quietly hold you back.

Why Speed Gets Overvalued Early

Speed is easy to see.

Managers notice it. Teams feel it. Metrics reinforce it. Compared to judgment or clarity, speed is simple to reward.

For early developers, this creates a dangerous shortcut:
If I go faster, I must be improving.

Sometimes that is true. Often, it is not.

Fast Does Not Mean Effective

Early-career speed usually comes from:

• Familiar tasks
• Repeated patterns
• Avoiding deeper questions
• Solving symptoms instead of causes

That kind of speed plateaus quickly.

You get faster at what you already know, but you do not expand what you can handle. Your scope stays small even as your output increases.

That is not growth. That is optimization inside a narrow lane.

What Speed Often Replaces

When speed becomes the goal, something else usually gets pushed aside.

Things like:

• Understanding why a system exists
• Thinking through edge cases
• Considering long-term impact
• Asking uncomfortable questions

These slow you down in the moment, but they compound over time.

Developers who rush past them often find themselves stuck later, wondering why their career stopped expanding even though they never slowed down.

What Actually Matters More Than Speed

As careers progress, teams care less about how fast you type and more about:

• Can you take ambiguous problems and make progress?
• Can you reduce risk instead of creating it?
• Can you explain tradeoffs clearly?
• Can others trust your decisions?

These skills develop slowly. Speed does not help much here. Patience does.

The Shift That Changes Trajectories

The most impactful developers are rarely the fastest early on.

They are the ones who:

• Pause before acting
• Ask better questions
• Notice patterns others miss
• Learn from consequences, not just outcomes

They may look slower at first. Over time, they pull ahead.

Not because they rushed, but because they learned to aim.

A Better Way to Think About Pace

Speed is useful only when direction is clear.

Early in your career, direction is usually the missing piece.

So instead of asking:
“How fast can I get this done?”

Try asking:

• “What is the real problem here?”
• “What happens after this ships?”
• “Who will deal with this six months from now?”

Those questions slow you down now and accelerate you later.

The Irony

Many developers chase speed because they want to grow faster.

Ironically, speed-focused careers often stall earlier.

Depth looks slow. Judgment looks invisible. Thoughtfulness rarely gets applause.

Until suddenly, it does.

And by then, it matters far more than speed ever did.

If this reframed how you think about progress, I’ve written a few short, practical guides for developers navigating growth, burnout, and career plateaus.
They are designed to be applied thoughtfully in real work, not rushed through.

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

Most early developers don’t sabotage their careers with obvious mistakes.

They work hard.
They learn constantly.
They want to do good work.

And yet, many still plateau.

The reason is rarely incompetence. It’s usually a handful of quiet habits that feel productive but compound in the wrong direction.

Here are seven of the most common ones.

1. Optimizing for Being Busy Instead of Being Useful

Early in a career, activity feels like progress.

More tickets closed.
More hours logged.
More commits.

But usefulness is not measured in motion. It’s measured in outcomes.

Developers who grow learn to ask, “Did this actually help?” not just “Did I finish it?”

2. Avoiding Ownership Until They Feel Ready

Many developers wait for permission before taking ownership.

They assume:

Ownership comes after confidence

Responsibility comes after mastery

In reality, confidence usually follows responsibility.

Waiting until you feel ready often means waiting forever.

3. Learning Too Broad Instead of Deep Enough

Trying everything feels smart early on.

Languages. Frameworks. Tools. Patterns.

But shallow familiarity across many things rarely builds trust.

Teams rely on developers who understand a smaller surface area deeply, not those who skim everything lightly.

4. Treating Feedback as Evaluation Instead of Information

Early developers often hear feedback as judgment.

That creates defensiveness, avoidance, or overcorrection.

Feedback is not a verdict. It’s data.

Developers who grow fastest learn to extract signal without attaching identity.

5. Staying Quiet to Avoid Looking Inexperienced

Silence feels safe.

Questions feel risky.
Disagreement feels dangerous.

But quiet developers often become invisible developers.

Asking thoughtful questions and clarifying assumptions is not a weakness. It is how trust is built.

6. Assuming Someone Else Is Tracking Their Growth

Many developers assume their progress is obvious.

It usually isn’t.

Managers change. Context disappears. Work blends together.

If you don’t surface what you are learning and improving, it is easy for others to miss it entirely.

7. Believing Time Alone Will Fix Everything

Time helps. It does not solve.

Experience only compounds when paired with reflection and intent.

Without that, years pass and growth slows quietly.

The Pattern Behind All of These

None of these mistakes are dramatic.

That’s why they are dangerous.

They feel reasonable. They feel responsible. They feel safe.

But careers don’t slow down all at once.
They drift.

Awareness is often the first real correction.

If this list felt uncomfortably familiar, I’ve written a few short, practical guides for developers navigating growth, burnout, and career plateaus.
They are designed to be applied in real work, not just nodded along to.

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

Feeling behind is one of the most common emotions in an early or mid-career developer’s life.

You scroll through posts about promotions, new roles, new stacks. You see people shipping faster, learning more, seemingly doing everything better.

Meanwhile, you are busy. You are working hard. And you still feel stuck.

That feeling is not a failure. But if left unchecked, it becomes one.

Why “Feeling Behind” Is So Common in Tech

Technology moves fast. Titles are inconsistent. Career paths are vague.

There is no clear scoreboard.

So developers invent one. They compare:

• Skills learned
• Tools used
• Speed of output
• Titles and timelines

The problem is that most of these signals are incomplete or misleading. They measure activity, not progress.

Feeling behind usually has less to do with your ability and more to do with lack of clarity.

Step 1: Define Progress in Your Current Role

Most developers skip this step entirely.

They assume progress means:

• Learning more
• Doing more
• Moving faster

In reality, progress is role-specific.

Ask yourself:

• What problems am I expected to handle independently?
• What decisions do others still need to make for me?
• Where do I still create friction instead of removing it?

Progress is not about how much you know.
It is about how much you can be trusted with.

Step 2: Shrink the Comparison Window

Comparing yourself to everyone is guaranteed to make you feel behind.

Instead, compare yourself to:

• Who you were six months ago
• The scope of work you could handle last year
• The types of problems you now recognize faster

This does not lower standards. It restores signal.

If your responsibilities are expanding, you are not behind. You are growing.

Step 3: Trade More Learning for Better Application

When developers feel behind, they often respond by consuming more.

More courses.
More tutorials.
More reading.

That rarely fixes the feeling.

Instead, take what you already know and apply it more deliberately:

• Finish things fully
• Write things others can maintain
• Ask why decisions were made, not just how
• Follow work through its consequences

Application creates confidence. Consumption often creates anxiety.

Step 4: Make Progress Visible

This is the part many developers resist.

Progress that is never articulated is easy to miss.

That does not mean bragging. It means clarity.

Practice framing your work:

• What problem did this solve?
• Who did it help?
• What risk did it reduce?

If you cannot explain your progress, neither can anyone else.

Step 5: Accept That Feeling Behind Never Fully Goes Away

Even senior developers feel behind. The difference is that they recognize the feeling as a signal, not a verdict.

It usually means:

• You are stretching
• You are learning in context
• You are operating near the edge of your comfort zone

That is not failure. That is growth doing its job.

The Real Shift

The goal is not to eliminate the feeling of being behind.

The goal is to replace vague anxiety with intentional progress.

When you know what you are working toward, comparison loses its grip.
When you know why you are growing, speed becomes less important.

You are not behind.
You are just early in a process no one clearly explains.

If this helped reframe how you think about progress, I have written a few short, practical guides for developers navigating growth, burnout, and career plateaus.
They are designed to be applied quickly in real work, not just read.

You can find them here:
https://mullinsnick8.gumroad.com/

“Always be learning” is one of the most repeated pieces of advice in tech.

It appears in conference talks, job descriptions, onboarding documents, and social posts. It sounds responsible. Even generous.

It is also incomplete. And for early developers, it can quietly do more harm than good.

The Problem Is Not Learning

Let’s be clear. Learning matters.

Early in your career, learning fundamentals is essential. You need repetition. You need exposure. You need time to make mistakes and understand why they happened.

The problem is what “always be learning” turns into in practice.

It becomes:

• Another thing you feel behind on
• Another signal you are not doing enough
• Another reason to consume instead of apply

Learning without direction is not growth. It is motion.

When Learning Becomes a Distraction

Many early developers are constantly learning and still stuck.

New language.
New framework.
New course.
New side project.

Meanwhile, the work they are actually paid to do remains shallow, rushed, or disconnected from impact.

The uncomfortable truth is this: you can learn constantly and still not improve your career prospects.

Because careers do not reward the accumulation of knowledge.
They reward problem-solving in context.

What Early Developers Actually Need

Most early-career developers do not need more information.

They need:

• Time spent finishing things
• Feedback on real work
• Exposure to why decisions are made, not just how
• Fewer tools, used more deeply

Depth beats novelty almost every time.

Yet “always be learning” pushes people in the opposite direction. More tabs. More tutorials. Less mastery.

Learning Without Leverage

Here is the quiet failure mode.

You learn things no one needs right now.
You gain skills no one can see.
You improve in ways that do not translate to trust or responsibility.

That does not mean the learning was useless. It means it was misaligned.

Career growth comes from learning in service of something real, not learning for its own sake.

A Better Frame

A healthier version of this advice would be:

Learn what helps you solve today’s problems better than yesterday.

That means:

• Learning deeply inside your current role
• Asking why systems exist before trying to replace them
• Improving judgment, not just syntax
• Saying no to learning that creates anxiety instead of clarity

This kind of learning compounds. The other kind just accumulates.

What to Do Instead

If you are early in your career, try this shift:

Stop measuring progress by how much you consume

Start measuring progress by what you can now handle independently

Learn fewer things, but finish more of them

Tie learning to responsibility, not trends

You will still be learning constantly. You just will not be drowning in it.

The Irony

The developers who grow fastest are rarely the ones chasing every new thing.

They are the ones who:

• Learn with intention
• Apply what they learn
• Reflect on outcomes
• Adjust deliberately

They are not always learning.
They are learning on purpose.

If this perspective resonated, I’ve written a few short, practical guides for developers navigating growth, burnout, and career plateaus.
They are focused, direct, and built around real-world tech work.

You can find them here:
https://mullinsnick8.gumroad.com/

For the first few years of my career, I believed a simple formula:

Work hard.
Say yes to everything.
Get better.

And for a while, it worked.

I fixed bugs faster than most. I volunteered for messy tasks. I stayed late when things broke. I became “reliable,” which felt like a compliment at the time.

Then something strange happened.

I stopped growing.

Not suddenly. Not dramatically. Just quietly.

No promotions. No new responsibilities. No meaningful increase in influence. Just more work, same role, different sprint.

That was the moment I realized something uncomfortable: effort alone doesn’t drive a developer's career forward.

The Trap of Being “The Hard Worker”

Early in your career, working hard does pay off. It helps you build fundamentals. It earns trust. It gets you noticed.

But eventually, hard work turns into a trap.

You become the person who:

• Picks up the overflow
• Fixes issues no one wants
• Keeps things moving when others stall

You are valuable.
You are also replaceable.

No one is incentivized to move you when you are quietly holding things together.

I didn’t stall because I wasn’t good enough.
I stalled because I was optimizing for output instead of impact.

What I Was Missing

Here’s what I didn’t understand early on: careers don’t advance linearly with effort.

They advance when people can clearly articulate:

• What problems you solve
• Who benefits from your work
• Why it matters beyond your keyboard

I was heads-down, shipping code, assuming someone else was connecting the dots.

Spoiler: no one was.

Managers are busy. Teams change. Context disappears. If you don’t surface your impact, it effectively doesn’t exist.

That’s not politics. That’s reality.

The Shift That Changed Everything

The turning point wasn’t a new framework or language.

It was asking better questions:

• Why does this work matter?
• Who is blocked without it?
• What decision does this enable?

I started framing my work differently:

Not “I fixed a bug,” but “I removed a blocker delaying a release.”

Not “I refactored this,” but “I reduced future maintenance risk.”

Same work.
Different narrative.

Suddenly, conversations changed. So did opportunities.

Hard Truth for Early and Mid-Career Developers

If your career feels stalled, it’s probably not because you lack skill.

It’s more likely because:

• You’re invisible outside your immediate circle
• Your impact is implicit instead of explicit
• You’re optimizing for being helpful instead of being effective

Working hard is table stakes.
Being intentional is the differentiator.

Where This Leaves You

If you are early or mid-career and feeling stuck, here’s the good news:

You don’t need to outwork everyone.
You don’t need to become a “rockstar.”
You don’t need to fake confidence or chase titles.

You need to stop assuming effort speaks for itself.

It doesn’t.

Careers don’t stall because people stop working.
They stall because people stop being seen.

If this perspective resonated, I’ve written a few short, practical guides for developers navigating growth, burnout, and career plateaus.
They’re simple, direct, and built for real-world tech work.

You can find them here:
https://mullinsnick8.gumroad.com/