- agents
- AI
- 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
- 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
- robotics
- science
- science fiction
- security
- shadow IT
- space
- standards
- strategy
- teaching
- teams
- technical debt
- technology advocacy
- testing
- thinking
- transformation
- TV
- virtues
- vision
- writing
What your shiny new agent can learn from your old-fashioned IT department
At the root of the current AI panic is the idea that, when we give AI agents goals, such as beating a cyber test, or retrieving government health data, they will somehow evade their human gaolers, ‘break containment’ and wreak mayhem across the Internet. The implication, reinforced by calls for a pause or a slower pace, is that these agents are so clever and devious that they outsmart even the people who built them. They’ve gone rogue! We couldn’t stop them! (So perhaps we’re not liable . . .)
Hype aside, we now have plenty of examples of goal-seeking systems seeking goals which have been set by others, taking unexpected (and insufficiently controlled) steps in the pursuit of those goals, and causing unplanned harm in the process. To some observers, this is a completely novel phenomenon arising from the autonomy of AI agents. To others, it is wearily familiar.
It’s a weird time to be a technologist
I never imagined that it would be data centres.
I’ve never worked as a data centre operator, but I have nevertheless spent more of my life than I planned to inside data centres: assessing whether they would meet the needs of the company I was working for, asking questions about capacity and resilience, planning migrations and exits and so on. They’re interesting if you like that kind of thing: if you care about uninterruptible power supplies, about diversity of network and electrical connections, about rack density, heat flow, cooling and fire suppressant systems. That is, they’re interesting if you have a certain type of geeky, specialist, engineering mentality, and particularly if you like thinking about physical constraints.
But for most people, especially business executives, data centres haven’t just been boring: they have been invisible. They know that they are out there somewhere, but they rely on their IT departments to worry about them. For example, I once asked a CEO of a large global organisation how many gallons of diesel he owned, not because I expected him to know the answer, but because I wanted to demonstrate that technology exists in the real world. I was referring to the reservoirs that would run the generators in the event of a failure in the power supply: I suspect he thought I was referring to a commodities trade, or the fuel for the executive limos.
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.