- 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 five: . . . sorry, what were you saying?
Sometimes being a technology architect is like being an 18th century French agriculturalist. No, don’t go: hear me out . . .
You may have eaten potatoes Parmentier: fried potatoes with herbs and garlic. You may not appreciate, though, the effort that Antoine-Augustin Parmentier, inventor of the dish, put into getting people like you to eat potatoes.
Parmentier was introduced to the potato as a prisoner of war in Prussia, and came to believe in them as a reliable food source at a time of frequent crop failures, famine and shortages. However, he faced extraordinary cultural and legal resistance from his countrymen. Potatoes were considered to be fit for animal feed only, were believed to cause leprosy in humans, and were even banned from cultivation from 1748.
How do you spot a high performing technology architect? Look for head swivels, echoes and low batteries
Whenever the members of the HSBC architecture practice come together, I get a lot of direct and difficult questions, about technology, strategy, people and many other subjects. This week at our regular Town Hall, I was asked: ‘As we approach the end of the year and think about formal performance ratings, how do you recognise a high performing architect?’
Of course, the proper answer to this question depends on the person and their context, and should be an active conversation all the time, rather than a question that gets asked and answered once a year.
However, the informal answer that there are some signals of performance which I have found to be broadly reliable. Unsurprisingly, these are based on the three attributes of an architect we seek at HSBC, and which we call Zang Jing Ge: technical excellence; communication mastery; and leadership power. These signals comprise two head swivels, some loud echoes and low batteries.
Innovation needs light bulbs . . . and lenses
Thomas Edison didn’t invent the light bulb, but he made affordable, long lasting electric light a reality. And this wasn’t just because he was struck by a sudden inspiration (a light bulb going off over his head): it was because because of disciplined experimentation coupled with a commitment to industrialisation. Most people know that Edison worked his way through thousands of designs for bulbs before patenting a bulb with a carbon filament, and that, even after filing his patent, he worked through thousands more choices for the material that would provide the carbon filament, finally settling on bamboo. It is less frequently mentioned that Edison and the workers at this lab also invented much of the equipment necessary to produce bulbs at scale, as well as the infrastructure needed to distribute power.
Edison himself said of this endeavour that, ‘There was no precedent for such a thing, and nowhere in the world could we purchase these parts. It was necessary to invent everything: dynamos, regulators, meters, switches, fuses, fixtures, underground conductors with their necessary connecting boxes, and a host of other detail parts, even down to insulating tape.’
Innovation needs light bulbs . . . and lenses
Thomas Edison didn’t invent the light bulb, but he made affordable, long lasting electric light a reality. And this wasn’t just because he was struck by a sudden inspiration (a light bulb going off over his head): it was because because of disciplined experimentation coupled with a commitment to industrialisation. Most people know that Edison worked his way through thousands of designs for bulbs before patenting a bulb with a carbon filament, and that, even after filing his patent, he worked through thousands more choices for the material that would provide the carbon filament, finally settling on bamboo. It is less frequently mentioned that Edison and the workers at this lab also invented much of the equipment necessary to produce bulbs at scale, as well as the infrastructure needed to distribute power.
Edison himself said of this endeavour that, ‘There was no precedent for such a thing, and nowhere in the world could we purchase these parts. It was necessary to invent everything: dynamos, regulators, meters, switches, fuses, fixtures, underground conductors with their necessary connecting boxes, and a host of other detail parts, even down to insulating tape.’
Architecture leadership: the clarity pump
At HSBC, technology architects aim to achieve Zang Jing Ge: technical excellence, communication mastery and leadership power.
Most of us have a pretty good idea of what technical excellence looks like. We also have some idea of what communication mastery looks like, even if many of us are not as confident in our communication skills as we are in our technical skills.
But what does it mean for a technology architect to demonstrate leadership power?
It doesn’t mean that we have thousands of people working for us, or that we control large budgets. Many architects are individual contributors, and even those in leadership positions don’t usually have large teams (my team is the smallest function in the HSBC Technology organisation). You don’t normally find the architects by tracing the organisational hierarchy upwards or by following the money.
So how do we lead?
Architecture as balance #1: elephants vs building blocks
Q: How do you eat an elephant?
A: One bite at a time.
This is an old joke, and one that technology architects are very familiar with. We spend a lot of our time dealing with big, open ended questions and big problems. How do we make this legacy system respond to digital needs? How do we integrate this acquisition and realise efficiency gains without breaking the business? How do we turn this disruptive force into a competitive advantage?
One of our most basic techniques is to break the big problem down into smaller pieces: to eat the elephant one bite at a time. We progressively refactor the legacy system into micro-services. We figure out the processes, functions, systems and data of the acquired entity and map them to the integrated state. We get to grips with the fundamentals of the disruptive force, and work out the best places to start putting it to work in our current enterprise.
Do you know your system’s hierarchy of needs?
If you’ve ever been on any kind of management course, you’ve probably encountered Maslow’s hierarchy of needs. Defined by Abraham Maslow in 1943, this theory proposes that humans needs can be broadly classified into a hierarchy, with basic physiological needs such as air, water and food at the base, and more exalted needs such as self-actualisation at the summit. (The exact order goes: physiological; safety; love and belonging; esteem; self-actualisation. Maslow also added transcendence to the top of the hierarchy in later versions.)
The idea is that humans don’t care much about higher needs if more basic needs have not yet been satisfied. In a management context, this means that there’s little point in trying to motivate someone by holding out wonderful long term career prospects (self-actualisation needs) if you’re not paying them enough to eat (physiological needs). At the same time, if you have helped people meet the basic needs of survival and safety, you shouldn’t expect them to be content: you should expect them to seek satisfaction of the higher needs.
Are you a solution architect or a problem architect?
I am often asked what the difference is between an enterprise architect and a solution architect. My answer (which I realise not everybody will agree with) is that they are different in scope but not in kind.
I believe that, whatever kind of architect you are, whatever tools, frameworks and models you use, you need to do three fundamental things: set direction (figure out where we should be going); make decisions (figure out how we get there); and solve problems (figure out how to remove obstacles encountered along the way). The main difference, therefore, between an enterprise architect and a solution architect is the scope of the direction they set, the decisions they make and the problems they solve. I’m privileged to set direction, make decisions and solve problems at an enterprise level, but I am doing something very similar to a solution architect setting direction, making decisions and solving problems for the project or team they work in. (And, of course, we should do all these things while demonstrating the characteristics of Zang Jing Ge: technical excellence; communication mastery; and leadership power.)
A technology architect’s guide to humans part four: they don’t know what you do all day (and you don’t know what they do)
Try this quick puzzle (without searching on the Internet or looking in the dictionary).
First, estimate how many words in the English language start with the letter ‘R’.
Second, estimate how many words in the English language have ‘R’ as their third letter.
The rough answer is that there are about 8,000 words that start with ‘R’ and about 25,000 that have ‘R’ in the third place. (English being the mutable thing that it is, estimates vary, but the proportions are about right).
Unless you have read the wonderful book by Daniels Kahneman, Thinking Fast and Slow, you probably got this the wrong way round. If you have read the book, you may recognise this as an example of the availability heuristic.
Buy pipelines, not products
We’ve all experienced buyer’s remorse: the experience of building up to a big important purchase like a car or a house, thinking hard about all the options, finally taking the plunge . . . and then experiencing the sinking feeling that you’ve made the wrong choice. The cars you chose not to buy seem bigger and shinier, and the houses you rejected seem lighter and roomier.
Psychologists have researched this phenomenon and some suggest that it might be to do with the sudden shift from possibility to reality: when we still making our minds up, we have nothing but possibility ahead of us, and focus on the positive aspects of each of our choices; when have made our decision and made our purchase, we have nothing but reality, and have to deal with all the negatives and compromise of what we have bought.
Buyer’s remorse is particularly strong when buying enterprise software products. Our decision cycle can be long: we often construct detailed evaluation criteria based on our requirements and standards, conduct paper based and technical reviews, run POCs and bake-offs, take reference calls and read research by analysts.
Don’t turn architectural thinking into a golden hammer
You’ve already heard of the golden hammer anti-pattern: the idea has been around in software engineering since at least 1998.
It actually goes back much further than that: in 1966, Abraham Maslow (the inventor of the famous hierarchy of needs) wrote that, ‘I suppose it is tempting, if the only tool you have is a hammer, to treat everything as if it were a nail.’ Before Maslow, in 1964, Abraham Kaplan put it even more vividly: ‘I call it the law of the instrument, and it may be formulated as follows: Give a small boy a hammer, and he will find that everything he encounters needs pounding.’ And before both of them, an article written in 1868 described the phenomenon in a way which is even more recognisable: ‘Give a boy a hammer and chisel; show him how to use them; at once he begins to hack the doorposts, to take off the corners of shutter and window frames, until you teach him a better use for them, and how to keep his activity within bounds.’
Turn conflict into work with TATWAO and TITWTBD
In the mid-19th century James Prescott Joule proposed the theory that different types of energy could be converted to one another: specifically, that heat could be converted to work, defined in terms of mechanical motion. This idea was not well received at first: the dominant theory was that heat was a type of fluid (caloric), which could not be created, destroyed or converted. However, Joule was persistent (and right): his theory prevailed, and the SI unit of work, the joule, is named after him.
Technology architects should recognise Joule’s theory. A big part of our job is to convert metaphorical heat, in the form of conflict, confusion and disagreement, into work.
One of the challenges Joule needed to overcome to prove his theory was to create tools precise enough to measure small changes in temperature and motion. Just like Joule, technology architects need their own tools and methods. Without them we, like most other people, often struggle to cope with conflict. Even though we may encounter it every day, we don’t always enjoy the experience of people disagreeing loudly and energetically, and find it hard to get those people to move from emotional to rational discourse.