Field Notes/bryngtmplaysgtm-engineeringsignal-based-sellingagents
One Operator, a Portfolio of Plays
The lean teams everyone is citing did not win by automating outreach. They win because one operator now covers what used to take a team, by running a portfolio of Plays. The unit of GTM leverage is shifting from headcount to Plays.
Brad Webb, Chief Growth Officer
||5 min read|
tl;dr
The lean teams everyone keeps citing did not win by automating outreach. They won by changing the unit of work. One operator now covers what used to take a team, by running a portfolio of Plays instead of doing each one by hand. Leverage is moving from headcount to Plays: you define a Play once, approve it, and it runs, then you add the next one. The job becomes portfolio design and judgment, not volume. Here is how I would build the first one.
The headline everyone is misreading
You have seen the posts: tiny teams reporting revenue-per-employee numbers that would have been absurd five years ago. Forbes puts AI-native startups at $2M to $4M in revenue per employee, against roughly $300,000 for the average public SaaS company. Some are organizing the whole company around the number: Swan AI, three founders and no SDRs, runs growth, sales, and support through a swarm of agents and has made $10M in ARR per employee its explicit constraint.
The usual read is "AI replaced the reps." That is the wrong lesson, and it is the one that gets people to buy a bot and wonder why their pipeline got worse. The real lesson is quieter. These teams did not automate a rep's to-do list. They changed the unit of work. One person now runs a portfolio of small, defined motions that used to require a team of people doing them by hand.
The old unit was headcount
For most of my career, the way you got more go-to-market output was to add people. More pipeline meant more SDRs. More segments meant more owners. Coverage was a function of headcount, so it was linear, expensive, and slow: every increment of output was another hire, another ramp, another quarter.
Headcount, or Plays?
3
pricing to repeatde-anon to Slacktrial stall nudge
3 Plays running, held by 1 operator. By hand, this coverage is roughly 2 people's worth of motions. Adding a Play adds coverage, not a hire.
That model is not wrong, it is just capped by how many people you can hire and train before the org chart collapses under its own coordination cost.
A Play is a small, named motion you define once: a trigger, a set of bounds, an action, and a record. Pricing revisit inside a week, so send the intro from the owner. Trial stalls, so re-engage. Usage crosses a threshold on an existing account, so flag expansion. You write it down, you approve it, and from then on it runs each time the pattern appears, logging every instance. I described the loop in what Bryn actually does, and we ran the first ones on ourselves in Customer Zero.
The important part is what that does to leverage. Once the unit of work is a Play rather than a task, output stops being tied to headcount. I hold more Plays in my head now than I ever held motions, and it is less work, not more, because I am not executing each instance. I am designing the motion and letting it run.
Run it like a portfolio
Once you have more than a couple of Plays, you are managing a portfolio, and the useful mindset is exactly that. Some Plays are always-on, the steady captures you want running every day. Some are seasonal, stood up for a launch or a quarter and retired after. Some are experimental, small bets you are testing and will either promote or kill.
A healthy portfolio has a mix. All always-on and you never learn anything new. All experimental and nothing reliable is running. The operator's job is to keep the balance sensible, not to babysit any single Play.
What the operator actually does now
This is the part that trips people up, so let me be precise. Moving to Plays does not mean nobody is in charge. It moves where the human decides. Your authority lives at the definition and approval of a Play, not at each instance of it running.
Where the human decides
You touch
Define the Play
Set the bounds
Approve it once (at definition)
Bryn runs
Watch for the pattern
Score against your ICP
Take the action
Log the run
Run: judgment goes in once, up front. Bryn runs every instance on its own.
You decide which Plays exist, what bounds they run inside, and whether each one runs on its own, waits for your yes, or is switched off. Run is the default, Approve is there when you want the final say on a step, and the kill switch is always in reach. That is bounded autonomy, and it is the whole reason one person can safely let ten Plays run: the judgment went in up front, once, not into every send. I made the fuller case for that judgment in can vs should.
The honest limit
This is leverage, not magic. A bad Play scales badly: if the logic is wrong, letting it run just produces more wrong, faster. A portfolio still needs someone designing it, reading the record, and pruning what is not working. Bryn is not another dashboard to watch. It is the governed execution layer that runs Plays through your stack, and it is only as good as the Plays you give it and the attention you spend tuning them. The work does not disappear. It moves up a level, from doing the motion to designing the portfolio.
Your first three Plays
You do not start with ten. You start with three, one from each surface, and you add as you trust the loop.
Build a starter portfolio
One operator, 3 Plays, covering capture + activation + expansion. Full coverage across capture, activation, and expansion.
Pick one always-on capture, one activation nudge, and one expansion trigger. Approve those three, watch them run for a week, and you will have a portfolio one person can hold. That is the whole move: stop scaling the headcount, start scaling the Plays.
Stop watching signals. Start running them. You can start at civic.com/bryn.
Brad Webb is the Chief Growth Officer at Civic; he's been building the bridge between Engineering and GTM/Sales for over two decades, merging them into the science better known as Growth.
If Brad isn't running experiments or sending off Agents to verify data, he's probably building tube-based HiFi gear with his sons, hopefully remembering to drain the capacitors before soldering.
