How to Grow When You're Already a Senior

A team lead provides a clear point of contact between the business and a cross-functional team. The move can offer greater influence over outcomes, better processes, and different compensation. Further progression changes the work itself: a leader of several teams works through their leads instead of managing every individual task. Continuing to write code alongside these responsibilities becomes increasingly difficult.

An expert career requires the company to need complex technical solutions, not just the engineer to want a new title. In the proposed framework, levels from Principal Engineer to Technical Fellow differ in scope of influence. This framework was still being discussed when the talk was delivered. It illustrates a possible career structure rather than promising equivalent roles or rules in every organization.

The development matrix includes scope, product impact, problem complexity, leadership, and improvement. Technical depth matters, but it is insufficient without results and the ability to reach agreement. Developing other engineers and improving processes are also part of expert work. Without a formal ladder, the author suggests taking on a significant problem, proposing a clearly framed issue to management, or finding an organization that needs such work.

Two learning paths are compared: studying theory before experimenting, or starting with practice and seeking theory when existing tools prove insufficient. Both require checking outcomes. For a practice-first engineer, documenting the problem, alternatives, and plan in an RFC before implementation makes the solution available for discussion and prevents knowledge from remaining confined to one person.

Development often falls into the important-but-not-urgent category and is repeatedly postponed. The suggested approach is to choose a meaningful goal, create an achievable plan with intermediate outcomes, and focus on regular steps. Backcasting works backward from a desired future instead of limiting possible goals to the familiar boundaries of the current job.

For technical growth, the author highlights system design and troubleshooting. Theory covers distributed systems, tool characteristics, and reliability practices; practical work includes real projects, architecture exercises, and postmortem analysis. Building and operating a system connects these capabilities. The aim is to solve more consequential problems and leave working solutions that others understand, rather than merely accumulate reading material.