What is the C that you are trying to P?

Three little letters strike terror into the hearts of architects everywhere: P. O. C.

This seems strange. Surely in the age of digital transformation, innovation, and a willingness to fail fast, conducting proofs of concept is exactly what we should be doing. Why should architects be scared of POCs?

The reason is that, unfortunately, in large enterprises, many POCs are not POCs at all. Whether deliberately or accidentally, they stand little chance of proving a concept: in fact, it’s not even clear which C they are trying to P.

Let’s look at two types of POCs which standing little chance of P’ing a C: POCs in name only (let’s call them POCINOs) and POCs without concepts(let’s call them POCWOCs).

POCINOs

One of the jobs that architects don’t get thanked for often enough is maintaining the standards base of the organisation, and being the gatekeepers for the introduction of new technology. This may sound like a mechanical, procedural, governance task, but requires a surprising level of emotional intelligence, influencing and stakeholder managment. The reason for this is that people like technology, and they often like the technology best that they were introduced to most recently: it seems newer and brighter than the technology which is already in the organisation.

The job of the architect is often to patiently and rationally disappoint people who have fallen in love with a new product, explaining to them why their organisation already has five solutions which do the same job, and why the features presented by the vendor aren’t quite as compelling as they seem to be. This is, of course, usually unwelcome and, if the rational and emotional influence of the architect fails to win the day, they have to resort to the big stick of governance, and refuse to ‘approve’ the introduction of the new technology.

This is where the POCINO comes in: everyone agrees that it is reasonable to stick to the standards of the organisation, but who could object to trying out a new technology which promises to deliver value? We don’t have to commit to the thing across the enterprise: let’s just do a POC!

Again, there is nothing wrong with a POC which has a clear C which it is going to P. But that’s not what a POCINO is: a POCINO is an attempt to disarm architects, governance structures (and, occasionally, rationality) through an apparently reasonable and low impact approach, but with the intent of getting the product into the organisation.

Architects are very familiar with this, and know that ‘POC’ is often code for ‘I know you don’t want me to do this, but I’m going to do it anway’ (just as ‘pilot’ is often code for ‘I know you didn’t want me to do this, but I’ve already signed the contract’). Architects can recognise a POCINO a long way off, and their hearts sink because they know that they have some even more difficult conversations in their future.

POCWOCs

POCINOs come from a place of bad faith, and are best addressed through honesty: this is not always emotionally easy, but is at least conceptually straightforward. POCWOCs are rather more difficult to deal with intellectually, as they come from a place of conceptual confusion.

The conceptual confusion usually arises from a chain of reasoning that goes something like this:

• Here is a tool, product or technique which looks like it has some value.
• We should do something to determine what that value is.
• However, until we know what the value is, we don’t want to make a big commercial, architectural or project commitment.
• Let’s do a POC!

This is not unreasonable: it makes sense to assess something in a contained context before making a big commitment. The only problem is that this chain of reasoning misses a vital step: it doesn’t determine what C we are trying to P. That’s why it’s a POCWOC: a POC without a concept.

POCWOCs are often characterised by lots of initial enthusiasm, followed by lots of activity. Things tend to fall apart, however, when we try to figure out what all this activity is telling us. Are we any wiser about the value of this thing than we were when we started?

The cure for the POCWOC is to be precise about the C. It is to treat a POC like a scientific experiment, in which a hypothesis is clearly and precisely framed at the beginning, and the activity is designed to test that hypothesis.

The easiest way to tell whether you have found a POCWOC is to ask the question: what is the C that you are trying to P? Often you will get justifications which don’t qualify as Cs:

• ‘Let’s get familiar with the technology’ is not a C. ( But ‘This technology requires new skills which will influence the speed of deployment and the cost of operations’ is a testable hypothesis.)
• ‘Let’s see how it works in our environment’ is not a C. (But ‘The costs of integrating this product with our existing architecture are sustainable when compared with the benefits’ is a testable hypothesis.)
• ‘Let’s see whether it works’ is not a C. (But ‘This technology successfully performs X function’ is a testable hypothesis - although, if the technology is already performing this function successfully for millions of customers, it may not be a hypothesis worth testing.)

Even better Cs are those which are clearly connected to outcomes:

• ’Integrating this product into our customer journey will improve customer satisfaction by X points.’
• ‘Applying this product to our CI/CD pipeline will reduce defect rates by Y% and prevent Z% of outages in production.’
• ‘Using this technique to categorise work will improve the operational efficiency of this process by Q%.’

Sometimes you can convert a POCWOC into a valuable, genuine POC by discovering and articulating one of these outcome based hypotheses.

More Zang Jing Ge, Please

Spotting POCINOs and POCWOCs is not hard: architects see them all the time, and they usually know when they have found one. Dealing with them can be hard, though, as it often means dashing or directing the enthusiasm of people who are genuinely excited about the potential of new technology. And, believe it or not, we really like it when people are excited about the potential of new technology.

The Zang Jing Ge disciplines of technical excellence, leadership power and communication mastery help here. Technical excellence is required to figure out whether a product is worthy of a POC and if not, why not. Leadership skills are required to coach and steer people (often, as is the case with most architecture influencing, without any hierachical authority), and to communicate clearly, patiently and calmly.

But it all starts with the question: what is the C that you are trying to P?