- agents
- AI
- ambiguity
- architecture
- augmented reality
- books
- bureaucracy
- career
- change
- Christmas
- cloud
- collaboration
- communication
- compliance
- corporate life
- data
- decisions
- delivery
- devops
- disagreement
- end user tools
- ethics
- failure
- fear
- fundamentals
- government
- halloween
- history
- humans
- hype
- identity
- inclusion
- infrastructure
- innovation
- language
- leadership
- learning
- legacy
- management
- measurement
- mental health
- money
- networking
- New Year
- operations
- philosophy
- physics
- platforms
- prediction
- privacy
- process
- procurement
- products
- programming
- quantum
- reliability
- resilience
- risk
- science fiction
- security
- shadow IT
- space
- strategy
- talent
- teaching
- teams
- technical debt
- technology advocacy
- testing
- thinking
- transformation
- TV
- virtues
- vision
- writing
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.
On the edge of the storm
In 1965, Bruce Tuckman published his paper Development Sequence in Small Groups, and introduced the world to the idea that teams go through four stages of development: forming, storming, norming and performing.
This is one of those ideas which, while it comes from a formal academic literature review of psychology research, is immediately intuitive. If we have ever worked in a team, we can easily recognise the feeling of the early days of a new team, when we are figuring each other out (forming), that period when we know each other well enough to challenge and complain, but not well enough to trust each other (storming), the point when we start to establish our ground rules of behaviour, whether implicit or explicit (norming), and the time when we know and trust each other well enough to help each other develop (performing).
What are you optimising for?
Recently, one of the teams I am lucky to work with showed me a tool they had built to help plan and manage Cloud adoption. It captured system data, project data, dependencies between applications and platform capabilities, and the roadmap for launch and enablement of those capabilities. Such a tool is helpful for any Cloud adoption programme, but what really stuck with me was the goal that the team had set for themselves.
The team wanted to answer two questions. First, what were they optimising for? And, second, what would they do differently depending on the answer to the first question? If they were optimising for cost, then one set of dependencies mattered more than another set. If they were optimising for agility, then they would give one set of tasks more priority than another set. If they were optimising for risk, then they would build their plan this way rather than that way.
When is a meeting not a meeting?
Those of us who spend a lot of time in meetings often spend a lot of time complaining about meetings. We complain that they are poorly organised, that they do not lead to clear decisions, that the organisers aren’t well prepared or that the attendees haven’t done their homework. We wonder why we still go to that recurring meeting that rolls around every week although nothing ever seems to get done.
Given these feelings, it can be a good idea to be ruthless with our calendars: to get rid of those meetings which aren’t worth our time, to cut attendance for meetings which are overpopulated, to cut the duration of those meetings which drag on, and to reduce the frequency of those meetings which happen too often. When we do that, we hope to find that the meetings we keep are more effective and more efficient, and that our diaries are more free: we may even find that we have time to think.
Except . . .
Thinking time, or thinking just in time?
One of the good things about working at Google is the opportunity for continuous learning, not just about technology, but about topics such as how teams work and how to manage one’s own time - all based on data and research.
One thing I learnt recently was how little time people at work typically spend thinking (not thinking in meetings, or thinking while they write code or documents, but just thinking): for most people it’s less than 30 minutes per day. This was a surprise, but feels intuitively plausible. If we think about how we spend our days, we realise that we spend most of our time running from task to task or from meeting to meeting. Scheduling time for nothing but thinking can feel self-indulgent, or as if we are not doing ‘real’ work.
Can one voice change a strategy?
The lunar module from the Apollo missions is so familiar that it is hard to imagine other ways of landing on the Moon. Surely that spindly, fragile lander, and the command module in orbit with its lonely pilot are the way that these things are done.
But this way of landing on the Moon was not inevitable: in the early days of Apollo, it was not even seen as an option worthy of consideration. The original plans were for a single craft, capable of landing on the Moon, taking off again and flying all the way home on its own. Such a craft would have no need for a docking manoeuvre in Lunar orbit, which was seen as unnecessary and risky.
And, once we shed our preconceptions based on decades of images, this approach seems intuitively simpler. The Moon missions would already involve many dangerous firsts: why complicate things further by splitting the landing craft and command module, and attempting a docking manoeuvre a quarter of a million miles from home?
Are you new here? Lessons learnt from many new starts
I joined Google on 7th September 2020, so I’ve just celebrated my six month Google-versary! As well as being a fascinating experience at a very strange time, passing this milestone prompted me to reflect on my experience in other new roles and new companies. I’ve changed jobs many times in my career and, although Google is different from most companies I have worked for, I have been through many of the same thoughts and feelings, highs and lows as I have experienced in other places. I thought that it might be useful to share some of the lessons I have learnt, in the hope that they can help other people moving into new roles.