- 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
Build a movement, not an enclave
The current wave of AI products have been around long enough for enterprises to launch ‘AI transformation’ initiatives, to wonder why those initiatives aren’t yielding the results they hoped for, and to reach for new ways of working to try to jolt them into life.
For people who have worked in technology for more than a few years, this cycle is familiar: a new technology becomes generally available (cloud, mobile, web, Big Data and so on); bold claims are made for the impact of that technology (cut costs, improve customer engagement, make better decisions and so on); initial projects fail to make that impact; big transformation programmes also fail to make that impact; enterprises make organisational changes to try to get the benefits they were promised.
If you have seen this cycle many times, you have probably developed several survival tactics: try to get behind the hype and learn the fundamentals of the new technology; learn what it can do and what it can’t do; calm unrealistic expectations; salvage value from failures; and, ultimately, work with your peers to develop sustainable professional practice.
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.
Which are more dangerous: slides, or sticky notes?
In the story of the three billy goats gruff, the goats want to cross a bridge guarded by a troll. They manage this by each telling the troll that there is a bigger goat just behind them until (spoiler alert!) the biggest goat comes along and butts the troll into the sky.
Sometimes, when we are trying to make the case for enterprise technology capabilities, it feels like we are the trolls, and that we are so scared of the biggest billy goat that we won’t tackle the smaller goats. When we look across our technology landscapes, we see mess, waste and mayhem, and wish that we had some of the foundational capabilities that would help clean things up. Yet we hesitate, because we know that every time we build something we will uncover another problem, and another problem, and another problem, until we get to problems that are so big that we cannot imagine how to solve them.
Danger zones on the way to cloud: the Mists of Confusion, the Mountains of No, and the Swamps of Error
‘We’ve tried this before. It didn’t work then. What makes this time different?’
Are there any more dispiriting words to hear when you’re leading transformation? If you’ve been in that job, the scene is familiar. You have built the business case. You have secured the investment for the programme. You have found your partners. You have prepared your slides and you have organised the launch meeting. You are ready to inspire, organise and motivate. You have delivered your pitch and you have opened the floor for questions.
The first hand that goes up is from a veteran member of the team. They have lived through many changes. They know the systems inside out. Their support is vital: other people will follow their lead. And then they ask that dreaded question.
How do I get there from here? Two first rungs on the ladder to cloud?
If only we hadn’t called it ‘cloud’. I sometimes wish that the technology industry had come up with a better term for the global, hyperscale, software defined platforms that I believe will form the dominant computing infrastructure of tomorrow. ‘Cloud’ implies something nebulous, light and airy, something that is impossible to touch or pin down. In real life, the physical implementation of cloud is a long way from this image: it is made of servers, storage arrays, network equipment, cables and physical facilities. The cloud is something you can weigh.
However, there is one way in which the term ‘cloud’ is useful. When we think of a cloud we think of something which is way up in the sky, something that is difficult to reach for mere earthbound mortals. The reason that I think that this image is useful is that it represents something true about cloud: that answering the question, ‘how do I get there from here?’ is difficult. To reach a real cloud, you would need a very long ladder and you would have nothing to lean it against. Getting to the computing cloud from your on premise starting point can seem like just as much of an acrobatic balancing act.
The team is the unit of transformation
In enterprise technology we like to count things: applications, petabytes of data, physical and virtual servers, gigabits of bandwidth and so on. Even if it's often surprisingly difficult to find them all and figure out what state they're, you know where you are with things.
It's not surprising, therefore, that when we attempt transformation, we often plan and measure success in terms of these things. We are shifting to a new operating system: how many servers have we upgraded? We are unlocking access to our data with APIs: guess many APIs have we built? We are moving to the Cloud: how many applications have we migrated?
The problem with measuring transformation like this is that it leaves out the most important thing: the people.
Predicting doomsday: is your transformation initiative in trouble?
Can this initiative be rescued? Or is it doomed to failure?
If you’ve worked on any transformation initiative, I expect that you have asked these questions when things were difficult. If you were a member of the team, you may have wondered whether it was time to find a new project. If you were a leader of the initiative, you may have wondered whether you were up to the job. And if you were a sponsor of the initiative, you may have wondered whether you should apply your sponsorship elsewhere.
In my last couple of blog posts, I wrote about the importance of sustaining energy in large scale transformation, and offered some suggestions on how to keep going. James Cole, who leads architecture for the British Red Cross, asked in the comments for suggestions about when to persevere and when to think again - about how to detect that your initiative is doomed.
The persistence of vision: sustaining energy in strategic transformation
Sometimes you just feel like giving up. Some days, even when you are the visionary leader of a transformation programme, even when your teams and your company are looking to you to provide energy, direction and confidence, it just feels like there are too many obstacles. You look at the many other abandoned programmes in your enterprise’s history, and you wonder how you can succeed when so many others have failed. You look at the status quo, and wonder whether it is really so bad. Maybe you should curtail your ambitions, and settle for some incremental improvements.
I don’t have a perfect answer for sustaining energy in the face of seemingly insurmountable obstacles. But there are three ways of seeing - three perspectives - that I find helpful: the perspectives of imagination, of time and of others.
Apathy is transformation’s greatest enemy; wholeheartedness its greatest friend
There are many abandoned projects in the world. If you Google ‘abandoned projects’ you will mostly come up with examples of construction projects: buildings that have never been finished, that are never going to be finished, and now haunt their environments as shells and echoes of their original intent. When such a project goes wrong, the results are plainly visible.
For those of us who work in enterprise technology, or who try to transform companies, the remnants of our abandoned projects are not so visible. When we walk around our offices we do not see the millions of lines of code that were written but never made it into production, the packages that we bought but never implemented, or the process and culture changes that didn’t stick. Our false starts and u-turns are largely invisible to the eye. But they are visible to our memories: anyone who has been working in enterprise technology or transformation for some time has their mental store of abandoned projects.