David Knott 05/05/2022 David Knott 05/05/2022

The team is the unit of transformation

In enterprise technology we like to count things: applications, petabytes of data, physical and virtual servers, gigabits of bandwidth and so on. Even if it's often surprisingly difficult to find them all and figure out what state they're, you know where you are with things.

It's not surprising, therefore, that when we attempt transformation, we often plan and measure success in terms of these things. We are shifting to a new operating system: how many servers have we upgraded? We are unlocking access to our data with APIs: guess many APIs have we built? We are moving to the Cloud: how many applications have we migrated?

The problem with measuring transformation like this is that it leaves out the most important thing: the people.

David Knott 28/04/2022 David Knott 28/04/2022

Are we any good at explaining technical debt?

Updating code can sometimes feel like an Indiana Jones movie: avoiding traps, solving puzzles, evading dangers and unravelling mysteries of the past. And, if you get it wrong, frantically trying to deal with the huge boulder of mayhem or swarm of bugs that you have unleashed. What makes it worse is that the people that created these traps and riddles were you and your teammates, and you did it just a couple of months ago: it’s astonishing how fast the memory of code fades.

This is, of course, the world of technical debt. While this is a powerful metaphor, and a term used frequently by technologists, I think that we are often unsuccessful in conveying its importance to non-technologists, especially in large enterprises. If we were more successful, then our systems would be less full of short term fixes and quick bodges, and we would give more funding and resources to refactoring and code repair. The state of our systems shows that we have more work to do.

David Knott 21/04/2022 David Knott 21/04/2022

Dunning-Kruger and the duty to explain

You have probably heard of the Dunning-Kruger effect: the idea that people who are not expert in a particular field tend to over-estimate their level of competence, while people who are more expert in a particular field tend to under-estimate it. This is often expressed as the claim that non-experts don’t know what they don’t know (‘how hard can it be?’) while experts know just how much they don’t know (‘I’m an imposter!’). The effect was originally described by David Dunning and Justin Kruger in their 1999 paper, Unskilled and Unaware of it: How Difficulties in Recognising One’s Own Incompetence Leads to Inflated Self-Assessments.

Even if you are not familiar with Dunning-Kruger, I expect that you are familiar with the effect it describes, especially if you have ever used the words,’Well, it’s a bit more complicated than that . . .’

This is particularly true if you work in a complex, technical field such as enterprise technology. Those of us who work in such roles frequently get frustrated with the people who ask us to do things (sometimes business leaders, but also often technology leaders who are no longer close to technology) fail to understand what they are asking for, and fail to understand the degree to which they don’t understand.

David Knott 14/04/2022 David Knott 14/04/2022

Three things I’ve learnt at Google

Today is my last day at Google! (I’ll share what I’m doing next in a few weeks time.)

It feels both different and similar to my last move, when I left HSBC. Different because, when I left HSBC, my memories were of experiences from all over the world, whereas most of my time at Google has been spent in my study at home, talking to people on video. The same because, in both cases, the memories of people are more important than the memories of places. And the same again because, like every company I’ve worked for, I’ve learnt a lot in my time at Google, and plan to take those lessons with me on my next adventure.

The list of things I’ve learnt about at Google is long and varied, and includes things that have enriched my life, many of them not directly related to my role: a trans awareness course that changed my understanding of the world, participation in an AI ethics reading group that challenged my understanding of complex topics, and coaching on creativity and flow states that shifted my understanding of myself.

David Knott 07/04/2022 David Knott 07/04/2022

What do you do when the warm glow of positive feedback fades?

It seems like a paradox. We enjoy positive feedback more than negative feedback. Who doesn’t like being told that they’re great? And who likes being told all the ways that they could do better? Yet, we typically let negative feedback stay with us, while, after a brief glow of satisfaction, we let positive feedback fade fast. If you are anything like me, then you are probably brooding on that little bit of negativity (What did they mean? And how could they have got it so wrong? And here’s what I should have told them!) long after the warmth of praise has cooled.

I think that we owe it to ourselves to do more with positive feedback, not just because it’s good to feel good about ourselves, but because it helps us get better. I offered some suggestions last week about how we can be more receptive to difficult feedback: lowering our shields, avoiding excuses, reflecting before jumping to solutions, and thanking the messenger. I’m going to try this week to offer some suggestions for how we can make the most of positive feedback. These come in the form of questions we can ask ourselves and others. I can’t say that I remember to ask all of these questions all of the time: for some reason it seems harder to act on positive feedback than on difficult feedback. But I try to try. Here are the questions:

David Knott 31/03/2022 David Knott 31/03/2022

Feedback is the breakfast of champions, but it can be an acquired taste

Do you remember your first ever cup of coffee? Or your first oyster? Or olive? Or Marmite on toast? Not everything tastes good the first time you try it. But if you try it again, you may come to like it.

Getting feedback can be a similar experience. When someone says, ‘do you mind if I give you some feedback?’ we often tense up, as if expecting that first challenging taste of an unfamiliar food. It’s rarely a welcome phrase to hear: you know that you’re about to be presented with something that is going to be difficult to digest.

But if, as Ken Blanchard famously said, ‘feedback is the breakfast of champions’, it is something that we must try to learn to enjoy. I’ve made plenty of mistakes in my career, and have had many opportunities to improve. I’m fortunate enough to have worked with people who have been prepared to point them out to me. So, whether I like it or not, I’ve been served many dishes of feedback. I can’t say that I’ve learnt to enjoy all of them, but I have learnt to recognise when my own reactions make them more difficult to swallow.

David Knott 24/03/2022 David Knott 24/03/2022

Is being the family technical support person a warning of digital exclusion

While you’re here, could you take a look at the printer?

My phone was normal before, but it just started doing this weird thing.

I’ve lost the icon and now I can’t get it back.

If you work in technology, in any capacity at all, you know how it goes. If your less family or friends have problems with technology, then you are the one they call. If you are visiting, then you will spend at least some of your time configuring their phones, resetting their wireless network, or breaking the news that their ten year old laptop really isn’t going to survive another upgrade. You will be used to patiently explaining that this prompt to update their OS isn’t a virus and shouldn’t be ignored, but that this email from a friendly person who wants to help make their machine go faster is a dangerous scam and should never be opened.

David Knott 17/03/2022 David Knott 17/03/2022

Don’t just take your apps to the cloud: take your teams too

I was recently reading a graphic novel version of The Goal, the classic business novel by Eliyahu Goldratt. The book has been translated into many languages and inspired the equally essential DevOps book, The Phoenix Project, by Gene Kim, Kevin Behr and George Spafford. It’s always worth engaging with the ideas these books contain, and the graphic novel form is an accessible and entertaining way of getting to grips with them.

On this reading, though, I was struck by one thing in particular. The guru to whom the protagonist turns for advice provides guidance which changes the fortunes of the fictional business. But he doesn’t give the protagonist every answer at the beginning of the book: he keeps telling him that he must figure things out for himself, and must apply each lesson in practice before being ready for the next revelation.

This may partly be a literary device: the novel form wouldn’t work if all it comprised was one character explaining the theory. But I think it is more important than that: I think it is a reminder that, in business and in software development, as in other human activities, learning requires experience.

David Knott 10/03/2022 David Knott 10/03/2022

How does a group of experts become a team?

There’s a leadership problem I have struggled with over and over again in my career. I’ve been fortunate to have the chance to lead teams of specialists, people who are deployed into difficult or complex situations, who are gifted in making sense, making decisions and figuring out solutions. They have sometimes been called architects, and they have sometimes been called consultants, but they have always been smart people who make a difference wherever they go. Let’s call a team like this a team of distributed experts.

There are many problems with running such a team. It can be hard to find the right people. It can be hard to keep people motivated in the face of never-ending, apparently insurmountable problems. It can be hard to win the respect and advocacy of the people you are trying to help. But when you get it right, the team is never big enough and is always in demand.

David Knott 03/03/2022 David Knott 03/03/2022

Infrastructure can be opaque: your cloud should be see-through

Imagine this situation. You have just been alerted to a critical security vulnerability in a piece of systems software embedded in thousands of physical and virtual servers across your on-premise technology estate. Your software provider has issued you with a patch, and you need to apply it as quickly as possible. Your business and technology stakeholders understand the gravity of the situation, and are willing to accept the disruption necessary for an emergency patching programme. It’s a race against time, between your ability to patch and the bad actors coming after your systems.

You have many problems in winning this race. Some of your systems don’t have automated testing in place, and you suspect that the patch will break at least a few of them. Many of your systems aren’t properly stateless, and restarting servers will disrupt their operations. Some of your really old systems don’t like being restarted at all, and will need careful attention.

David Knott 24/02/2022 David Knott 24/02/2022

Cloud operations should be visible and invisible at the same time

Do you need a Cloud Operations team at all?

I’ve heard many companies ask this question, and believe that it is a reasonable question to ask. After all, for many people, the attraction of Cloud is to avoid the frustration they associate with central teams. Development teams who were dependent on overworked, under-resourced and under-automated infrastructure teams can now take direct accountability for the infrastructure themselves. Project managers who used to have to put long lead times for procurement, commissioning and configuration of infrastructure on their critical path can now drop those tasks from the plan. If everything is software now, and the DevOps team takes accountability for operations, why do we need another operations team?

David Knott 17/02/2022 David Knott 17/02/2022

Three steps through the thicket

Last week, I wrote about those horrible processes which still exist in most technology functions in most large enterprises - the release process, the production acceptance process, the onboarding process and so on. The process that everybody dreads, no-one seems to be accountable for, which we don’t seem to be able to change, and which stands between us and our code running in production. I suggested that the way to tackle such processes is not simply to optimise and streamline them: such ‘process gardening’ is a never ending battle against a thicket of thorns that grows back every day. Rather, it is to shift from a focus on process to a focus on trust and accountability.

I realise that’s a difficult thing to do. If everyone is telling you that the process stands between the company and catastrophe, then it takes a lot of courage to step away from it. It’s also rarely wise to abandon all of your process: you just want to get rid of those parts that add friction but not value. However, based on my own mistakes and the successes of others, I can offer three suggestions to get started.