Systems Analysts: A 900-Person Profession

Kirill starts with his own route: he joined as a developer and an architect of integration solutions, and that predetermined his interest in systems analysis. Then came heading the integration department, several investment services, work on social mechanics, and now he is technical director of marketing automation, which also covers external advertising. Alexander, who has known him for years and watched those moves, explains why the marketing domain became cross-cutting: with a base of more than 40 million clients — a bit under a third of the country — the boundary between external advertising and internal communications about the current portfolio blurs, and both audiences have to be worked with systematically. Kirill adds that the goal is not marketing as such but smart marketing, recommendation-driven for the client, though he saves that for future episodes: today's subject is his second passion, the systems analyst profession.

The profession grew out of integration. There were plenty of tasks and somebody had to document them; technical writers describing solutions after the fact worked badly — documentation and contracts drifted from reality. So Kirill's team was among the first inside Tinkoff, and by his reckoning the first, to start bringing in systems analysts. In 2022, at the very first meetings right after the New Year holidays, an active group decided to turn this into a profession: they discussed the competency matrix and above all hiring, growth was not yet on the agenda. Today the community is close to 900 people with 41 profession holders from various business and service lines, and by open vacancies the profession is, in Kirill's words, second in the company, behind development only. Holders run the matrix, growth, hiring and interviewer training, but it takes some fifteen per cent of their time: the point is playing coaches, not talking heads who have dropped out of real work.

Last year the company began merging front-end and back-end teams. The same feature used to be described differently in different teams, specifications multiplied, development took longer, and at the seam the round peg did not fit the square hole. Teams are now assembled on various principles, with experiments running, but the premise is that a cross-functional team needs a cross-functional analyst who works a feature through end to end. Alexander notes that such teams have acquired a fashionable new name which captures the point: the team is built around a value stream, it gains something like a local P&L, and hand-offs between the front end and the deep back end disappear; he discussed team topology in the podcast's very first episode with his former colleague Stas. He went through a similar transformation in his own teams: he wrote an RFC arguing that analysts should become end-to-end, and split the universal analyst-technologists into those closer to the business and those digging into systems analysis.

The worry that merging would stuff everything into the analyst was discussed in the community around an article on Habr by a systems analyst from another company. In fact, Kirill says, the matrix has not grown at all, and for the person it is even a gain — they see their whole piece of work, the front end included, and that is energising. The matrix itself is built like the engineers' one: juniors with their own development programme, then middles, seniors and the emerging staff level. It grades not hard skills but results: the level of tasks a person takes on, their complexity, the requirement uncertainty they work under, the artefacts behind them, and the organisational scale at which they improve processes — from their team to the department and the community. A newcomer gets the matrix on day one and sees where they stand and where to grow. The separate hard-skills matrix, which Alexander has seen, is large and overlaps noticeably with what is expected from an engineer: design, notations, technology choice.

This year the profession took on recommendations and mentoring: the matrix said what you should be able to do, but there was no library of materials, videos or courses, and a development plan arrived only after an evaluation. Alexander dislikes the word assessment: what they look at is less the interview than the person's application, results and artefacts — how far they have already shown the expectations of the next grade. Hard skills are probed at a few acupuncture points, some five per cent of the time, and the level matrix leaves them a small last row. Hiring works the other way round and grills hard skills hard: a recruiter screening, a theory section on the tools, and a practical mini design section where the candidate explores a domain, draws diagrams and designs a database. Over two years the headcount has doubled, more than two hundred sections a month are run, any community member may interview, and that is rewarded in performance reviews and internal currency. Alexander recommends sections to everyone who can run them: writing a troubleshooting task is like inventing a Dungeons and Dragons scene.

The staff level is described as an architect who ties several teams together and designs large solutions closer to business processes and a complex domain: laying them onto technical building blocks that already exist. Such people read code, some write it, and passing the design section at a very high level is mandatory. The other track is team lead: an analyst who has become the glue of a team grows into its manager, though systems analysts are not hired into that role from the market, since a newcomer would have to dive into the team's engineering at once. The closing argument is whether an analyst is needed at all. Kirill states the counter-argument honestly: technical documentation largely duplicates code. But somebody has to talk to the product manager, who lives outside the team's pipeline, and pull out functional and non-functional requirements. Alexander objects that a good engineer always thinks about non-functional requirements and that system design interviews check exactly this, so the thesis holds only up to middle level. His model: an analyst pays off where engineering rails and a money-minded product manager exist, while in a deeply technical team they arrive later, polishing the solution and explaining it to internal consumers rather than breaking ground.