- 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
When is it reasonable for technology architects to go to unreasonable lengths?
Teller, the silent half of the duo of magicians, Penn and Teller, is not always silent: he’s given interviews and written articles on the theory, practice and psychology of magic.
Any insight into how people perceive and believe can be helpful to technology architects, but I think that one principle shared in this article is of particular use: make the secret a lot more trouble than the trick is worth.
The idea is that every trick has a public side (what the audience sees) and a secret side (how the effect is achieved), and that most people will assume that an apparently simple effect (the magician identifies the right card) is achieved by a similarly simple cause, and, if they cannot figure out that cause, will be mystified and entertained.
Learn sense making and storytelling from the world around you
My wife and I paid a (socially distanced and suitably masked) visit to the Tower of London last week. It was a strange experience to be visiting this site of so many historical events whilst in the middle of our own historical event, and even stranger because it was so quiet: visitor numbers are currently strictly limited.
The quiet gave us an opportunity to spend a little time longer with the exhibits, and to appreciate them in more detail. The one that stayed in my memory was an exhibit in the Bloody Tower which told the story of the princes in the Tower. (If you’re not familiar with this story, then you can learn more on Wikipedia or, if you’re in London, plan a visit when conditions permit.)
This exhibit held my attention because it told the story in two very different ways.
Take a trip in your architect’s time machine
I have claimed in the past that technology architects have superpowers, particularly x-ray vision and, even more importantly, the ability to figure out how things work. But if you are lucky enough to work with a technology architect, you should make the most of another one of their special abilities: time travel.
You have probably already realised that architects can travel to the future. After all, they spend a lot of their time talking about the fantastic advantages that new technology will bring us, and how great our lives will be one we have built their vision. They also spend a lot of their time giving us dire predictions of how things will be if we make the wrong choices in the present. They may even talk about future state architectures (although this is not a phrase I am a fan of - I will explain more in an upcoming article but will just say for now that attempting to define a single fixed ‘state’ for anything which changes as rapidly as technology architecture feels like a mistake).
Make Feedback a Batch Process
How do technology architects know that we are doing a good job? We are often working as the only architect on the team, making decisions which others may not agree with, making sense of complex and ambiguous topics, and trying to set a direction which others can follow. How can we tell that this all adds up to something useful?
One way to find out is to ask for feedback. We do better when people tell us freely why they disagree with us, whether we are successful in making ourselves understood, and whether the paths we lay out lead to the right place.
If you’re a technology architect, you can find something interesting in every job
Don’t believe them when they tell you you’ve got the boring project.
I remember when I had just started a new job as an architect, and was given the project that nobody else wanted to work on: to replace the scanning solutions in the correspondence handling centre. When I was given the project, I was told that it was a boring job: bulk scanners were not seen as cutting edge technology, and paper correspondence felt very old fashioned. It was a long way from digital customer experience.
Fortunately, as I had just joined the company, I was not in a position to do as many other architects had done, and find themselves a project that was more ugent, or at least which seemed more interesting.
So, I got in my car and drove to the correspondence handling centre, on what turned out to be the first day of a project that was not always easy, but was always interesting.
Architecture as communication: what voice do you write in?
Which voice do you use when you write about technology architecture? Do you use the voice of the relentless pedant who is determined to share every last technical detail, regardless of whether your audience understands or cares? Or do you use the voice of the patient and diligent educator, who helps people understand why they should care about these technical details? Do you use the voice of the exuberant evangelist who can’t figure out why nobody finds the topic as exciting as they do? Or do you use the voice of the grounded visionary, who paints a picture of the future which gets people excited? Do you use the voice of the weary cynic who doesn’t expect to be listened to, but wants the chance to say, ‘I told you so’? Or do you use the voice of the concerned and persistent stakeholder, whose mixture of passion, reason and commitment convinces others to listen, pay attention and act?
In the HSBC Technology Architecture team, we aim to live by the principles of Zang Jing Ge: technical excellence, leadership power and communication mastery. Each of these principles comes with its own challenges, but communication mastery can be particularly difficult, especially in written form. For everybody in the Architecture team, including me, it is a constant struggle to get thoughts from our heads into the heads of others, and, through writing, to pull off this trick of telepathy over time and space.
Help others find their voice: be generous with your attention and parsimonious with your time
Difficult questions can be the best questions: they make us stop, think and learn.
One of my colleagues recently asked me a question which was both difficult and relevant to our current strange circumstances. This person had previously sought my advice on building the confidence to speak up more frequently in meetings. This was advice I was happy to give, as it is a problem I have had to deal with myself. Many people who know me today would probably say that I talk too much rather than too little in meetings, and that I have no problems being vocal and expressing my opinion. However, it was not always this way: I used to be very shy, and it took me a long while to find my voice and my confidence. So, I had some advice to give, even if no more than sharing what had worked for me. This seemed to be of some help - although not as much help as my colleague's own courage and determination.
Then we found ourselves in our current situation of social distancing and remote working, and my colleague came up with the more difficult and interesting question. They had started to find their confidence in face to face meetings, but were finding it hard to adapt to a world in which all meetings were by video conference. They felt that they had taken a step backwards.
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!’