Scope of the unit and three pillars
Alexander admits up front that the topic is too big and that he narrowed it to his own area of responsibility; the host asks for depth rather than a quick tour, wanting to see how a large corporation works inside, because the audience wants to know how startups and vendors plug into such systems. The digital systems development unit was created shortly before the webinar — in June, as he mentions at the end — and owns the mobile app, the public web applications from the front page to the product pages, and the data management services: connectors, a CMS and a constructor for assembling content. It also covers marketing automation and an advertising console where keywords and rules make the buying of contextual advertising more efficient, and where demand is compared with competitors; project work such as a New Year campaign; and the infrastructure under all of it. The unit's focus is acquisition: a user first has to become a client and only then start using products through the app.
The word digitalisation sounds too broad on its own, so Alexander pins down his meaning from a book by top managers at a consultancy — named in the material's own description as ThoughtWorks. The first pillar is repurposing the business and its operating architecture around customer value: companies used to maximise the share price while customer value came along as a side activity, and now the order is reversed. The measures of success are several: user value dictates what to build next in the product; financial indicators show how the company feels on the market; individual metrics help an employee improve their own work; and separate measures cover the company itself — product quality, speed and predictability. Long-term planning tied to the management structure hides the point of the work, and top management needs transparency. The second pillar is an adaptive organisation, obstructed by fixed org structures, a tangle of stakeholder interests that turns decisions into compromises, functional boundaries where a task gets stuck between development, testing and operations, and a lack of data-driven feedback.
Technology, products and Bank 4.0
The third pillar is technology as a core competence and as the thing that sets a company apart from its competitors. Alexander insists you cannot say the innards do not matter as long as the picture is pretty: the speed of shipping functionality depends precisely on them, and on underdeveloped technology a single feature takes half a year or a year. Talented engineers go to technology companies and do not want to be an appendage to a business — hence internships and other activity aimed at young specialists. Continuous delivery and a DevOps culture reduce friction between the stages of delivering value and reconcile development with operations, although the movement itself, in his words, is far from new. Digital platforms become a meeting place for an audience and service providers who sell goods inside someone else's application. The project paradigm gives way to the product one: instead of delivery on time and on budget there is a long life cycle, a standing team and a check against data that a new feature added value.
Alexander shows the evolution of banking on a picture he drew himself from the book Bank 4.0: traditional banks he skips as uninteresting, Banking 2.0 is service through ATMs, Banking 3.0 is a mobile bank in a smartphone, and Bank 4.0 is an omnipresent bank that suggests in real time how to handle money more effectively and reaches into non-financial scenarios. The company's timeline sits on the same scale: an online bank founded in 2007, mobile banking somewhere between 2007 and 2011, then insurance, a bank for legal entities, investments and a mobile operator; over the last couple of years a shift towards AI banking with non-financial services and the voice assistant Oleg, and in 2020 the lockdown let them lift restrictions so a person could become a client without waiting for a courier. Some five years ago everyone fitted into one small office at Vodny Stadion, a few hundred people; growth forced a restructuring of teams that kept them flexible, and the company, in his words, is regarded as an IT company with a banking licence.
Tech radar, AI and audience questions
The technology radar — again an approach from the same consultants — is drawn per unit and then reconciled across units: a single radar for the whole organisation comes out too abstract. Four quadrants — languages and frameworks, tools, platforms and techniques, meaning approaches to design, delivery and the organisation of work — sit alongside four rings of maturity and markers for whether a technology is being adopted or retired. The specifics he names are containers, Node.js for the front end and part of the back-end services, private and public clouds for different kinds of load, and databases as a service. The main challenge of Bank 4.0, by his reckoning, is not technological: clever features earn nothing on their own without a scenario — remind a client that no PIN has been set for a new card, recommend a film release with a discount, surface dangling subscriptions. Behind the elegant stories about models lies a great deal of drudgery: data has to be prepared and kept current, a pipeline for shipping models is needed, and the first version usually fails to take off.
In the answers Alexander separates the models of working with contractors: a small number of their people are embedded in teams as full members, and that works, while buying whole projects usually flies badly. The reason, he reckons, is not only the contractor — the customer has to think through in advance what they want and how the product will develop. Worse, expertise handed outside leaves together with the solution: the bank's mobile findings from around 2016 soon appeared at every other bank, because one company baked the same thing for everyone, repainted for each new customer. His unit has 250 people on staff plus, he reckons, fifty to a hundred contractors, teams are spread over more than ten cities from Novosibirsk to Sochi, and a newcomer joins a feature team with a written first day, first week and first month. There is no single methodology across the company: they moved from Scrum towards Kanban because many products are in an experimental phase.
What to take away
- 01Three pillars of digitalisation from the consultants' book: turning the business and its operating architecture towards customer value, an adaptive organisation without functional fences, and technology as a core competence.
- 02Technological excellence is not cosmetic: on underdeveloped technology a single feature stretches to half a year or a year, and strong engineers avoid places where IT is an appendage to the business.
- 03Handing a whole product to a contractor is doubly risky: developing it afterwards is hard, and the expertise leaves the building and gets replicated for competitors from one template.
- 04A technology radar is more useful per unit: the company-wide one comes out too abstract, while radars of separate units can be reconciled against each other.
Sources
- Presentation slides
- Talk recording