Engineering Manager Career: Delivering Value Through People

Andrey starts with a definition: an engineering manager runs a set of engineers and answers for that set bringing value to the business. He sees three streams of work — delivering business value and money; the state of the system, meaning stability, bugginess, release speed and how current the stack is; and building the team, down to what a developer's LTV would be if such a metric existed. Metrics are born where the streams meet, and processes out of metrics; for him processes are a tool for balancing the three goals, not a separate function. Alexander adds the angle from his HighLoad talk of some three years ago: the balance depends on the company's stage. A startup needs domain knowledge, and engineering there is about the feasibility of roadmap goals; a scale-up needs managers so you do not become the bottleneck; a large company puts processes and tooling first; a mature market puts operational efficiency and costs first, because the shares are already divided.

Andrey agrees and sharpens it: the focus shifts not only with the size of the company but with the size of the team inside one: with fifty or a hundred engineers rather than five, the hard part becomes literally organising people. He has a contradictory feeling about it: if internal efficiency genuinely becomes more important than the product being shipped, that may be a signal the company will not grow further; he has had teams like that, and it is slightly sad. Alexander objects that the conclusion does not necessarily scale to the whole company: in a big organisation some directions are cash cows from the market-share-versus-growth-rate matrix, where new bows and ribbons excite nobody, while others deserve the effort. Andrey confirms it from Yandex: a business matures, its efficiency gets tuned, and new units are launched on the people and ideas freed up — Lavka itself once appeared as a startup built by people from the taxi business when taxi was already large.

Why go into management gets an unexpected answer from Andrey: he motivates nobody and does not believe a developer should become a manager. Some people only need to learn such work exists; others like everything about engineering and should change nothing. His own interest in a task ended the moment the solution was found: coding is interesting the first five times, and by the sixth it is not. What drove him was influence on the outside world — not beautiful code but people getting their food in five minutes instead of fifty, or a virtual machine becoming movable between clouds; he worked at a startup building exactly that software. With his own hands he would be as effective as five developers at most, while some products are built by a hundred or a thousand. He has seen many engineers talked into management: the success rate is low and they do not look happy.

A dangerous expectation is quick money: first-level leads often earn no more than seniors while the workload grows a lot. Alexander recalls his own move some thirteen years ago, when management was practically the only way up: at first he delivered less, not more, while the team went through forming, storming, norming and performing. Joining T-Bank in 2016, he earned less than the engineers of his own team and caught up with them only a year later. Andrey describes the ladder like this: a beginning team lead with three to five developers who still writes code part-time; a manager of about ten who no longer writes code at all — that is where a full-fledged manager starts; leads of leads with several dozen; teams of up to a hundred, where in smaller companies a CTO already sits; and an arbitrary number of director-level steps covering hundreds and thousands. Both laugh at title inflation: a CTO once meant the director of development, and now a whole technical top management covers it.

The hardest transition, for Andrey, is from senior engineer to manager: you stop turning knowledge into value with your own hands and learn to deliver it through people who do not have that knowledge. He compares it to mild schizophrenia: another person is a separate mind you cannot force — they will simply change jobs if you are impolite. Every level after that repeats a shape: build a picture of the future from product pieces and a technology vision, get traction along it, make it work without you, and invest the freed time wider than your own team. Alexander adds a constraint: promotion assumes there is somewhere to go, while structures are being flattened instead, and in a stagnant company promotion more often arrives through someone else's failure. He also brings up Ron Westrum's culture typology from Accelerate: where messengers with bad news get killed, problems stay hidden. An experienced team lead once asked Andrey how to grow further; the company turned out not to be growing, and the best advice was a new job.

Andrey's time management rests on two tools: one calendar and a personal to-do list, with everything personal in the calendar, from breakfast to sleep, and no meeting booked over those blocks. He splits work meetings into watching processes (failures and downtime, product bugginess), change projects where a mistake is too expensive, personal conversations with reports and stakeholders, and a couple of hours a day for intellectual work and the to-do list; tasks are prioritised expertly — impact from S to XL plus a deadline. Eighty per cent of deadlines not missed he counts an excellent result, and he tries to stay within eight to ten hours. Staying technical rests on two and a half methods: an hour a week on each of a handful of key engineering build-outs, reading posts for the signal (forty articles on Habr in a quarter is a reason to read at least five), and talking to peers; writing code by hand only fits into free time. Alexander adds papers instead of books, and Cursor with Perplexity closing the lost hands-on feeling.