The tech lead and the engineering manager are the two roles through which every decision about AI in development reaches a team. A delegation profile sets ceilings, procurement buys the tools and the works council negotiates the terms, but it is the lead who sets the rules for the pull request on a Tuesday and the manager who is asked, in the planning round, whether the team can be smaller. This chapter concerns three of the five developer functions defined in Chapter 4. D1 Frame is the lead's duty to keep intent ahead of generation. D3 Build is the team's rules for making software with assistants and agents: what may be generated, under which mandate, with what disclosure. D5 Steward is the team's answer to who owns what, who can stop a change and what evidence goes upward. The chapter asks what the tech lead owns that the tools do not, which measures help and which mislead, how pairing and onboarding change, how headcount is discussed with evidence, and what a team working agreement and weekly rhythm look like.
A tech lead is a developer who is accountable for the technical direction of a team's software. Software Engineering at Google draws the line between the two roles in a sentence: a manager is a leader of people, whereas a tech lead leads technology efforts, and on small and new teams a single person often does both as a tech lead manager, although the chapter's author prefers two specialists where the team can afford them (132, Fitzpatrick, 2020). The description predates generative AI and still holds; what changes is where the lead's attention goes.
Four things stay with the lead because no tool in the two organisations holds them.
Primary topics explored
- Two jobs in one team
- Metrics that do not mislead
- Pairing and onboarding
- Headcount conversations
- A team working agreement
- Summary
About AI Developer
AI Developer is Book 12 of The Transformed Architecture. It takes the developer as its subject and asks what happens when AI is used broadly in software development: the five developer functions (frame, design, build, prove, steward), the delegation ladder and the Level 4 prohibitions, the stewardship principle (name, understand, revert), verification as the scarce skill, the junior pipeline, adoption and productivity as claims that need evidence, regulation (the AI Act, the Cyber Resilience Act, the Product Liability Directive, NIS 2, DORA, the GDPR), ethics, intellectual property and sovereignty in the toolchain, and the developer as a person, for European enterprises and public authorities.
It builds on the conclusions of Architecture as Code, AI Governance, AI Platform and Security, AI Red Team, AI Threat, The Transformed Security Architect, AI Boss, AI Blue, AI Purple, AI Operations and AI Leader.
developers at every level, tech leads and engineering managers, architects, platform engineers, site reliability engineers and testers, product owners and designers, leaders who decide on developer tooling, heads of public-sector IT and procurement, works councils and unions, educators, and supervisors and auditors.
Continue with the full chapter
Chapter 15: The Tech Lead and the Engineering Manager in AI Developer gives the detailed explanations, practical examples and implementation patterns behind this summary.
This whitepaper belongs to “Developer Roles Across the Organisation” and is one of 37 drawn from the manuscript.