The instinct is to fix it. To overhaul the system until it is clean, modern, and “right.”

While this conscientiousness is a vital trait for senior engineers, there is a dangerous trap that lies between the urge to fix and the execution of that fix: The Big Bang Refactor.

In my latest article, I explore why smart teams fall into this trap and how it paralyzes delivery. It usually starts with the “Illusion of Control.” You intend to rewrite a single module, but software is rarely that contained. A change to authentication breaks the user model, which breaks reporting, which requires a library upgrade. Suddenly, you aren’t refactoring; you are unearthing an archeological dig site.

The Clinical Signs of Stagnation

When a team gets stuck in this mode, they stop shipping features to focus on “stabilization.” If you suspect your team is currently caught in this trap, look for these symptoms:

• The “Long-Lived Branch” Syndrome: Feature branches stay open for weeks or months, requiring constant, painful rebases.

• Fear of Deployment: Releasing to production feels like a military operation rather than a routine task.

• The “One More Thing” Justification: Estimates slip week after week because of “one last edge case.”

• Silence in the Metrics: Engineers are working hard, but the user-facing changelog is a flatline.

This paralysis is incredibly expensive. While the team is stuck in the mud of a “perfect” architecture that hasn’t shipped yet, value delivery hits zero and stakeholders lose trust.

The Solution: Build the Skill of Shipping

The best teams fight the urge to rewrite everything at once because they have developed a superior skill: Shipping.

We tend to view shipping as merely the final button press, but it is a discipline as complex and necessary as writing unit tests. If you want to move quickly, you must build the habit of shipping expediently.

This requires a shift in strategy toward “Aggressive Incrementalism.” You must break the work down until it fits in a single day and apply the Boy Scout Rule, cleaning the mess while you deliver value, rather than holding the value hostage for a perfect cleanup.

A messy system that is improved daily is infinitely easier to manage than a “perfect” system that is stuck indefinitely.

If this is striking a chord with your team, check out the full article about building the skill of shipping on your team.

Everything feels… slow. You have a critical feature or an urgent bug fix, but it takes forever to get it through the process. Your engineering team feels crushed under a mountain of work, their calendars are full, their velocity charts look good, and they are busy.

But where are the results?

This disconnect, where “busy” doesn’t equal “delivery,” is one of the most frustrating and costly problems in software development. It’s a sign your company’s “ship” has a lot of little leaks.

The good news? There is one metric that exposes every single crack, bottleneck, and wasteful activity in your entire product development system.

It’s called Lead Time.

📈 The One Metric That Actually Matters

Lead Time is the total time from the moment an idea is requested to the moment it is live and in the hands of your customer.

That’s it. From “Hey, we should…” to “It’s live.”

It includes everything:

• The time it rots in a backlog.

• The time it’s “waiting for design.”

• The time it’s debated in a “prioritization” meeting.

• The time it’s being coded.

• The time it’s waiting for code review.

• The time it’s waiting for a “QA” team.

• The time it’s waiting for the “next deployment.”

This number is your company’s true speed. If your Lead Time is measured in weeks or months for bite-sized tasks, you have a blaring-red alarm.

🚨 Your “Agile” Metrics Are (Probably) Lying to You

“But wait,” you say, “our Cycle Time is low!”

This is the most common and dangerous trap. The “Agile” world has so confused these terms that they’ve become meaningless. Many teams now measure what I call “Troglodyte Cycle Time”, a useless vanity metric that only measures the active coding part of building software.

It conveniently ignores all the handoffs, the delays, and the “waiting” that happens before and after.

• Lead Time is the entire journey, from idea to customer value. This is what your customer feels.

• Cycle Time is just one subset of Lead Time, the actual production process. And, FYI, it should include dead time!

If your engineers code a feature in two days, but it takes 28 days to ship, your Cycle Time is 2 days and your Lead Time is 30. Which number actually matters to your business?

What Lead Time Tells You

When your Lead Time is long, it’s not an “engineering problem.” It’s a system problem. That Lead Time delay is the sound of your business breaking in four distinct ways:

1. Your Best Ideas Are Rotting in a “Cemetery”: Your backlog isn’t a list of assets; it’s a list of broken promises. Every day an idea waits, it depreciates in value. By the time you build it, the market may have already moved on.

2. You Are Paying Your Team to Play “Priority Hot Potato”: A long Lead Time is a classic symptom of leadership chaos. When every new sales call creates a new “top priority,” your team is constantly stopping, starting, and context-switching. Everyone is “busy,” but no one is delivering.

3. Your Business Is Too Unpredictable to Run: How can you promise a feature to a major client when you have no idea if it will take two weeks or two quarters? You can’t. You’re not running a business; you’re running a casino, pulling the lever and hoping the right features come out.

4. Your “Process” Is Strangling Your Product: The 2 days of coding isn’t the problem. The 28 days of waiting is. Your “process” has become a series of bureaucratic tollbooths: waiting for approval, waiting for review, waiting for QA, waiting for the “Friday deployment.”

💡 How to Fix It

This isn’t a “tech” problem. It’s a system problem.

Start measuring your true Lead Time. It’s the honest, and often painful, measure of your company’s ability to learn, adapt, and win.

To read the full, in-depth article on diagnosing and fixing your Lead Time, click here.

The tech industry narrative has soured on this archetype, painting them as a short-term gain for a long-term headache. Many have even concluded that the true 10x developer is a myth, a cynical recruiting buzzword with no basis in reality.

But what if this narrative is wrong? What if, in our rush to criticize the stereotype, we’ve started celebrating mediocrity and allowing ourselves to just bumble through?

Redefining the “Rockstar”: It’s About Taste

A true rockstar developer isn’t defined by the sheer volume of code they can churn out. Their true value lies in a powerful combination of focus, clarity, and taste.

While focus and clarity allow them to cut through noise and find the most direct path to a solution, “taste” is their underrated superpower. In software, taste is the earned wisdom that separates the exceptional from the merely good. It’s an intuitive feel for elegant solutions, clean architecture, and high-quality code, much like a master chef instinctively knows how flavors and textures will combine.

A developer with taste doesn’t create complexity; they produce elegant solutions that are easier to understand and maintain. They’ve already seen the future multiple times, and can draw from their experience to ensure that software they architect and code won’t fall prey to traps that others would never even think to consider. Their clear vision eliminates the need for “design by committee,” saving countless hours of meetings and churn.

Are We Just Cutting Down the Tall Poppies?

So, if these developers are so valuable, why the bad reputation?

Often, it comes down to “tall poppy syndrome”, a cultural tendency to resent or criticize those whose talents elevate them above their peers. Instead of admitting that some people are exceptionally good at building quality software quickly, we find faults to drag them down. We make excuses:

• “Sure, they’re fast, but the code quality must be terrible.”

• “They’re not a team player.”

• “Nobody else can maintain their code.”

These criticisms are often a defense mechanism for a culture that is uncomfortable with outliers, and they are a handicap to learning for everyone else.

What To Do About It?

This leads to a critical dilemma for any CTO or tech lead: What do you do when one developer is vastly outperforming the rest of the team?

Conventional wisdom often suggests reining in the rockstar. Force them to slow down, to write “simpler” code, to spend more time hand-holding.

Your job as a leader is not to manage your best person down; it’s to manage the rest of the team up. If your team can’t understand or maintain the code your best engineer is writing, you don’t have a rockstar problem, you have a hiring or training problem.

And the others on the team, or in the world as a whole? How should rockstars be treated? With a student’s mindset: if there is something to learn from them, then learn it. Why take potshots from the crowd? It’s like the moral from Roosevelt’s Man in the Arena speech, only those who are making attempts matter, everyone else may be ignored.

If you’re interested in more, I have a longer-form post you can read: Taste: In Defense of the “Rockstar Programmer”.

Building software is usually really intricate, but also fairly tedious. There are a lot of tools to help get past the tedium nowadays, but we tend to lose sight of the fundamentals in favor of what we feel like we should do. We copy what we see other admirable companies doing in the hope that their success will rub off onto our own process and we’ll see similar results.

Pick an architecture here, build an infrastructure there, pull in a process you read in some thought leader’s blog post, and before you know it you’ve built a nuclear power plant to power a lightbulb.

Years ago, Netflix famously unleashed a “Chaos Monkey”, a tool designed to randomly break their own systems. It was a brilliant solution to a problem of immense scale: how to ensure a global streaming service never went down.

And in the process, they accidentally created a trap that thousands of startups have fallen into ever since.

I saw it happen in real-time. Young, agile companies, who should have been obsessed with their first customers, were suddenly spending months building their own Chaos Monkeys. They were copying the complex solution without having the complex problem.

This is a pattern I see over and over in my advisory work. Teams get seduced by the siren’s call of complexity. They adopt the tools and processes of giants like Google and Netflix, believing that if they mimic the process, they will achieve the outcome.

The result? They bury themselves in something I call “Process Debt.”

It’s like technical debt, but sneakier. It’s the ongoing tax you pay for maintaining overly complex CI/CD pipelines, premature microservice architectures, and the poster child of modern overkill: the unnecessary Kubernetes cluster. It’s a constant drain on your most valuable resources, time, focus, and momentum.

Why do we do this?

• We’re trying to solve for a future scale we haven’t earned yet.

• We’re “bikeshedding”, focusing on complex technical problems to avoid the messy, ambiguous work of finding out what customers actually want.

• Frankly, it can seem more fun and look better on a resume.

In my latest article, I pull back the curtain on this phenomenon. I talk about the surprising power of a single server, why most startups under $10M in revenue should run from systems like Kubernetes, and how to use the “You Ain’t Gonna Need It” principle for your processes, not just your code.

The goal isn’t to build a beautiful, intricate machine. The goal is to solve a customer’s problem. And the path to doing that is almost always simpler than you think.

If you’ve ever felt the pull of a complex new technology or wondered if your team is over-engineering its infrastructure, this one’s for you.

You can read more about this in my article, You Aren’t Gonna Need The Chaos Monkey.

Cheers,

Jordan