- 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
Look on the bright side: the power of applied optimism
Somewhere in the 20th century, at the beginning of my career, I worked with a project manager on several projects. After a while, they told me why they liked to have me on their team.
I waited for them to tell me that it was due to my technical brilliance, my architectural insight, or my all-round charm and charisma. Instead, they told me that it was because I was an optimist, and that I was quite vocal about my optimism.
That gave me an immediate lesson in self-awareness: that the attributes that people value you for are not always those that you value in yourself. I would much rather have been known as the technical wizard than as the person who says, ‘Don’t worry, everything will probably be alright’. Especially as, on most IT projects, such optimism is often seen as a sign of naivety and inexperience.
Three leadership lessons (in theory)
I have learnt most about leadership from people and practice: from working for and observing people who are good leaders (as well as some bad leaders) and attempting to do more (or less) of what they do.
Most large enterprises attempt to supplement or accelerate this practical experience with theory: with leadership frameworks, principles and objectives which attempt to express what a good leader should be. These theoretical constructs exist in companies of all shapes and sizes: start-ups, global giants, banks, tech companies and consulting firms. They are usually well-intentioned, sometimes banal, frequently obvious - and generally less useful than what can be learned from seeing leaders lead.
How augmented is your reality?
In the Battlestar Galactica reboot series, the Cylon character Brother Cavil laments that, when he saw a supernova, ‘you know how I perceived one of the most glorious events in the universe? With these ridiculous gelatinous orbs in my skull! With eyes designed to perceive only a tiny fraction of the EM spectrum. With ears designed only to hear vibrations in the air . . .’ He goes on to demand, ‘I want to see gamma rays! I want to hear X-rays! And I want to - I want to smell dark matter!’ In the story, Cavil is a synthetic being but, rather than the gleaming robot form of the Cylons from the original film and TV series, he inhabits an organic human body, subject to humanity’s frailties and constraints.
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.’
There’s plenty of room on the LILO
What are LLMs good for? Everything, if you believe marketing announcements and press releases. Very little, if you believe the most sceptical of sceptics. It sometimes seems that we are still waiting for the crowning innovation, the killer app that will secure the place of LLMs in our enterprise – or the deflating moment when we realise that our expectations cannot be met.
While we are waiting for that moment, I think there is plenty for us to do by putting LLMs to work in relatively mundane contexts. What are they good for? There’s a clue in the name: Large Language Models are good at language, something which traditional computing has been notoriously bad at for most of its existence.
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.
Haunted legacy: a Halloween code story
It was 17:55 on the 31st October. Five minutes before the programmer’s shift ended and the night shift took over. The time when you hope that no new bugs will be reported and no new tickets will be raised.
Ping!
The ticketing system sounded an alert, and the notification bubble popped back into existence, a bright little ‘1’ in the middle of its red circle.
Return of the spec
How much thinking do you need to do before you start coding?
When I got my first professional programming job, back in the late 1980s, the answer seemed to be all the thinking. We were encouraged - no, obliged - to use a method known as Structured Systems Analysis and Design Method, or SSADM, developed by the UK government. It was the very definition of a Big Upfront Design method, where you had to write multiple layers of specifications, accompanied by a whole array of models which described data structures, data flows and the lift history of data items (it was a very data-oriented method), before you even thought about writing a line of code.
How hard can it be? The power of optimism and naivety.
‘ . . . and now I couldn’t do it because I could see right off there’s no way you could do this. But at that time, we lacked the benefits of age and experience.’ (Ed Roberts, creator of the Altair 8800, the first home computer.)
‘I was so nervous, I felt this is just not going to work - and it worked!’ (Steve Allen, co-founder of Microsoft, on running BASIC on the Altair 8800 for the first time.)
‘We didn’t know what we were doing.’ (Steve Jobs, co-founder of Apple, on creating the Apple I.)
‘How hard can it be?’ What do you think when you hear those words?
Three sentences that I say too often - and will keep on saying
The longer I spend in leadership roles, the more often I find myself saying the same things over and over again. I expect that part of this is due to intellectual laziness – it’s easier to recycle the same thoughts than to have new thoughts. But part of it is because, over the years, I have found leadership principles that work for me, and words which express them concisely.
There are three things in particular which I say a lot, which my team sometimes tells me that I say too much. None of them are original – they are all ideas which I have learnt from others. They are . . .
A moment in the project plan; a lifetime in the codebase
Software can be a source of regret as well as value. It is a common experience to find yourself looking at code and wondering what fool could possibly have written it, only to read the comments and find out that it was you.
The passage from choice to regret is often clear to developers, despite their faulty memories. You knew what you were doing when you made those decisions – and that you (or someone else) would pay for them in the future.
However, this path is not so clear to other stakeholders and non-technical decision makers – and their choices are often the ones that create the most regret.
Welcome to the age of the puppeteer octopus
What will software development teams look like in the age of AI agents? Will they look much the same as today, with the productivity of each team member incrementally enhanced? Will they be hybrid constructs, comprising human members and AI members? Or will there be no teams, just networks of AI agents talking to each other in the absence of human beings?
As we learn more about the potential and limitations of the current form of AI, I become increasingly convinced that we are entering the age of the puppeteer octopus.