At Apple, my team once needed a firmware fix to unblock a feature in a prototype iPhone build. We had the root cause. We had a plan. We needed another team to make the change.
They were busy with a customer-facing issue.
Reasonable priority…terrible timing for us.
Ever work hard on something just to be gated by someone else?
Hardware programs give you plenty of practice. Different teams own different pieces of the same deadline, and your emergency can arrive while somebody else is already dealing with theirs. We had engineers available during the build. Headcount wasn’t the solution; adding more people to our side would have left them waiting on the same firmware team.
Our schedule depended on someone else’s clock.
We eventually side-loaded an engineering version of the firmware during the station flow. It ran only during manufacturing and exposed the APIs our test stations needed for the new calibration routine. That let us use the hooks on the line without waiting for the full qualification cycle to complete.
That was an engineering judgment call. We understood where this version would run and what we needed it to do. We could accept that limited risk ourselves.
The build shipped on time, and every unit in that build got the calibration fix.
I remember that because knowing how to fix the bug had only gotten us so far. We also had to figure out how the work could proceed with the people and time available. The workaround changed that dependency.
Years later, working alone, I rebuilt the same problem from scratch. Efficient.
Since January, I’ve merged 666 pull requests. The median time from opening one to merging it was about two hours. In my experience, a run of the automated checks takes roughly 20 minutes. A change can need more than one run. Review and rework take time too, along with the wait until I get back to it.
There’s no other team’s approval queue to blame.
And one of the gates is embarrassingly easy to identify.
I am the other team now.
I love using agents. They let me attempt work I could never reasonably do alone. In May, I wrote about finding my way back to the keyboard after years in management. I still feel that way.
I also have to come back to the work, rebuild enough context to judge it, and decide whether it can land. While I’m doing that, the agents can keep producing more for me to look at.
“Human in the loop” sounds reassuring. There’s an adult somewhere who can intervene. Usually the discussion concerns what that person should approve and how much authority the agent should have.
The adult also has a calendar.
A decision that needs a few minutes of attention can wait hours for those minutes to become available. If other work depends on the answer, the delay spreads. The agent doing the waiting may have finished its assignment perfectly.
In OpenAI’s internal research workflows, more than half of successful agent tasks estimated to require four to eight hours of human work involved at least one human intervention. That’s from its September 6 report.
The report doesn’t measure time spent waiting for people. Those interventions may have been exactly what made the work successful. They still needed room in somebody’s day.
This is where my old management habits become useful again.
If an agent is investigating a question that determines how the rest of the work should be built, I need to give that question attention early. Letting the other agents race ahead can leave me with more finished work to redo once the answer arrives.
The longest-running task might need a head start. Keeping every agent busy can be a very convincing way to avoid noticing that the work I need is still stuck.
I can do that to myself without scheduling a single meeting.
So before starting more work, I want to know where it will have to stop. What decision will it need from me? Can I make that call now, while I already have the context, and give the agent a boundary it can work within?
Some choices deserve a human review every time. Others keep coming back because I haven’t been clear enough about what can proceed without me. Treating every small decision as a fresh request for permission makes my attention a dependency everywhere.
On a team, that gets more consequential. “Waiting on review” is a weak plan. Someone needs to know whose decision is missing and when the answer is needed.
On that build, we could make the call to run engineering firmware on our stations and take responsibility if it went wrong. That let us move while the firmware team handled the customer issue. If the workaround had still needed their sign-off, we’d have been back in the same queue.
Escalation can get your work moved up the list. Somebody else’s deadline still exists. If every dependency needs an escalation, I need to look at how I’m planning the work.
The cheaper move is usually to make the decision smaller. Narrow the work until there is a version somebody can say yes to today, with the risk written down and owned by name. Sometimes that means getting the right person involved earlier. Sometimes it means changing what you are asking for.
A thinner management layer leaves those decisions with whoever is still there. An engineer running agents inherits more of this work, whether or not they ever wanted to manage anything.
I thought going solo would at least make the coordination simpler.
Now I can be the engineer waiting for an answer and the manager who hasn’t gotten back to him.
Creators lock in holiday calendars 90 days out. Structure commissions, recruit creators, and optimize your creator affiliate strategy before the rush with Levanta's 90-Day Holiday Sprint. Get the Free Guide.
