I’m David Knott. I’ve been working in enterprise technology for over forty years and I’m still learning. This blog is based on mistakes, failures, lessons and some things I find interesting:


Subscribe on LinkedIn
Cloud leadership: the champion
David Knott David Knott

Cloud leadership: the champion

Transformation is hard, especially in large, traditional enterprises optimised for stability. In fact, transformation is so hard that any traditional enterprise of age and scale will be littered with the wrecks of previous transformation programmes, and it takes courage to try again.

Cloud transformation is particularly hard because, if you are serious about it, you will change many aspects of your enterprise at once: the way you run technology, the way you build and manage software, the pace of innovation in your enterprise, and the experience you offer customers.

What do you do when you meet challenges? What do you do when your teams want to change, but seem trapped by their own processes and policies? What do you do when it seems easier to give up than to keep going? Answering these questions is the job of the Champion.

Read More
Cloud leadership: the visionary
David Knott David Knott

Cloud leadership: the visionary

There are many ways to adopt Cloud, and they don’t all need the Visionary. If you are a new company figuring out where to deploy your applications, Cloud platforms are the obvious choice: you’re already there. If you are part of an existing company making tactical use of Cloud to make incremental improvements in cost, risk or agility, then you may not need the Visionary (although, you might need the topic of my next blog post, the Champion, to convince your company to let you do it).

But if you want to make a profound transformation in all the ways that Cloud can offer, if you want to reshape your company and your technology team to make use of the best platforms in the world, then you need to create a vision which people can understand and follow. You need someone who can define an ambitious goal, and who can help others feel that it is possible to achieve.

Read More
Seven leadership roles for cloud transformation
David Knott David Knott

Seven leadership roles for cloud transformation

I believe that small, empowered teams of skilled people are the best way to get things done. However, I also believe that there is still an essential role for leadership, especially in deep, enterprise wide transformation.

Moving to Cloud can be just such a transformation: an opportunity to change technology, culture and ways of working, as well as your relationships with customers, with data and with innovation. Transformation is delivered best by those small, empowered teams - but will go faster and be more successful if you have people who can play one of seven leadership roles:

Read More
One book a week: simple goals signal purpose
David Knott David Knott

One book a week: simple goals signal purpose

A few weeks ago, I was intrigued to receive an email at work headed ‘One-Book-A-Week is back! Sign up now!’. It came to me (and everyone else at Google who subscribes to a mailing list of productivity tips) from a colleague who was inviting us to pledge to try to read at least one book a week from April to June. We could do it as a team or we could do it individually. There were no prizes for succeeding or penalties for failing - but there was a page to log our books read, a regular email to encourage us and to tell us how we were doing as a group, and a bingo card of different types of books (a novel, a business book, a book by an author we hadn’t read before, a book we had been meaning to read) which we could optionally aim to complete.

I like reading, so I signed up, and pledged to read 13 books during the challenge. Four weeks in I have learnt a few things.

Read More
On the edge of the storm
David Knott David Knott

On the edge of the storm

In 1965, Bruce Tuckman published his paper Development Sequence in Small Groups, and introduced the world to the idea that teams go through four stages of development: forming, storming, norming and performing.

This is one of those ideas which, while it comes from a formal academic literature review of psychology research, is immediately intuitive. If we have ever worked in a team, we can easily recognise the feeling of the early days of a new team, when we are figuring each other out (forming), that period when we know each other well enough to challenge and complain, but not well enough to trust each other (storming), the point when we start to establish our ground rules of behaviour, whether implicit or explicit (norming), and the time when we know and trust each other well enough to help each other develop (performing).

Read More
What are you optimising for?
David Knott David Knott

What are you optimising for?

Recently, one of the teams I am lucky to work with showed me a tool they had built to help plan and manage Cloud adoption. It captured system data, project data, dependencies between applications and platform capabilities, and the roadmap for launch and enablement of those capabilities. Such a tool is helpful for any Cloud adoption programme, but what really stuck with me was the goal that the team had set for themselves.

The team wanted to answer two questions. First, what were they optimising for? And, second, what would they do differently depending on the answer to the first question? If they were optimising for cost, then one set of dependencies mattered more than another set. If they were optimising for agility, then they would give one set of tasks more priority than another set. If they were optimising for risk, then they would build their plan this way rather than that way.

Read More
When is a meeting not a meeting?
David Knott David Knott

When is a meeting not a meeting?

Those of us who spend a lot of time in meetings often spend a lot of time complaining about meetings. We complain that they are poorly organised, that they do not lead to clear decisions, that the organisers aren’t well prepared or that the attendees haven’t done their homework. We wonder why we still go to that recurring meeting that rolls around every week although nothing ever seems to get done.

Given these feelings, it can be a good idea to be ruthless with our calendars: to get rid of those meetings which aren’t worth our time, to cut attendance for meetings which are overpopulated, to cut the duration of those meetings which drag on, and to reduce the frequency of those meetings which happen too often. When we do that, we hope to find that the meetings we keep are more effective and more efficient, and that our diaries are more free: we may even find that we have time to think.

Except . . .

Read More
Thinking time, or thinking just in time?
David Knott David Knott

Thinking time, or thinking just in time?

One of the good things about working at Google is the opportunity for continuous learning, not just about technology, but about topics such as how teams work and how to manage one’s own time - all based on data and research.

One thing I learnt recently was how little time people at work typically spend thinking (not thinking in meetings, or thinking while they write code or documents, but just thinking): for most people it’s less than 30 minutes per day. This was a surprise, but feels intuitively plausible. If we think about how we spend our days, we realise that we spend most of our time running from task to task or from meeting to meeting. Scheduling time for nothing but thinking can feel self-indulgent, or as if we are not doing ‘real’ work.

Read More
Can one voice change a strategy?
David Knott David Knott

Can one voice change a strategy?

The lunar module from the Apollo missions is so familiar that it is hard to imagine other ways of landing on the Moon. Surely that spindly, fragile lander, and the command module in orbit with its lonely pilot are the way that these things are done.

But this way of landing on the Moon was not inevitable: in the early days of Apollo, it was not even seen as an option worthy of consideration. The original plans were for a single craft, capable of landing on the Moon, taking off again and flying all the way home on its own. Such a craft would have no need for a docking manoeuvre in Lunar orbit, which was seen as unnecessary and risky.

And, once we shed our preconceptions based on decades of images, this approach seems intuitively simpler. The Moon missions would already involve many dangerous firsts: why complicate things further by splitting the landing craft and command module, and attempting a docking manoeuvre a quarter of a million miles from home?

Of course, we now know that there are many good reasons to take the approach which we are familiar with, known as Lunar Orbit Rendezvous (LOR), not least that it dramatically reduces the weight of the lunar landing craft. But these reasons would not have been recognised without the persistent intervention of one person: John Houbolt.

Houbolt was an engineer who believed wholly in the value of LOR, and who also believed that it was not being taken seriously. He believed this so much, but met so much resistance, that he circumvented the hierarchy and wrote a famous and notoriously forthright letter to NASA Associate Administrator, Robert Seamans, advocating for LOR and criticising the way that decisions were being made. He was so persuasive that LOR was considered as a serious option, was eventually selected, and resulted in millions of models of lunar landers in museums and bedrooms around the world.

There are lessons (especially for technology architects) to draw from Houbolt, most obviously about persistence, courage and communication.

However, if we go to the text of the letter (which can be found from page 55 of this document), then I think that there are three further lessons we can learn.

First, Houbolt is clear and urgent about objectives. The most striking sentence in his letter is: ‘Do we want to get to the moon or not?’ When we are in the middle of the details of technical arguments, it can be easy to forget why we are having those arguments. Houbolt was clear (we’re going to the Moon!): we should make sure that we are clear too.

Second, Houbolt challenges artificial constraints placed on thinking: what were known as the ‘ground rules’ in the early days of Apollo planning. For example, one of the ground rules was the mission should allow a crew of three to land on the Moon: this rule determined the minimum size of the craft, with knock on effects on the size of the rocket system, on fuel and so on. Houbolt asked: if the job can be done by two people, why not do it with two people (leaving one person free to fly the command module)? We should make sure that we identify our own ‘ground rules’ and ask whether they really need to be rules.

Third, the final section of Houbolt’s letter begins, ‘It is one thing to gripe, another to offer constructive criticism. Thus, in making a few final remarks I would like to offer what I feel would be a sound integrated overall program.’ However, despite the tone of much of his letter, Houbolt hardly needed to make this assertion: it is clear throughout that he is an advocate rather than a critic, and has been moved to write because he believes in what he says. We should make sure that we are just as clear about what we are advocating for as we are about what we are arguing against.

Few, if any, people reading this will have the privilege to work on an endeavour such as the Apollo missions. But we all work on our own endeavours, and we all face criticism and challenge. Houbolt’s letter - and the success of that letter - remind us that passionate, persistent, expert advocacy, focused on the goals of the mission and unbound by needless rules, can change the world.

Read More
Are you new here? Lessons learnt from many new starts
David Knott David Knott

Are you new here? Lessons learnt from many new starts

I joined Google on 7th September 2020, so I’ve just celebrated my six month Google-versary! As well as being a fascinating experience at a very strange time, passing this milestone prompted me to reflect on my experience in other new roles and new companies. I’ve changed jobs many times in my career and, although Google is different from most companies I have worked for, I have been through many of the same thoughts and feelings, highs and lows as I have experienced in other places. I thought that it might be useful to share some of the lessons I have learnt, in the hope that they can help other people moving into new roles.

Read More
Built in or bolted on?
David Knott David Knott

Built in or bolted on?

If you are a technology architect, do you regret the complexity of your legacy architecture? Do you wonder how you ended up with so many layers, and so many different technologies which do similar jobs - but never quite seem to do 100% of any particular job?

I believe that feeling dissatisfied is a natural part of the life of a technology architect. However, I also believe that we should extend ourselves a little forgiveness. It is true that some of the complexity in legacy estates is our fault: sometimes we have not been successful in convincing people to address technical debt, and sometimes we have failed to resolve disputes between champions of different technologies. But much of the complexity in legacy estates is simply a function of time and the continuously changing environment in which enterprise technology must operate.

Read More
Accelerate off the plateau
David Knott David Knott

Accelerate off the plateau

What’s your memory like? Mine is far from perfect, especially for names and faces: let me take the opportunity to apologise in advance to anybody I haven’t seen during the long lockdown, and who I fail to recognise when we meet again. If you see me with a polite smile and a confused look, I am probably trying to jolt my memory into action.

In his book Moonwalking with Einstein, Joshua Foer attempted to answer the question of how to improve his memory, and ended up competing in the U.S. Memory Championships. To do this he had to train hard to master various events, such as memorising random lists of binary digits, long poems word for word, and the order of multiple packs of playing cards. I found many interesting ideas in Foer’s book about the history of memory, the techniques used to improve memory, and about talent and expertise. There is one particular idea, though, that made me think about how we develop throughout our careers, and the conditions that leaders must create to support that development.

Read More