Staff+ Engineers: Growing Without Going into Management

Alexey introduces himself: several years with the company, and work on the architecture of the investment product — in his words, a world within a world, a bank inside a bank. The systems are high-load and demand low latency and high reliability, because this is client money and trading operations, and losing it is not an option. The company grew very fast, so architectural problems abound: a constant evolution from legacy monoliths into distributed systems, plus the import-substitution challenge almost everyone now faces. Together with strong engineers Alexey built a process for taking and documenting architectural decisions, and then, with Alexander, began rolling it out across the company and neighbouring units. Hence the Staff+ stream: a developer who runs a single service does not always see the surrounding landscape and cannot rise above it, and without people able to take larger-scale decisions the decisions come out worse.

Alexander starts with the engineering matrix that appeared around the middle of 2020. It is not a hard-skills grid listing which language, database or queue you must know: levels differ by the scope you work at, the impact you have, the complexity of your domain, your leadership skills and how much you improve the work of the people next to you. Most of the matrix was assembled by a former colleague, Andrey Marchenko, who is promised as the guest of one of the next episodes. Alexander himself used to think the path stopped at senior and continued only into team lead: small companies simply had no need for high-level engineers. Here he saw both such people and the demand for them, and the Western big-tech pictures with Staff, principal and distinguished engineers — and, in places, a vice-president-level engineering title — began to make sense. Moves between the tracks are treated as normal: once management palls, you can return to Staff+ at the high level you have already reached.

The term Staff+ was claimed by the author of the book Staff Engineer; Alexander recommends both the book and the site with its interviews — roughly half of it is conversations with such engineers about what these rare beasts do. Next comes a classification that matters because these are roles, not job titles. Some sit in the thick of things and work as the tech lead of a direction: improving engineering processes and reliability, refactoring and designing a complex system. Some jump between teams and put out fires — the supermen called in when others cannot cope; Alexander recalls a Java application optimisation specialist at Netflix whose name he has forgotten, and a couple of similar people at Yandex. The architect goes less deep but holds the landscape, the cross-dependencies and the agreements, so that the hot potato is not tossed to the neighbour. The far end is the right hand of a head of architecture — a role Alexey seems to Alexander to have played in investments. The roles emerge on their own; the company only systematised them, finding a concrete person behind each.

Do they grow such engineers themselves? A frequent question; yes, but the company grows faster: in the three-odd years since a late-2020 talk the client count has tripled, the in-house education arm supplies interns and its named talents, and an influx of new blood is still needed. The growth process: an employee agrees a plan with their manager against the matrix, with tasks of the right complexity — say, from middle-plus to senior in two years. When they are pulling the next level, they file an application in an internal system listing whom they worked with and what artefacts came out of that work, and profession leaders from different streams decide whether the bar is met, returning feedback when it is not. If someone arrives with a team-lead offer in hand it is usually too late: something already went wrong at the level of their own management. Simple projects critical for the business offer no growth, so a rotation process lives alongside for those who hit their ceiling.

Alexander walks through market hiring from his interview slide. The technical part was always a sweet trio: algorithms — neither of them sees anything shameful in LeetCode, and they make others love it too — a section in your primary language, of which the company has almost all, and system design. He recaps what that is, because the question kept arriving in his DMs: functional and non-functional requirements, quality attributes, the public API and the scenarios that pass through it, a conceptual diagram, the classes of components inside the main workflow, and finally a choice of technologies with a load calculation — a miniature hour-long design task. Alexey pushes back a little: candidates who have read Alexander's articles pass the section noticeably better, but someone else's algorithm without experience carries you only to an entry level, and the task can always be made harder. Alexander handed the curation of the section to Alexey, who made it more systematic.

Seniors who do not want a team but can carry large projects used to be sent to the team-lead section out of sheer desperation. Many strong engineers failed it — not empathetic, unwilling to manage people or fed up with it — and the colleagues running it said it made little sense. The problems from the 2020 talk piled on top: cross-cutting technical decisions were taken by non-technical specialists — technologists, business analysts with project-manager duties; finding out what had already been built was hard; the reasoning behind old decisions could not be traced; consumers did not always demand an SLA and providers did not always know what SLA they offered, so consumers wrapped themselves in workarounds, accruing tech debt. Hence a section on architecture and the development process. Alexey draws the distinction: in management, leadership is about resources and capacity, while in the Staff+ track it is about proving you are right without formal authority and admitting when you are wrong. The section runs as a conversation of equals: the candidate's experience, model situations such as depending on neighbouring teams with their own backlog, and the candidate's own questions.