Seniority Is Knowing What Not to Build

Production endpoint is crawling. Two paths: spend a week designing a caching layer, or look at the logs for five minutes and send a Slack message to the team that owns a cron job they forgot to turn off. One of those paths requires Redis, a message queue, and a deployment. The other requires context.

This week, engineers across the industry are recognizing something publicly that takes about six years to fully absorb: the instinct to solve problems architecturally is often the wrong instinct, and most of the work that actually matters is a conversation, not a design.

The progression is familiar. Early in your career, seniority looks like knowing how to build more complex things. You graduate from CRUD apps to distributed systems. You learn when to reach for a message queue, when to shard a database, when to introduce a caching layer. The value proposition is legible: you can build harder things than someone with less experience.

Then, somewhere around year five or six, the instinct flips. You start asking "should we?" before you ask "how do we?" You stop in the middle of a design review and ask who actually needs this data, and how often. You find a cron job hammering a slow endpoint for a feature that was killed two years ago, send one Slack message, and watch latency drop before lunch. The work was the message. The architecture was knowing it was a message.

What's strange is how little of this shows up anywhere. No commit, no ticket, no sprint point. The best architectural decision you make in a quarter might be a conversation in a meeting where you stopped a project from starting. That conversation doesn't appear in a performance review because nothing happened — nothing was built, no deadline was hit.

The alternative would have been six engineers spending three months on infrastructure solving a problem nobody actually had.

This is what senior engineers mean when they say the job changed: it shifted from making things to preventing things. From design to diagnosis. From building to asking the right question in the right room before anyone fires up a ticket. The challenge is that organizations are built to reward building. Sprint points go to completed work, not prevented work. Kudos flow to the engineer who fixed the production incident at 2am, not the one who spotted the cron job before it became one. The instinct to instrument, dashboard, and architect everything runs directly counter to the highest-leverage move available to experienced engineers — which is often leaving the room without starting a project.

This isn't anti-engineering. The skill of knowing when to reach for Redis is real, and there are problems that genuinely require it. But it comes second to the skill of knowing when to ask whether the endpoint needs to be faster at all.

Call this the prevention layer — the decision-making that sits upstream of architecture, asking whether the problem requires a technical solution in the first place. Most organizations don't have an explicit one. They have it in the form of a single engineer who keeps asking awkward questions in design reviews, slowing things down in ways that feel like friction. When that person leaves, the org loses something they can't name and don't know how to replace. Projects start multiplying. The codebase accumulates systems that solve problems nobody has anymore.

The engineers building those systems aren't incompetent. They just never had a conversation that would have pointed them at the cron job instead.

The pattern we see at early- and mid-stage companies is that the prevention layer collapses under growth pressure. There's always more to build than there are people to build it. Stopping to ask "should we build this?" feels like waste when you're shipping fast, so it gets skipped. Requests become tickets. Tickets become projects. Architecture gets more complex. Nobody is asking whether the upstream request was valid in the first place, because the person whose job that was is now in four planning meetings.

At GigSmart, running a marketplace across all 50 states with a lean team meant every build decision had to be interrogated before it started — not because the team was slow, but because the cost of building the wrong thing in a real-time, geographically distributed system is paid downstream in operations and on-call burden, not in the initial sprint. The prevention layer wasn't optional. It was the thing that kept the architecture from eating the team.

This is where fractional CTO work earns its keep in ways that are hard to put on a slide. The first two weeks in any engagement aren't spent building anything. They're spent listening — sitting in design reviews, reading through tickets, tracing requests back to their origin. The goal is to find the cron jobs. The features nobody uses. The architectural decisions being made to solve what are actually social problems. The most expensive conversation we don't have is the one that would have stopped a project from starting.

That's not a metaphor. We've walked into organizations where the first discovery was a background job, a duplicate integration, or a data pipeline feeding a dashboard nobody looked at — and the engineering time freed by turning those off was more than any productivity tool would have delivered.

There's a reason this takes years to develop: it requires enough context to see what's unnecessary, and enough organizational credibility to stop it before it starts. A junior engineer can't walk into a design review and say "I don't think we need to build this" — not because they're wrong, but because they haven't earned the standing to stop the train. Senior engineers have that standing. The question is whether they use it.

The good ones do. They get comfortable with the fact that their most valuable work will often be invisible — no artifact, no deployment, no closed ticket. Just a problem that never became a system.

If your most experienced people are spending their days in review queues and planning meetings rather than asking the questions that prevent projects from starting, you're using them wrong. Their leverage isn't in the architecture. It's in the conversation upstream of it.

If you want to know whether your prevention layer exists — or who's doing that work right now, and what happens when they leave — let's talk.