David Knott 26/08/2021 David Knott 26/08/2021

Are you making a difference? Managers must tell correlation from causation

Does eating chocolate make you smarter? In a study published in The New England Journal of Medicine in 2012, Franz Messerli demonstrated a correlation between the amount of chocolate which a nation eats and the number of Nobel prizes its citizens win. Unsurprisingly, Messerli’s findings were deliberately playful: he was not really attempting to assert that eating chocolate leads to prize winning research - he was illustrating the difference between correlation and causation. Chocolate consumption tends to correlate with national wealth, which also correlates with those factors which create an environment suited to Nobel prize winning research.

We might think that we already understand the difference between correlation (factors which co-exist and which may change together, but which have no causal link) and causation (one factor which drives another through a causal mechanism), and would never fall into the trap of mixing them up. But I think that if you are a manager you are at risk of mixing these concepts up all the time - I know that I am.

David Knott 19/08/2021 David Knott 19/08/2021

Agreement is optional; understanding is essential

Technology architecture is characterised by debate: we spend a lot of time arguing with each other. Given how much time we spend, we should ask ourselves whether we are any good at it. But being good at arguing doesn’t mean that we win all the time: in fact, winning all the time might be a sign of badness. Arguing well means that we are reliably successful at discovering the truth and making decisions - which may mean that we have to change our minds.

Some time ago I wrote that, as a technology architect, one of your jobs is to get ideas from your head into other people’s heads. I still believe that to be true, but realise that I left something very important out: it is also your job to get ideas from other people’s heads into your head. It is your job to understand the objectives, motivations, constraints and thinking of other people, and to see how these change your perspective.

David Knott 12/08/2021 David Knott 12/08/2021

Cloud transformation: don’t stop at the foundations

Over twenty years ago, I was working in Canary Wharf when the next set of towers after 1 Canada Square started to be built. I had the opportunity to watch the foundations of new buildings being laid, and to see the surprising contrast between the amount of time it took to lay those foundations, and the speed with which the new buildings climbed to the sky. For months it seemed that nothing was happening - but that ‘nothing’ was what made the rest of the building possible.

In Cloud transformation, we usually start by building foundations: basic concepts and constructs such as landing zones, tools and security policies, accompanied by essential training, and proven by pilot workloads. This first phase can be difficult, as it requires you to make some of your most important choices and do some of your most important work at the time when you have least experience and capacity. As with any profound change, you will experience setbacks and surprises as well as success, and you will need to adapt your plan. It is also wise to seek help.

David Knott 05/08/2021 David Knott 05/08/2021

Predicting doomsday: is your transformation initiative in trouble?

Can this initiative be rescued? Or is it doomed to failure?

If you’ve worked on any transformation initiative, I expect that you have asked these questions when things were difficult. If you were a member of the team, you may have wondered whether it was time to find a new project. If you were a leader of the initiative, you may have wondered whether you were up to the job. And if you were a sponsor of the initiative, you may have wondered whether you should apply your sponsorship elsewhere.

In my last couple of blog posts, I wrote about the importance of sustaining energy in large scale transformation, and offered some suggestions on how to keep going. James Cole, who leads architecture for the British Red Cross, asked in the comments for suggestions about when to persevere and when to think again - about how to detect that your initiative is doomed.

David Knott 29/07/2021 David Knott 29/07/2021

The persistence of vision: sustaining energy in strategic transformation

Sometimes you just feel like giving up. Some days, even when you are the visionary leader of a transformation programme, even when your teams and your company are looking to you to provide energy, direction and confidence, it just feels like there are too many obstacles. You look at the many other abandoned programmes in your enterprise’s history, and you wonder how you can succeed when so many others have failed. You look at the status quo, and wonder whether it is really so bad. Maybe you should curtail your ambitions, and settle for some incremental improvements.

I don’t have a perfect answer for sustaining energy in the face of seemingly insurmountable obstacles. But there are three ways of seeing - three perspectives - that I find helpful: the perspectives of imagination, of time and of others.

David Knott 22/07/2021 David Knott 22/07/2021

Apathy is transformation’s greatest enemy; wholeheartedness its greatest friend

There are many abandoned projects in the world. If you Google ‘abandoned projects’ you will mostly come up with examples of construction projects: buildings that have never been finished, that are never going to be finished, and now haunt their environments as shells and echoes of their original intent. When such a project goes wrong, the results are plainly visible.

For those of us who work in enterprise technology, or who try to transform companies, the remnants of our abandoned projects are not so visible. When we walk around our offices we do not see the millions of lines of code that were written but never made it into production, the packages that we bought but never implemented, or the process and culture changes that didn’t stick. Our false starts and u-turns are largely invisible to the eye. But they are visible to our memories: anyone who has been working in enterprise technology or transformation for some time has their mental store of abandoned projects.

David Knott 15/07/2021 David Knott 15/07/2021

Servant leadership for cloud transformation (or any other transformation)

What character traits do you need to lead Cloud transformation? Which should you avoid?

I recently wrote a series of blog posts about seven key roles for Cloud transformation - or for any other large scale, technology enabled transformation. That prompted me to ask myself a question: how should leaders behave when they fill these roles? I believe that leadership requires more than the competent execution of a set of tasks and responsibilities: it requires the adoption and practice of a set of behaviours which will make your transformation successful - and make the experience rewarding and fulfilling for the people in the team.

When asking questions about behaviour, my philosophical background leads me to Aristotle’s theory of the virtues. In Aristotle’s philosophy (and much philosophy which has come after), virtues are behaviours which we value, whose practice is self-reinforcing (the more often we are honest, the more honesty becomes a habit), whereas vices are self-reinforcing behaviours which we don’t value (if we lie frequently it is hard to stop).

David Knott 08/07/2021 David Knott 08/07/2021

Architecture or archaeology?

Last weekend my wife and I visited London together for the first time in several months. As well as having the chance to eat in great restaurants and see inspiring art, we did one of our favourite and simplest things: wandered the streets of a city which we have visited thousands of times, but where there is always something new to see. This time, we happened to be walking along London Wall. This is one of those streets where you can see history piled on top of itself: the remnants of the Roman wall next to the ruins of a medieval hospital, near a Victorian building, all in the shadow of skyscrapers from this and last century.

As ever, this reminded me of the work of technology architecture. While the history of computing is much shorter than the history of London, we have our own layers of technology from different ages. In banking, for example, a customer might initiate a payment from a mobile app which was updated yesterday, calling APIs which were built a couple of years ago, running on a five year old gateway, routing messages into queues that have been in existence for over a decade, before triggering a transaction in a back-end that was developed in the 1980s. And all that history is played out when the response is sent back. It might not be apparent to the end user, but performing a simple operation on their phone can be like sending a boomerang into the past.

David Knott 01/07/2021 David Knott 01/07/2021

Cloud leadership: the team

A team is more than the sum of the people who make it up - if you put the work in.

Over the last several weeks, I have written about seven key leadership roles for Cloud transformation. These are all demanding and difficult roles, and it will be hard to fill all of them. However, even if you have a name in every box on the org chart, you don’t yet have a team: you have a collection of individuals.

Despite all the literature on effective teams, despite all of the training available, and despite the ubiquity of those team building events that many people dread, I believe that one of the most common mistakes we make is to fail to invest time in team formation, cohesion and performance. I know that I have been guilty of assembling groups of talented people, aligning (or so I thought) on task and mission, and then setting off together - before realising (usually when facing tough challenges), that the members of these groups did not yet trust and support each other - or even properly know each other.

David Knott 24/06/2021 David Knott 24/06/2021

Cloud leadership: the Operator

Why does it always happen at three o’clock in the morning? In all the conversations I’ve had about resilience, recovery, incident management, problem management and, latterly, Site Reliability Engineering, we always seem to end up asking the question, ‘What do we do when everything goes wrong at three o’clock in the morning?’

In the days of always-available mobile customer experience, it might seem more relevant to worry about what goes wrong in the middle of the day, when all of your customers are awake. But I think that the iconic 3:00 am failure still serves two purposes.

The first purpose is procedural and technical: it makes us think about how we work when the (virtual) offices are closed and nobody is around. How do we detect failures? How do we respond to them? How do we contact the people who aren’t awake? How do we reduce our dependence on those people?

David Knott 17/06/2021 David Knott 17/06/2021

Cloud leadership: the Educator

It is puzzling that many technology teams routinely underspend their training budgets - even though those budgets are rarely large enough to start with. I have not conducted the research to prove that this pattern is universal, or to diagnose its cause, but I suspect that part of the cause is that most enterprises do not measure technology leaders directly on the capabilities (or career development) of their team: rather, they measure them on project success, operational performance, and management of cost and risk. To achieve all of those things, you need a good team, but if those things are all you are measured on, you may be tempted in the short term to buy, borrow or rent the team, rather than by building capabilities and careers.

This pattern is not sustainable when attempting large scale transformation, such as Cloud transformation. Such transformations require a shift in culture and capability at least as much as a shift in technology. That’s why the Educator is one of the seven key leadership roles for Cloud transformation. Given the transactional approach of many enterprises to technology learning, the Educator is also one of the roles most likely to be left out of the transformation leadership team, or to be ill-defined: giving someone the job of organising a set of technical training, and making sure that <x> people have achieved accreditation by <y> date is not to give them the role of the Educator.

David Knott 10/06/2021 David Knott 10/06/2021

Cloud leadership: the Guardian

A recent LinkedIn post asked people to suggest two words of advice they would give to someone starting out in their career. I immediately knew which two words I would choose: ‘Don’t Panic’. As well as welcoming any opportunity to recognise the work of Douglas Adams, I believe that these words are relevant to all business circumstances. I can think of many challenges, crises, setbacks, failures and genuine disasters which I have faced throughout my career and, while most of them needed energy and urgency, I can’t think of a single one that would have been improved by panic.

I think that these two words should be the motto of one of the seven key leadership roles for Cloud transformation: the Guardian. The Guardian is the person who thinks about all the things that could go wrong, and how to protect their enterprise from those circumstances. They are also the person who understands that risk cannot be eliminated, only managed, and that risk mitigation measures have a cost to the enterprise, often expressed in impacts on speed and agility, as well as cost.