Subscribe on LinkedIn
5 Ps: ingredients for technology success
David Knott David Knott

5 Ps: ingredients for technology success

There are lots of ways of organising a digital or technology capability, and I’ve tried many of them. Most of them don’t work, resulting in slow, bureaucratic organisations which fail to  realise the full potential of technology. However, over time, through difficult lessons learnt in many different places, I have come to believe that there are five ingredients of a successful technology organisation. They all begin with the letter P, so let’s call this the 5 Ps model. It can be described something like this:

Platforms are highly homogenous, standardised, software-defined technology capabilities which enable products to be built at speed, with confidence that they will scale and be reliable and secure.

Products are highly specialised functional capabilities which deliver value to end users.

People are people! But the talent and capabilities of the people who do these jobs matter, as does the level of trust and autonomy they are afforded. In this model, people are expected to to be trusted experts with the power to manage, develop and continuously improve their products and platforms.

Practices are common ways of working which unite people who are otherwise distributed into autonomous platform and product teams. They are at least as much cultural as they are formal, and are driven by the pride and experience of expert professionals.

Performance comprises a set of meaningful metrics which describe the success of platform and product teams, and which are owned and driven by those platform and product teams.

Read More
Do you know whether you are building a platform or a product?
David Knott David Knott

Do you know whether you are building a platform or a product?

Many years ago, I was working as a solution architect for a large organisation, designing a system for scanning and processing inbound physical mail (I said that it was a long time ago). One of the things I had to figure out was how to host the system. The default approach at that time would have been to size, spec and procure some physical servers, but the company I was working for was just building out its first shared virtual machine infrastructure (once again, this was a long time ago), so the project team and I decided that that was what we should use. After all, why go through the delay and difficulty of getting physical equipment bought and commissioned, when we could consume pre-provisioned capacity from a shared facility?

Of course, things didn’t quite work out that way. The VM farm wasn’t quite as ready as I thought it was. And there was some enabling infrastructure that needed to be put in place. And the first adopter was expected to pay some of these costs. And the scanning and processing software wasn’t quite as ready to run on VMs as the provider thought it was. What was supposed to be a project about handling information, figuring out customer needs and routing work turned out to be a project about getting infrastructure in place and arguing about funding.

Read More
Reflections on one year at Google: platforms, products and practices
David Knott David Knott

Reflections on one year at Google: platforms, products and practices

I celebrated my first Googleversary this week! It’s hard to believe that I have been here a year. I don’t know whether it feels longer or shorter: for me, as for many people, time has passed strangely over the last year.

I’ve learnt many things so far at Google - about culture, about collaboration and about customers. Unsurprisingly, I have also learnt about technology - in particular, to think more deeply about how Google uses technology, and what Cloud means for customers.

A lot has been written about Cloud (including quite a few words by me), but I’ve had a feeling for a while that much of this writing (including my own) does not really capture why Cloud matters so much. Considerations of Cloud often focus on core technology benefits (reduce cost, reduce risk, increase agility) or jump straight to ambitious business goals (innovate, disrupt, create new models), but I think that they often miss a big and important architectural chunk in the middle.

Read More