Development path for a development manager

It began with school and a physics-and-maths class, then a technical university and the expectation of a career in science. Science did not work out: the pay was low, and by his own admission he was not very good at it. The first job came in his third year — a junior role in a company on the university campus. The processes there and the code he had to maintain surprised him, so he started looking into whether things were done better elsewhere. In the course of that he wondered whether programming was for him at all: he went off to intern as an analyst, did not enjoy it and returned to development — back to the same campus company, because he had not finished university, this time as a middle developer. He graduated, grew to senior and hit a fork: the company was not growing, the team was not expanding, and the product was effectively legacy they maintained.

The bigger thing turned up elsewhere: an interesting product that needed a new version launched, and permission to assemble a team for it — a publishing house. Alexander spent about two years there, built an excellent team and left exactly when that team dispersed, following it out. Several more team-lead jobs followed, and at some point it became clear that a team lead's responsibility for the result is capped: a team will not do more than a certain volume of work, and he wanted to bring benefit at a larger scale. First came a small startup, which he liked a lot, then Tinkoff.ru, where acquisition had about ten technical staff and very large plans for a variety of projects. They decided to automate the area themselves — and in two years grew by an order of magnitude. By the talk he had around a hundred technical specialists, and notes straight away that he is not the company's only development manager.

The first conclusion is about deliberateness: the outcome of a career depends heavily on how the path was thought through — which stages you went through and what information you gathered. Had Alexander thought from the start about where he wanted to arrive, thirteen years might have shrunk to, say, seven: the first five or six went into searching for a direction, done inefficiently and with too much scattering. The second conclusion is about being a junior: computer science with its algorithms overlapped little with the actual work, while the business needed systems engineering — the basic rules, processes and principles you follow to get quality code out. Not wildly fast algorithms, but simple, understandable things built inside the right process. The third is about the ceiling: a senior does every technical task there is, yet his effect is capped by his own output, while teammates, in his view, do not quite the right things and not quite the right way. Influencing that from the lead developer's chair did not work.

That is how he became a team lead, and he found the role is more about processes, about people and about the engineering approach you bring into a team. A team lead's horizon is his team's context: the product and delivery, the internal processes, who the customer is. With several teams come priorities and strategy: in what order things should be done, how to distribute programmers across teams, what deadlines to commit to given complex interdependencies, and how to spread changes around. The yardstick here, as it seems to him, is the business result, and you start from the business goal — why we are doing this. Next comes controlling the architecture: businesses often stop developing past a certain point because it was laid down unscalably, just to get off the ground, and reworking it later is very expensive. Then comes forming the right teams and organising their processes: teams exist, processes inside them do not, the result is mediocre. Once that is done, you step aside, watch how the teams show themselves, single out those who succeed and help the ones falling behind.

The first question was about the role of luck and about whether he chose his moves himself. Luck is definitely there, Alexander answers: the detour into analytics coincided with a new university department opening, the master's programme sounded interesting from its description, and he wanted to try it — he learned a great deal about processes and architecture, which helped later, though on the direct path he lost a year to eighteen months. An understanding of what he wanted arrived roughly at the middle level: the choice between architecture and managing teams was still open, but it was clear he had at least to reach lead developer, get to grips with the technical side and see whether he could exert influence from there. He picked his next company on two conditions: an interesting project with a challenge to overcome, and the confidence that he would be helped — allowed to assemble a team and act within a budget, with a business that has big plans and is not stagnating. That filtering is serious and takes time, though searching is easier when you are a good specialist.

The floor asked what companies with weak processes should do if they want to grow juniors. The answer: improve the processes first, then bring juniors in — in chaos a strong specialist works things out, but a newcomer has nothing to lean on, and that is when his foundations are laid. Alexander counts his own start as the wrong one: a company without processes, some 200 megabytes of code five years old, three people digging around in it, wall-to-wall copy-paste; he bought Code Complete and a pile of other books to see how software is built industrially. The right process, he clarifies, is all of it together, sides of one coin: clear duties, code review and the technical part — tests, an automated pipeline, reproducible infrastructure. Roman asked how to get a process working in a second team: no Procrustean bed — understand why it took off in the first (the release rhythm, the team's make-up), then come not from above but with the shared problem, showing the neighbours' before-and-after story. The horizon stretches out here: a change may take half a year to fly, and expecting results within a sprint is demotivating. The last question was where to cut corners: skip the analytics detour and start in a company with processes, and the six years to team lead would have compressed to about three.