- 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
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.
We’re still struggling to learn forty year old lessons about cyber security
I just finished re-reading The Cuckoo’s Egg, by Clifford Stoll. It’s a classic of cyber security, telling how Stoll, as an astronomer-turned-reluctant-sysadmin, attempted to resolve a 75 cent computer billing discrepancy, only to be drawn into a story of hacking, surveillance and theft, involving the FBI, CIA and NSA.
The action in the book takes place in 1986 and 1987, so it is full of references to technology which was modern at the time, but seems quaint and old-fashioned today: 1200-baud modems, pagers and daisy wheel printers. What is striking, though, is how much of the hacking activity uses techniques which are still in use today. I won’t spoil the book for anyone who hasn’t read it, but will say that it contains examples of identity theft, credential compromise, dictionary attacks, supply chain attacks, vulnerabilities in commonly used software and privilege escalation. The pattern of behaviour would suit a cyber criminal working today: probe for assets which aren’t properly secured; gain access; take over an unused account; escalate privileges; move laterally; exfiltrate data; erase evidence. And keep on coming back and doing the same thing over and over again.
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.
How many placebos do you have in your diary?
In 1955, the researcher Henry K. Beecher published a paper called The Powerful Placebo, which described the placebo effect.
This is the phenomenon that, if you have two groups in a medical trial, and you give one group the drug being tested, and the other group a harmless substitute – a placebo – both groups will show improvement. If you want to know the true effect of the drug, you have to subtract the effect of the placebo.
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.
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.
Are you under attack from your corporate immune system?
It was supposed to protect us.
One of the most disconcerting aspects of the recent Crowdstrike incident was that the process which caused the disruption - a rapidly deployed update to a piece of endpoint protection software - was meant to prevent disruption. Rapid deployment was intended to help us respond quickly to new threats against which we would otherwise be defenceless. Low level access to the operating system was intended to enable us to detect and deal with anomalous behaviours and subtle modes of attack. Tools such as Crowdstrike are supposed to be vital parts of our immunity against deliberate attacks and accidental failure: they are not supposed to turn on us.
It might seem that incidents such as the Crowdstrike update failure are, mercifully, rare. Most of the time, we rely on our corporate immune system to help us, not to harm us.
Speed bumps in reality: overcoming failed attempts at change
‘We’ve already tried that. It didn’t work.’
How many times have you heard these words? They’re a familiar feature of change in large organisations. If you have been the leader of a change programme, or an eager consultant, or a manager inspired by the prospect of doing things differently, then these words have probably left you daunted and deflated. You knew that this was going to be difficult, but you didn’t anticipate apathy and resignation.
Before we condemn such a reaction, though, and write off the people who react this way as resistant cynics, let’s consider whether such a reaction is reasonable.
Legacy isn’t a technical problem; it’s a management problem
Imagine a world in which your car was subject to a product recall every week. Sometimes the recall notice would be gentle but firm: bring your car into the garage when it’s convenient, but don’t wait too long. At other times, the notice would be more alarming: stop what you’re doing and bring the car in NOW!
If this was the case, you’d probably change your car. But what if every car in the world was the same? If you really needed to drive, you’d build regular maintenance into your schedule. It would be irritating and inconvenient, but better than having no car at all - and much better than crashing. You’d probably get pretty good at it, and so would your garage: they’d have lots of practice.
This is the world of enterprise technology. If you run commercial software of any complexity, then you receive patches and upgrades on a regular basis, most frequently to fix security vulnerabilities. Some of these patches will be minor or advisory, but others will be critical: they address immediate danger. Fortunately, we don’t have to take our software to the garage to get the patches applied: they come to us over the Internet. But there is work required to apply them.
A mishap on Mars
On September 23rd, 1999, the Mars Climate Orbiter fired its thrusters for a manoeuvre that would bring it into a stable orbit 226 kilometres above the Martian surface. From this orbit, it would gather valuable information about weather systems on Mars, as well as acting as the communication relay for subsequent missions. 226 kilometres was a safe height, well above the 80 kilometeres at which the atmosphere would be thick enough to cause problems.
But the manoeuvre went wrong, The Orbiter dropped to an altitude of 57 kilometres, and either burnt up in the atmosphere, or skipped off and flew away from Mars altogether. Whatever happened, it was never heard from again.
The investigation found that the problem was due to a mismatch in the units used by the different systems used to calculate and control the craft’s manouevres. One system was working in pound-force seconds (an Imperial measure), while the other was working in newton-seconds (a metric measure). The ratio between these units is 4.45:1 - no wonder the craft crashed.
How do we get what we want from AI systems - and human systems?
I am sure that you have heard of the paperclip problem. Just in case you haven’t, it is the idea that, if you ask an AI system to make paperclips, then it may go on making paperclips, until the whole world is nothing but paperclips. There’s even a fun game based on this concept.
The paperclip problem illustrates the problem of setting goals for AI systems which represent what we truly want. Unlike us, AI systems do not come ready equipped with goals and desires: we have to provide them, in the form of what is often known as a reward function.
And crafting this function can be more difficult than it first appears. When I wrote some recent articles on generative AI, it was suggested that I read the book Human Compatible by Stuart Russell. It’s a great book, and triggered lots of other reading: it took me down a rabbit hole of articles and papers about optimisation, particularly a phenomenon known as specification gaming.
When is a meeting not a meeting?
Those of us who spend a lot of time in meetings often spend a lot of time complaining about meetings. We complain that they are poorly organised, that they do not lead to clear decisions, that the organisers aren’t well prepared or that the attendees haven’t done their homework. We wonder why we still go to that recurring meeting that rolls around every week although nothing ever seems to get done.
Given these feelings, it can be a good idea to be ruthless with our calendars: to get rid of those meetings which aren’t worth our time, to cut attendance for meetings which are overpopulated, to cut the duration of those meetings which drag on, and to reduce the frequency of those meetings which happen too often. When we do that, we hope to find that the meetings we keep are more effective and more efficient, and that our diaries are more free: we may even find that we have time to think.
Except . . .