Field Note: Defining “Operator”
The term “Operator” has been co-opted by tactical aesthetics. But its true value isn’t found in gear or martial skill. It’s found in the relationship to Contact with Reality – the interface between intent and a resisting system.
Operator (def): One who possesses the technical mastery to maintain system uptime when the environment is resisting.
When the Term Applies
The term “Operator” is appropriate when three conditions are met:
- Skin in the Game: There is a real-world consequence for failure that cannot be “edited” or “rescheduled” away.
- System Resistance: You are interacting with a system (mechanical, digital, or human) that has its own agency and can push back.
- Mastery Through Contact: You have moved through incompetence, committed to the drill, and reached operational flow under pressure.
If these conditions don’t exist, you’re managing a plan or studying a system. Nothing wrong with that. But it’s not operating.
The Problem: Evaluation Authority vs Operational Authority
For 20 years, I believed that building and running systems was “grunt work” subordinate to the intellectual authority of researchers and academics. I was wrong.
There’s a learned hierarchy that privileges those who study systems over those who run them. I call this the Transitive Property of Executive Achievement: the false belief that if you can explain the taxonomy of a system, you must have the capability to operate it. And that you have the exclusive license to discuss the entire system professionally. Authority transfers from studying the thing to doing the thing – and with it, the sole right to speak authoritatively about both theory and practice.
The observer can comment on operations. The operator is told to “stay in their lane” when discussing frameworks or theory.
It doesn’t work that way.
The Researcher (The Observer):
- Operates in an Evaluation Environment where failure is a data point, not a catastrophe
- Has legitimate authority over methods and taxonomy
- Optimizes for what’s easy to grade
The Operator (The Actor):
- Operates in a Contact Environment where the system has its own agency and can push back
- Has legitimate authority over reality
- Optimizes for uptime when things resist
This matters because we often trust the person who can cite the ritual over the person who can recover the system when the ritual breaks. Worse, we grant the researcher exclusive authority to speak about the entire domain – including the parts they’ve never operated.
Today we see this property at work in certification exams and panel interviews. We reward the person who has memorized the most “true statements” from a list. We assume their achievement in the evaluation environment translates to achievement in the operational environment.
It doesn’t.
What Operating Looks Like Across Domains
Whether it’s a fire apparatus operator, a pilot, or a systems engineer, the title denotes a specific relationship with a system under pressure:
Fire Service:
- An “Operator” isn’t just a driver. They’re responsible for the life support system of the fire ground – the pump.
- If the operator misses a pressure spike or loses their prime, the people inside the building lose their protection.
- Immediate feedback: The pump cavitates. The line goes dry. People notice instantly.
Aviation:
- A “driver” is someone who has moved past the kata of flight school into the flow of managing energy, physics, and weather in real-time.
- The airframe resists. Weather resists. Physics doesn’t negotiate.
Systems Engineering:
- A Site Reliability Engineer manages a live, breathing system that can fail, push back, or resist.
- The server crashes. The integration breaks. The database locks. Reality responds immediately.
Operations vs Project Management
The distinction between an Operator and a Project/Product Manager is found in the feedback loop:
| Feature | The Operator (Ops/Systems) | The Manager (Project/Product) |
|---|---|---|
| Primary Tool | The Engine / The Interface | The Roadmap / The Backlog |
| Feedback | Immediate (The pump cavitates, the server crashes) | Delayed (The milestone is missed, the feature is late) |
| Risk Profile | Operational Failure (Contact with reality) | Strategic Failure (Mismatch with plan) |
A Project Manager manages the map. An Operator drives the vehicle across the terrain. You can have a perfect map and still drive the vehicle off a cliff because you lacked operational skills.
Competency and Flow
Being an Operator means having the “stick and rudder” skills to move from Stage 2 (The Revelation) to Stage 4 (The Flow).
A four-stage journey: from safety, through crisis and choice, to the divergent paths of growth or stasis. Most adult learning follows this progression, but the critical point is the level of stakes revealed at Stage 2: The Revelation. There is a fundamental difference between learning a skill for enjoyment and learning one for survival. For example, learning to play the piano for pleasure is a choice of convenience… however, learning CPR because you witnessed a failure and realized you were powerless to help is a response to Contact with Reality.
The Revelation of incompetence is often felt as terror. This shift in Decision Altitude changes the nature of the learning. It moves the student from a state of passive study into the active Stewardship of life-saving knowledge… the stakes at Stage 2 determine whether the learner remains a victim or commits to the drill required to become an Operator.
Stage 1: Unconscious Incompetence (you don’t know what you don’t know)
Stage 2: Conscious Incompetence (the revelation – you know you don’t know)
Stage 3: Conscious Competence (the drill – you can do it with effort)
Stage 4: Unconscious Competence (the flow – you can do it without thinking)
Most people quit at Stage 2 when they hit the revelation. It’s uncomfortable. The Operator commits to Stage 3 (the drill) and reaches Stage 4 (flow under pressure).
The researcher studies the path. The Operator walks it under fire.
You can be an operator in one domain, a researcher in another, and a spectator in a third. Neither role is superior. The labels aren’t permanent. But knowing which role you’re in – and respecting the legitimate authority of each – matters.
Why This Matters
For Hiring:
If you evaluate operators using evaluation-environment tools (panel interviews, certification exams testing taxonomy), you’ll optimize for smooth talkers who memorize stage-correct moves. You’ll filter out people who excel under contact with reality but struggle in artificial evaluation settings.
For System Design:
If you privilege observer authority over operator authority, you’ll design systems that look good on paper but break under operational pressure. The person who studied the pump isn’t the same person who can maintain uptime when it cavitates.
For Documentation:
Practitioner authority – the authority of having been there, making calls under pressure, and watching what failed when stakes were real – is inherent and legitimate. But operational knowledge that isn’t documented dies.
Stewardship means ensuring the person standing in the EOC twenty years from now doesn’t have to pay the re-learning tax.
The Operator Role Diagnostic: Where Do You Stand?
When one or more of the three pillars (Skin in the Game, System Resistance, or Mastery Through Contact) are absent, the nature of the work changes. Use this breakdown to identify your current role and the specific type of authority you possess in that context.
Identifying the Role Gap
| Role Name | Pillar Missing | Primary Environment | Failure Outcome |
| The Operator | None | Contact | Catastrophe (Real-world consequence) |
| The Researcher | Skin in the Game | Evaluation | Data Point (Failure is a lesson, not a loss) |
| The Planner / PM | System Resistance | The Map | Strategic Variance (Mismatch with plan) |
| The Novice | Mastery | The Revelation | Victimization (Overwhelmed by resistance) |
Detailed Role Breakdown
- The Researcher (The Observer): You possess technical mastery and understand system resistance, but you operate in an environment where failure is not a catastrophe. Your authority is legitimate over methods and taxonomy (the ritual)… however, it does not automatically grant authority over operational reality.
- The Manager (The Planner): You manage the roadmap or the backlog. While you are an expert at managing the “map,” you are not interacting with a live, resisting engine in real time… you are insulated from the “stick and rudder” requirements of the terrain.
- The Novice (The Exposed): You have skin in the game and are facing system resistance, but you have not yet reached “Stage 4 Flow” under pressure. You are currently experiencing the “Stage 2 Revelation”… you are conscious of the gap in your skill but unable to maintain uptime when the system pushes back.
The Transitive Fallacy: A Study in Authority
When these roles are confused, organizations suffer from Transitive Property of Executive Achievement: the belief that because someone can explain or even contribute to a system’s taxonomy, they have the exclusive license to speak for the practice.
- Operator Authority: Legitimate authority over Reality.
- Researcher Authority: Legitimate authority over Methods.
- The Stewardship Obligation: The Operator’s duty is to document their Practitioner Authority so the next generation doesn’t pay the “re-learning tax”.
The Role Transition Guide: From Actor to Steward
An Operator can effectively move into a “Researcher” state to document their knowledge without losing their operational edge. Moving from the role of Operator to that of a documented Steward requires a deliberate shift in focus. You are moving from the “4K high-density” action of your career into a “high-bandwidth” channel of documentation (The Doctrine).
- Acknowledge Practitioner Authority: Recognize that your experience building and running systems under pressure is a legitimate form of knowledge… it is not subordinate to academic research.
- Move from Tacit to Explicit: Operational knowledge that stays in your head dies. Your transition involves turning your “Stage 4 Flow” back into a “Stage 3 Drill” that others can follow… this is the core of loop closure as system infrastructure.
- Bridge the Bandwidth Bottleneck: Documentation allows you to transmit the full signal of your experience. By creating a “Doctrine” or “Field Note,” you ensure the next generation doesn’t have to pay the “re-learning tax” for predictable mistakes.
- Adopt the Observer’s Tools: While you maintain your Operator edge, you must learn to use the Researcher’s tools (Taxonomy, Frameworks, and Schemas) to label your experience… these labels provide the control necessary for others to access your expertise.
Competence as a Burden
Being an operator is a state of being “at the interface.” It does not convey prestige: it conveys Obligation.
When you have the technical mastery to recover a system that is cavitating or crashing, you have a duty to the mission. This is where the Stewardship Obligation becomes part of the definition. You are not an operator because you are “better” than the researcher… you are an operator because you are the one currently bearing the weight of the system’s agency.
Being an Operator means you’ve walked the path under fire. The stewardship obligation isn’t just maintaining uptime. It’s documenting what you learned so the next person doesn’t have to rediscover what failure costs.
Stewardship as an Obligation
Operating at this level of competence is not a final destination or a social title. It is a functional requirement for high-consequence environments. Once you possess the “stick and rudder” skills to maintain uptime under pressure, you inherit a stewardship obligation.
Operational knowledge that stays in your head dies when you leave the room (this is an unnecessary tax on the next generation). Stewardship means turning your “Stage 4 Flow” back into a “Stage 3 Drill” that others can follow. By documenting the interface, you ensure that the person standing in the EOC twenty years from now has a ladder rather than a hole. You aren’t claiming a status… you are fulfilling the responsibility that comes with the skill. The operator’s duty isn’t just to maintain the system.
It’s to ensure the next generation doesn’t have to rediscover what broken looks like.
Last Updated on December 29, 2025
