Skip to content
back to the episode
Episode summary2025CTO

T-Investments: Three Years Defending the Broker Idea

The guest of the 41st episode is Pavel Permyakov, CTO of T Invest, thirteen years with the company and, as Alexander admits, not a very public person. The conversation follows his whole path: the school computer class, a decade in contracting, the integration bus at T-Bank, the first microservices and the launch of the broker.

Code of Leadership · episode #419 min read

This summary is shorter than the full episode; examples and assessments reflect the participants’ experience and views.

The main thread of the material
01

From a school computer class to credit pipelines

The scale of the business comes first: by retail client count it is the largest broker on the market, with around 30 million open accounts — though the number depends on methodology, since one client usually holds several accounts. The talk then goes back to childhood: Moscow, the Solntsevo district, a small school in the city's south-west, a computer class and the turtle that walked across the screen on basic commands. His reference points were neighbours and an older brother who worked as general IT hands; the first computer arrived at about nine, and the turtle grew into Pascal. Alexander recalls his own bachelor's thesis — a cellular model of a biogeocenosis written in Delphi, two releases behind the current one, because his supervisor disliked the new constructs.

The university was picked by geography: the nearest was the Moscow Institute of Radio Engineering, Electronics and Automation, the department of computing machines, complexes, systems and networks. The emphasis was on hardware and networks, and part of the material had aged — in the third year or so they were taught about 5 MB hard drives that had to survive a two-metre fall. In his first three years Pavel only worked as a lab assistant at the department and did coursework for fellow students in Delphi for free. His first job came from there too — the head of the lab invited him as an intern at a contractor: effectively a five-day week for bread, free hands for the client, and a year on IBM integration products where everything came down to mapping fields with type conversion. He stayed at Neoflex for ten years: four more client banks after the internship, by his count, credit pipelines, time-and-materials work and, towards the end, full projects from analysis to production — and a path from intern to architect.

02

The integration bus and the first microservices

Pavel was headhunted by colleagues from the future T-Bank, then sitting near Tushinskaya; the offer came, but a counteroffer held him — and that lasted half a year. In parallel he built a startup with a friend that never reached launch, and then went to the people he had turned down: we remember how you ditched us. Both agree that a counteroffer treats the symptom: in contracting you tire of constantly changing client and project, of other people's processes, and of being asked at 17:45 on a Friday to leave the client's office. His first working day in 2012 coincided with the company's move to its new head office near Vodny Stadion, where the whole team still fitted on one floor. Pavel came in as an architect to build an integration bus: business processes for credit cards and deposits lived in the core banking systems, which were wired to each other directly over dated protocols, and that did not scale.

The ambitions were large — connect every system to every other, give them common monitoring and alerting — but the paradigm shifted: microservices were gaining ground, the bus pattern was on its way out, and the team decided to wind it down. The protocol stayed the same; the implementation changed. Asynchrony was assembled from whatever existed: queues inside the database, queue channels in the bus, then IBM MQ; Alexander recalls that before Kafka the same role in his world went to RabbitMQ. The department was among the first to experiment with Rancher, and the company's first microservices were probably theirs: Pavel bootstrapped the notification centre's front end himself in Ruby on Rails, wrote the first services and the SMS and email template management in Spring, and later a proper team rewrote it all. Alexander has his own score with Rancher: he had pulled the news part out of a monolith, and days later the orchestrator itself went down, so the services had to be reassembled into one unit and redeployed onto the old machines.

03

Launching investments and the CTO's day

Investments took a long time to launch because nobody believed in them: one business leader, by Pavel's account, spent about three years arguing at open-door days that elsewhere in the world this makes money. The question was whether there was an audience in a country of low financial literacy where the market was already split between large players. The hypothesis was tested by a team of up to ten people in partnership with BCS: a convenient interface on top of somebody else's backend, and account top-ups taking, as he recalls, up to two days — part of the trouble came from the partner's side. When they decided to go all in, the licence came only on the second attempt: the technology side was ready, the paperwork was not. Most core systems were taken from contractors to launch fast, and the bill arrived later — logic held in databases would not take the load, data drifted out of sync, the service could be down for an hour because of a partner, and parts of the system were rewritten in flight; Pavel remembers the meme of the dog in the burning room, which gave an internal incident tool its name.

Growth was close to exponential: about 50 people in the first year, then 200, 400 and 800, and with it came systems drifting apart and teams decomposing. Competitors first asked what they were up to, then started copying: promo mechanics were repeated within a month, and the national investment championship, if Pavel remembers correctly, was launched a year later by Sber. He became CTO almost painlessly — he was effectively the deputy already, and his manager left for an international project; the difficulties came afterwards, with the growth. A CTO's day is mostly meetings: he kept one-on-ones only with his six deputies once he had fixed his span of control. He declines meetings without an agenda: an hour of getting context and a situational decision late in the day is doomed. He breaks any role down into planning, implementation and checking the result. His closing advice is not to chase the CTO title, to grow where the work gives you pleasure, and to test a decision for the effect of scale: a coffee shop scales badly, a franchise scales well. And to read books rather than only scroll channels: for him, good science fiction and a book on Amazon's strategy whose exact title the two agree to look up later.

Takeaways

What to take away

  1. 01The investment business was not a flash of insight but three years of one business leader defending the idea; the hypothesis was tested by a team of up to ten people on a partner's backend before full resources arrived.
  2. 02Speed at the start is paid for later: contractors' core systems with logic in the databases allowed a fast launch but hit scaling limits once the audience grew.
  3. 03Span of control and meeting culture are working tools: six deputies instead of a crowd of direct reports, declining agenda-less meetings and async decisions; grading a document with a model is Alexander's idea.
  4. 04Not everyone has to climb: the staff track is just as valid, and any decision is worth testing for the effect of scale — the coffee shop versus the franchise.

Sources