The favors we used to need
The favor economy teams were built to smooth is dissolving, and the roles that ran it invert rather than vanish.
I ended the last post on a promise. That one was about the day I stopped doubting AI coding agents, and about how much further they let a single experienced engineer reach: things you can now build alone in an afternoon that used to take a team and a month. Then I dodged the obvious next question. If one person’s reach can expand this much, the way teams are built around that person has to change too, and this is the start of that argument. Less about me this time, more about everyone standing next to me, and about the whole apparatus we’ve spent decades building to hold groups of engineers together.
Running on favors
I’ve spent most of my career on engineering teams, and almost none of the work that mattered ever moved the way the org chart promised. It moved on favors. When I got wedged on something I didn’t understand, I’d wander over to the one person who actually knew the deploy pipeline and ask. When a teammate was about to commit to a shaky design, they’d grab me to poke holes in it before it hardened into something we’d all regret. I owed someone a code review, someone owed me an afternoon of debugging, and that web of small, unrecorded debts was how things really got built. I earned standing by helping people, I spent it when I was stuck, and that quiet tally of who had helped whom was most of what turned a roomful of engineers into a team.
Anthropic, in a piece about AI building itself, put the same idea more sharply, and named the part I’d been circling around:
Work (and life) ran on a gift economy of small favors between humans. “Can you help me get this script running?” […] each one created a little debt, a little mutual awareness. [Claude is] faster, it creates zero debt, but each of these is a lost bid for human collaboration.
Once I started seeing work this way, I couldn’t stop noticing how much of how we build teams exists to smooth that chain of favors. Team leads, product managers, project managers, engineering managers: underneath the titles, much of what these roles do is keep the favor economy fair and keep it fast. A good team lead gives people an equal footing across wildly different seniorities and temperaments. A product manager keeps the backlog legible enough that you know who to ask, and for what. A project manager arbitrates the cross-cutting priorities so the person with the least accumulated credit can still get what they need to move. The whole discipline grew up around the friction of humans needing other humans, and in the end most of it is a careful machine for managing debt.
The favor I didn’t ask Albert for
A few weeks ago Albert Horta handed me a small black circuit board. Albert is the friend I call whenever a project drifts somewhere near a soldering iron, the one whose hands I borrow the moment something stops being software and starts being hardware. The board was a LILYGO T-Call: an ESP32 microcontroller with an LTE modem bolted onto it. I wanted to turn it into a self-hosted SMS gateway, a little always-on box that talks to the cellular network directly and lets me send and receive texts from a web app, with no cloud in the middle.
This is embedded firmware work, and it is genuinely not my world. Arduino, ESP32, driving a modem over a serial line with AT commands, decoding incoming SMS in raw PDU mode where you reassemble multipart messages by hand and pull Unicode and emoji out of hex. I have never programmed one of these in my life.
In the old world, this is where the favor would have continued. Albert had given me the hardware, and for the hard part I’d have leaned on him too. I’d have explained what I wanted, we’d have gone back and forth over a few days, he’d have written the tricky modem code himself, and at the end I’d have owed him an evening and a few beers. That’s not a complaint. That back-and-forth is one of the better parts of the job.
Instead, the honest admission that I’d never programmed one of these went to a coding agent, along with two photos of the board, and about two hours later I had it running. The commit history is blunt about it: first commit to last, two hours and eight minutes. Around fifteen hundred lines of C++ I couldn’t have written on my own, including a hand-rolled, separately unit-tested PDU decoder, a captive-portal setup so I could never lock myself out, webhooks, and a web app that looks better than most embedded admin panels have any right to. Every progress update along the way arrived, fittingly, as a text from the gateway reporting on itself.
So Albert is still in the project. He supplied the board, and that turned out to be the one favor I couldn’t route around: someone still had to put a piece of hardware in my hand. But the part that would have been the real favor, the evening of embedded work I’d normally have borrowed from him, simply didn’t happen as a favor at all. I’m glad I shipped the thing. I also notice, honestly, that I didn’t get the evening with Albert.
Both things are true
I want to sit in that discomfort for a second, because the easy version of this post picks a side and I don’t think either side is right on its own.
The favor economy was also a tax, and I’ve watched it fall hardest on the people least able to pay it: the new hire who doesn’t yet know whose desk to walk to, the quiet engineer who would rather stay stuck for a day than ask, anyone sitting outside whatever in-group had formed. Plenty of good ideas died right there, unasked, because for the person who had them the cost of asking was simply too high. Lifting that tax is a real liberation, and I don’t want to weigh the losses without saying that part first. Flattening exactly this kind of unfairness was much of what those coordinating roles were for, and a good slice of it now takes care of itself.
And the favor economy was also the connective tissue. The debts were the relationship. When the favor creates zero debt, it also creates zero relationship, and a hundred tiny moments of “I owe you one” that used to accumulate into a team simply stop accumulating. Both of these are true at the same time, in the same afternoon, in the same repo with Albert’s name in the credits. The roles we built to smooth the chain were also, quietly, built on the assumption that the chain was load-bearing.
What this unlocks
A whole category of work no longer needs the chain at all.
The SMS gateway is a tiny instance of it. The crazy experiment, the throwaway proof of concept, the MVP you’d never get headcount for: most of that used to die in the gap between having an idea and rounding up enough people who cared to help build it. That gap was mostly social, not technical, and it’s the one that’s closing. Simon Willison makes the economic version of the point: code has gotten cheap enough that you should fire off the prompt even when your gut says the thing isn’t worth building. Once the cost of trying collapses, what counts as worth trying changes with it.
Mostly, what it buys me is the ability to unblock myself. I stop waiting. The lag between a question and a working answer collapses, and most of that lag was never really technical. It was someone else’s calendar, someone else’s priorities, and my own reluctance to spend hard-won credit on something I wasn’t even sure would work. Take all of that away and the iteration gets faster for reasons that have nothing to do with typing speed.
The roles don’t shrink, they invert
The tempting conclusion from all of this is that the coordinating roles shrink. If agents smooth the favors, who needs the people who used to? I think that’s exactly wrong, and it’s the part I feel most strongly about.
The need those roles served is shrinking. The roles themselves don’t disappear. They get repointed at a much harder problem.
When anyone on a team can spin up ten experiments in an afternoon, the scarce thing is no longer execution. It’s judgment about the lifecycle of all those experiments. When is it the right time to stop investing in something? How do you tell the difference between an experiment that’s earned another week and one you’re propping up out of sentiment because it was fun to build? How do you take something that started life as a throwaway and promote it into a real product line, supported and on-call and load-bearing, without it folding the first time it meets actual traffic?
There’s an architecture problem hiding in there too, and it’s the one I’m most wary of. More and more of these heterogeneous, half-experimental systems are going to end up carrying real production load tied to real revenue. As I wrote last time, the danger isn’t that the machine builds badly, it’s that without good context and conventions you don’t get a clean system, you get a Frankenstein that’s very hard to tame later. Someone has to own the question of which experiments graduate, and someone has to make sure the ones that do stay coherent with everything else instead of sprawling into a museum of one-off architectures. That work is not smaller than the old coordination work. It’s bigger, and it matters more.
So the cross-cutting roles invert. They move from making the favor economy fair to curating a portfolio of living experiments, deciding what to kill, deciding what to grow, and keeping the fleet from turning into chaos. That’s a more demanding job than the one it replaces, not a less demanding one.
The questions I don’t have answers to
That’s roughly where my conviction ends and my uncertainty begins. Here’s what I keep turning over. Each of these is probably its own post, and I’m fairly sure I’ll get some of them wrong.
Do organizations get smaller? The tidy answer is yes: smaller teams, smaller product lines, less internal competition for the same narrow slice of customer attention. It’s the natural outcome and I’m still skeptical of it. Coding agents don’t just let us do our existing work with fewer people, they let us go after surfaces we never could have attacked before. Innovation comes from trying things well outside the known space, and that argues for more shots on goal, not fewer. I don’t think this resolves cleanly in either direction.
The manager’s life becomes a Jekyll-and-Hyde thing. Org charts are already flattening. Meta spent two decades letting engineers pick their own teams and their own work, and is now tearing that model up; more broadly, managers are getting more reports and being told to stay technical at the same time. The leader of this new world has more direct reports, has to stay close to a technology that changes monthly, and has to keep hundreds of live bets in their head at once. These jobs were already stressful because the distance between an action and its result was so long. Now they’re stressful in an entirely new way: the sheer concurrency of it. Willison, who does this for a living, says he can run four agents in parallel and be “wiped out for the day” by eleven in the morning. The limit isn’t the agents. It’s us.
Juniority stops being the axis we look at. I used to assume the risk was that juniors would drown. I’m less sure now. The better evidence suggests juniors are doing fine, and that it’s mid-career engineers, the ones who came up during the long hiring boom without ever building deep fundamentals, who are most exposed. I’ve started to think the real axis isn’t seniority at all. It’s whether someone is willing to work outside their comfort zone. That’s harder to screen for, and it cuts in an uncomfortable direction: it bites the comfortable senior specialist just as hard as anyone, because the person who built a whole career being the expert in one quiet corner just watched the moat around that corner drain overnight. The shape that survives is the T-shaped one, broad and willing to leave its lane, an idea that long predates Spotify and matters more now than when it was coined. So how do we keep new joiners from an imposter syndrome heavy enough to stop them taking the one kind of risk that’s suddenly the whole game?
The people at the top are the furthest from the kitchen. The most senior technical decision-makers are already juggling corporate, investor, and team pressure, and now they also have to understand a set of primitives that didn’t exist a year ago. How do you stay calibrated about a technology you no longer have any time to actually touch?
And if everyone can try more things, how do we choose what to keep? More bets, more experiments, all competing for the same narrow slice of customer attention. The decision of what gets promoted to a real, supported feature gets harder, not easier. How do we balance the new freedom to try almost anything against the old, stubborn truth that you can only ship and maintain so much?
What teams are for now
In the last post I said the thing that really changed wasn’t speed, it was reach. This is the other half of that. When one person’s reach expands this far, the people whose job was to coordinate that person don’t become redundant. They get handed the harder half of the problem. The question stops being who does the work, because increasingly anyone can, and becomes which work deserves to live.
I started believing. Now I’m trying to work out what to build around the belief, and that’s going to take a few more posts than this one.
Originally published at https://davidpoblador.com/blog/the-favors-we-used-to-need.html