- 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
Servant leadership for cloud transformation (or any other transformation)
What character traits do you need to lead Cloud transformation? Which should you avoid?
I recently wrote a series of blog posts about seven key roles for Cloud transformation - or for any other large scale, technology enabled transformation. That prompted me to ask myself a question: how should leaders behave when they fill these roles? I believe that leadership requires more than the competent execution of a set of tasks and responsibilities: it requires the adoption and practice of a set of behaviours which will make your transformation successful - and make the experience rewarding and fulfilling for the people in the team.
When asking questions about behaviour, my philosophical background leads me to Aristotle’s theory of the virtues. In Aristotle’s philosophy (and much philosophy which has come after), virtues are behaviours which we value, whose practice is self-reinforcing (the more often we are honest, the more honesty becomes a habit), whereas vices are self-reinforcing behaviours which we don’t value (if we lie frequently it is hard to stop).
Architecture or archaeology?
Last weekend my wife and I visited London together for the first time in several months. As well as having the chance to eat in great restaurants and see inspiring art, we did one of our favourite and simplest things: wandered the streets of a city which we have visited thousands of times, but where there is always something new to see. This time, we happened to be walking along London Wall. This is one of those streets where you can see history piled on top of itself: the remnants of the Roman wall next to the ruins of a medieval hospital, near a Victorian building, all in the shadow of skyscrapers from this and last century.
As ever, this reminded me of the work of technology architecture. While the history of computing is much shorter than the history of London, we have our own layers of technology from different ages. In banking, for example, a customer might initiate a payment from a mobile app which was updated yesterday, calling APIs which were built a couple of years ago, running on a five year old gateway, routing messages into queues that have been in existence for over a decade, before triggering a transaction in a back-end that was developed in the 1980s. And all that history is played out when the response is sent back. It might not be apparent to the end user, but performing a simple operation on their phone can be like sending a boomerang into the past.
Cloud leadership: the team
A team is more than the sum of the people who make it up - if you put the work in.
Over the last several weeks, I have written about seven key leadership roles for Cloud transformation. These are all demanding and difficult roles, and it will be hard to fill all of them. However, even if you have a name in every box on the org chart, you don’t yet have a team: you have a collection of individuals.
Despite all the literature on effective teams, despite all of the training available, and despite the ubiquity of those team building events that many people dread, I believe that one of the most common mistakes we make is to fail to invest time in team formation, cohesion and performance. I know that I have been guilty of assembling groups of talented people, aligning (or so I thought) on task and mission, and then setting off together - before realising (usually when facing tough challenges), that the members of these groups did not yet trust and support each other - or even properly know each other.
Cloud leadership: the Operator
Why does it always happen at three o’clock in the morning? In all the conversations I’ve had about resilience, recovery, incident management, problem management and, latterly, Site Reliability Engineering, we always seem to end up asking the question, ‘What do we do when everything goes wrong at three o’clock in the morning?’
In the days of always-available mobile customer experience, it might seem more relevant to worry about what goes wrong in the middle of the day, when all of your customers are awake. But I think that the iconic 3:00 am failure still serves two purposes.
The first purpose is procedural and technical: it makes us think about how we work when the (virtual) offices are closed and nobody is around. How do we detect failures? How do we respond to them? How do we contact the people who aren’t awake? How do we reduce our dependence on those people?
Cloud leadership: the Educator
It is puzzling that many technology teams routinely underspend their training budgets - even though those budgets are rarely large enough to start with. I have not conducted the research to prove that this pattern is universal, or to diagnose its cause, but I suspect that part of the cause is that most enterprises do not measure technology leaders directly on the capabilities (or career development) of their team: rather, they measure them on project success, operational performance, and management of cost and risk. To achieve all of those things, you need a good team, but if those things are all you are measured on, you may be tempted in the short term to buy, borrow or rent the team, rather than by building capabilities and careers.
This pattern is not sustainable when attempting large scale transformation, such as Cloud transformation. Such transformations require a shift in culture and capability at least as much as a shift in technology. That’s why the Educator is one of the seven key leadership roles for Cloud transformation. Given the transactional approach of many enterprises to technology learning, the Educator is also one of the roles most likely to be left out of the transformation leadership team, or to be ill-defined: giving someone the job of organising a set of technical training, and making sure that <x> people have achieved accreditation by <y> date is not to give them the role of the Educator.
Cloud leadership: the Guardian
A recent LinkedIn post asked people to suggest two words of advice they would give to someone starting out in their career. I immediately knew which two words I would choose: ‘Don’t Panic’. As well as welcoming any opportunity to recognise the work of Douglas Adams, I believe that these words are relevant to all business circumstances. I can think of many challenges, crises, setbacks, failures and genuine disasters which I have faced throughout my career and, while most of them needed energy and urgency, I can’t think of a single one that would have been improved by panic.
I think that these two words should be the motto of one of the seven key leadership roles for Cloud transformation: the Guardian. The Guardian is the person who thinks about all the things that could go wrong, and how to protect their enterprise from those circumstances. They are also the person who understands that risk cannot be eliminated, only managed, and that risk mitigation measures have a cost to the enterprise, often expressed in impacts on speed and agility, as well as cost.
Cloud leadership: the Architect
I believe that most technology architects have a secret: that the work that everybody wants them to do is not the work that they believe is most important.
I believe that most people want two things from their technology architects. They either want solutions (‘tell me how this is supposed to work!’) or standards (‘tell me the rules I am supposed to follow!’). (Sometimes, of course, they just want the technology architects to get out of their way - but dealing with that challenge is a different article.)
I also believe that most technology architects working in 2021 know that they should focus on capabilities. They realise that the details of solutions are increasingly ephemeral. This does not mean that systems go away (we have learnt that systems almost never go away), but it does mean that, in a modern enterprise, the ability for systems to change and adapt quickly is essential. The system may never go away, but the best systems are flexible and amorphous, and do more tomorrow than they can today. And we only get our systems to be flexible and amorphous by creating the capabilities for them to be so: by building development pipelines, by enabling engineers, by steering enterprises towards a product mindset - and by creating the right capabilities.
Cloud leadership: the Director
I believe two apparently contradictory things about Cloud transformation (and other ambitious change programmes). First, I believe that the best way to get things done is through small teams of smart experts with as much autonomy as possible. Second, I also believe that the best way to get things done is with clear leadership and direction, and the exercise of programme management disciplines, many of which might seem old-fashioned.
How do we reconcile autonomy and empowerment with clear leadership and disciplined programme management? Is there a role for classic programme management skills in a world of agile practices? Answering these questions is the job of one of the seven key leadership roles for Cloud transformation: the Director. The Director is the person who leads and organises, who sets priorities, goals and metrics, who creates structure and discipline.
Cloud leadership: the Champion
Transformation is hard, especially in large, traditional enterprises optimised for stability. In fact, transformation is so hard that any traditional enterprise of age and scale will be littered with the wrecks of previous transformation programmes, and it takes courage to try again.
Cloud transformation is particularly hard because, if you are serious about it, you will change many aspects of your enterprise at once: the way you run technology, the way you build and manage software, the pace of innovation in your enterprise, and the experience you offer customers.
What do you do when you meet challenges? What do you do when your teams want to change, but seem trapped by their own processes and policies? What do you do when it seems easier to give up than to keep going? Answering these questions is the job of the Champion.
Cloud leadership: the Visionary
There are many ways to adopt Cloud, and they don’t all need the Visionary. If you are a new company figuring out where to deploy your applications, Cloud platforms are the obvious choice: you’re already there. If you are part of an existing company making tactical use of Cloud to make incremental improvements in cost, risk or agility, then you may not need the Visionary (although, you might need the topic of my next blog post, the Champion, to convince your company to let you do it).
But if you want to make a profound transformation in all the ways that Cloud can offer, if you want to reshape your company and your technology team to make use of the best platforms in the world, then you need to create a vision which people can understand and follow. You need someone who can define an ambitious goal, and who can help others feel that it is possible to achieve.
Seven leadership roles for cloud transformation
I believe that small, empowered teams of skilled people are the best way to get things done. However, I also believe that there is still an essential role for leadership, especially in deep, enterprise wide transformation.
Moving to Cloud can be just such a transformation: an opportunity to change technology, culture and ways of working, as well as your relationships with customers, with data and with innovation. Transformation is delivered best by those small, empowered teams - but will go faster and be more successful if you have people who can play one of seven leadership roles:
One book a week: simple goals signal purpose
A few weeks ago, I was intrigued to receive an email at work headed ‘One-Book-A-Week is back! Sign up now!’. It came to me (and everyone else at Google who subscribes to a mailing list of productivity tips) from a colleague who was inviting us to pledge to try to read at least one book a week from April to June. We could do it as a team or we could do it individually. There were no prizes for succeeding or penalties for failing - but there was a page to log our books read, a regular email to encourage us and to tell us how we were doing as a group, and a bingo card of different types of books (a novel, a business book, a book by an author we hadn’t read before, a book we had been meaning to read) which we could optionally aim to complete.
I like reading, so I signed up, and pledged to read 13 books during the challenge. Four weeks in I have learnt a few things.