Technology Strategy Patterns — Episode 3

The guest is Pasha, a technical director: he used to run platform infrastructure, monitoring, logging and on-call, and security and mobile development have since been added; he sums the role up as taking on every problem where nobody knows whom to go to. Alexander sets the frame: seven patterns across forty pages, six pages each on average, though any would fill a book of its own. The first two are about interested parties, the next about how the company is built, and the last three about where to invest and what to say goodbye to. Pasha adds a test for a stakeholder: real interest shows in actions and duties, not words - saying that something sounds interesting usually means the opposite. The author compares the exercise to a 360 review: some announce from the stage how the world will be conquered, some inside the team build the thing, and some do neither yet later complain that your implementation is awkward to live with. Another group is cross-cutting: security, legal, resource management and hiring.

The main pattern is the stakeholder matrix, the two-by-two that consultants love: your project's influence on a person against their influence on you. The participants define influence plainly: resources, money, extra teams and the power to keep your service out of production. With the strong ones you need collaboration up to co-authorship of ideas: high influence usually rests on long business experience, so such people are worth listening to, and their approval makes success likelier; the rest only need informing. Alexander recalls that project-management courses give stakeholder work separate attention, because a project succeeds by meeting expectations, an art engineers pick up when they answer for a team's result, not for code. The second pattern, RACI, spreads roles across activities: responsible does the work by hand, accountable answers for the result, consulted is asked for advice, informed is simply kept in the loop - forget to inform them and the project will not be blocked, but the slight will be remembered.

There can be several responsible people but only one accountable: two labourers dig the pit while the foreman answers for it, and two accountables would demand a synchronisation the real world never delivers. One of the participants argues that two people can well take a decision together if both share the context and there is a procedure for it; Alexander agrees about the decision but insists that one person still owns the implementation, and that going beyond the expected scope sends the question back to those who voted. Next comes the company lifecycle: start, growth, maturity, decline, and an ending that is not necessarily bankruptcy. The stage is read off the financial reports: profit growth above 15% means capturing new markets, 8-15% approaching maturity, 5-8% maturity, and below 5% decline. The engineering agenda shifts with it: first the point is grabbing share quickly, then flexibility to change products without breaking everything around them, and maturity brings multi-product strategy, platforms and standardisation. Pasha adds that internal efficiency gives the business most at maturity, four nines do not pay off early on, and later reliability becomes a condition of existence.

The value chain continues the previous episode: the author of the five forces, having covered the industry, rested for five years and wrote his next book about it. Pasha explains the pattern as a conveyor: you see the stages value delivery passes through, so you can measure and optimise them and know what each costs in time and resource; shared things such as the platform lie underneath. Alexander recalls counting such a chain at Tinkoff while leading a then-small online acquisition team. He needed an engineer who was asking for some five per cent above the band, and instead of arguing about the rules he counted the effect: what that link costs and what it brings; the model is known, spend a rouble and get roughly three, with acquisition cost kept near a third of the discounted revenue. The decision tree showed that months of further searching would cost more; the engineer stayed two years, the MVP flew, and it grew into an internal advertising console. A supporting activity, the participants add, can be pumped up until it becomes a product of its own - as AWS was for Amazon.

The growth-share matrix is valued for its shared vocabulary: say cash cow and a product's position is clear without explanation. Pasha describes mapping their pizza-chain market across Russia, Belarus and Kazakhstan: being the largest chain in the region might look like a cash cow, yet the market keeps growing and changed a great deal this year, so the picture has to be revisited. The participants add that architectural projects can be treated as a portfolio too - is this one worth more money. The next pattern sorts products by dependence on the core and by novelty to decide what to fund; one of the participants recalls its name with visible uncertainty. The investment map is another two-by-two, of market readiness against implementation difficulty: ready and easy means invest, wanted but hard means build an MVP, easy but not wanted means monitor. The author's example is a startup with electronic hotel locks opened from a smartphone: not everyone has one, and phones keep running out of charge.

The department context comes down to two big patterns. The first is principles, practices and tools: start from principles, pick practices to support them and only then tools, otherwise the answer will be Kafka simply because someone knows how to configure it well. The author suggests labelling processes by maturity and drawing a picture of where you are against where you want to be. One of the participants admits he has never done the exercise in such an elaborate form, but on becoming technical director of a new area he kept a similar table with current and target state, the goal and a status. Another anecdote: one participant's teams write all their backend processes in BPMN - more than a hundred diagrams, with a higher-level abstraction on top, or you cannot see the wood for the trees. The last pattern is application portfolio management: applications are ranked by business value, running cost and technical risk, with circle size for the number of users, which shows what to retire, stabilise or grow. This, Alexander notes, is exactly how splitting a monolith gets argued - except the case has to be made in business terms, not technical slang. Next time the club starts the part about communicating strategy.