For the first time since computers happened, managers understand what’s going on in the machine better than ICs.
We’re all working from a cold start as these technologies appear, but managers have an edge. The job of management — the literal whole job — is getting a set of heterogeneous intelligences, each with incomplete context, to coordinate through a set of ever-changing deliverables.
It’s a job I love. LOVE. Not because of the process, but because of the investment. You pour yourself into people, you share stories of your own failures that help them, you get in the trenches with them, and you watch their careers soar. When I see someone I’ve managed doing incredible things, it feels like I did something that mattered.
But when I was a new manager I couldn’t do any of that. New managers are pretty bad at actual management because it’s a distinct set of skills. Skills that every IC engineer just got forcibly thrust into needing.
Most of them are less happy about this than I am. And most of them are unaware.
Delegation toolkits
When an engineer tells me they use AI but they don’t want to rely on it, I hear that they don’t have a delegation toolkit.
A first-time manager cuts hard toward either micromanaging or abdication. They’re either the bottleneck for their team, driving every decision through their own head, or they step away and “trust their team” as the team drifts off into misalignment. That’s the IC-and-AI spectrum right now. Either you hand-hold every line of output, or you YOLO it to production and hope.
A senior manager has a whole toolkit built from years of investing in other people:
- Develop an intuition for where each person is competent versus where they’re merely confident
- Build feedback loops so each person can see their own progress against goals
- Identify roughly where to dive deep into the details to spot-check
- Encapsulate the work so each person can work independently
- Deliberately frustrate that encapsulation to break down silos
When an exec asks a manager “is this project done?” the manager relies on their team’s belief. If your most trusted ICs say it’s done, then it’s done. If it turns out you were wrong to trust them, the failure isn’t with the team — it’s with how you used your delegation toolkit.
Engineers trusting AI
Worries that AI is an “unproven technology” are real but unhelpful. Your team members were unproven once too. The manager didn’t refuse to delegate to them — they developed a calibrated sense of when to trust them and when to check. It looks like faith but it’s skill.
Here’s what that same toolkit looks like when you point it at a model:
- Keep exploring what the frontier models can do, developing intuition for where they’re competent. You wouldn’t hand a junior engineer your hardest architecture problem, and you wouldn’t have a senior engineer perform minor edits all day.
- Build feedback loops. Don’t just accept output — tests, type checks, review checklists. The same mechanisms a manager puts around a fast-moving team that ships more changes than one person can read.
- Identify where to spot-check. You can’t review every line of a giant PR any more than you can attend every standup.
- Encapsulate the work into well-scoped deliverables, then deliberately look at the seams between those deliverables.
We’re at a weird stage where some of our best, most senior engineers have the fewest delegation skills. The junior folks are YOLO-ing code to production and the senior folks can’t review the giant wall of huge PRs. We’re watching hundreds of ICs turn into first-time managers, with all the expected failures.
I think the path forward is the same one every good manager walks: soberly compare the mistakes the models make to the ones you and other humans make; let yourself accept that all of the models and all of the people are imperfect. Then commit to building the skills.