Development path for a development manager

My career began with the expectation that after technical education I would be able to work in science. In my third year, I got my first job as a junior developer in a small company without mature engineering processes. The discrepancy between university computer science and real industrial development forced me to independently study code review, testing, assembly and rules for supporting large systems. Then there was an attempt to move into analytics, a return to development, growth to middle and senior, and the first fork: go deeper into technology or look for a larger scale of influence.

The next step was the role of team lead: first the launch of a new version of the product in the publishing house, then several more teams, a startup and, finally, Tinkoff.ru. In terms of recruitment, the technical team grew from approximately ten to one hundred people. In retrospect, the first years could have gone by faster - I didn’t have to go into analytics for long and got into a strong environment earlier. But these deviations provided a broad view of the business, architecture and processes. Mindfulness does not preclude experimentation; it helps to understand why each of them is needed.

Junior and middle are building up their engineering base and independence. At the senior level, responsibility for large parts of the system appears, but influence is still limited to personal productivity. The transition to team lead changes the profession: the result is now created through people and the process. It is necessary to establish work rules, develop specialists, delegate and be responsible for the overall result of the team, and not for the amount of code written with one’s own hands.

The leader of several teams changes the scale again. He works through team leads, distributes resources between areas, agrees on priorities and deadlines, disseminates good practices and implements changes. At the technical manager level, business results become the yardstick.

The first working environment is especially important. Junior, with no previous experience, accepts local rules as the norm, so he needs both clear responsibilities and a complete engineering loop: code review, tests, CI/CD, reproducible infrastructure and a transparent delivery process.

It is better to transfer practices between teams not by order from above, but through a common problem and experiment. First you need to show that a similar team has already gone from the initial state to the result, then offer to try the approach and check the effect. For a development manager, the feedback horizon is measured in months: a change agreed upon today may only work in six months. Impatience at this level can easily be mistaken for lack of progress.