Becoming a team lead in the AI transition

2026-10-11

I'm writing this as a memo to myself. I recently moved into a small team lead position, and I want to capture what the job feels like from the inside — so I can look back in ten or twenty years and remember, and because the ground is shifting under the role in ways worth recording.

Before taking this role, doing well was self-contained: my lead assigned me impactful work, I went deep on the hard technical problems inside it, and shipped it. I enjoyed that — the work was legible and the credit was clear. As a lead, I'm evaluated on what my team achieves, not what I build. The problems changed shape — roadmaps, sequencing, splitting work, motivation — and the feedback loop stretched from weeks to much longer.

There's a classic trap in that transition, and I walked straight into it. My first projects as a lead were in a very fast-moving area, our plates full of high-priority tasks due in days. We solved real problems, but someone else defined them, and the story afterward belonged to the requester. You can do everything right there and remain invisible — and I feel responsible not only for my own contributions but for growing the team, which means their work has to be seen and credited, not absorbed into someone else's story.

That much is the timeless part — any experienced lead has lived some version of it. What I want to add is what's new about doing this now, in the middle of the AI transition.

There used to be a natural protection around the reactive trap: some work could only be done by the team that owned it. Writing a kernel for a specific accelerator demanded depth that made asking non-experts pointless — expertise assigned ownership automatically. Coding agents have drained that moat. They need context and a plan, not expertise, and with enough context they can go quite far on their own, including proposing what is worth doing. When any team can implement anything, "we are the only ones who can build this" stops being a reason for a team to exist.

My response, as a team lead, has been to create the roadmap for my team and explicitly own our part of the project. When any team can implement anything, what I can still provide that a partner team can't is direction: understanding the problem more deeply than anyone asking for help, declaring the objective, and setting the bar for the outcome. That's how a team stops being support and becomes a driver.

But I also see another way of working emerging. For the most important projects, the pattern where I work is a handful of people sharing the full context and converging quickly on the objective — not pillars divided by layers of the stack. People feel valued, responsible, indispensable: the conditions in which they give their maximum. That feeling is load-bearing.

I wonder what the org-structure theory of the coming years will be — whether the small, context-sharing team becomes the default unit, or something else entirely. Maybe in twenty years the team lead role looks nothing like this, or maybe only the tools changed. Either way, this is what it looked like from the inside, at the start.