The Road to CTO: Catch the Window of Opportunity

Sergey opens by joking that today they will decompile his code, and noting that in a week he turns forty-one. He was born in Omsk and stayed there for a while: at home there was a Spectrum, where a game was found on the tape by the recorder's counter, or by ear without one; then a Pentium upgraded every holiday with a memory stick and jumpers moved for overclocking. Maths and olympiads came easily, physics less so, and since building processors did not appeal, he chose programming. There were no unified state exams yet and his parents could not afford to send him to Moscow on the off chance, so it was the Omsk polytechnic and a degree in computing machines, complexes, systems and networks. Alexander recalls his lyceum in Severodvinsk and a teacher who coached international olympiad medallists: physics turned out to be less about formulas than about picking a model and discarding the rest — a trick he later used on an engineer who insisted physics was useless.

Getting into Omsk companies ran on caste logic: which university are you from — and then, nice to meet you, goodbye. The Central Bank took him on, with the whole development team in Omsk while customers flew in from Moscow departments with a finished specification; the era was pre-agile and full-stack. The system served cash circulation: settlement centres and counting-and-sorting machines the size of a combine harvester without wheels, fed with money by the sackful. One project was a vault in the Krasnodar region: a huge barn-like building with railway tracks running in so the money train drives inside, rows of racks, and later Italian and German robots whose C interfaces he wrapped from Java through JNI. He spent nine years at the bank and admits that in hindsight he should have left earlier; meanwhile he reached the final stage with an Oracle internet-of-things team in St Petersburg and passed rounds at Deutsche Bank before a hiring freeze.

The next stop was Sbertech, where a team was being assembled for Sberbank Online: until then the app had been written by an outside contractor he pointedly refuses to name on air. Sergey illustrates vendor relations with a dead-souls trick: the customer was told sixty people in Moscow were on the account, all herded into one room for the visit, while perhaps thirty actually worked. Releases shipped once a quarter, sometimes twice a year, and one, he thinks, dragged on for nine months — long enough, as he puts it, to release a child instead. For half a year the team tried to absorb expertise the vendor was in no hurry to hand over, and before the New Year the bank's leadership decided to part ways. The distribution arrived on a flash drive: they deployed it, fixed around a thousand bugs and, by his recollection, shipped the first in-house release in April 2016, which even earned a bonus. Then the same man turned up with a second flash drive holding a newer version, and the merge brought another eight hundred bugs.

His roles changed with the product: developer, then team lead of the first team about six months in, then three or four teams, then the development-side owner of assembling the release — chasing developers and arguing with testers and analysts; someone, he reckons, had spotted a talent for quarrelling in him. The team grew from ten people to roughly three hundred; they headhunted from the Omsk office of a large outsourcing firm where engineers had spent years on projects for Boeing, with ten-page CVs in English. Hence the thread running through the episode: growth depends not only on how good you are but on the window of opportunity — a fast-growing operation opens roles, while a company that only needs to survive opens none. Both add a caveat straight away: chasing speed produces a colossus with feet of clay who can explain neither the architecture of his product nor his own management.

After being moved into Sberbank itself Sergey felt his expertise draining away and spent three months as an architect of Sberbank Online: meetings from nine to six or seven and a stream of people opening every conversation with an instruction from the very top — you sit, he says, like a genie everyone keeps rubbing. Next came a blockchain startup, joined after his move to Innopolis with Sbertech: seven people, sixteen-hour days for the first two months, culture shock after Sberbank's rails (where is the man who signs it off, where is the button?), the startup's boss, who changed the model after each epiphany, and a year of rework. Hence the habit of designing so you can part with a solution at any moment and covering it with tests; he saw in the New Year with a glass in one hand and a deploy with the other, because production lived in Asia. Then Raiffeisen, owning the platform under the internet bank and mobile app for retail customers — a school of making porridge from an axe.

Technical debt there had piled up until the cupboards held not skeletons but a tyrannosaurus skeleton, while the unit owner fully controls his own opex and capex — a model Sergey considers right — except that a lean team would arrive and cut fifteen per cent. He left when the platforms were broken up across product domains and the priority switched to shipping fast and sorting out the mess later: after two years of clearing that debt he had no wish to fill in a hole he had dug. At Tinkoff he was interviewed by Alexander, who tried a new system-design question about an A/B testing platform on him; there Sergey worked between two bosses, Alexander and Andrey Timonich, and built end-to-end origination in place of the bank's historical layers, and the stream-team groundwork, Alexander says, stayed useful after he left. Today at Gazprombank the day is meetings, annual KPIs, one-to-ones with stream leads and walks into teams so as not to live in a tower. On balance he is brief: switch off around seven or eight, keep tasks out of the weekend, and treat emergencies as the price of responsibility. His closing advice: there is no silver bullet, so start by asking what you actually want.