- 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
- films
- fundamentals
- gaming
- government
- halloween
- history
- humans
- hype
- identity
- infrastructure
- innovation
- language
- leadership
- learning
- legacy
- management
- measurement
- mental health
- money
- networking
- New Year
- operations
- philosophy
- physics
- platforms
- prediction
- process
- procurement
- programming
- quantum
- reliability
- resilience
- risk
- science
- science fiction
- security
- shadow IT
- space
- standards
- strategy
- talent
- teams
- technical debt
- technology advocacy
- testing
- thinking
- transformation
- TV
- virtues
- vision
- writing
Performative reasoning
How many of your reasons are comforting illusions? How many of the decisions which your organisation makes are based on well-ordered reasoning, and how many are simply surrounded with the trappings of reasoning in order to make you feel better?
Organisations make a lot of decisions. What products to buy, what products to launch, who to hire, where to invest, which projects to support and which initiatives to cancel. These decisions are particularly apparent in the field of enterprise technology, where we make choices about how to design, build and operate systems, how to organise resources and how to adopt and integrate new capabilities. The need to tell machines precisely what to do seems to require precision in our own thinking.
Because these decisions seem important, we feel that we should take them seriously, and be seen to take them seriously. When we are making purchasing decisions, we construct elaborate scoring criteria, invite bids and conduct extensive evaluations. When we are planning investments, we build detailed business cases, evaluate ROI and risk factors, and construct portfolios of change. When we are running delivery programmes, we create dashboards, produce reports and run steering meetings, so that we can respond to circumstances and keep everything on track.
Good standards are like a good starting word in Wordle
What’s your starting word in Wordle?
I use STEAM. It has a good combination of common vowels and common consonants, and for some reason I find it pleasing (something to do with steam engines?). There are words which are mathematically proven to be better, but I like this one.
In case you’re one of the few people who didn’t become familiar with Wordle during the pandemic, I should explain. It’s an online game where you have six attempts to guess a five letter word, and each letter in the guess is marked green, for a correct letter in the correct place, yellow, for a correct letter in the wrong place, or grey for a letter which is not in the word at all. It’s just about hard enough to give you a sense of achievement, but easy enough that you get the right word most of the time. It also has the virtue that everyone who plays the game worldwide gets the same word every day, making it feel as if you are all playing together - you can also share your pattern of green, yellow and grey without giving the game away.
Freedom is not free: managing your cognitive and operational economies
Freedom is not free.
Let’s unpack that apparently paradoxical phrase into something a bit more unwieldy, but a little clearer.
In the context of enterprise technology, freedom of choice comes with a cognitive and operational price which we must be sure we want to pay.
The question of freedom versus control in enterprise technology has been debated with varying degrees of heat and passion for as long as the field has existed. Centralised corporate IT functions usually like control. They like to be able to manage costs and risks, to limit the complexity of their architecture and their supply chain, to strive for confidence and predictability. By contrast, development teams and product teams typically like freedom. They like to be able to pick the technologies, frameworks and ways of working which suit them best, to innovate freely, to use their skills and express their professional expertise.
Keeping the lights on
Do you have a line in your IT budget which says something like ‘keep the lights on’ or ‘keep the show on the road’, or ‘maintenance’ or ‘support’ - or even just ‘run?.
Over the years, I have put together IT budgets with at least one of these lines in. They’re a convenient way of signalling to finance people, hovering over their printouts and spreadsheets, ready to wield the red pen or press the delete key, that they’d better not strike out this item. They don’t have to understand technology to understand that, without this money, something will break. They’ll probably ask us to swallow inflation, or to trim around the edges, but they’re unlikely to cancel it altogether.
While this arrangement can be convenient (the IT department gets its money; the finance department does not have to understand technology), I do not believe that it is healthy or helpful. I believe that we would do a better job if we explained exactly what we spend this money on, why it matters, and why it gets more complex and more difficult every year.
It *is* about the technology (and all of the other stuff too)
It’s not about the technology.
Have you ever said those words? I have said them several times in my career, and heard them many more times. They are usually followed with something like . . . it’s about culture / user experience / business outcomes / customers / change management.
I think that there are good reasons to use these words, and bad reasons to use these words.
They are useful words when we are in danger of losing sight of all the other factors. When building software solutions, it is easy to get lost in the details of tools, components, services and other technical considerations. It is not unusual for technical teams to lose weeks arguing about frameworks and languages, while forgetting about the outcomes that those frameworks and languages are intended to deliver.
The technology hierarchy of needs
The theory has been criticised and challenged, but has a continuing intuitive appeal, and is often taught on management courses. If you’ve done any management or leadership training in your career, you have likely seen that pyramid many times.
I believe that we can borrow the concept of the hierarchy of needs to help us understand the answer to a related question: why do anything with enterprise technology? And, more importantly, which things matter most?
Enterprise technology is a field of continuous, strenuous activity. The digital service that you consume as an end user may look simple and elegant, but behind the scenes there will be people writing code, testing systems, managing deployments, building infrastructure, probing security, negotiating contracts, defining architecture, making decisions and so on. And there will be more people managing and leading the first set of people, gathering data, reading reports, assessing risk, allocating funding, finding resources and so on. Over time, some of this work will become automated or delegated to service providers, but the total amount of work never seems to reduce: there is always something else to do, and there is never quite enough budget or resource to go around.
Do you wish to proceed? y/n
If you play video games, particularly adventures that take many hours to complete, you may be familiar with an experience you sometimes get just before the end. The list of sidequests is dwindling and you have run all the errands for your party members. You suspect that you are nearing the conclusion of the story, when an option pops up, something like this:
Do you want to proceed? (You will not be able to return past this point.)
If you’re anything like me, when you see this option for the first time, you say no, you save your game, you check your inventory, you upgrade everything that you can upgrade, and you save your game again for good measure. And then you say yes.
If you don’t play video games, you can get the same feeling by administering a computer, even if it’s just your own laptop. Sooner or later you will get prompted to apply an upgrade, accompanied by a message something like this:
Do you wish to proceed? y/n
Embrace the glorious art of architectural procrastination
According to legend, the night before the opera Don Giovanni was due to open, it was still not finished. But Mozart was not locked in his room, desperately seeking inspiration: he was out with his friends. When they finally convinced him to go home and finish his work, he completed the opera in a few hours, so late that the orchestra was handed still-wet copies of the music as the curtain went up, and had no time for rehearsal. ‘Some notes fell under the stands,’ said Mozart, ‘but it went well.’
I don’t know how much of this story is true. There is documentary evidence: Mozart recorded the completion of the opera in his own catalogue of works the day before the first performance. But the story has the air of embellishment: we would love to believe the tale of the mercurial genius dashing off a masterwork with only moments to spare.
When evaluating startups, evaluate yourself. Will you be a good customer?
Last week, I was privileged to support the annual Female Fintech Founder competition run jointly by Google, Deutsche Bank and Atos. The competition seeks to find the most promising early stage fintech companies founded by women, and to provide the winners with support for the next stage of their success. (And to provide all the participants with advice and networking opportunities.)
At the heart of the session I attended was a great presentation by my colleague Prue MacKenzie. You can read more about that here.
I can’t improve on Prue’s advice, but the session did prompt me to think about how established companies work with new companies, and whether they always get it right. Many of the founders taking part in the competition will offer their services directly to consumers, but many will have corporates as customers or partners. Founding a company takes great courage, especially in times of great uncertainty. Whether they win the competition or not, all of the founders have already taken a greater risk than any I have ever taken in my career. I think that they deserve customers and partners who think deeply about how to work with them.
Agreement is optional; understanding is essential
Technology architecture is characterised by debate: we spend a lot of time arguing with each other. Given how much time we spend, we should ask ourselves whether we are any good at it. But being good at arguing doesn’t mean that we win all the time: in fact, winning all the time might be a sign of badness. Arguing well means that we are reliably successful at discovering the truth and making decisions - which may mean that we have to change our minds.
Some time ago I wrote that, as a technology architect, one of your jobs is to get ideas from your head into other people’s heads. I still believe that to be true, but realise that I left something very important out: it is also your job to get ideas from other people’s heads into your head. It is your job to understand the objectives, motivations, constraints and thinking of other people, and to see how these change your perspective.