- AI
- ambiguity
- APIs
- architecture
- augmented reality
- books
- bureaucracy
- career
- change
- Christmas
- cloud
- collaboration
- communication
- complexity
- computer history
- corporate life
- data
- decisions
- delivery
- devops
- end user tools
- ethics
- failure
- fear
- fundamentals
- gaming
- government
- halloween
- history
- humans
- hype
- identity
- infrastructure
- innovation
- language
- leadership
- learning
- legacy
- management
- measurement
- mental health
- money
- networking
- New Year
- operations
- partnership
- philosophy
- physics
- platforms
- prediction
- process
- procurement
- programming
- quantum
- reliability
- resilience
- risk
- science
- science fiction
- security
- shadow IT
- space
- standards
- strategy
- teaching
- teams
- technical debt
- technology advocacy
- testing
- thinking
- transformation
- TV
- virtues
- vision
- writing
Philosophy for architects: which habits will you make and which habits will you break?
Many of us will be working in unusual circumstances for extended periods of time. We will be at home rather than in the office. We will see more of our family than our colleagues. When we do see our colleagues, it will be by video rather than in person. (And, of course, if we are fortunate enough to be healthy, housed and in work, we will learn to be grateful for those things that we normally take for granted.)
As we adjust to this new way of life, we will form habits. We will (or will not) find ways to exercise. We will (or will not) find time to talk to people we wouldn’t otherwise see. We will (or will not) let our frustration and impatience with technology leak through into our behaviour. We will (or will not) continuously raid the cupboard for snacks.
Ethics, the philosophy of morals, contains some ideas about habits which might be useful to us as we live through these strange times. To understand these ideas, though, we must begin with some basics.
Technology isn’t magic: it’s better than that
In the 1973 version of his essay, Hazards of Prophecy, Arthur C. Clarke famously wrote, ‘Any sufficiently advanced technology is indistinguishable from magic.’ In the same essay, Clarke suggested that certain fundamental advances in science and technology, such as the discovery of radioactivity, and its use in fields as diverse as medicine, energy and warfare, were so far beyond the experience and expectations of previous times that people from those times could not even begin to understand them.
I think that technology architects should challenge and embrace this idea at the same time.
We should challenge the idea that advanced technology must be as mysterious as magic. Magic seems to me to be something that we not only do not understand, but something that we cannot understand: if books and films are anything to go by, we are dealing with magic when we can figure out effects but we cannot fully explain causes (if we could, then wouldn’t it be science or technology?).
Perspective for technology architects: keep thinking bigger
In 1959 the physicist Hugh Everett met with Niels Bohr, one of the pioneers of quantum physics. He wanted to share an idea: that the strange behaviour of quantum particles could be explained by postulating that, every time a particle could be in multiple different states, it existed in all those states, but in different universes. This was an early version of what came to be called the many-worlds theory.
Unfortunately for Everett, the meeting did not go well. That wasn’t a surprise: Everett was trying to convince one of the creators of the Copenhagen interpretation of quantum physics that that interpretation was wrong - and he had even gone to Copenhagen to do it. Everett admitted that the meeting was ‘doomed from the start,’ and he turned out to be right. He could not even establish sufficient common ground to have a meaningful discussion.
Although the idea languished for many year, seventy years later, the many-worlds interpretation is treated as a serious, if controversial, way to describe the universe.
Architecture as education: it’s okay to be enthusiastic
Had we finally found the answer?
It was my leadership team meeting in Pune, India, and we were discussing, yet again, what we could do to improve the visual communication skills of the architecture team. How could we teach people to recognise bad layout and design, to understand that it gets in the way of understanding, and that it undermines what they are trying to say?
Anubhav Pradhan, the head of the HSBC Technology Academy, had a suggestion. Had we read the C.R.A.P. book? After our initial, obvious reaction, Anubhav explained that the C.R.A.P. book was The Non-Designer’s Design Book by Robin Williams, which explains why Contrast, Repetition, Alignment and Proximity are so important to design and visual understanding.
We agreed that anything was worth trying, even if it was C.R.A.P., and Anubhav duly assigned us all the training in our learning platform, so that we could all learn together and share our experience.
Philosophy for architects: where did all those reasons come from?
Let’s do some philosophy!
When people notice that I have a PhD in philosophy, specialising in ethics, they often ask me how I apply it in my day job. Up until a few years back, the honest answer was that I didn’t: I tried to behave ethically, like everybody else, but that was just normal behaviour, not an attempt to do philosophy at work. That has changed following the growth of commercially useful artifical intelligence: interest in AI ethics has brought philosophy into the workplace. I hope that it has shown that philosophy does not have to be an obscure, impenetrable discipline: at its best, the aim of philosophy is to answer hard and important questions that matter to everybody.
So, now that philosophy has come to the office, let’s see if we can put it to work. We can start by seeing if when we need to make a decision, but people just can’t agree with each other. (I realise that philosophy is not for everybody: if it’s not for you, skip to the TL;DR non-philosophical punchline at the end.)
When did you first know that you wanted to be a technology architect?
It can take a long time to figure out where you fit. It needs self-awareness, often earned through a success and failure, elation and disappointment. It needs a dose of self-confidence, a shedding of self-doubt and false modesty, to admit that you are actually good at something, perhaps better than many other people. And it needs a big helping of humility, to admit that there are plenty of things that you are not good at, and which are best left to other people.
However, if you are a successful technology architect, I suspect that there was a moment early in your career where you figured out that this was the work for you. You discovered that there was something in the combination of problem solving, persuading and explanation that motivated you; that you had an itch made of equal parts curiosity, persistence and a desire to see things done right that could only be scratched by doing architecture work.
I can remember when I first realised that I wanted to be a technology architect. Except that this was so long ago that we didn’t call it architecture: if we called it anything, we called it analysis, design or Figuring Stuff Out.
Who will ask you the tough questions?
How can one short conversation undo months of decision making and design? And how can that be a good thing?
If you have been a technology architect for a while, you probably spend time trying to make difficult decisions. You may be defining the architecture for a major programme, or an essential platform, or an important business initiative. You are in the cut and thrust of choices and arguments and opinions every day: it sometimes feels as if you will never get out. But finally, clarity begins to emerge: you find the answers to the most important questions, the ones that unlock the rest of the work. Are we going to pick this product or that product? Or this partner or that partner? Or this approach or that approach?
You know that there is lots more work to do, but now you feel that you can proceed with confidence. The most difficult decisions have been taken.
And then you encounter . . . that person.
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.
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.
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.
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.’
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.