- 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
A technology architect’s guide to humans part six: join more than the dots
What’s the most important email you will write today?
I bet that it’s not the one that starts, ‘Sorry to chase . . .’ or ‘As per my last email . . .’ or ‘Approved,’ or even the one that contains your fantastic new project or design idea. I think that the most important email that you write today might the one that says ‘<Person X>, I’d like you to meet <Person Y>: it looks like you might be working on the same thing / able to help each other / struggling with the same problem.’
Some years ago, I was fortunate enough to attend a leadership course on the value and power of connections within companies. The course tutor had conducted research in which they asked people within our company to list the people they spent time with each day, then mapped the results as a network. When we saw the shape of this network we were quite surprised: it was not shaped like a traditional corporate hierarchy, or even like a set of departments: it was shaped into lots of little clusters, each of which corresponded to a relatively small team.
Double, half, quarter: a lesson from the book of Richard
A few months ago the HSBC Technology leadership team had the privilege of spending time with Jez Humble, author of iconic books such as Accelerate and The DevOps Handbook, and the co-founder of DORA (DevOps Research and Assessment ), now working at Google. Jez had many valuable lessons to share about the theory and practice of DevOps - all backed up by empirical data.
However, what stayed with me most from that day was not what Jez said (sorry Jez) but what Richard Herbert, our CIO for Global Banking & Markets said when he opened the session.
I didn’t have the presence of mind to record his words, but in my memory Richard’s introduction went something like this:
'I believe that our teams come to work every day to do the best job they can.
I believe that if we give our teams ambitious goals and let them figure out how to reach them, they will achieve things we never expected.
I believe that if we empower our teams and trust them, they will repay our trust many times over.
I believe that it is possible to go faster and break less - and we break less because we go faster.
In GB&M, we express these beliefs by setting every team the goal to double, half and quarter every year: double the frequency of releases, half the number of low impact incidents, and quarter the number of high impact incidents.'
If you’re a manager, you’re a role model (whether you realise it or not)
Today, after five years of leading the Technology team at HSBC on a journey of profound transformation, our Group CIO, Darryl West, leaves the bank. We will miss him.
I’ve worked with Darryl for many years in different companies, and have learnt a lot from him, especially about leadership. It therefore seems appropriate to mark his departure by sharing one of those lessons.
This lesson came several years ago, when we both worked at another bank. I didn’t know Darryl well at that time: he was Group CIO, and I was leading architecture for an area called Central Functions (all the back office heavy lifting of the bank - operations, payments, finance, risk and so on). Darryl was holding a meeting of senior managers, and was speaking about our role in leading our teams, when he said something I had never considered before: ‘When your team members go home at night, they talk about you.’
Time to connect; time to reflect
A few weeks I wrote that, in these strange and difficult times, those of us working remotely from home (which means, we must remember, that we are fortunate enough to be healthy, housed and in work, and are not on the front lines as essential workers) will make habits and break habits, and that some of those habits are worth making while others are worth breaking.
My team mates and colleagues have helped me find a couple of habits which I believe are worth making. They are also answers to the question: what do you do with the time you used to spent commuting when your commute has shrunk from a one hour train trip to a walk down the stairs?
Should we teach the green field or the space capsule?
How do we help people become technology architects?
I think that we should start by asking ourselves what it’s like to be a new technology architect. Which of these best describes your first day as a solution architect?
This . . ?
You step into your new realm. The grass is lush and green. Crystal waterfalls sparkle in the background. Hills, forests and valleys stretch away into the distance. You know that the landscape is beautiful: you just need to find a vantage point from which to see it all. You need to build a tower high enough to gain perspective, but what should you build it from? Ivory?
Or this . . ?
You wake up with a start. Your surroundings are lurching and spinning around you. You seem to be in some sort of spacecraft. Looks something like Apollo 13. Gas is venting and there is smoke in the air. You spot your crew mates: they are frantically flipping switches, pressing buttons and turning dials. They turn to you in relief when they see that you are awake: ‘Help!’ they say. ’Tell us how this thing works!’
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.