Technology Strategy Patterns — Episode 1

Nikolay introduces himself as a man who spends his life piling data into a huge heap and sitting on top of it: hired as an architect, he grows into management. He used to lead a data platform, now runs data engineering and analytics at ManyChat, teaches at a university in Barcelona, and belongs to another, developer-facing club that read a book on data-intensive applications and interviewed its author. Alexander describes the book: the author collected the tools of consultants who paint a happy future well, loves philosophy and talks about complex things in a complicated way, and borrowed the structure from the Gang of Four, only these patterns serve analysis and strategy creation. Nikolay notes that in the Agile era companies spend years closing tactical tasks at speed, like busy shrews, with no victory in sight, whereas a strategy is a big goal chosen in advance that keeps you focused. Alexander has played chess since childhood and hears a red flag in the interview phrase let us start and then iterate quickly; the opposite failure is a three-year strategy filed away in a drawer.

Nikolay, who woke up on 24 February in a university flat in Barcelona with a VTB card in his pocket, agrees planning does not always save you, yet even a mediocre strategy gives its owner an edge. The slides carry the five steps of chapter one: context, market and competitors, the technology landscape, your own options, evaluating them, and recommendations that consultants are paid handsomely for. Nikolay adds a step zero often skipped, including at Avito by his own account: work out whom you are telling the strategy to. The example given: walking up to a finance-trained CEO with the open-source technology Hadoop shows excellent results in the latest analyst tests is a sure way to hear very interesting, we will get back to you. The next move is to anchor to a problem you both agree on, so the listener sees you will fight on the same side. Alexander admits he used to talk about the technology and hit the target by luck; after one unsuccessful job move he began asking at the interview what hurts his prospective manager.

Asked by Nikolay how to gather input when decisions are taken above you, Alexander answers with culture: one person wants change while the team does not, and then you need a Hercules who turns out to be Sisyphus; from inside you can see whether the declared strategy matches actual behaviour, and he recommends The Corporate Tribe, on the anthropological view of culture. The author puts heavy emphasis on the problem: understand it, study it, find the optimal solution. Engineers have it easy when everyone acknowledges the problem — split the monolith, get ten times faster — but more often it looks like everyone is working hard and there is no problem, and isolating it is the hardest part. Chapter two offers a logic tree, the five whys and the Ishikawa diagram, but the participants prefer another of the author's points: patch the status quo and you become slightly more efficient, while someone who thinks in opportunities leaves you out of the game.

The book describes a company that spent years buying others and folding them into its ecosystem while missing the cloud story; by an estimate voiced in the conversation, some forty billion over ten years went into rewriting. Nikolay names the engineers' habit of looking for problems under the streetlight: things are bad, so you need microservices, Go and Hadoop. Alexander counters with opportunity cost: in-house speech recognition for call centres is tempting to sell outside, but boxing it up and deploying it elsewhere pulls away effort that banking and insurance products would repay far better. Nikolay separates two cases: turning up with the problem, alternatives and criteria rather than I am a genius and I have an insight, and the harder argument against a refusal to admit the problem — we need Hadoop, while sales are what is broken. A good architect, like a doctor, asks the patient shouting where it hurts whether they also sneeze. The second of the five steps is language: Nikolay's papers on warehouses are discussed by linguists from Australia, while ManyChat had contact, person, user and subscriber side by side until everyone eventually settled on contact.

The author asks for options to be presented as MECE lists, mutually exclusive and collectively exhaustive. The conversation puts it mathematically: a full partition of a set into non-overlapping segments, like the four card suits or the four seasons; items must be of the same order, and when south-west turns up among the cardinal directions instead of west, anyone used to MECE asks what happened. Alexander tests it on his own case: build in-house, outsource or buy, is that MECE? Nikolay replies that sometimes you need no system at all, because people do the job by hand, so he would make two MECE lists: first do or do not do, then a branching one. The list is a test of professional competence: a missing option has two explanations, a poorly structured mind or manipulation, and both are red flags. That is how one participant reads any architecture or strategy, building the lists in his head even when the text has none and hunting for what was left out; you get one chance to sell a strategy.

Then the prioritisation matrix: size of result on the horizontal axis, ease on the vertical. There are always more good ideas than capacity, so the low-hanging fruit goes first, while the author ranks easy but small second and big impact but you die on the way third. Nikolay objects that this is how technical debt accumulates: a company never gets to splitting the monolith, rebuilding the architecture or moving to functional teams until it hits a wall — ironic in a book on technology strategy. The way out is cutting the big thing into parts with a cumulative effect, though borrowing is easy when someone else repays. Nikolay is sceptical about the diagram where a decision is assembled from data points: an insight and a justified hypothesis are two very different things. Very often there is enough data for an insight, since the brain sees a cloud in a heap of sand, but often not enough for significant growth or an A/B result. Ice-cream sales correlate with fires and paperclips with pirate attacks, yet there is no rigorous apparatus for causality: you test it by removing a factor, which astronomers cannot do.