Technology strategy

Deciding what to build, what to buy and what to leave alone, before the budget is committed.

The build versus buy question is rarely answered honestly, because the firm answering it usually sells one of the two. We take a position on each candidate and say plainly when a vendor already does the job well enough, even where that removes work from our own scope.

Strategy that cannot be executed is a deck. Every recommendation we make is constrained by what we would have to build if you accepted it, which is a useful discipline for the firm writing it.

The common failure is not choosing wrong. It is choosing without a position. A long list of candidates is scored on effort and impact, almost everything survives the exercise, and the estate ends up with several vendors doing overlapping work while a platform team maintains the seams between them. Buying is treated as the safe option because somebody else operates it, and the consequences that actually bite never enter the comparison: the data you now have to move, the process you have to bend to fit a vendor's model, the exit you no longer have. Building is treated as the ambitious option, and the obligation to run the thing afterwards is left to a team that was not in the room when the decision was made.

We start from where your differentiation actually lives. Almost none of it is in the model, which is now a commodity anyone can rent. Some of it is in proprietary data and the right to use it. More of it sits in a process your competitors cannot copy, and in the judgement your people apply inside that process. Anything outside that set is a candidate for buying, judged on what your own team would have to operate afterwards rather than on the feature list in the room. Anything inside it is worth building and worth owning outright, because handing it to a vendor means handing over the part of the business that is hardest to replace.

A recommendation is worth no more than the plan underneath it, so every position we take is written with the architecture, the dependencies and the operating burden attached. We name what has to be true for the recommendation to hold, what would make us change our minds, and which decisions can safely be left open so the organization is not committed to an answer before it has to be. The purpose of a technology strategy is not to be right about this year's market. It is to leave the business able to change its mind without starting again.

The articles

Other topics

Talk to a partner

If this is the problem in front of you, describe it and a founding partner will reply.