From assembling servers to a risk department
Artem starts with his education: his university specialisation was in infocommunication technology and communication systems, one of its tracks covered transistor logic and processor design, and he had assembled computers himself since school. His first job he still calls server hardware engineer: a large integrator of data centres and server racks, an order along the lines of replace a motherboard, and a one-day SLA. You come to work at ten, by twelve you are flying to another city, you find the rack in some shop and rebuild the server. As an undergraduate he realised he did not want to continue that way: from the end of his second year he taught himself Java, moved to a consulting company as a developer, and with that experience joined his current company. On entry he was graded lower than he thought fair, and he disagreed with it, but he liked the company and reached middle within a couple of months, half a year at most.
At the company he joined the scoring team, which is still in his department today, and lived through the splitting of a huge origination monolith. Asked by Alexander why a monolith should be split at all, Artem answers with symptoms rather than dogma: nobody understands how the system works; any small fix is impossible or takes weeks; so many people own the monolith that nobody does, and every breakage is met with a shrug that it is not mine. Hence the carving into domains and responsibility assigned to specific teams. In the near-final iteration, product teams take feature requests from business lines such as credit cards, cash loans and mortgages, while the core team absorbs change so that growing logic, request volumes and infrastructure complexity do not eat delivery speed, and run stays with the product teams. Hiring helped him grow: Artem wrote the interview competency matrix, always looked one level above his own, and has run around two hundred Java and Kotlin interviews. Alexander recalls his own roughly two hundred technical interviews and how at the two hundred and tenth he grew tired and switched to another track.
The risk department and its decision pipeline
Around 2021 Artem was promoted to senior, though he never measured himself by grades: people already reported to him, and he took on tech lead and engineering manager duties such as reliability and goal setting, simply because he enjoyed them. Then the company needed the risk pieces gathered together, scoring for individuals and for companies, verification and antifraud, so that a single stakeholder, credit risk, would find every system implementing its logic in one department. March to September 2022 was a kind of probation which, by Artem's account, flew past in one breath; in September he was told he was becoming head of that department. By the end of 2022 it held 48 engineers; today it is 110 plus around twenty matrixed people, roughly 130. Alexander notes that in many large organisations 110 engineers would be the whole of IT, whereas here it is one domain that must be decomposed well.
The teams mirror the decision funnel: scoring for individuals, scoring for companies and scoring for insurance, antifraud and verification, which grew as one team and split in two, an interface team building micro frontends for verifiers and the investigations unit, and a platform team. The span of control rule is simple: about ten people in a team is when splitting is considered and a team lead vacancy opened. The pipeline itself Artem calls an area even more closed than information security: a customer submits an application, a contact and an application are created, then scoring runs a strategy prepared in advance out of models and factors, expert rules that can be rejecting, negative and occasionally positive. Data is pulled from a huge number of sources: online ones such as the credit bureau, because the person may be shopping for loans across channels right now, and offline ones too heavy to compute online and therefore precomputed. Around seventy per cent of decisions go through automatically in seconds, ten at most; the outcome is either a refusal, including one driven by insufficient margin, or the final offer the customer sees as an approval, or a manual check.
Platform, calendar and the profession
Once the domains were gathered into one department, the participants saw repeating pieces: deploying models and preparing features, what a model consumes as input. Every team had been thinking that through from scratch, and a new team needs about two years to close that gap, which is why a platform team appeared. Alexander pushes back: the company has a large centre with an ML platform, yet Artem's teams were preparing and serving models before it existed, and Artem agrees that they built a similar lifecycle because all risk rests on models. Every six months he audits his calendar, opening the past couple of weeks to see where the time went. Hiring is the baseline item; team leads take the most, since they are his team; then come product managers, stakeholders on the risk side, architecture reviews and the profession: he has run the system design interview for about two years and checks the competence strictly when hiring, because with it a person takes on such a task inside their own domain and sees it through.
Alexander recalls a line from an old management book, by his reckoning possibly the one about herding cats: a manager works like a router, forwarding useful information to where it will be needed so that people do not do similar things in parallel. Towards the end Artem shares his approach to learning: he picks up books not in the abstract but for a task in hand or for an area he will have to move into, otherwise a year or two later he will not remember reading them. He consolidates by teaching others, by talks and notes on almost every book; Alexander adds that he writes with a stylus over PDFs and is not shy about writing in the margins of paper books, fixing clumsy translations and broken formulas. Rhythm is what works: without it tomorrow always looks like the better day. And a manager can hardly take on hands-on work without becoming a bottleneck, so Artem, who has swung heavily towards management over the past eighteen months or two years, is looking at pet projects, just to keep the scissors sharp.
What to take away
- 01Splitting a monolith is justified by symptoms, not fashion: nobody understands the system, a fix takes weeks, everyone owns it so nobody does; the cure is domains with explicit owners.
- 02The core team absorbs change while product teams keep run, so growing logic, load and infrastructure do not eat the speed of feature requests.
- 03The risk pipeline rests on strategies prepared in advance, online and offline data and model monitoring: around 70 per cent of decisions are made automatically in seconds.
- 04A book sticks only when it is tied to a task in hand or to an area you will have to enter; notes, talks and teaching others are what fix it in memory.