Between 2011 and 2014, I was a Python tech lead at Tikal. My team was four people. On any given workday, we were sitting in four different companies.

Tikal is a software consulting firm. Each of us was placed at a client site. I was at Radvision, then at Healarium. My team members were somewhere else entirely. I could not sit next to them. I could not read their commits over their shoulder. I could not tell them what to type next.

That physical structure quietly forced the right role on me. I could not be a team lead if I tried. So I became a tech lead.

Placed at Four Companies

The Tikal model works by embedding consultants inside client teams. You show up at the client’s office, use their laptops or yours, sit in their standups, and ship into their repo. From the client’s side, you are effectively one of their engineers for the duration of the engagement.

That model has a specific consequence for how a “tech lead” role can actually function. There is no shared office. There is no daily walk-past. There is no way to keep tabs on line-level work without turning yourself into a bottleneck across four unrelated codebases you have no context on.

So the role naturally collapses to the parts that scale.

What “Tech Lead” Actually Meant

In practice, my job broke into three things:

  • Hard design and architecture calls. When a team member hit a real problem, they would send me the context and we would work through it. Not “what should this variable be named” but “should this thing be a queue or a database table,” “how do we structure this service so it survives contact with the client’s ops team,” “is this framework worth adopting for this project.”
  • Framework and tooling picks. Which ORM. Which task queue. Which testing setup. Which deploy story. The decisions where being wrong costs six months and being right is quiet.
  • Mentoring, not micro-managing. The distinction that matters. I was not reviewing every commit line for style. I was helping a smart engineer think through a hard problem, then trusting them to write it.

 

The Pre-Project Consultancy Pattern

Separately from managing the internal team, startups started coming to me before their next project. A founder or a CTO would set up a meeting, walk me through the product they were about to build, and ask which stack to use, which tools to standardize on, which framework decisions would matter and which would not.

That pattern surprised me at first. Then I understood it. The value of an outside voice is highest before you have written any of the code. Once the code exists, changing your mind about the framework is a rewrite. Before it exists, changing your mind is a conversation.

Those pre-project conversations were the highest-leverage hour a founder spent in the entire project. I did dozens of them over three years.

The Two Projects I Actually Wrote

In parallel with the tech lead role, I did two hands-on placements myself. One at Radvision, building video conferencing infrastructure. One at Healarium, working on a health platform. Real engagements, real code, real production.

That was important. A tech lead who does not build anything themselves loses the taste for what is easy and what is hard. I needed to be inside the same kind of engagement my team was inside, or my architectural advice would drift into theory.

The Shape That Works With AI Agents

Fifteen years on, the tech-lead-not-team-lead distinction is the single most useful frame I have for working with AI coding agents.

An AI agent is not a junior engineer you review line by line. It is a team of engineers who produce more code, faster, than you can meaningfully read. If you treat that team like a team-lead would, reading every diff, correcting every comma, insisting on a particular ordering of function arguments, one of two things happens. Either you slow the agent down to the point where you might as well have written it yourself, or the agent stops producing anything meaningful because your review latency became the bottleneck.

The role that scales is exactly the one Tikal forced on me in 2011. Set the design. Pick the frameworks. Catch the wrong turn before it becomes a rewrite. Mentor the parts of the system that need judgment. Get out of the way of the parts that do not.

Why Team-Leading an AI Doesn’t Work

The team-lead reflex, applied to AI, has a specific failure mode. It goes something like this:

  • Round one: the agent produces a working feature. You spend two hours refactoring it into the style you would have used.
  • Round two: the agent produces another feature. You spend two hours refactoring it, notice the same patterns, and start writing more detailed instructions to prevent it next time.
  • Round three: your instructions have become their own maintenance burden, the agent’s output still needs your two hours of cleanup, and you are now doing the work of writing the code AND the work of writing the meta-code about how the code should look.

 

You have re-invented the worst version of team lead. You are on the hook for every line, and you did not even write them.

What Tech-Leading an AI Looks Like

The tech-lead version is different in shape.

  • The design conversation happens up front. Before the agent writes anything, you decide the shape. What module structure. What data model. What the boundaries are between what the agent can touch and what it cannot.
  • You catch the wrong turn, not the wrong comma. If the agent chose the wrong data model, that matters and you fix it. If it named a variable differently than you would have, you let it go.
  • You review architecturally, not line-by-line. “Does this fit the shape we decided” is a five-minute question. “Is every line the way I would have written it” is a two-hour question that produces the same running code.
  • You keep hands on the hard 10%. The gnarly integration. The subtle concurrency bug. The part that will bite you in production. Do not delegate that.

 

The mistake most teams are making in 2026 is treating AI like an infinitely-patient junior who needs supervision. It is not that. It is a team of four engineers you cannot sit next to. The role that works with a team of four engineers you cannot sit next to is tech lead.

Let’s Talk

If your team is trying to figure out how to actually work with AI agents day-to-day, and the current setup feels like it is producing more diffs than progress, that is usually a role-shape problem, not a tooling problem. Happy to walk through it, no pitch, just a design conversation. Reach out.