Why My Company Stopped Using “Positions & JDs”
use measurable business loops
We are planning our Q2 strategy meeting this week, and we will make a final decision to stop using Positions and Job Descriptions.
Why?
We think “Position” is a museum word now
My team, like most teams, used to run the same play when it came to “org structure”:
Draw boxes.
Name the boxes.
Write job descriptions.
Hire people to sit in the boxes.
It looks organized. It feels professional.
But it is increasingly detached from reality.
I have a strong gut feeling: I do not need a “position” that can be quickly taken over by AI, but I still need humans as colleagues.
Here is the clean line I’m staking my flag on:
In the AI era, “positions” stop making sense. Measurable business loops become the unit of work.
The word itself gives it away
Position comes from the idea of being placed.
Not activated. Not measured. Not iterated.
Placed.
A “position” is a location in a structure. Static. A slot.
That worldview made sense when capability was hard to get. You needed school, apprenticeship, years of repetition. Scarcity protected the role. Once you earned the skill, you earned the spot.
Skill → position → stability
That was the old contract.
The contract breaks when capability becomes a utility
AI turns capability into something closer to water and electricity.
Not in some abstract “AI will change everything” way.
In a boring, operational way:
Writing ability becomes a button.
Research ability becomes a workflow.
Coding ability becomes an agent.
Analysis ability becomes a prompt chain.
Design ability becomes a system, which can be vibe-coded in a few days.
When capabilities can be summoned, swapped, multiplied, and chained…
the idea that a human’s value is “the skill they bring to a static slot” collapses.
So the real question becomes:
If skill is no longer scarce, what exactly are humans doing inside companies?
What humans become: Operators
I’m going to name the new responsibility with one word:
Operator.
Not a “job title.” Not a “role.” Not a “position.”
An Operator is someone who runs a measurable business loop.
That’s it.
A human in modern work should be defined by three traits:
Multi-capable
Able to chain capabilities into a running system
Directly accountable to an observable business outcome
If we can’t measure the outcome, we are back to vibes.
If we can’t close the loop, we are back to theater.
Why “workflow” isn’t enough
People will try to rename positions into “workflows” and pretend they upgraded.
They didn’t.
A workflow is just steps in a row.
A loop is different.
A loop is steps + feedback + iteration + measurement.
Most workflows don’t force a business result.
They just describe activity.
A real loop has a hard requirement:
We can point to a metric and say: this loop moved it.
If we can’t, it’s not a loop. It’s a story.
The measurable business loop definition I use
A Loop is a closed system that:
has a single business objective
produces a repeatable output
triggers a measurable change
improves through feedback
can be decomposed into automatable and semi-automatable capabilities
And every loop needs an Operator.
Not a manager. Not a coordinator. Not someone “supporting” it.
Someone who owns it.
Replace job descriptions with loop specs
If “position” is dying, then JD dies with it.
The replacement is simple:
Loop Spec.
A Loop Spec is a short document that describes a loop so clearly that:
you can run it
you can improve it
you can replace parts of it
you can prove it creates value
Here are the 7 fields I consider non-negotiable:
North Metric
The metric this loop is responsible for moving (revenue, retention, time-to-value, cost, risk).
One Irreversible Action
A single CTA that can’t be faked: payment, signed pilot, booked date, submitted list, shipped unit.
Trigger and Inputs
What starts the loop and what it consumes (leads, tickets, content, inventory, onboarding requests).
Execution Chain
The actual steps, with tags:
automated
semi-automated
human-only
Output
What the loop produces (proposal sent, onboarding completed, renewal triggered, shipment delivered).
Feedback Signal
How the loop knows it’s working or failing (open rates, conversion, churn reason, cycle time, error rate).
Success Threshold
What “good” looks like, and when you call it broken.
That’s the spec.
No org chart can do what this does.
Examples of real loops
Keep it concrete. Three loops almost every company has:
Growth loop
Trigger → contact → conversation → pilot → proof → follow-up → referrals
North Metric: irreversible actions per week
Delivery loop
Request → confirm → build/configure → ship → activate → usage → renew
North Metric: time-to-value or renewal rate
Cash loop
Invoice trigger → reminder → reconciliation → payment → receipt → repeat
North Metric: DSO, overdue rate, or cash collected
Notice what’s missing:
No departments.
No titles.
No “responsibilities” paragraphs that nobody reads.
Just a closed system and a metric that forces reality.
Migration: how to transition without blowing up our company
We are thinking about applying this to my team in Q2.
If you want to switch from “positions” to “loops,” don’t start with philosophy.
Start with five moves:
List the 5–12 loops that actually create business value
If a loop doesn’t move money, retention, efficiency, or risk, it’s not a core loop.
Force each loop into one metric + one irreversible action
Multiple CTAs = no CTA.
Multiple metrics = hiding.
Assign one Operator per loop
One throat to choke. One mind to improve it. One person accountable.
Decompose the loop into capabilities
Make a capability map:
agents you can plug in
tools you can buy
humans you must keep
Run a weekly loop review
Only three questions:
did the metric move
where’s the bottleneck
what’s the next experiment
That’s how I turn “concept” into an operating system.
Not sure if it works, will see.
Billy H.
I really like the shift from static positions to owning measurable loops. It makes work feel alive and closer to outcomes rather than job descriptions.
My question is about authority and decision ownership.
If someone operates a loop, do they also have full decision rights within it? And when loops intersect or trade-offs are needed, who has the final call?
Removing positions can increase clarity around results. But clarity around decision rights is what keeps speed and accountability intact. I’m curious how you’ve designed that part in practice.