Technology Strategy: Build It Like a Product

The episode is a dialogue between two programme committee members of a 2025 conference for technical directors: strategy is on the programme, and the host wants to show why it matters. Kiverin introduces himself: six months at Sber, responsible for IT development in the large retail B2C block enriched by the ecosystem companies, where he shapes the technology strategy and its implementation across the units. Before that came Gazprom Neft's digital development directorate, where he owned how the hubs raise engineering maturity: which tools and processes they use and what calibre of people they need. Earlier still, six years at Ak Bars Bank as technical director of its IT company, building in-house development, a product approach, and the IT-business link through streams aimed at business results. The two met years ago at a conference neither of them could name for certain, discussing the role of the CTO and the shape of teams.

The host's first question is practical: you join a new company, you were invited to run sizeable changes, and you could sink into operations and pick up the dropped flag — hardly the best option. Kiverin separates the calibres: a company-wide CTO holds the image of the result that takes the company to its business outcome, while a direction's head already has several inputs on arrival — the company's technology strategy and what his unit must deliver. Then comes context: a technology manager is the business's counterpart, a mature company has a business strategy, and if it does not, it is the CTO who should raise with the CEO and CPO where the company is heading, what the image of the result is, and which activities are business critical. The guest recommends a book by people from Amazon about working back from the image of the result: it helps to think outside the current status quo.

The guest lists the stakeholders straight away: the CEO, CPO, and CIO or a head technology block above you, and the units and teams reporting to you. He likes to compare a technology strategy with a product: first the Vision, absorbing a look at competitors, a financial model and — the part even CPOs forget — your team's real capabilities. The input parameters come from the business strategy: speed, quality, or a balance of the two; new digital solutions or optimisation of the landscape; and sometimes business capabilities are defined with the business and checked against what technology covers. Next comes what hurts — above, sideways, and inside your own unit — and not only in technologies and processes but in people and org design. Goals grow from that: from KPIs to OKRs, where business objectives become technology objectives and key results become initiatives. A strategy, Kiverin stresses, is not only goals but the initiatives that get you there.

The host adds a note on top-down and bottom-up goal setting: when teams assemble the key results themselves you get their commitment, while dictated deadlines breed rejection. He recalls how the hype cycle kept shifting: first DevOps, then the run to the cloud, away from own data centres, then platforms, and now artificial intelligence everywhere. Hence the guest's advice to keep a piece of R&D inside the technology unit — for know-how the business can use and for judging how applicable a new technology is. The host turns to the reports from large analyst agencies: everyone is immersed in the information flow, but nobody has time for a deep dive, so trend watching is worth handing to someone and feeding that team findings from industry conferences. The guest had such teams everywhere: a small one in Sber's B2C, one next to the architects at Gazprom Neft with dedicated research capacity, and one at Ak Bars covering technologies and new business solutions; analyst material such as Gartner is what they accumulate.

The host describes T-Bank: a centre that publishes papers at top conferences and released a long text a day or two earlier on how its models were trained, plus fresh news about an engineering research centre created about a year ago, where assistants are wired into tests, code review, and migration of codebases between languages. The benefit works like a technology branch in Civilization: it suddenly upgrades and opens possibilities you never had focus for in day-to-day work. The conversation then moves to metrics: if stakeholders care about effectiveness and speed, focus shifts to production processes; if delivery of value sags, to delivery and project management; if satisfaction drops and hiring stalls, to managing people. The host cuts in with an example: a colleague was preparing a talk on adopting SPACE, whose first item is satisfaction and wellbeing, and it became visible that the least happy are the reliability engineers, who meet incidents most often, followed by those who triage bugs and production requests, while developers are on average content: they see code and ship features.

He suggests starting with measurement: if reliability was never your focus, build a way to measure it and set a target; if total cost of ownership and duplication hurt, assemble a shared platform from an MVP of the services you cannot do without. By his reckoning, that is how internal developer platforms started in many companies. The guest packages this into a mechanism: an effectiveness team watches the metrics and finds sagging areas, teams and initiatives form around them, planning runs in annual cycles while iterations are quarterly, with a retrospective and stakeholder feedback. The host adds that there is much project management here: gates show where an initiative finished sooner than expected and where it slips or the hypothesis failed. Out of the accumulated changes, Kiverin notes, engineering culture takes shape: practices, team org design such as Team Topologies or a Spotify-style structure, competencies, role models, and communities. The host also asks how to balance features against practices whose effect is delayed. Kiverin answers with scale — process losses multiply by the number of teams, so a smaller company is fine with a solid CI/CD pipeline — and with objective indicators: fitness functions on maintainability and scalability say whether to develop the architecture further, not a wish to build it Google-style from day one.