David Knott 13/02/2020 David Knott 13/02/2020

Architecture as education: share your superpowers

Learning new technology skills is like getting x-ray vision.

I don’t know how you learn coding skills, but for me it goes something like this (I should stress that nobody pays me to write code any more, so this is all for my own education or for non-profits):

Realise that I need to do <something> that I don’t know how to do.
Search the Internet and find the frameworks or libraries that everybody else seems to use to do <something>.
Scan the documentation and panic. Experience the usual feeling that I have no idea what I’m doing.
Try to figure out how to do <something> on my own, before realising once again that I’m trying to recreate something the community has already done much better.

David Knott 30/01/2020 David Knott 30/01/2020

Technology architects should learn to spacewalk

On March 18th, 1965, Alexei Leonov achieved a historic first, but also had a tougher day at work than any of us are ever likely to have.

At 8:34:51 UTC, he left his crew mate Pavel Belyayev behind in their Voskhod 3KD spacecraft, and stepped through the outer airlock hatch to become the first human to walk in space. Like many advances in space exploration, this moment represented a shift in humanity’s place in the universe: for the first time, one of us had stepped outside the bubble of atmosphere brought from the surface, and into the cosmos. Of course, Leonov still brought some of Earth’s atmosphere with him in his spacesuit, but he was as close as any of us will ever be to surviving outside a spacecraft in the vacuum of space.

His tough day started when he tried to get back through the airlock hatch: his suit had swelled so much in the zero pressure environment that his fingers no longer reached the end of his gloves, his feet were no longer in his boots, and he couldn’t fit through the hatch. With the calmness and resourcefulness of many astronauts, he took the terrifying decision to vent some of his oxygen, to leak away the thing that was keeping him alive, to get back into the spacecraft.

David Knott 23/01/2020 David Knott 23/01/2020

Which of your ideas will survive the cataclysm (or at least the end of the meeting)?

At the beginning of his famous Lectures on Physics, Richard Feynman said something that is so important and so useful, it is worth quoting at length:

“If, in some cataclysm, all of scientific knowledge were to be destroyed, and only one sentence passed on to the next generation of creatures, what statement would contain the most information in the fewest words? I believe it is the atomic hypothesis (or the atomic fact or whatever you wish to call it) that all things are made of atoms – little particles that move around in perpetual motion, attracting each other when they are a little distance apart, but repelling on being squeezed into one another. In that one sentence, you will see, there is an enormous amount of information about the world, if just a little imagination and thinking are applied.”

This passage not only conveys an essential piece of scientific knowledge, but focuses with precision on what Feynman considers to be the most essential piece of scientific knowledge, and expresses it using very ordinary language. I believe that there is an important lesson here for technology architects.

David Knott 16/01/2020 David Knott 16/01/2020

Architecture as balance #5: fruitful frustration vs fruitless moaning

Have you tried the red button / green button exercise?

It’s one of the simplest and quickest team exercises I know: all the team members simply write down three ‘red buttons’ (things which immediately make them angry and which undermine their motivation) and three ‘green buttons’ (things which are guaranteed to excite and motivate them). They then share them with the rest of the team.

(I have to credit the learning company IDG for introducing me to this exercise through a great leadership programme which we now offer under the name Fusion within HSBC.)

The power of the exercise is that it reveals the diversity of motivation and potential sources of conflict within the team: whenever I’ve done the exercise with a team, I’ve always found people saying something like, ‘But I never knew that wound you up!’ or, ‘If I knew that you enjoyed that type of work so much, I’d have let you do all of it!’ The exercise also gives people permission and a vocabulary to remind each other why they’re heading into conflict: ‘You know that’s one of my red buttons.’

David Knott 08/01/2020 David Knott 08/01/2020

New Year’s resolution day two: suggestions for making your documents better

Last week I suggested a New Year’s resolution for technology architects: to improve how we present and format documents. I suggested this not just because I am pernickety about document formatting (I am), but because good formatting makes our ideas easier to understand, helps those ideas compete on a level playing field with others, and express our identity as professionals who care.

On the dangerous assumptions that that, first, you were persuaded by this blog post, and, second, that you are interested in keeping this resolution beyond 2nd January, here are a few further suggestions from me on how to put it into practice. As ever, these suggestions come with the caveats that they work for me, but may not work for you, and that I am frequently wrong.

David Knott 02/01/2020 David Knott 02/01/2020

A suggested New Year’s resolution: don’t let bad formatting hide good ideas

My parents gave me many gifts: a loving home and all the support I could ask for. There is one gift, though, which they didn’t plan: a low tolerance for poorly formatted documents, to an extent which has enabled me to irritate every team which has ever worked for me throughout my career.

This started back in the 1980s, when my Dad, who sold print and reprographic equipment, had two realisations. First, he spotted that the shift from hot metal (blocks of lead type set by hand) to phototypesetting (photographic images of type produced electronically) was an inevitable trend. Second, he realised that he’d far rather work for himself than for an employer. As a result he and my Mum founded a typesetting company based out of our home.

Growing up in the same house as my Mum and Dad’s typesetting business taught me many things. It showed me the evolution of a business through technology: as the years passed, I saw the equipment change from its original incarnation (an electric typewriter with an interchangeable ‘golf ball’ for different fonts, to produce paper copy physically cut and paste with scalpels and glue on a light table) through our first proper computers (green screens attached to big orange boxes, which still produced paper for the light table) to its first fully electronic form (Macs with giant screens that produced files(. I also saw the impact on businesses and ways of working: how the flow of motorbike couriers to pick up copy at any time of day and night (print was always a deadline driven business) slowed and stopped as they were replaced by file transfer and email (but still at any time of day or night).

David Knott 26/12/2019 David Knott 26/12/2019

Architecture as balance #4: finding the time

Last week, Manoj Chugh asked me for my view on how architects should balance their time between strategic and tactical priorities.

I suspect that Manoj’s question was motivated by the feeling we all sometimes have, that there is simply not enough time: we set ambitious strategic goals and have lofty intentions to realise them, but those ambitions get overtaken by the sheer quantity of decisions we must take and problems we must solve every day.

I can’t even pretend to have a perfect or comprehensive answer to this problem. I could try to point out that strategy and tactics should not be enemies, because good tactics are just the actions which are taken to implement strategy. However, even when strategy and tactics are perfectly aligned, it is easy to feel as if there is just not enough time to get everything done.

I think that we have to accept that this is just part of life as a technology architect (and many other technology roles). If our job is to figure out how to deploy rapidly changing technologies in the service of customers and of business goals, then the number of things we could do will always exceed the number of things which we can do. In this case, then the best we can hope to do is to make the best possible use of the time we have.

David Knott 21/11/2019 David Knott 21/11/2019

Architecture as balance #3: what do you do when ‘tactical’ means ‘irrational’?

Let’s spend some time with the glass half empty.

In my last article I claimed that tactics and strategy do not need to be enemies. Strategy defines goals and sets priority and direction; tactics comprise the actions that implement the strategy. On a good day, technology architects remember that strategy doesn’t happen without tactics, and successfully align the two.

But not every day is a good day. Too often, architects find themselves in situations where someone is trying to justify a design choice or course of action on the basis that it is ‘tactical’, when the architect knows that this is just code for ‘please go away and stop bothering me’ or ‘I know this is a bad decision but I’ve got to go along with it’. These situations are not resolved by remembering the proper relationship between strategy and tactics: they are resolved by hard choices and difficult conversations. Dealing with them is not the most fun part of the job, but if we don’t deal with them, then we are not really doing the job.

David Knott 14/11/2019 David Knott 14/11/2019

Architecture as balance #2: strategic vs tactical

Technology architects frequently ask me how they should balance tactical choices with strategic goals. Sometimes this question is asked in a grand, enterprise context: how is it possible to transform a complex enterprise while maintaining service and delivering immediate change goals? More often, though, it is asked in a very narrow, specific and personal context. How do I get my team to stop picking bad solutions and justifying them because they’re ‘tactical’? How do I get my project manager to let me design a proper solution, when they won’t provide the time, money and resources to do a good job? How do I convince people that they should adopt the ’strategic’ solution when it’s so expensive and hard to implement?

Almost all technology architects face these problems almost every day, and if any of them claim to have solved them once and for all, then you should go and read their blog. I can’t offer a perfect solution, but can offer some thoughts which might be helpful. These will come in two instalments: this is the first, which deals with some common conceptual mistakes made by technology architects.

David Knott 07/11/2019 David Knott 07/11/2019

Tinker, tailor, strategist, innovator

What do you want to be when you grow up?

I’m still not entirely sure that I know, so it’s slightly scary when people ask for my advice on their career choices. Fortunately, being a technology architect means that I’m always prepared to express an opinion on something I don’t completely understand.

Two of the career choices I am asked about most frequently are technology strategy and innovation (probably because I have people that do both of these types of work in my team). Here is some of the advice I offer people to help them figure out whether these choices are good for them, and what kind of qualities they need to do this work well. (Like all advice from a technology architect it is well meant, but possibly wrong.)

David Knott 31/10/2019 David Knott 31/10/2019

Cloud helps us solve the rocket fuel problem

Putting code into production is a bit like going to space.

If you want to reach Earth orbit from the surface of the planet, you will need some help. To start with, you can’t survive on your own in space: you need a spacecraft.

But your spacecraft needs help too. It can’t escape Earth’s gravity on its own: it needs a boost. The only way humans have found to solve this problem so far is by using rockets.

But your rockets need help too. Lifting you and your spacecraft needs fuel, determined by your combined weight. But that fuel adds to the total weight, so you will need more fuel to carry that fuel. And more fuel to carry that fuel.

David Knott 24/10/2019 David Knott 24/10/2019

Lessons last: how one small idea helped shape my career

It is strange how a small lesson learnt early can last your whole life.

Forty years ago, I found myself staring at a piece of text which made no sense to me, wondering whether I had made a terrible mistake. My school offered Russian as a language and, attracted by difference and by the strangeness of the alphabet (and the prospect of a school trip to Moscow and Leningrad), it was the option I had selected. Now I felt like I was illiterate again: I could only recognise some of the characters in the alphabet, and even they didn’t sound like I thought they should sound.

That first lesson made a big impression on me. First, it helped me to decode text that was previously impenetrable: even if I couldn’t understand the words, I could start to figure out the sounds. More importantly, though, my Russian teacher, Mr Clark, pressed home on us the importance of being conscientious. He expected us not just to learn the alphabet, not just to write it, but to write it well. He would mark our work not just on grammar and spelling, but on the care and attention we took in writing. This wasn’t because he was an especially tough teacher: it was because he knew that time invested in the basics would embed the skills, and would help us develop habits of excellence and diliigence. To impress these habits in us, he asked us time and time again whether we were being conscientious, and let us know very clearly when we were not.