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:
- AI
- ambiguity
- architecture
- augmented reality
- books
- bureaucracy
- career
- change
- Christmas
- cloud
- collaboration
- communication
- corporate life
- data
- delivery
- devops
- end user tools
- ethics
- fear
- government
- halloween
- history
- hype
- innovation
- language
- leadership
- learning
- legacy
- measurement
- mental health
- networking
- New Year
- operations
- prediction
- process
- procurement
- programming
- risk
- science fiction
- security
- shadow IT
- space
- teaching
- teams
- technical debt
- technology advocacy
- testing
- thinking
- TV
- writing
Thinking differently about . . . data
One of the first tools I used in my programming career was something that we would barely recognise as a tool today: it wasn’t a testing tool, or a deployment tool, or even a compiler. It was a physical rubber stamp used to create a variant of something called a Bachman diagram: a representation of an ICL IDMSX database structure. You used the stamp to create boxes that represented record types, and then filled in name and other characteristics in ink.
I share this story not just out of nostalgia (although I am sure that this will bring back memories for many people), but to illustrate just how differently we must think about data today than thirty years ago - and to remind us that, for many of us in senior technology leadership positions, we acquired skills, beliefs and habits in a world very different to that of today.
Thankful for new perspective
One of the many privileges I have had in my career is to work with people from all over the world, to learn about and take part in their traditions. This week, now that I am part of a team which is mostly based in the USA, I got to celebrate Thanksgiving in a small way: at our regular team meeting, we took the time to share the things that we were thankful for.
Naturally, everyone in the team was thankful that they and their families were healthy, and that, despite these strange times, they were employed and got to do interesting work in a great company. The thought that inspired me most, though, came from a colleague who said that she was thankful for the opportunity to choose who we are going to be as we come out of this crisis.
Finding wisdom in unexpected places
In strange and uncertain times, it helps to find wisdom, whatever the source.
I don’t mind admitting that, even though I am privileged to be healthy, housed and in work, I find it challenging to work in a world where we can’t meet each other in person, where I sit in the same room every day, and those days blur into a seamless stream.
In theory, as I no longer have to take the time to travel home on a train (or even a plane), I should end each day with the extra energy to put that lockdown time to productive use. In practice, I find that, most evenings, I don’t have the energy to do much more than watch TV. I suspect that I am not alone.
Use cloud to create focus
I feel slightly guilty as I write this article - but only slightly. I’m typing this on an old Macbook Air, and every now and then it reminds me that I haven’t backed up the hard drive for nearly a year. Whenever it does that, I feel a twinge of guilt - and then I dismiss the reminder.
The reason that I only feel slightly guilty is that it’s been a long time since that reminder mattered. I started making the shift from local storage to Cloud storage a few years back, and started making the shift from locally installed applications to Cloud based applications a year or so ago. While I’m typing this on a Macbook Air, I’m using Google Docs on a Chrome browser - and could be doing that on a range of devices.
To transform in isolation, create context
Imagine the experience of going to a meeting in a physical office, back when that was a normal thing to do (who knew a year ago that we would be nostalgic for featureless meeting rooms, grubby white boards, and markers that don’t work?). Don’t think about the content of the meeting: think about the context.
On your way to the meeting room, you walk past your colleagues and you catch glimpses of what they were working. You say hello to your friend who sits on this floor, but who you don’t see every day. You walk past the charts on the wall which show team performance and progress against the big project plan. You smile when you saw that the idea you sketched out on the whiteboard still hasn’t been wiped away.
Teaching is the killer app
When listening recently to the great BBC Radio 4 science show, The Infinite Money Cage, I learnt that, while chimpanzees and baboons learn from other members of their species (for example, tool using behaviour such as fishing for termites with twigs), there is much less evidence of active teaching.
We could congratulate ourselves on finding a way in which humans appear to be more advanced than our primate cousins. Teaching allows us to transmit knowledge, skills and wisdom across time and distance. It helps us to adapt to new environments and new circumstances. And its power and importance have only been reinforced by the current global pandemic.
Thinking differently about . . . DevOps
Last week, I claimed that technology leaders attempting to change the culture of their organisations should start with themselves. I think that this is especially true for technology leaders who are trying to introduce DevOps to their organisations. I am one of the people who have tried to do just that, and have not always been successful: as usual, this article is inspired by the opportunities I have had to make mistakes.
The concept of DevOps has been around for over ten years now, and has been described by more expert people than me, so I won’t attempt to give a precise definition here. (And I will also take this opportunity to say that, although I work for Google, a company which exemplifies many of the practices attributed to DevOps, the views in this article are my own.) I will, though, offer two ways in which I think about DevOps.
Technology leaders: cultural transformation starts with you
How do you react to the launch of a cultural transformation programme in your company? How does your team react? With anticipation and delight, or with the suspicion that this will be a parade of slogans and new names for old things, and that it will melt away after a few months? I know that I have been responsible, with the best of intentions, for eliciting the latter reaction several times in my career. How do we learn to avoid it?
A few weeks back, I wrote about my first day at Google, and how pleased I was by the focus on culture, and the message that as Nooglers we were, from day one, custodians and participants in this culture. (And I should say that, just like that article, the views here are my own: if you’d like the official Google view, you can find plenty of that here.)
Thinking differently about . . . collaboration
How often have you accidentally hit ‘reply all’ when sending an email? Or included someone on the cc: list that you didn’t intend to? I think that we all know the feeling of making that mistake.
I had a similar experience in my new job at Google last week - but it turned out to be a lesson about collaboration instead of a mistake.
I was editing a document using Google docs, and when I hit the share button, I was asked whether I wanted to share it with the same people as the document I had copied it from. I hit ‘yes’ - then realised that I had shared the document with about a hundred people, rather than the half dozen I had intended it for. I had a sinking feeling for a moment - then remembered that I needed to think differently about collaboration.
Thinking differently about . . . cloud
I will always associate the concept of Cloud with a view of the Thames. That’s what I could see on the day when the Cloud light bulb first began to flicker on in my head. One of my colleagues had arranged for the CTO of a Cloud company (not the one I work for today) to visit us, and he was explaining how his company had built their platform to support their own business. I started to realise how Cloud differed from traditional enterprise infrastructure and why I, as a technology architect, needed to pay attention.
As promised, this article is one of a series on how I learnt to think differently about key concepts in enterprise computing, written in the hope that they may be useful to people on the same journey. Before we go further on Cloud, though, I should declare that I work for a Cloud company (Google), but that the views in this article are my own. I should also say that I work for a Cloud company because I believe in the value of Cloud, not the other way round.
Thinking differently about . . . the persistence of code
This week I learnt that some of the code I wrote thirty years ago is still running in production. I don’t know whether to be pleased or terrified, but I know that it’s not the first time I’ve had that surprise.
Back at the beginning of my career, I wrote part of a system using technologies which barely exist in memory today: Application Master on an ICL mainframe accessing an IDMSX database. Ten years later, I did some more work for the same company, and was surprised when the year 2000 project team (yes, this was around 1999) approached me, asking me whether I knew anything about this code with my name on it. I recognised the code, but had never imagined it would be running ten years in the future.
Chief Architect: Day One
What should you do in your first day as Chief Architect of a large organisation?
I got to ask myself that question four years ago, when I started as Chief Architect for HSBC: it took me a long while to find (some of) the answers. Now that I have left HSBC for a new role, my successor has also had the chance to ask that question.
Here are some of our combined thoughts, in the hope that they will be useful to other people stepping into such a role. As with all offers of architecture advice, they are offered with a combination of confidence (won through learning from many mistakes) and humility (recognising that anyone people taking up the role will already have found some better answers than mine).