- 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
- philosophy
- physics
- platforms
- prediction
- process
- procurement
- programming
- quantum
- reliability
- resilience
- risk
- robotics
- science
- science fiction
- security
- shadow IT
- space
- standards
- strategy
- talent
- teams
- technical debt
- technology advocacy
- testing
- thinking
- transformation
- TV
- virtues
- vision
- writing
Building the leadership team: more than a seat at the table
How inclusive is your leadership team? Hopefully it is inclusive in all the dimensions of diversity, but do you actually include all of your leaders as genuine parts of the team? Or do you think of some parts of your leadership team as ‘core business’ and other parts of your leadership team as ‘support functions’?
Regarding your team in this way creates an implicit hierarchy of leadership positions, even if all leaders enjoy similar grades and reward packages. Metaphorically, the CEO, or head of the business division sits at the head of the leadership table. The people who run revenue generating business divisions are clustered close by. The CFO may sit at the leader’s right hand, depending on the financial position of the organisation. But the head of HR is probably further down the table, while the head of IT is down the corridor fixing the printer, and the head of procurement is out at the shops, haggling over prices.
Learning the fundamentals: beyond the IT slot machine
Business executives often experience their IT department as a slot machine: something that consumes money, occasionally gives a payout, and whose inner workings are opaque and inscrutable.
Sure, sometimes the slot machine gets new lights and buzzers which claim to give an idea of what it is going to do (project plans, progress reports and dashboards), and sometimes it gets new buttons which make players feel as if they are in control (steering committees, governance processes and change boards). But the machine still seems to keep on doing the same old random things, as if the lights, buzzers and buttons weren’t actually connected to anything.
A suggested New Year’s resolution: be more curious
When I was growing up, my Dad and my uncles were always working on cars and motorbikes. This was partly through need: they didn’t have much money and they had to travel for work, studies and family life, so fixing a car using spare parts, ingenuity and improvisation was an essential skill. They also enjoyed it: it was as much of a hobby as a necessity.
It was not a practice I ever acquired the skill or the appetite for. I was much more interested in reading books than getting my hands covered in grease and oil. I enjoyed spending time with my Dad and Uncles as they struggled to fit strange shaped pieces of metal into strange shaped spaces, and as they scoured scrap yards to find an old car with the right part. But I never really understood what they were doing.
This Christmas, give yourself the gift of knowing that your work isn’t boring
‘Sorry, this is the boring bit.’
When I hear those words, my heart sinks almost as much as it used to when I heard someone declare that they were not technical. In the field of enterprise technology, they normally mean that the speaker is about to attempt an explanation of technical detail to an audience which includes non-technical people.
Perhaps they are going to explain to a product manager why the system built for a hundred users can’t scale to a million without extra infrastructure. Or why it’s not a good idea to put a system which holds customer’s personal details into production without security testing. Or why, while it might be tempting to make the chat interface available to every user, someone has to pay for all those tokens.
Don’t settle for horses when you could have dragons
Sometimes, when we are talking about technology, we quote Henry Ford, who said, ‘If I had asked people what they wanted, they would have asked for a faster horse.’
Except that Henry Ford never said these words. They were first associated with him in 1999, when an article by John McNeece suggested that, ‘There is a problem trying to figure out what people want by canvassing them. I mean, if Henry Ford canvassed people on whether or not he should build a motor car, they’d probably tell him what they really wanted was a faster horse.’
Learn to fail fast? Technologists fail all the time
From time to time, organisations attempt to learn new ways of working. They attempt to become digital or agile or data-driven or innovative. These attempts come with some familiar ideas: that we should execute through cross-functional teams who are empowered to experiment. One of these ideas is that we should not be scared of failure, and that we should learn to fail fast.
These attempts sometimes elicit eye rolls from the technology teams, especially the idea that we should embrace failure. This is not because these ideas are invalid: in fact, they are welcome to technology teams, and reflect their preferred ways of working. However, technologists have a different relationship with failure than non-technologists.
Embrace the low-coders and the no-coders (and perhaps even the GPTers)
In the early 1950s, there was a problem with programming. Digital computers offered the promise of automation and innovation: the press was full of reports about the wonders of ‘electronic brains’. But it had become apparent that just having computers was not enough: to do useful work, they had to be programmed, and programming turned out to be hard.
It’s important to remember what programming meant in those early days. It did not mean opening up an IDE: there were no IDEs, there were no text editors, there weren’t even any screens. It did not mean importing libraries, or entering commands in a language which looked like English. It meant breaking down every problem into mathematics, and then breaking the maths down into basic arithmetic and atomic logic. The primary productivity innovation was the creation of assembly languages: symbols and mnemonics to make it easier to shuttle numbers in and out of memory and perform operations on them - but even these languages were only one step away from the physical hardware.
Respect before beanbags
I have worked in some strange offices in my career. At a start up, I spent six months in a cramped office above a meat market, where arriving in the morning meant dodging large men in blood smeared coats carrying sides of beef. While working for a large UK bank, which had run out of space in its premises, I spent time in a business continuity centre, surrounded by banks of anonymous desks stretching away into the distance, waiting to be filled in the event of a disaster. As part of a confidential corporate restructuring project, I worked in an empty office scheduled for decommissioning and demolition, hoping that the security systems would keep working for long enough to let the team out in the evening.
And, because I have spent my career in enterprise technology, I have also worked in many environments which look as if they have been outfitted from the ‘digital’ section of the IKEA catalogue, full of bright colours, breakout areas, ping pong tables, expensive chairs - and, of course, bean bags.
Is your frontend fixation robbing your sponsors of agency and accountability?
Text scrolls across the screen. Lights flash and patterns whirl. Images of faces flicker past, overlaid with lines and symbols. The frantic activity slows and settles. One face remains. PERFECT MATCH.
I was watching yet another new police procedural drama. And I was having the same reaction that I always have when they show the user interface for the big computer system that takes three pieces of data and a blurry image, and finds one suspect amongst millions. It doesn’t work that way.
I’m not an expert in police systems or forensic systems, but I know that anyone building any systems has limited time and resources, and they avoid spending those resources on things that aren't necessary. And a user interface that attempts to show all the inner workings of the system isn’t necessary: if you’re lucky, you’ll get a progress bar, a buffering symbol or a spinning ball.
Remember to look down
I had two astonishing experiences while travelling recently.
First, I got on a plane in one country and, some time later, stepped out in another country.
Second, I tapped my phone against the reader on the local metro system and paid for my fare, even though my bank was thousands of miles away.
It might seem that neither of those things are astonishing, but I think that fact is astonishing in itself. It is remarkable how quickly technological miracles become a mundane part of our lives, and we cease to notice how unusual they are.
Don’t stop explaining
Have you ever been tempted to give up trying to explain how technology works? To accept that ‘it’s not about the technology’, that business people only care about outcomes, and to keep the technical details for the people who understand them?
If so, it is worth referring back to a piece of wisdom buried in a footnote of a book on computing from 1953: We apologise for the repetition of much of the subject matter of this chapter elsewhere in this book; it has been our experience that the layman finds it very hard to grasp and follow an account of the operation of a computer, and that he finds it helpful if the whole subject is presented to him several times, particularly if successive treatments are more and more sophisticated . . . In any event it is quite unnecessary to follow all the details of circuits and things: if the fact can be appreciated that circuits exist, and can readily be built, which will perform certain specified functions, that is all that is necessary in order to follow the rest of the book.
Three reasons to learn to code
There’s no point in learning to code: In a few years’ time, we won’t need programmers any more.
I’ve heard people say that a lot in the last couple of years. But that’s nothing new: I’ve heard people say this every year throughout a long career in technology.
On my very first day in my very first paid programming job, I was told that we wouldn’t need programmers any more, because fourth generation languages (4GLs) would enable us to express user requirements in a structured way. In that case, ‘expressing user requirements in a structured way’ turned out to mean using clumsy abstractions that needed to be supplemented with code. Thirty years later, that particular 4GL is forgotten, but we still produce billions of lines of code.