Technology Strategy Patterns — Episode 5

Vova opens the last episode on the book: the line-up is only partly the usual one, and the guest is Igor Kurochkin, who introduces himself as exactly the consultant the book is about. Behind him: operations at a Russian hosting startup, a video streaming and calls company where he owned availability and infrastructure, acquisition by Skype and then Microsoft, work as a platform engineer, then technology consulting at Express 42. The first template is the one-slider: the author advises preparing the first slide last, once all the workings are done, and putting only the meat on it, so a stakeholder knows at once whether to keep listening. One of the hosts compares this with clients who want a commercial proposal before the detail. The slide runs from a vision with a one-to-three-year horizon to a handful of strategic goals, then to measurable practices and initiatives, all resting on culture.

One of the hosts recalls assembling such a slide for a mobile bank platform: mission and vision, strategic goals by area and the plans underneath. Culture was not called out separately, but a long comment on engineering culture sat in the document and never moved — the participants recall that culture eats strategy for breakfast. Talks with top managers ran as backcasting, from the target future back to the structure — the participant knows no faster way to get their attention. The author reminds us that a template is always a pair: a deck and spreadsheets where the data is pulled together and calculated, while an initiative breaks into actions, result artefacts and an owner — bringing back the RACI matrix. The priority map is a table where each case gets a customer outcome and a costed business benefit, the data and major system components affected, and metrics in SMART form with a deadline.

Igor leads the costing template. The author starts from the problem: he was once asked to estimate migrating a thirty-year-old legacy system overnight, and he calls that a dysfunctional relationship. The first step is to accept that estimating is itself a project: days, a week, sometimes a month of thinking, negotiation and research, and it should be paid for; nobody hurries an architect in construction, and a bad quote ruins both building and business. The second is a template with a model and formulas carrying your past experience: how many meetings, how much audit, how many teams an initiative needs. The third is a funnel of three estimates: a rough one in a few days at about fifty per cent accuracy, a refined one in a couple of weeks within twenty-five, a realistic one costing weeks. The fourth is a range instead of an exact figure: a year to two becomes fourteen to sixteen months after an audit. The fifth is writing down assumptions; for one host they filled half the estimate.

Igor also leads the tech radar: the tool came from a consulting firm where Martin Fowler works. It describes the technology lifecycle and shows the stack: what is adopted and in active use, what is being assessed, what is not recommended. It synchronises practices across teams, squeezes out legacy, checks how an initiative maps onto the current stack, shows the stack to candidates and finds internal expertise. Igor has seen radars that were a plain Excel table and ones that were heavy recurring processes; one of the hosts describes radars by profession, a radar at unit level and a public radar for web and mobile, and compares the topics in a recent external issue to a tossed salad. Igor first met due diligence over ten years ago, when Skype was buying his company and sent an engineer who interviewed every lead and reported to management on the technical and operational state. In consulting his team had its own checklist for development, testing and operations, while the author offers a scale from absent and roadmap-only to world class.

Build, buy or partner is worked through by subdomains: if it is your core and your competitive advantage, there is one option — build it yourself, which means a team first to build it, then to support and evolve it. If there is no advantage and a ready product exists, buying is fastest, although integration costs money and time, and you cannot influence the vendor's updates. Alexander adds that purchases differ: a licence can be bought by a competitor too, whereas you can take a whole company — which, by his account, is how a manufacturer was bought for roughly a third of a billion dollars at the very start, to set up in-house Arm processor development and inherit a ready team; the third generation shipped only recently. Partnering is the compromise: you count costs and risks, down to the partner going bankrupt. The chapter's final template, architecture definition, starts with metadata and the language of internet standards — must, should, may — then covers business, application, data and infrastructure architecture.

Non-functional requirements, the author argues, belong inside the features rather than in a separate make-the-system-reliable ticket, and the architecture should be defended like a dissertation: circulate the document in advance, accept that over half, perhaps eighty per cent, will not read it, tell it as a hero's journey, and line up respected people's support beforehand. Then come the decks. A ghost deck is an empty structure of slides with pithy titles, leaving only theses and charts to add; one of the hosts instead sketches the titles with arrows on a tablet to check whether the path holds together, while Igor notes a ready structure is easy to hand to a team of consultants. An ask deck runs from data to the way out, to answers on timing, cost and staffing, to the ask itself and an appendix of sources, the one-slider placed first but written last. The strategy deck is simply everything together, the roadmap a simplified Gantt chart, the mashup meeting a mix of a retrospective and the first stages of event storming. The book took five episodes; Igor calls it one about very large companies and points anyone below a thousand people to Will Larson.