- 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
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.
A technology architect’s guide to humans part three: difficult meetings will come to an end, respect will last much longer
Humans have a strange attitude to meetings. They claim to hate them, but spend a lot of time attending them.
Meetings are strange too. They are supposed to be tools for effective decision making. But, because they are made up of humans, they are also full of feelings: fear, doubt, pride, hostility, defensiveness and the rest.
At their best, great meetings can draw out these feelings, precipitate productive conflict (conflict is not always bad) and use them to help make good decisions. However, great meetings like that depend on a lot of conscious teamwork, some external coaching, and a team which is highly mature and comfortable with itself. Most teams and most meetings are not like that. As a result, they often attempt to take decisions in an environment which is not calibrated for good decision making.
The biggest step is from zero to one
This week I visited our Griffin House office in Sheffield for the last time, before we complete the move to our fantastic new Grosvenor House office a short distance away. The place was part way through packing. Amongst the crates and unplugged machinery, I discovered a print of an article which I guess is from the early 1980s, entitled ‘Into the computer age’and subtitled, ‘Hard on the heels of the Bank’s mechanisation programme came the first commercially viable computers, big enough to fill a room and as mysterious as the switches and dials of Flash Gordon’s space rocket.’
The article lovingly described the purchase of HSBC’s first ever computer in 1961, the English Electric KDP10 (which it turns out, sadly, was not actually a British computer, but a rebadged RCA501 from the USA - computer historians feel free to correct me in the comments), the selection and training of the ‘Magnificent Seven’, the first members of the nascent IT department, and the system of collecting paper tape from machines in branches and shipping them to the computer to be processed.
Design Agile bridges to the future
In 1960, Geoffrey Anthony Jellicoe unveiled his plans for Motopia: a city of the future in which cars drove on the tops of buildings, and pedestrians were transported by moving walkways at street level. Freed from the need to dedicate land to roads, Motopia would be a city of parks and trees. Unsurprisingly, Motopia was never built, and it’s possible that it was never intended to be built.
Technology architects in large enterprises sometimes look like Jellicoe presenting his grand ideas, and often feel like Jellicoe when those grand ideas are never realised. We paint pictures of the future based on exciting new technology, while others wonder whether that future is possible, and whether it is somewhere they would actually want to live (or whether cars would fall on their heads).
In an earlier blog post I said that if people don’t understand architects, then it is our fault, not theirs. This is just as true of strategic visions as it is of day to day design decisions: no-one is obliged to understand us or back us if we can’t explain ourselves, and if we can’t make it clear how we get from here to there.
Sometimes it’s good to feel stupid
There’s a video circulating on the Internet which claims to show a fast way to peel garlic. The poster of the video simply sticks a knife into each garlic clove while its still attached to the bulb, and levers it straight out of its papery casing. Each clove takes less than a second to peel.
It’s not clear whether the technique is real, or whether there is some trickery involved, but it’s hard to watch it without thinking: ‘If this is right, I’ve been stupid. I’ve been peeling garlic the wrong way all my life.’
If you’re a technology architect in a large enterprise, this is probably a familiar feeling. We try to cover a broad field which changes every day, and it’s impossible to know everything, even if people often expect us to. Often, our value lies not in knowing everything, but in knowing when to turn to others for help. And the best type of help is that which doesn’t just address an immediate problem, but changes the way we think about the problem entirely. It’s the type of help which makes us think, ‘I’ve been stupid.’
A technology architect’s guide to humans part two: it’s not them, it’s you
Nobody believed Cassandra, but she had a good excuse.
Cassandra was a figure in Greek mythology. When she spurned the advances of the god Apollo, he gave her the gift of prophecy, but also inflicted the curse that no-one would believe her predictions. Depending on which versions of the myth you read, if people had paid attention to Cassandra, then Odysseus could have avoided the long wanderings of the Odyssey, the Trojans would not have taken the horse into their city, and Paris would not have abducted Helen in the first place, avoiding the whole Trojan war.
All technology architects feel like Cassandra at least some of the time.
Cowboys vs dinosaurs: peace through perspective
When I was growing up, cowboys fought dinosaurs.
This was in the distant past, before streaming, before cable and even before VHS, in the days when entertainment meant Sunday afternoon films round my grandparents’ house, on the big telly which took forever to warm up and which made everyone look orange.
In those days, even though there were only three channels to fill, the schedule was full of repeats, and we seemed to see the same films over and over again. In particular, I am sure that I saw the film Valley of Gwangi several times.
This film is a bit of an oddity. My grandfather and I watched plenty of Westerns together, but this is the only one where members of a traveling show enter a hidden valley to capture dinosaurs and put them on display. It doesn’t end well.