Round Table: Tech Lead and the Individual Contributor Track

The host opens on a rarely aired topic: a tech lead is nominally a separate role, yet what it steers is left unsaid, and the job usually falls to the team lead — that mythical player-coach. The reverse happens too: a strong developer is handed a team and told to slice up tasks. Maxim would rather a tech lead stayed out of people management and shaped the team's technology landscape, managed dependencies and inspired people to learn, because on the management track the despair of never writing code is endless. The room gets a quick quiz: who knows what an individual contributor is, who has met one, who thinks they are one. Alexander recalls that in small companies senior is the ceiling and the next offer is a team; which is how he left for management. He also remembers talks of years past — how to stop being an engineer and become a team lead, and two years later how to become one again — and the good developers talked into becoming poor managers.

In a large company, he continues, it is different: many teams, a complex landscape, platform tooling, boxed systems to be replaced with a new stack — problems you cannot throw ordinary engineers at, while such people are scarce on the market, so companies grow them internally and justify the new role matrix to the business. And the business asks bluntly why a developer with nobody reporting to him should cost as much as someone with a couple of hundred people, and where a lead engineer's team is. The Delimobil CTO answers with a metaphor: such an engineer is Messi, LeBron, the position-one carry who pulls the team along; leadership cannot be delegated, these people grow on their own authority and expertise. The host objects that there is no market standard of competencies — the smartest guy in the room can be neither hired nor validated, because no finite list of knowledge describes him.

The grade matrix, Alexander explains, is common to any software development engineer rather than split per stack; it was driven for a long time by a colleague who has since left. Its criteria are tied to influence, not to the tools you know: scope, the scale you work at; impact, what your actions lead to and how much benefit they bring; leadership, sorting things out through relationships rather than pulling rank; and improvements, for which he has the image of a paladin whose aura makes everyone around work better. He reviews promotion cases against those criteria, and the language someone wrote in matters far less. Influence varies: one only has to turn up and review an architecture document, another mentors the team, a third automates processes, a fourth replaces a zoo of libraries with one so that teams need not migrate for a year.

Demand comes from the business and always sounds the same: we can assemble a prototype or an MVP, but at scale-up reliability and performance break, and doubling the team left delivery speed unchanged. Growing such engineers is deliberate work: find proactive people inside, hand them responsibility for hard technical problems rather than for people, promote them and show the result publicly, so others see the path is real. The levels map onto scale: an entry-level individual contributor sits at the senior grade, a fully rounded team lead at the staff grade, and a staff engineer rarely works inside one team — usually several teams in a domain, roughly a department of fifty. The next step is two hundred to two hundred and fifty people, then a company of over ten thousand engineers, while fellow is about recognition across the industry. Such engineers also lead their professions: tooling, unifying the stack, reviewing promotion cases, interviewing, developer relations. Hiring from outside runs through separate stages: a coding session, system design, and a walk through the candidate's cases they call the architecture of the development process.

How do you notice such an engineer on a project? Gleb lists the symptoms: the build suddenly got faster, flakes less, rolls out better, and six months later the whole team lives in TBD — and he calls these people agents of change. A colleague jokes that the phrase is a poor choice and offers the boy scout rule instead: you walk across the car park, see a cigarette butt, carry it to the bin, because the usual reasoning is the opposite — this bad code has rotted here for five years, let it rot on. One participant says the essence is simply caring: if the neighbouring team is struggling you can put up with it, or take responsibility and push impact through initiative rather than orders. The host adds the distinguishing mark: a tech lead not only understands deeply but explains what he is adopting, so rolling out a technology doubles as coaching in it, not configuring the build tool once and forgetting it.

The opposite risk is the engineer who tells nobody and simply does it — guerrilla work that eventually crosses a line. The room presses on the sore spot: a Monday pull request over thousands of files is a fine way to inflict good, speeding up the build while wrecking feature delivery. Alexander, who told the 2,600-file story himself, gives the context: about ten teams, a bank for corporate clients, the stage right after the first MVP; it was not going straight to production, a couple of teams were certain to break, but the code fell into libraries and domains and ownership got less tangled — and he had warned people, asked, and was ready to apologise. Better, the participants agree, to describe the problem before the pull request and legitimise the initiative through a profession or a guild, say one for build speed: good nobody asked for turns into harm easily. The room also asks about grade inflation: it exists, but in one participant's view it is the useful kind. The last question, on the IC competency matrix and the formula for scope, impact and leadership, is answered in money — impact recast as money earned or saved, as when a platform team at Uber moved from Java to Kotlin in eighteen months instead of a decade of decentralised migration.