I’m David Knott. I’ve been working in enterprise technology for over forty years and I’m still learning. This blog is based on mistakes, failures, lessons and some things I find interesting:
- AI
- ambiguity
- architecture
- augmented reality
- books
- bureaucracy
- career
- change
- Christmas
- cloud
- collaboration
- communication
- corporate life
- data
- delivery
- devops
- end user tools
- ethics
- fear
- government
- halloween
- history
- hype
- language
- leadership
- learning
- legacy
- measurement
- mental health
- networking
- New Year
- operations
- philosophy
- prediction
- procurement
- programming
- risk
- science fiction
- security
- shadow IT
- space
- teaching
- teams
- technical debt
- technology advocacy
- testing
- thinking
- TV
- virtues
- writing
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: