- 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
- partnership
- philosophy
- physics
- platforms
- prediction
- process
- procurement
- programming
- quantum
- reliability
- resilience
- risk
- science
- science fiction
- security
- shadow IT
- space
- standards
- strategy
- teaching
- teams
- technical debt
- technology advocacy
- testing
- thinking
- transformation
- TV
- virtues
- vision
- writing
Warning: philosophers at work
I’ve bumped into a couple of conversations about philosophy this week. The first was in the Economist, in an article which claimed that philosophy graduates may have a better chance of getting hired then computer science graduates, especially by AI companies. It’s not clear whether those philosophy graduates are expected to teach the models, coach the executives, or advise the developers, but it’s nice that they have jobs.
On the face of it, I should feel positive about this development. For the last ten years, since AI (in its pre-generative, pre-transformer incarnation) started to be used in the companies I was working for, especially in data-rich decision making use cases, such as fraud and financial crime detection and customer needs analysis, I have believed that AI ethics was an urgent problem.
What was I thinking?
A few months ago, I decided to set up this blog site to hold all of the articles I have published on LinkedIn, whether in the A Lot to Learn newsletter or standalone articles from before LinkedIn used newsletters.
That might seem like a self-indulgent exercise, but I thought, first, that it might be useful, and, second, that, if it was useful, I might need a content lifeboat. Unfortunately, social media platforms tend to decay, and I anticipated that there might come a point in the future where I didn’t want to be on this platform any more. (I won’t comment in depth here about the quality of LinkedIn, other than to say that I have a mental threshold for the number of toxic, divisive posts I’m prepared to see, and, sadly, the content here increasingly approaches that threshold.)
Whatever the motivation, I found the process of transferring articles across to the new site interesting. I kept thinking that this is exactly the sort of busywork that I should be using AI to help with, but found that I enjoyed the process of reviewing what I had previously written and trying to figure out what I thought about it.
Failing fast is fun until you fail at scale
Finding bugs in your code is like being betrayed by your own brain.
Sometimes the betrayal is blunt and obvious. The system generates errors or crashes outright. When you look at the code, you realise that you have mis-spelt a variable name (again), or left out punctuation (again), or called the wrong function (again).
Sometimes the betrayal is subtle and insidious. The system appears to be working properly, until you realise that the data in the database is drifting away from reality. When you look at the code, it looks fine, until you wrap your mind around the logic and discover that it is decidedly wonky. And this is logic that you created.
Rethinking phase three: your AI adoption programme is stalled, but your organisation is adopting AI anyway
I used to tell a story about AI adoption which went something like this . . .
AI adoption in traditional organisations has taken place in three phases.
In phase one, prior to the public release of ChatGPT, AI was a specialist pursuit for specialist people, solving specialist problems with specialist datasets. AI was used within banks to detect fraud and financial crime, or in retail to manage stock levels and distribution. But it was not knowingly used by most people most of the time.
After the release of ChatGPT, AI was available to anybody who could frame an English sentence and type it into a browser. It seemed to become a general purpose technology which could be applied to any business process which needed to handle language or make decisions.
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.
Embrace *all* the fundamentals, of software, of models - and of humans
I sometimes try to persuade business leaders that they should get to grips with the fundamentals of the technology they depend on. This often manifests as an exhortation to learn to code, not because I think they will be great coders (although they might be) or because we need more coders (although we do), but because engaging with the practical reality of building and running systems is the best antidote to the confusion, bewilderment and mystification that surrounds technology. And because they might make better choices about technology partnerships, investment, organisation, sourcing and strategy if they knew more about how it all worked.
For most of my career, this advice has been focused on traditional software: procedural code, written line by line by humans. However, as enterprises are attempting to figure out how to make effective use of AI, I think it is necessary for leaders to get to grips with the fundamentals of three types of work that goes on in their organisations: that carried out by software, that carried out by models, and that carried out by humans. I regularly see people confusing the characteristics of these three types of work, for example, claiming that an AI model is ‘like an intern’, or that there is no more need for a code base of software because AI will either make all the necessary decisions or generate all of the necessary code on demand.
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.
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.