The Operator Engineer

I'm watching someone build a dashboard for a logistics company. The developer is good — clean code, proper architecture, sensible database design. Three weeks in, they show me the prototype. It works. It does everything the spec asked for. And it's completely wrong.

Not wrong in any way I can point to in a requirements document. Wrong in a way that makes my chest tighten. The interface is too flexible. It has seventeen configuration options when it needs three. The data refresh happens every five seconds when it should happen on-demand. Someone spent two days building a beautiful filtering system that no dispatcher will ever use because it requires them to think in categories they don't think in.

The developer looks at me, waiting. "Should I add the export feature next?"

This is the gap. Not a knowledge gap — this person knows React, knows databases, knows how to ship features. Not a skill gap — the code is well-structured and the implementation is sound. It's something else. Something harder to name and impossible to teach in a bootcamp.

Call it judgment. Call it intuition. Call it taste.

What An Operator-Engineer Is Not

Before I try to define what makes someone an operator-engineer, it helps to draw some boundaries. Because the tech industry is full of adjacent roles that look similar but miss the essential quality.

Not the consultant who can diagnose your problem, write a beautiful deck with the solution, and hand it to someone else to build. I've worked with consultants who understand businesses better than I ever will. They can see the whole system, map the dependencies, identify the leverage points. But when you ask them to actually build the thing, they deflect. "That's an implementation detail." "You'll want an engineering team for that." The taste is there — they know what good looks like — but it never gets tested against reality. It stays theoretical.

Not the engineer who needs a perfect spec before writing a line of code. These people are often exceptional at their craft. They think carefully about edge cases, write comprehensive tests, build systems that scale. But hand them a fuzzy problem — "we need to track inventory better, but I'm not sure exactly how" — and they freeze. They want requirements. They want user stories. They want someone else to make the judgment calls about what matters and what doesn't. They'll build exactly what you specify, which means they'll build exactly wrong if your specification is wrong.

Not the product manager who coordinates but doesn't create. PMs are often brilliant at synthesis — taking input from customers, engineers, executives, and finding the through-line. But most stop at the strategy layer. They draw the boxes and arrows, write the PRDs, run the standups. When it comes time to actually make the pixels move or the database return the right results, they're spectators. They can identify good work, but they can't produce it themselves.

Not the tinkerer who builds for the joy of complexity. You know this person. They're the one who spent six months building a perfect automated deployment system for a product that doesn't exist yet. Or who rebuilt the authentication layer three times because they read a blog post about a better pattern. They have taste — strong taste, often — but it's taste for craft, not for solutions. They optimize for elegance when the situation calls for duct tape. They're solving the wrong problem beautifully.

Each of these archetypes has part of what's needed. Business sense, technical ability, product instinct, creative drive. But operator-engineers have something different: all of them operating simultaneously, in constant conversation with each other.

The Three Capacities

Most people have one of these, maybe two. Operator-engineers have all three, and it's the combination that matters.

Business sense. This is the ability to distinguish between problems that matter and problems that are just distractions. It's knowing which fires to let burn because they'll burn themselves out, and which ones will consume the building if you don't act now. It's translating executive anxiety — which is often vague and emotional — into actual work that can be done. It's understanding what "good enough" means in a specific context, which requires knowing what the constraints actually are and which ones can be negotiated.

I once watched an operator-engineer sit in a meeting where the CEO kept saying "we need real-time visibility into our pipeline." Everyone else in the room started planning a dashboard with live updates, WebSocket connections, the whole thing. The operator-engineer asked: "How often do you actually look at pipeline?" CEO thought about it. "Weekly pipeline review, every Monday morning." The operator-engineer built a PDF that regenerated Sunday night. It took two days instead of two months and gave the CEO exactly what they needed, which was not what they asked for.

Technical ability. This isn't "can write code." Lots of people can write code. This is the ability to actually build the thing — to go from idea to working system without handoffs, without translation layers, without a six-person team to "just handle the infrastructure." It's knowing what's possible versus what's hard versus what's impossible. It's being comfortable with ambiguity and rapid iteration because you can change direction without filing tickets or scheduling standups.

But more importantly, it's knowing the entire stack well enough that you don't solve problems at the wrong layer. When the database is slow, you know whether to add an index, denormalize the schema, or rethink the feature that's generating the query in the first place. When an API is returning the wrong data structure, you know whether to transform it on the frontend, fix it on the backend, or tell the stakeholder their mental model doesn't match how the system actually works.

Taste. This is the ineffable part. The thing that makes you look at the logistics dashboard and know it's wrong before anyone uses it. The thing that makes you stop building after six weeks when the original estimate was six months because the core problem is solved and everything else is decoration.

In the mid-1980s, researchers Giyoo Hatano and Kayoko Inagaki noticed something odd: not all experts were equally adaptable. Some sushi chefs could make the same perfect roll a thousand times but fell apart when an ingredient was missing. Others improvised. Hatano called this the difference between routine and adaptive expertise — and it turns out the distinction matters far more than raw skill level.

Routine experts optimize for efficiency. They get really, really good at executing a known pattern. The problem is that most business problems don't fit known patterns. They're novel in small but important ways. The database isn't quite like the last one. The users don't quite behave like the previous users. The constraints are different.

Adaptive experts — and this is backed by a comprehensive 2014 review of the research — are characterized by their ability to apply knowledge both efficiently and innovatively in new situations. They have the same depth of domain knowledge as routine experts, but they organize it differently. More flexibly. In a way that lets them recombine pieces for novel situations.

That's what taste is. It's adaptive expertise applied to the specific problem of knowing what to build and when to stop building it.

The Pattern That Produces It

I can't tell you how to teach taste, but I can tell you where I've seen it come from.

Look at the backgrounds. They're almost never linear. The operator-engineers I know have resumes that look wrong. Sculpture, then software. Finance, then millwork. Academic research, then startup founder, then consultant. The through-line isn't the industries — it's that they've all had to ship things that people actually use, with no one to blame if it doesn't work.

There's research on this. A 2024 meta-analysis of entrepreneurial experience found that what matters isn't total years of experience — it's startup-specific and industry-specific experience. Generic "years in tech" barely correlates with venture success. But having launched something before? Having worked in the specific domain? Those predict both venture size and profitability.

The pattern is: they've had to make something real, seen it fail or succeed, and carried the consequences.

The consultant who writes recommendations walks away before implementation. The engineer who builds to spec isn't responsible if the spec was wrong. The PM who coordinates doesn't own the quality of the output. But the operator-engineer who shipped the inventory system and then had to live with angry calls when it didn't work? That person learns what matters. Fast.

And here's the thing about failure: it teaches better than success. There's research showing that past negative entrepreneurial experience actually strengthens problem-solving competence. The scar tissue is the curriculum. You build something that seems elegant in your head, watch it collapse under real-world use, and recalibrate your sense of what's robust. You ship a feature you thought was essential, watch nobody use it, and adjust your model of what users actually need. You miss a deadline because you were chasing perfection, and you learn where the "good enough" threshold actually sits.

This is why side projects matter so much. Not because they make you a better coder — though they might — but because they're the place where you get to make all the decisions and live with all the consequences. A 2014 study of 433 workers found that creative activities outside work were positively associated with better job creativity and extra-role performance. The mechanism was clear: those activities gave people practice making something from nothing, with no template and no safety net.

Every operator-engineer I know has built dozens of things nobody asked them to build. Little tools, weekend projects, systems that solved some annoying personal problem. Most of those things failed or never shipped. But each one was a repetition — a chance to practice the full loop from "this could work" to "it worked" or "it didn't, and here's why."

You can't shortcut this. You can't take a course on judgment. What you can do is create situations where someone has to exercise judgment repeatedly, with feedback, with stakes. That's what side projects do. That's what small companies do. That's what entrepreneurial experience does.

Why Organizations Struggle With Them

If operator-engineers are so valuable, why don't more companies use them?

Because they don't fit in boxes.

The modern organization is structured around specialization. There are product people and engineering people and data people and design people. There are clear swim lanes. The product person writes the requirements, the engineer implements them, the designer makes it look good, the data person measures whether it worked. Everyone has a defined scope and a manager who understands that scope.

The operator-engineer breaks this. They're too technical for the business side — they want to see the database schema, they have opinions about API design, they'll push back if you spec something that's architecturally wrong. They're too business-focused for engineering — they don't want to spend three months building a perfect abstraction layer, they want to ship something that solves the problem this quarter, even if it's not elegant.

They're too fast for procurement. Most enterprises have vendor processes, budget cycles, approval chains. The operator-engineer says "I can build this in six weeks" and someone in procurement says "but we're already three months into the RFP process with Oracle."

And they're too opinionated for staff augmentation. They're not going to quietly implement your Jira tickets. They're going to tell you the tickets are solving the wrong problem.

All of this makes them politically complicated. A meta-analysis of organizational ambidexterity — the ability of firms to both exploit existing capabilities and explore new ones — found that companies with this capability significantly outperform those without it. But ambidexterity requires creating protected spaces where the normal rules don't apply. Skunkworks teams. Special projects with different reporting lines. Small units that can move fast without asking permission.

Most organizations say they want innovation, then structure themselves to prevent it. They optimize for coordination and legibility and risk management. These aren't bad goals — they're essential at scale. But they're antithetical to the operator-engineer model, which optimizes for speed and judgment and individual accountability.

When one person ships in six weeks what was scoped for six months, it raises uncomfortable questions. Why did we think it would take six months? What were all those other people going to do? If this person can build it alone, what does that say about our seventeen-person platform team?

The honest answer is often: your process was theater. Your roadmap was a negotiating document, not a plan. Your team was sized for legibility to executives, not for actual work.

The Taste Question

Let me come back to taste, because it's the hardest part to articulate and the most important.

Taste is partly tacit knowledge — the kind of knowledge that lives in pattern recognition rather than explicit rules. There's a model from naturalistic decision-making research called Recognition-Primed Decision making, studied initially in firefighters. The finding: experts don't compare options. They look at a situation, recognize it as similar to situations they've seen before, mentally simulate a single plausible action, and act. The pattern-matching happens below conscious thought.

That's what good taste feels like from the inside. You look at the logistics dashboard with seventeen configuration options and something feels wrong before you can articulate why. Your pattern-recognition machinery is firing: this reminds you of that other system that nobody used, which reminds you of the general principle that complexity is usually a cope for not understanding the real problem.

But taste isn't just intuition. It's also explicit frameworks, consciously learned and applied. It's Simon's satisficing — knowing that you're not looking for optimal, you're looking for good enough, and "good enough" is defined by constraints and tradeoffs. It's understanding which dimensions matter for this problem and which ones don't.

A 2019 study analyzed 65 million papers, patents, and software projects from 1954 to 2014. Small teams, they found, were far more likely to produce disruptive work — the kind that opens new directions. Large teams were better at developing existing ideas. The mechanism seems clear: small teams, often built around one or two people with strong taste, can move fast and change direction without consensus. Large teams need alignment, which means they optimize for what everyone can agree on, which tends to be incremental improvement.

Taste is what lets you see the new direction. Technical skill is what lets you build it. Business sense is what tells you it's worth building. You need all three.

Recognizing It

So how do you know when you're talking to an operator-engineer?

They ask "who's going to use this?" before "what's the tech stack?" Most people optimize for technologies they're comfortable with or want to learn. Operator-engineers optimize for the user's actual problem, which means they're comfortable using boring technology if it fits.

They show you something embarrassing on day three. Not a deck, not a plan — actual software, rough and incomplete, that you can click through. They want feedback early, when it's still cheap to change direction.

They have strong opinions, weakly held. They'll argue passionately for an approach, then switch completely when new information arrives. This is different from the person who argues for the sake of arguing or the person who has no opinions at all.

They know when to be precious and when to ship. Sometimes the typography matters. Sometimes you ship with Comic Sans because you're solving a different problem and perfection is the enemy of done. They have a model of what matters when.

They're impatient with process but patient with people. They'll push back hard on a three-month planning cycle or a six-layer approval chain. But they'll spend hours walking someone through how the system works or why a particular approach won't scale.

And most tellingly: they're unreasonably productive in a way that makes other people uncomfortable. Not because they work longer hours — often they don't — but because they collapse all the handoffs and translation layers that usually slow things down. They move from idea to working system in a straight line because they can hold the whole thing in their head at once.

The point isn't that everyone should become an operator-engineer. The point is that certain problems — especially the novel, ambiguous, high-stakes ones — need someone who can hold business context, technical reality, and judgment about quality all at once. Someone who can see the gap between what was asked for and what's actually needed, and who has both the skill to build it and the taste to know when to stop.

Organizations that can identify these people, give them space to work, and resist the urge to force them into standard process tend to solve hard problems faster. Organizations that filter them out because they don't fit the boxes tend to spend eighteen months building systems that technically meet the requirements and completely miss the point.

The taste gap is real. And it matters more than the technology stack, the methodology, or the size of the team.