David Knott 15/06/2023 David Knott 15/06/2023

The technology hierarchy of needs

The theory has been criticised and challenged, but has a continuing intuitive appeal, and is often taught on management courses. If you’ve done any management or leadership training in your career, you have likely seen that pyramid many times.

I believe that we can borrow the concept of the hierarchy of needs to help us understand the answer to a related question: why do anything with enterprise technology? And, more importantly, which things matter most?

Enterprise technology is a field of continuous, strenuous activity. The digital service that you consume as an end user may look simple and elegant, but behind the scenes there will be people writing code, testing systems, managing deployments, building infrastructure, probing security, negotiating contracts, defining architecture, making decisions and so on. And there will be more people managing and leading the first set of people, gathering data, reading reports, assessing risk, allocating funding, finding resources and so on. Over time, some of this work will become automated or delegated to service providers, but the total amount of work never seems to reduce: there is always something else to do, and there is never quite enough budget or resource to go around.

David Knott 08/06/2023 David Knott 08/06/2023

Time to talk about mental health

It was Mental Health Week a couple of weeks ago, but I was too busy to write this article. Actually, that’s not true. I was too nervous to write this article. But those are both good reasons to write it, even belatedly.

I want to write about how anyone can experience challenges with their mental health at work, how it can be difficult to know when this is happening, and how welcome it is that times have changed. I also want to illustrate this with an example of a personal experience.

Two declarations before I share that experience. First, I am not a health professional and have no training in the field. Second, this is a tale of everyday stress and its consequences. I have come to realise that, part of the reason that it is important to talk about mental health is that many people experience challenges which are not long term, and which don’t require a diagnosis, but that nevertheless need help. And they (including me) don’t always feel comfortable asking for help.

David Knott 01/06/2023 David Knott 01/06/2023

The value and inevitability of being proven wrong

Do you like being proved wrong? If you work in enterprise technology, I hope that you do, because it’s an essential part of the job.

Working in enterprise technology means that you are in the business of making predictions: small predictions, such as how many stories you are going to complete in this sprint; medium predictions, such as whether this partner is going to deliver the project successfully; and big predictions, such as whether this technology is going to make an impact on people’s lives.

I have got every single one of these predictions wrong at some stage in my career. My favourite example of getting a big prediction wrong is the way that I thought about QR codes.

David Knott 25/05/2023 David Knott 25/05/2023

Swimming against the tide of your own skills: the importance of unlearning

Which is harder, acquiring new beliefs or discarding old ones?

Last week, I wrote about how technologists can respond to the pressure - and the frequent interview question - to stay current, to keep their skills and knowledge fresh and up to date. Tim Pieters suggested that I consider the related topic: how we unlearn. That is, how we shed beliefs and practices which are no longer helpful.

I think that unlearning is harder than learning.

Both require humility, but learning requires an easier sort of humility: we need simply to admit that we are ignorant, and that we need to put in the effort to read, listen, watch and practice. Unlearning requires us to admit that we were wrong, that prior decisions and efforts were made on the basis of beliefs that we now consider to be mistaken.

David Knott 18/05/2023 David Knott 18/05/2023

Answering the question: ‘How do you stay current?’

How do you stay current?

I have to admit that, every time I am asked this question, I panic a little internally. I have an answer: there are blogs and sites I read, there are people I follow on social media, I have a long list of courses and books, and I try to do some real coding when I get the chance. But I also know that all those activities are flimsy bulwarks against the rapidly rising tide of ignorance, and that if I truly wanted to ‘stay current’ I would have time to do nothing else. In recent years and months, the press has been full of stories about new technology: ChatGPT and LLMs are the latest topics to grab the global imagination. But, for technologists, these are just the highly visible tips of a very large iceberg of trends in computing, networking, cyber security, software engineering and data science that most people don’t see. We are used to our concepts being disrupted.

Does this mean that there is no point in trying to stay current, that we should abandon all attempts to maintain a general understanding of the field, and only learn about new topics as we need to (perhaps using an AI assistant to explain things to us)? Unsurprisingly, I don’t think so: I enjoy learning, and think that the dynamism and volatility of the technology market make it fun. I do believe, however, that we should be thoughtful about what we learn, and distinguish between knowledge that will last and knowledge that will fade.

David Knott 11/05/2023 David Knott 11/05/2023

Styles of reuse: what do we expect from each other?

Reuse seems like a good idea. Building new stuff takes time and money, whereas copying or using existing stuff sounds like it should be easier. If that’s the case, though, why is it so hard? Plenty of organisations attempt to control the cost and complexity of their technology by increasing reuse, setting metrics to measure their achievement of this goal. Unfortunately, these metrics usually show that they have limited success: people seem to like building and acquiring new stuff, even if they have stuff that does the same job.

I think that one of the reasons for this phenomenon is that reuse is dependent on trust (if I am going to use your software, I need to trust that it works), trust is dependent on expectations (if we are going to work together, we need to know what we expect from each other), and expectations are often unstated or unclear (I don’t know what I can expect from you, and you haven’t said what you expect from me). Furthermore, there is more than one style of reuse, each of which comes with different expectations.

David Knott 04/05/2023 David Knott 04/05/2023

What do I believe about enterprise technology?

Last week, I wrote about three things that I learnt in my time at Boston Consulting Group. One of those things was the practice of conducting belief audits: figuring out what you believe and what your true goals are. This practice is particularly important when considering major change: if you don’t know what you are really aiming for, then how are you going to achieve it?

I’m moving to a new role, so it seems like a good time to conduct a personal belief audit. There are inherent beliefs that I’ve acquired in a long career in technology (note that I use the term technology in this article to mean the broad field of computing: I realise that there have been many other technologies since the earliest days of stone tools - but that’s the way we use the word these days - and, unfortunately, if you say Information Technology or IT, that makes people still think that you have come to fix the printer), but I’m not sure that I have ever attempted to write them all (or at least the most important ones) down. Here goes . . .

David Knott 27/04/2023 David Knott 27/04/2023

Three things I’ve learnt at BCG

Today is my last day at BCG. (I’ll share what I’m going to do next in the near future: let’s just say that it had to be something pretty special to tempt me away from BCG.) My time here has been one of the most intense learning experiences of my life: I’ve learnt about new industries, new technologies, and got to see how one of the world’s leading consultancies works from the inside. But there are three things which have particularly stayed with me, and which I plan to add to the box of conceptual, practical and technical tools I have built over my career.

David Knott 20/04/2023 David Knott 20/04/2023

Will conversation save us from frustration?

. . . I will do such things -

What they are yet, I know not; but they shall be

The terrors of the Earth!

These are King Lear’s lines in Act 2, Scene 4, as he rages against his daughters.

Like much of Shakespeare, these lines can be interpreted in distinctly different ways. I have seen them played as threats of fathomless malice: I shall do such terrible things that they cannot even be named. And I have seen them played as expressions of impotence and frustration: I am so powerless that I cannot even say what I will do.

We might think that, in our normal lives, we could not attain the towering anger of a mythic and tragic figure such as Lear. Yet it is remarkable how frequently, when faced with even little frustrations, we find ourselves uttering curses that might rival Shakespeare for venom and invention.

David Knott 13/04/2023 David Knott 13/04/2023

What if we could see software?

One problem with software is that we can’t see it.

This might seem like a strange thing to say. Don’t we see software all the time? I am looking at a word processor embedded in a browser as I type these words. If I get interrupted (as I inevitably will) by a message or a call, I will see and touch a software defined interface on my phone. This software was written by human beings staring at lines of code on screens. If I doubt the existence of this code, then I can hop across to one of many public code repositories, and see millions of lines of it for myself.

Yet none of these experiences really count as seeing software. When I use my word processor, I simply see the behaviour which the software presents to me. When I pick up my phone, I merely see a veneer on top of a whole network of applications and interactions which work together to get messages to me. And when I look at actual code, I only see a tiny fraction of software at a time. Anybody who has tried to hold multiple sections of code in their head at the same time knows how quickly your memory fills up - and how fragile it is.

David Knott 06/04/2023 David Knott 06/04/2023

Breaking the cloud barrier

On October 14th, 1947, Chuck Yeager became the first human to break the sound barrier, flying the Bell X-1 experimental plane. Prior to that event, there had been serious doubt about whether it was possible to break the sound barrier at all: aircraft approaching the barrier had experienced buffeting, instability and even crashes. However, Yeager’s flight was remarkably smooth: his plane had been designed for supersonic flight. Yeager later said, ‘I realized that the mission had to end in a let-down because the real barrier wasn’t in the sky but in our knowledge and experience of supersonic flight.’ Your and my definition of a let-down may vary from Yeager’s definition.

I believe that the experience of human efforts to break the sound barrier is analogous to enterprise efforts to adopt new technology. Right now, this is particularly apparent in the adoption of public cloud. Despite being convinced of the advantages of software defined, elastic, on-demand platforms, every organisation seems to have its own version of the sound barrier when it comes to cloud. Let’s call it the cloud barrier.

David Knott 30/03/2023 David Knott 30/03/2023

A mishap on Mars

On September 23rd, 1999, the Mars Climate Orbiter fired its thrusters for a manoeuvre that would bring it into a stable orbit 226 kilometres above the Martian surface. From this orbit, it would gather valuable information about weather systems on Mars, as well as acting as the communication relay for subsequent missions. 226 kilometres was a safe height, well above the 80 kilometeres at which the atmosphere would be thick enough to cause problems.

But the manoeuvre went wrong, The Orbiter dropped to an altitude of 57 kilometres, and either burnt up in the atmosphere, or skipped off and flew away from Mars altogether. Whatever happened, it was never heard from again.

The investigation found that the problem was due to a mismatch in the units used by the different systems used to calculate and control the craft’s manouevres. One system was working in pound-force seconds (an Imperial measure), while the other was working in newton-seconds (a metric measure). The ratio between these units is 4.45:1 - no wonder the craft crashed.