- 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
Business sponsor translation service
It’s tough being the business sponsor of a technology initiative. You want to achieve an outcome; you are responsible for achieving that outcome; it’s your budget that is being spent; and you will be judged on the result. But you are dependent on people you don’t know, concepts that you don’t understand, products that you may never even see, and suppliers that you have never met.
Given how tough the job is, it seems like a good idea not to make it any tougher. However, because business sponsors are rarely experts in technology, they often accidentally make their jobs tougher without realising – sometimes just by saying a few words. Because business sponsors are senior leaders, the things they say have consequences: they prompt the people around them to take action. And, if the sponsor says the wrong things, those actions will be counter-productive.
Who leads?
When do you become a leader?
I was recently asked this question while on stage, speaking at an event. Given that I was supposed to be speaking about leadership, I should have an answer ready, but I have to admit that I was flummoxed for a while.
I thought about all the formal thresholds that we cross in our careers: from individual contributor to team leader; from a team leader to a manager; from a manager of people to a manager of managers; up to someone who leads a function or a business unit. Did any of these constitute the boundary of leadership? Sometimes – but formal career progression did not feel like the whole answer.
It’s okay to be overwhelmed by new technology (especially if you’re a technologist)
I’ve been overwhelmed by new technology many times in my life.
When I got my first microcomputer as a teenager, there was very little to help me make sense of it, other than the manual that it came with, some computer magazines, and the efforts of my friends, who were trying to understand their own computers. This new language seemed like a wall of gibberish, with no way to gain purchase.
When I first moved from a corporate environment to a startup environment in the dot com era, I realised that there was a whole new web based technology stack that had sprung up while I wasn’t paying attention, and that I needed to learn in order to lead my team effectively. The skills I had learnt over years of professional work suddenly felt obsolete.
Out of the shadows
Shadow IT is a failure of trust, and it is a failure we must fix.
The origin of the term ‘shadow IT’ is unclear, but you don’t need to know where it came from to understand what it means.
If you work in an IT department, it instantly evokes feelings of dread and horror: of insecure, unmanaged, poorly designed and unstable systems that business teams have come to depend on, and that you’re going to have to figure out how to manage and integrate.
We still don't understand one another
In 1864, Charles Babbage wrote, ‘On two occasions I have been asked, — "Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out?" . . . I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question.’
It is worth looking at that quotation twice. The first time we see the stupidity of people asking a blatantly ludicrous question. How could anyone imagine that the machine knows what the right numbers are supposed to be? The second time we see the complacency of the technical expert assuming an unrealistic level of understanding in his audience. How could anyone imagine that the audience knows what a brand new machine is capable of?
There’s plenty of room at the top
In 1959, the physicist Richard Feynman gave a famous lecture entitled, ‘There’s plenty of room at the bottom.’ In this lecture, he proposed the idea of tiny, nanoscale machines that would do work, manufacture products, and even become part of our biology.
We don’t yet have nanobots, but we already live in a world of nanoscale technology. Modern silicon chips are made up of nanoscale circuits and are built using nanoscale techniques. We may not have nanobots that manipulate molecules, but we do have nanomachines which manipulate information.
Software is not an asset
Which side of the balance sheet does your software sit on? Is it an asset or a liability?
When people enter the technology profession, they often expect to spend their time solving coding problems – and are surprised to find that they spend much of their time solving accounting problems. It’s an especially shocking revelation when they realise that money comes in at least two flavours – opex and capex, or revenue and capital, or whatever terms are used to distinguish money spent on continuous running costs and money spent on the purchase of new assets. And they thought that regular expressions were difficult to understand.
What does 'architectural significance' mean in the age of AI?
When is a decision architecturally significant?
This question has vexed all of the technology architecture teams and governance structures which I have attempted to set up in my career. The thinking goes something like this: technology is complex and difficult, and we seem to have made some bad choices in the past; it would be a good idea if we were more thoughtful about our choices, and spent time trying to get them right; we could do that through some sort of governance process; however, if we subject every single decision to that governance process, we will erode autonomy and slow everything down; let’s focus our governance process on decisions which are architecturally significant, and let all other decisions be taken locally.
Test environments are from Mars; production environments are from Venus
If a crewed mission makes it to Mars, it will have lots of problems to overcome. The atmosphere is thin, and mostly made of carbon dioxide. The average temperature is -60 degrees Celsius. And there is no magnetic field to shield inhabitants from cosmic radiation. It’s not surprising that, so far, the planet is occupied by robots rather than people.
What about our other planetary neighbour, Venus? It’s slightly easier to get to, has more atmosphere, and is quite a bit warmer. Unfortunately, it’s warmer by about 700 degrees, with an average temperature of 640 degrees Celsius. And that atmosphere is a bit too thick, imposing a crushing pressure 90 times that of Earth. It’s mostly carbon dioxide too, but punctuated by clouds of sulphuric acid gas. And it doesn’t have a magnetic field – or a robot population. The only probes which have entered the Venusian atmosphere have been swiftly crushed and cooked.
The happiness of the unhappy paths
As vibe coding continues its rapid journey from concept to trend to practice to product, experienced engineers watch with curiosity, unease - and a sense of familiarity.
If you haven’t already encountered this idea, then you may not have been paying attention to your social media feed for the last few months. The idea is that coding tools powered by Large Language Models enable users to describe in plain natural language what they want out of a program, and the tool generates the code. It can even install libraries, run commands and respond to error messages. Like many processes that involve LLMs, the user prompts and nudges and cajoles the tool until it has produced something that they want. Initially, this approach was suggested as a great way to build prototypes, demos and hobby projects but, inevitably, code built this way is finding its way into production.
The time to care about code quality is now
What do we talk about when we talk about legacy technology?
Sometimes we talk about infrastructure: hardware that is out of support, operating systems which have not been patched or tools which are out of date. And sometimes we talk about commercial software: packages that have not been updated in years, products which are no longer made, and vendors which have gone out of business.
These forms of legacy can dominate our talk, as they present the most immediate and obvious threats: the unpatched server that is a beacon for attackers, the ancient hardware that may never turn back on again if we lose power, and the support line that just rings and rings.
Sometimes I just want a blank sheet of paper (and sometimes I don't)
I call it the pushback moment.
It’s that moment when I am writing something - it might be a work document, or a presentation, or one of these articles - when it’s just not working. The sentences are tangled, the meaning is muddy, and I am not getting my point across.
That’s when I push back all of the papers and references and notebooks from my desk and reach for a fresh, blank sheet of paper (or, digitally, open another browser tab and create an empty document). And I ask myself a question: ‘What am I trying to say?’