The Evolution of the Technical Leader

A cross-functional team combines different specialties and a complex development process. The team lead gives the business a clear point of contact for discussing work and problems. In a small team, the lead can still combine hands-on technical work with management. Reasons for making the transition vary; the author cites greater influence over outcomes, process improvement, and compensation.

Management is not simply the next programming proficiency level. A leader needs to understand how people's joint work becomes a product and accept responsibility for the team's results. The example of around ten people illustrates this scope. Headcount does not automatically define the role; the nature of collaboration and the decisions actually owned by the leader matter more.

As a business area grows, the team becomes the unit of scaling. An Engineering Manager oversees several teams, works through team leads, and ensures the teams are appropriately composed. The example of roughly fifty people illustrates why personal involvement in every technical detail stops being the main job. The leader must create conditions in which teams can deliver without constant intervention from above.

The author identifies four foundations for this role: engineering knowledge, business understanding, delivery processes, and working with people. Technical knowledge alone is insufficient without understanding the user-facing product or the business process being supported. Good relationships are also insufficient if teams cannot complete their work. These capabilities reinforce each other as dependencies between teams increase.

At the next scale, one person struggles to combine architecture, processes, and people management. Dedicated delivery and architecture leaders may emerge, alongside explicit roles, career levels, and performance assessment. The CTO needs to coordinate product and platform teams, develop technical leadership, and connect technology strategy with business needs. Increasing the number of reports does not create this operating system by itself.

Large organizations may distribute responsibilities among a CTO, CIO, and VP of Engineering, but the titles do not guarantee equivalent duties. The author distinguishes an illustrative allocation from Tinkoff's structure, where the CIO leads IT and business-area leaders act as CTOs for their domains. The company's lifecycle also matters: during contraction, maintaining the product and managing costs may take precedence over the earlier demands of rapid growth.