- 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
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.