- 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
Are you suffering from chapter one syndrome?
Keeping up with the latest thinking in technology can be hard. New products emerge every day, and existing products shift and change. If we did nothing but read announcements from technology providers, then our days would be full. If we tried to understand the implications of all those announcements, our nights would be full too. And, to make things more complicated, it’s not just technology that changes: the ways in which we build, organise and manage technology also change. I have had to relearn how to do things many times.
If you’re anything like me, you have a pile of unread books (either physical or virtual), and a creeping sense of guilt about not having read all of them - and that sense of guilt gets stronger as the pile grows higher. But where will you find the time?
Reflections on one year at Google: platforms, products and practices
I celebrated my first Googleversary this week! It’s hard to believe that I have been here a year. I don’t know whether it feels longer or shorter: for me, as for many people, time has passed strangely over the last year.
I’ve learnt many things so far at Google - about culture, about collaboration and about customers. Unsurprisingly, I have also learnt about technology - in particular, to think more deeply about how Google uses technology, and what Cloud means for customers.
A lot has been written about Cloud (including quite a few words by me), but I’ve had a feeling for a while that much of this writing (including my own) does not really capture why Cloud matters so much. Considerations of Cloud often focus on core technology benefits (reduce cost, reduce risk, increase agility) or jump straight to ambitious business goals (innovate, disrupt, create new models), but I think that they often miss a big and important architectural chunk in the middle.
Empowered must not mean abandoned
The most stressful experience in my entire career was when I felt truly abandoned. A very long time ago, I was trying to run a project which was dependent on the work of many other teams - but those teams weren’t interested. The system I was building needed new infrastructure - but the infrastructure wasn’t even ordered. The budget I had inherited was clearly insufficient for the task - but no-one was prepared to provide more money, or change scope, time or quality. And, although I have not always been fast enough to ask for help, this time I did not hold back: I took every opportunity to make sure that everyone around me knew the problems the team was facing and the help we needed, including my boss. But no help came. We were abandoned.
I like autonomy and don’t cope well with micro-management. But the feeling of being truly abandoned was far worse - I ended up leaving that job and have never forgotten the lesson.
Are you making a difference? Managers must tell correlation from causation
Does eating chocolate make you smarter? In a study published in The New England Journal of Medicine in 2012, Franz Messerli demonstrated a correlation between the amount of chocolate which a nation eats and the number of Nobel prizes its citizens win. Unsurprisingly, Messerli’s findings were deliberately playful: he was not really attempting to assert that eating chocolate leads to prize winning research - he was illustrating the difference between correlation and causation. Chocolate consumption tends to correlate with national wealth, which also correlates with those factors which create an environment suited to Nobel prize winning research.
We might think that we already understand the difference between correlation (factors which co-exist and which may change together, but which have no causal link) and causation (one factor which drives another through a causal mechanism), and would never fall into the trap of mixing them up. But I think that if you are a manager you are at risk of mixing these concepts up all the time - I know that I am.
Agreement is optional; understanding is essential
Technology architecture is characterised by debate: we spend a lot of time arguing with each other. Given how much time we spend, we should ask ourselves whether we are any good at it. But being good at arguing doesn’t mean that we win all the time: in fact, winning all the time might be a sign of badness. Arguing well means that we are reliably successful at discovering the truth and making decisions - which may mean that we have to change our minds.
Some time ago I wrote that, as a technology architect, one of your jobs is to get ideas from your head into other people’s heads. I still believe that to be true, but realise that I left something very important out: it is also your job to get ideas from other people’s heads into your head. It is your job to understand the objectives, motivations, constraints and thinking of other people, and to see how these change your perspective.
Cloud transformation: don’t stop at the foundations
Over twenty years ago, I was working in Canary Wharf when the next set of towers after 1 Canada Square started to be built. I had the opportunity to watch the foundations of new buildings being laid, and to see the surprising contrast between the amount of time it took to lay those foundations, and the speed with which the new buildings climbed to the sky. For months it seemed that nothing was happening - but that ‘nothing’ was what made the rest of the building possible.
In Cloud transformation, we usually start by building foundations: basic concepts and constructs such as landing zones, tools and security policies, accompanied by essential training, and proven by pilot workloads. This first phase can be difficult, as it requires you to make some of your most important choices and do some of your most important work at the time when you have least experience and capacity. As with any profound change, you will experience setbacks and surprises as well as success, and you will need to adapt your plan. It is also wise to seek help.
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.
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.