Processes and Tools: Words Fade, Tooling Stays

Pavel grew up in a family of engineers and teachers and first programmed on a Soviet computer at home. He studied mechatronics, wrote code for microcontrollers and then became a software developer.

In outsourcing his colleagues' sloppiness about delivering a result annoyed him, so he began pulling people together, drifted into team leading and read management books. Then came a large systems integrator, straight into management, followed by Yandex, a Rostelecom subsidiary and a few startups.

He was invited into his current company at a party, but there was no management vacancy: he joined as a developer on payments, where more experienced colleagues told him in review what to improve, and three months later he was given the investments frontend team.

The defining story of those years was the launch of the company's own brokerage: the business had previously run through a partner, and now financiers, high-load engineers and a crowd of others sat in one room, each with their own language. Daily standups stretched to three hours. Over one weekend Pavel moved every task onto an enormous physical board with stickers — the photographs, he says, still exist — after which standups shrank to five or fifteen minutes and he was declared scrum master without any certification.

He then drew a critical chain and pulled the metrics: the team was nowhere near its deadlines. Top management proposed adding developers to the bottleneck; he argued it was testing, without which a financial instrument cannot be released. The experiment with outsourced developers only increased the testing backlog without bringing the launch forward; Alexander recalls Brooks and The Mythical Man-Month. Pavel says the brokerage launched on the dates he had calculated from the process constraints.

He also made everyone push Oracle scripts through git for a diff and a review, and was surprised how many had never heard of it.

The turning point came after Kanban training: the company required anyone who took a course to come back and teach it internally. He not only told the story but applied visualisation and metrics, which a neighbouring travel team came over to look at; word reached management, which offered him the job of rolling the approach out company-wide, turning informal help into an official evangelist role.

Next came a delivery management function, established by several colleagues, communities for team leads and delivery managers, courses, a large internal knowledge base and a facilitation track whose service he now uses himself; he also properly qualified as a Kanban teacher.

At some point he realised everything rested on words and explanations while people had no tooling at all. A quotation he had heard, whose author he could not recall precisely, helped: it is technology that changes life first.

Alexander unfolds the same thought from the engineering side: a process changed by words alone fades unless the cognitive load drops. You can explain at length how to call someone else's API — retries, limits, circuit breakers — or hand over an SDK that already does it, and people will get it right out of the box; their own teams, replacing an external analytics service with one of their own, ship an SDK for sending events.

The day before he had told students on a joint programme of the Higher School of Economics and Central University that an engineer is now expected to cover design, operation, security and data pipelines at once, and that tooling has to close part of it: baseline checks in the pipeline, an annotation or a configuration that makes it work out of the box.

There is a flip side, Pavel adds: people start thinking in the tool. He calls it Jira thinking — a good but limited product that ought to adapt to the process rather than the other way round. Alexander offers a parallel: an engineer who calls themselves a React developer, while hiring is for developers of systems.

Pavel's remit today is collaborative work, and every product in it grew independently around one data source, Jira. An automated Gantt chart builds dates from prioritisation and Monte Carlo simulation and even accounts for holidays: it solves the very cross-team synchronisation problem he once worked out with a pencil on paper.

A statistics service collects process data and returns lead-time reports, and an iteration planner uses Monte Carlo to estimate what can fit into a sprint. Pavel explains how to act on the reports: examine the tasks in the long tail of lead time and group the causes of delay. If dependencies repeatedly block work, investigate why tasks are started before those dependencies are resolved.

A dependency table for SAFe-style PI planning appeared separately: a neat technology for visualising links between issues had no use until teams from non-financial services came with a synchronisation pain and Nastya Medvedeva suggested pairing the two. The tool is narrow, but it syncs with Jira and links issues in bulk.

The cross-team report was named C level at the executives' own request, though Alexander thinks it is a dashboard for middle management.

The second track is shared whiteboarding. The deal to buy Miro was all but closed when the vendor said it could not guarantee the service would keep working in Russia; a Chinese alternative answered much the same, and the local market had little to offer. In two years the team built its own board, released it publicly and, by their own research, covered most of the scenarios Miro had been used for; at the time of recording, Pavel expects new sanctions restrictions from 15 September.

They refuse on principle to clone someone else's product: the question is not how to build an equivalent, but why a person uses it and what problem they solve — the same logic applies to personal notes in Notion and Obsidian.

Confluence and Jira will have to be replaced too, but whoever kills the dragon becomes the dragon: a clone carries over limitations without necessarily gaining the advantages accumulated over years, such as a marketplace. Yandex, the participants recall, first tried to copy someone else's tracker and then built its own for its own tasks: it fits those with similar tasks and not the rest.

Changing a tool means changing perception: like driving, when you stop noticing the car and start seeing the other traffic. In closing Pavel advises worrying less about how you are organised and more about what for: asked for a story-points chart, he asks which problem it solves.