Sidetracked by Sizzle: Staying Focused on True Value

What "Sidetracked by Sizzle" Means to Me

Most of what I know about building good software didn't come from the projects that went well. It came from noticing, project after project, which decisions held up and which ones didn't — and being honest enough with myself to tell the difference. Judgment isn't issued on day one of a career; it's built, slowly, out of choices that looked smart in the room and looked different a year later. Some of my early instincts were wrong in a specific, recurring way: I was drawn toward whatever looked most advanced, rather than what the problem in front of me actually required.

I carry the phrase Sidetracked by Sizzle as a personal compass distilled from that pattern. It appears in my LinkedIn profile, in how I introduce myself in professional contexts, and in the way I try to frame technology conversations on teams I work with. It is, in three words, the failure mode I have watched derail more projects than any technical problem I can name.

Sizzle is what something looks like when the presentation is more compelling than the substance. In a restaurant, sizzle is the sound a cast-iron skillet makes when it arrives at the table — before you've tasted anything. In software, sizzle is the demo that generates excitement in a room, the framework that every blog post says you should be using, the architectural pattern that seems to solve everything at once. It looks good. It sounds right. It generates momentum.

Sidetracked is what happens when that momentum pulls a team away from the outcomes they were actually hired to deliver. Not because anyone made a bad decision with bad intentions — the pull is real and reasonable. The people most drawn to sizzle are often the most technically curious and capable people on the team. They got into this field because they liked exploring what technology could do. That curiosity is a genuine asset.

The problem isn't curiosity. It's what happens when the appeal of something new substitutes for the harder question: does this, for this problem, for this team, at this moment, actually produce better outcomes for the business? When that question doesn't get asked — or gets answered too quickly — resources flow toward what's interesting rather than what matters.

I keep the phrase in my profile as a standing public commitment: I will ask that question. I will prioritize substance over appearance. I will evaluate technology on what it delivers, not on how it presents.

I also recorded a Deep Dive video on Sidetracked by Sizzle that covers this topic in more depth — including examples from projects where the sizzle trap was hardest to spot.

The Moment Sizzle Enters the Room

It usually happens in a meeting. Someone opens a demo, or mentions a framework that a competitor just adopted, or shares a blog post about a technology that promises to solve the exact category of problem the team has been struggling with. And for a moment — sometimes longer than a moment — the room forgets what it was working on.

That pull is worth understanding rather than just resisting. New technology is genuinely exciting. Curiosity isn't a defect. The ability to recognize when something new is actually better than what you have is a skill worth cultivating.

The problem is the pattern where the appeal of novelty substitutes for the harder work of asking whether this particular technology, for this particular problem, for this particular team and timeline, actually produces better outcomes for the business.

What Sizzle Actually Costs

The cost of chasing sizzle rarely shows up cleanly in a project budget. It accumulates in more subtle ways.

There's the direct cost: time and engineering effort spent evaluating, piloting, and partially integrating a technology that turns out not to justify its complexity. That's recoverable, if it surfaces early. The more damaging version is when a team spends months on an approach and then discovers that the fundamental business outcome — the thing the project was supposed to improve — hasn't moved.

There's also an opportunity cost. Every sprint spent on a feature that didn't need to exist is a sprint not spent on one that did. Flashy dashboards built while core reliability issues remain unresolved. Impressive integrations that no user actually needed. The portfolio of things that got built but didn't matter is often much larger than anyone would like to admit, and it tends to expand when teams are drawn toward interesting work rather than impactful work.

The subtler cost is the credibility one. When stakeholders see resources absorbed by things that don't translate into business improvement, they start to wonder whether the team understands what the business actually needs. That loss of trust is harder to measure and harder to repair than any delayed timeline.

Staying Anchored Without Closing Off

The antidote to sizzle isn't skepticism about all new technology. That overcorrection creates its own problems — teams that miss genuinely useful shifts because they've conditioned themselves to resist anything unfamiliar.

The more useful frame is treating technology choices the same way good product decisions get made: by starting with the outcome, not the solution. Before evaluating whether a new tool or framework is worth pursuing, the prior question is whether there's a clear, measurable outcome it would help achieve. If the answer is yes, the evaluation has a standard to work against. If the answer is vague — "it'll make things more modern," "it's what everyone's moving to" — that's a signal worth pausing on.

Deep knowledge of the business domain matters here in a way that's easy to underestimate. The engineers and project managers who are least likely to get sidetracked by sizzle are generally the ones who understand not just the technical problem but the business problem behind it. When you know what success looks like for the customer, it's much easier to see when a proposed solution is genuinely moving toward that versus when it's a detour that happens to be technically interesting.

Stakeholder feedback plays a similar role. Clients and end users are rarely seduced by technology for its own sake. They tend to be concerned with whether the system does what they need it to do. Regular conversations grounded in what they're experiencing — what's working, what's frustrating, what would actually help — provide a useful counterweight to internal enthusiasm about technical possibilities.

Craft, Service, and Judgment

Staying anchored to outcomes turns out to be about something larger than avoiding shiny objects. It's about practicing the craft well — building solutions that are thoughtful, maintainable, and genuinely useful to the people who depend on them long after the excitement of a launch has faded.

Every project teaches something, whether it succeeds cleanly or doesn't. The mistakes tend to sharpen judgment more reliably than the successes do, because they force a specific kind of honesty: going back to a decision and asking what signal got missed, or what question didn't get asked early enough. None of that argues for less curiosity. Some of my better decisions started with genuine interest in a new approach. The difference between curiosity that serves the work and curiosity that derails it is discipline — letting the excitement inform the evaluation instead of replacing it.

Underneath all of it is a harder question than "is this good technology?" The harder question is whether the work leaves things better than it found them. Better for the team that inherits the codebase. Better for the client whose system needs to keep running correctly long after the project is closed out. That question doesn't have a universal answer, but it's the one worth returning to before calling any project finished.

Software architecture and consulting are, at their core, a form of service. The systems I design are systems other people have to live with — maintain, extend, debug, and explain to their own stakeholders, long after I've moved on to the next engagement. That reality changes what "good work" means. A clever solution that only its builder can maintain isn't really a success; it's a liability with a delay on it.

Part of the job is mentoring the people who'll carry a system forward and enabling teams to make good decisions without me in the room. Measured that way, success looks less like applause in a demo and more like clarity — a system a new engineer can understand in an afternoon, a client who trusts what they're being told, a team that's a little stronger for having worked through the project together.

The Discipline of Staying Focused

Staying focused in the face of genuine novelty requires a kind of ongoing calibration. The question isn't "should we ever change course?" — course corrections are part of the work. The question is whether a proposed change is being driven by evidence about outcomes or by attraction to what's new and interesting.

That calibration is a leadership responsibility as much as a personal one. Teams will naturally drift toward engaging work. The leader's job is to ensure that what's engaging and what's impactful are pointed in the same direction — and to gently but clearly refocus when they diverge.

After enough years and enough projects, "Sidetracked by Sizzle" has stopped being just a warning against shiny objects. It's become the short version of what building software has taught me: that judgment is earned through the decisions that didn't hold up as much as the ones that did, that the work is a form of service to the people who inherit it, and that the best solutions are usually quieter than the most impressive ones. I keep the phrase close not as a boast but as a standing commitment — to keep asking the harder question, to keep the craft honest, and to keep the curiosity that got me into this field pointed at problems worth solving. That's still the work. It's just gotten clearer, project by project, what the work actually is.

Further Reading

• From Features to Outcomes: Keeping Your Eye on the Prize — the feature-vs-outcome distinction is the clearest lens for spotting sizzle
• Evolution over Revolution: A Pragmatic Approach — sizzle often arrives dressed as a revolutionary rewrite
• Accountability and Authority: Walking the Tightrope — accountability to outcomes is what keeps focus honest

Explore More

• The Power of Lifelong Learning -- The Ongoing Choice to Stay Curious and Capable
• When the Pressure is On - Late Sprint Hotfix Governance -- Rational decision-making when everyone's screaming "rush, rush, rush"
• Accountability and Authority: Walking the Tightrope -- A continuation of Dave's story — what happened Monday morning
• From Features to Outcomes: Keeping Your Eye on the Prize -- Focus on Outcomes, Not Just Features
• AI and Critical Thinking in Software Development -- What AI Handles and What Humans Must Still Own