- agents
- AI
- ambiguity
- architecture
- augmented reality
- books
- bureaucracy
- career
- change
- Christmas
- cloud
- collaboration
- communication
- compliance
- corporate life
- data
- decisions
- delivery
- devops
- disagreement
- end user tools
- ethics
- failure
- fear
- fundamentals
- government
- halloween
- history
- humans
- hype
- identity
- inclusion
- infrastructure
- innovation
- language
- leadership
- learning
- legacy
- management
- measurement
- mental health
- money
- networking
- New Year
- operations
- philosophy
- physics
- platforms
- prediction
- privacy
- process
- procurement
- products
- programming
- quantum
- reliability
- resilience
- risk
- science fiction
- security
- shadow IT
- space
- strategy
- talent
- teaching
- teams
- technical debt
- technology advocacy
- testing
- thinking
- transformation
- TV
- virtues
- vision
- writing
The software paradox: it’s rational to make plans; it’s irrational to expect them to work
Software projects suffer from a paradox. They are typically expensive endeavours which are of great importance to the organisation which is executing them. It is rational to want to be assured that they will be successful, that they will not cost more than the organisation can afford, and that they will not take longer than the organisation can wait. At the same time, they are fundamentally unpredictable. Any software project worth doing involves work which no-one has ever done before, creating new logic and new capabilities, and integrating existing components in complicated and interesting ways. This is difficult work which involves intellectual challenge and problem solving. Things which look hard often turn out to be easy, while (rather more frequently) things which look easy turn out to be hard.
Keep thinking; it’s worth the trouble
The term ‘cognitive offloading’ precedes the current generation of AI products. It was coined in a paper written in 2016 by Evan Risko and Sam Gilbert. In that paper, the term referred to the externalisation of reasoning and memory, including practices as advanced as using Internet search engines to find answers to questions, or as basic as tying knots in handkerchiefs to remind yourself that you have something to remember. It suggested that, although the practice has been around as long as humans have been able to manipulate their environment, offloading cognition could impair the ability to reason and remember, or be responsible for more subtle effects, such as undermining people’s confidence in their own thought and memory. The paper concluded that more research was required, particularly into metacognition: the practice of thinking about thinking.
Ten years later, the need for that research seems even more pressing. We have more tools on which to offload our cognition, and more people who are using them to do just that. Sometimes this offloading is explicit and deliberate, such as when somebody asks an LLM-based product to produce a business strategy or write an essay. But sometimes it is implicit and incidental, such as when somebody asks such a product to draft an email or summarise a document for them. They might think that they are merely offloading the work of typing or scanning mundane verbiage, but their choice means that there are thoughts that they will not think.
What is 54?
I didn’t set out to create a puzzle: I set out to create a way of recognising talented technical people.
When I was working for the UK Government, I saw that its Digital and Data profession suffered from the same problem as every other technical group working in a traditional organisation:
The organisation recruits talented technical people.
The talented technical people do good work.
People who do good work expect to advance their careers.
Career advancement means taking on management responsibility.
Talented technical people are not always talented managers.
EITHER talented technical people become mediocre managers
OR talented technical people seek career advancement elsewhere
OR (sometimes) they combine management and technical success.
Passkeys show why standards need explaining
I got a new phone recently, with mixed emotions. Delight: it’s a shiny new gadget! Scepticism: is it really that much better than my last phone was when that was new? Regret: could I have eked my old phone out for a bit longer, even though it was getting steadily slower and more full?
And, of course, dread: can I still access all the apps that I need to access? How many of my credentials have transferred seamlessly? How many apps just need a simple re-validation? And how many will trap me in a loop of email resets, forgotten user ids, and notifications sent to devices which I don’t even own any more?
Authentication has been a mess for years. Passwords provide flimsy protection, and companies keep trying to make them stronger by making them more complex: for example, sixteen characters, including numbers and special characters, leading to the absolutely unbreakable ‘Passwordpassword123!’, written on a PostIt note and stuck to the monitor. Password managers and strong password suggestions make them marginally better, at the cost of making password managers a target for attack. Two factor authentication is stronger still, if only providers could agree on what extra factors to use and how to implement them: I currently have four different authenticators on my phone.
Living with uncertainty: be ready to be wrong
Are you ready to be wrong?
Let’s imagine that you have followed the first seven steps in this article about becoming an enterprise AI leader (and maybe even attended the course to be launched later this year). You have learnt the fundamentals of computing, examined and adapted your leadership style, developed your leadership team, figured out your values and ways to stick to them, built a robust supply chain, re-imagined your enterprise and found a practical route to implementation.
And then everything changes. A leading AI company releases a whole new category of model which promises capabilities beyond anything you have seen before. Or the same company burns through its investors’ money, fails to raise new funds and the models you rely on vanish from the market. Or powerful, highly optimised new Open Source models are released which collapse the price of training and inference. Or companies come under pressure to recoup their capital investments and prices shoot up.
Managing the change: don’t turn your experts into novices
Technology people often forget the human side of change management. It is hard enough to design and build systems, integrate them, migrate data, configure infrastructure, and get everything working and stable. Technology can be erratic and unpredictable: who has time for even more erratic and unpredictable humans? Perhaps if we tack a training course and a couple of videos on the end of the systems rollout, we can achieve a bulk update of the human config files.
The error of thinking this way was demonstrated to me when I was working on a large scale merger between two banks. The technology choice was easy: we picked the systems of one bank, and then started planning how to migrate data from one set of systems to the other. Our designs were filled with data extracts and transforms, temporary integration layers, reconciliation and testing suites. We thought that our hardest problem was fitting all the migration work into a constrained time slot.
Imagining the enterprise: look through both lenses of your AI goggles
You’re looking at the problem wrong.
This is one of the perennial laments of technologists, particularly enterprise architects, when they work with leaders who claim to want to transform their business. Somebody senior, such as the Chief Operating Officer, or the person who runs all of the call centres, will invite the technologists in, and say that they want to fundamentally reimagine the way their business works. Yet, when the technologists start to produce designs and make proposals, it turns out that they have a rather different understanding of what fundamental means.
Leading with integrity: ethics does not equal compliance
This is the most important programme in the world because the regulator says so.
It’s a regular ritual in any large corporation: reviewing the proposed change portfolio for the coming year. The list of proposals is always longer than the company can afford, and, even if it could afford to do everything, there are only so many things it can do. Naturally, everyone proposing a change programme tries to make it sound as if it is more vital than all of the others: it is the one thing that will cut costs, boost revenue or protect the organisation from existential threats.
In regulated industries, such as finance, utilities and healthcare, one of the strongest justifications offered is compliance. The idea is that, if the change is required by law or regulation, the company is obliged to do it: there is no choice.
Tackling the AI market: more than just a product
My Dad used to enjoy buying things. Or, to be more accurate, he enjoyed the process of getting ready to buy things.
If we needed a new washing machine, or a microwave, or, best of all, a car, he would break out his graph paper and pencil, and a big pile of Which? magazines and other literature. He would make a list of criteria, and he would go through all of the candidate products, scoring them out of ten, adding the scores up, and adjusting them if he wasn’t convinced by the answer. And then we would tour the shops, interrogating the sales staff to a level of detail they were not always prepared for.
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.
Changing your behaviour: getting out of Boss Mode
Two of the most difficult transitions I have had to make in my career have been due to changes in my perception of what it means to be a leader.
The first came when I moved from a management role to a leadership role. This transition is rarely recognised and often poorly understood, especially in specialist fields such as technology. Notoriously, great technologists are frequently left to flounder when they are promoted to become managers. It’s not surprising that there is even less support when they cross the fuzzy boundary from management to leadership.
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.