- 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
Twelve firsts: lessons learnt from a few decades in technology
What have you learnt in your career?
I was privileged to be asked this question by some of my colleagues in the Central Digital and Data Office, in the hope that some of my stumbles, trips, outright failures and occasional successes would provide useful lessons. I’ve worked for about twenty organisations over more than thirty years, so there were a lot of examples to choose from, but twelve firsts stood out for me - things which shaped me when I experienced them for the first time.
The first time I used a computer was a ZX81 which one of my father’s friends had lent us. We only had it for a few days, but it taught me that if I put instructions into the machine, it would do what I told it to do. I’ve carried on putting instructions into machines, either directly or indirectly, ever since.
My first full-time job was in a lab while taking a year off before studying biology. It taught me that I was not cut out for the precision and repetition of lab work, and that maybe this field was not for me. I did like working with the computers that ran the lab equipment, though.
How do we make non-functional requirements exciting?
They’ve got that look again.
If you’re a technology architect, particularly one who designs infrastructure, then you’re used to people getting that look. Their eyes glaze over, their smile becomes fixed. They may have an air of panic. Why is this person talking to me? What’s a server? What is latency, and why are they so worried about it? What’s the quickest way out of this meeting? There’s only one sure way to dispel this look: to start talking about time and money.
Welcome to the conversation about non-functional requirements. This is the time when the technology architect tries to agree with their business sponsor (or, more usually, the business sponsor’s representative) what compromises they will make together. Because there are always compromises: if you ask someone how much downtime they can tolerate, what the response time should be, and how many users the system needs to support, the default (and not unreasonable) answers are likely to be: none, instant, and everybody. Until you explain how much it would cost and how long it would take to achieve those things.
Are we there yet? When can we stop mapping our technology architecture?
In his short story On Exactitude in Science, Jorge Luis Borges writes about a historical Empire so taken with cartography that it makes a map of itself at a 1:1 scale: so big that it covers the territory it describes. Such a map is, of course, useless, and it is allowed to decay into tattered ruins.
This story raises a common question faced by technology architects: when does it make sense to stop mapping?
I believe that the discipline of technology architecture first arose from the desire for a map. Back in the 20th century, when we had been building software for long enough that things were starting to get complicated, but not so long that they were impossible to understand, people realised that it might be a good idea if we had some sort of systematic explanation of how things worked. So, we started modelling and mapping, and building repositories, and producing diagrams, and creating methods, and inventing governance structures, and all the other things that we do to keep us busy.
Five pieces of advice for technical leaders
What advice would you give someone taking on a new technical leadership role? As I wrote a few weeks ago, technical leadership matters, but there are few resources to learn technical leadership, so we have to rely on what we can learn from each other. I’ve been privileged to work with and for some great technical leaders who have been generous with their advice. Fortunately, advice is one of those things which gets more valuable the more you pass it on, so I thought it might be helpful to share a few bits of advice which have helped me.
Don’t panic
In the field of enterprise technology, things go wrong. All the time. If you have an operational role, then you spend much of your time dealing with incidents. If you have a change role, then you spend much of your time dealing with obstacles to delivery. And if you have embraced DevOps (as we all should) then you get to deal with incidents and change obstacles at the same time.
The vicious circle of legacy technology
Where does a vicious circle start?
I think that, in the case of legacy technology, it starts with an implicit agreement: to optimise for short-term outcomes over sustained capability. I also think that, once that implicit agreement gets the vicious circle of legacy technology going, it gets progressively more difficult to stop.
Let’s take a step back, and make it clear what we mean by legacy technology, and what it means to optimise for short-term outcomes.
‘Legacy’ is a euphemism. In normal language, it means something good: the things that we are proud to leave behind. In enterprise technology, it means something bad: the systems that have truly been left behind, in the sense that technology, capability and best practice have all moved on.
How do we get people to care about computing?
‘I’m not technical.’
If you work in enterprise technology, I bet your heart sinks when you hear those words. Whether you hear them from a programme sponsor, the leader of a business unit, a product manager or a project manager, you most likely perceive it as shorthand for, ‘I know that the success of this project depends on technology, and I know that the technology is going to be really complex and difficult, but that’s your problem, not my problem: I’m not going to engage with things that I don’t understand.’
There are a couple of reasons that this sentiment irritates technologists.
The first is practical: it means that, when they hit problems, they are unlikely to get active, engaged, curious, empathetic support - they are more likely to get asked to just fix the problem, to make it cheaper, faster and easier to deliver.
The second is more emotional: many of us work with technology because we find it fascinating and exciting, and we want to bring its potential to the world. We want others to be as fascinated and excited as we are, and the phrase ‘I’m not technical’ typically signals a lack of interest: the door is closed to fascination and excitement.
Technology leadership matters
I believe that the use of technology has an outsized impact on the success of organisations, and that the quality of technical leaders has an outsized impact on the successful use of technology. Organisations which don’t make good use of technology lag their peers, and organisations without great technical leaders struggle to make good use of technology.
This means that technical leadership matters.
However, technical leadership does not seem to be well understood, and there are few resources to help people become great technical leaders. I have held many technical leadership roles in my career, and have been fortunate to have access to some outstanding leadership development and technical training - but have struggled to find help to put technology and leadership together.
As a result, I don’t claim to be a great technical leader: there’s a reason that the title of this newsletter is A Lot to Learn. However, I have worked with and for some great technical leaders, and have picked up a few ideas along the way.
The dawn of a post-legacy world
It’s easy to be fatalistic when you work in enterprise technology.
Of course the great big programme will go wrong: great big programmes always go wrong. Of course the infrastructure will fail: infrastructure always fails. And of course we will always have legacy technology: technology becomes legacy the moment it is deployed.
Sometimes this fatalism is cynical: it is the world weary shrug of people who have lived through many failures. Fortunately, though, this fatalism is more often realistic, practical and active, and prompts us to create mechanisms to deal with inevitable failure.
Great big programmes always go wrong: that’s why we break them up into smaller pieces, manage our work through backlogs, and adjust our plans after each iteration.
Infrastructure always fails: that’s why we design reliability and resilience into our solutions, and treat infrastructure failure as an expected operating condition.
Except for legacy.
Give your legacy teams room and respect
What’s the best thing to give the teams looking after your legacy systems?
I was fortunate to be invited to sit on a panel at techUK's Building for a Smarter State conference last week. The topic was legacy, and the discussion prompted me to consider this question.
I’ve heard many answers to this question in my career, on a sliding scale from optimism to cynicism. I’ve heard optimists say that the best thing to give these teams is hope: the opportunity to learn new skills, to adopt new ways of working, to embrace new challenges and new solutions. And I’ve heard cynics say that the best thing to give these teams is the sack: they are stuck in the past, burdened with outdated skills and ways of thinking, and unwilling to change. Fortunately, the optimists have outnumbered the cynics, and we had no cynics on last week’s panel.
However, I think that there are two more things that we should give the teams running legacy systems: room and respect.
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.
In praise of the golden hammer
If you have a hammer, everything looks like a nail.
The Golden Hammer is one of the best known anti-patterns. The idea is that, if you have a particular tool, especially a tool in which you have invested large amounts of effort and money, then every problem looks like something that is best solved using that tool.
If you work in enterprise technology, there is a high chance that you have experienced the golden hammer anti-pattern. For example, I once worked on a system that had to process real time data and store the results in a database. This was before the days of event buses, and the architects of the system decided to use stored procedures and triggers (bits of code embedded in the database that run when you do something, such as read or create a record). This wasn’t a bad idea to start with, except that everything became a stored procedure or trigger. Eventually, it seemed that the database contained more code than data, and inserting one record triggered cascading logic which took seconds to process - which might have been fine if we hadn’t been receiving thousands of records per second. The answer, of course, was to refactor the system, using a wider variety of tools and techniques than the golden hammer on which the team had become fixated.
Three predictions: probably wrong; possibly useful
Why make predictions about technology at all? I am writing this from a train which was predicted to be at its destination half an hour ago, but is still stuck between stations. If we can’t make accurate predictions about a well-known system with years worth of data, how could we possibly make predictions about the ever-changing field of technology?
Yet the process of attempting to make predictions tells us something, even if individual predictions are wrong. This particular train might not arrive as predicted, but I expect that there is a model somewhere which predicts the overall number of trains that will be delayed - and this delay may be consistent with that prediction. Somebody had to develop that model, and that process will have found something interesting about the factors that affect the reliability of trains.
Similarly, while it’s hard to make predictions about the future of technology, the process of attempting to figure out what’s coming next can be useful. It forces us to use our imaginations, to think about the consequences of choices we are making today, and to recognise the limitations of our own knowledge.