- 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
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.
Built in or bolted on?
If you are a technology architect, do you regret the complexity of your legacy architecture? Do you wonder how you ended up with so many layers, and so many different technologies which do similar jobs - but never quite seem to do 100% of any particular job?
I believe that feeling dissatisfied is a natural part of the life of a technology architect. However, I also believe that we should extend ourselves a little forgiveness. It is true that some of the complexity in legacy estates is our fault: sometimes we have not been successful in convincing people to address technical debt, and sometimes we have failed to resolve disputes between champions of different technologies. But much of the complexity in legacy estates is simply a function of time and the continuously changing environment in which enterprise technology must operate.
Accelerate off the plateau
What’s your memory like? Mine is far from perfect, especially for names and faces: let me take the opportunity to apologise in advance to anybody I haven’t seen during the long lockdown, and who I fail to recognise when we meet again. If you see me with a polite smile and a confused look, I am probably trying to jolt my memory into action.
In his book Moonwalking with Einstein, Joshua Foer attempted to answer the question of how to improve his memory, and ended up competing in the U.S. Memory Championships. To do this he had to train hard to master various events, such as memorising random lists of binary digits, long poems word for word, and the order of multiple packs of playing cards. I found many interesting ideas in Foer’s book about the history of memory, the techniques used to improve memory, and about talent and expertise. There is one particular idea, though, that made me think about how we develop throughout our careers, and the conditions that leaders must create to support that development.
Is my red your red? Is my experience your experience?
There’s a longstanding (and possibly unanswerable) question of whether one person’s experience of the physical world is the same as another person’s experience of the physical world. The question is often framed in terms of colour: (if we have no visual impairments) I know what it is like to see the colour red; you know what it is like to see the colour red; we even agree on the things that are coloured red; but we cannot know whether our subjective experience of red is identical.
Whether it is possible to answer this question or not, I think that there are things that have the same external, physical characteristics, but very different subjective experiences: our interactions with other people. I also think that this difference is amplified by working from home in lockdown. (And, as ever, I have to point out that when considering this experience, those of us working from home have to remember how fortunate we are to be healthy, housed and in work.)
From the data lake to the front page of data
How many times have you tried to build a data lake? Or, to put it another way, how many times have you tried to solve the analytics problem? I have to confess that I have tried more than once - and had varying success, until I learnt to think about the problem differently.
The problem is familiar: our enterprise has data which we believe to have value; that data is sitting in systems of record which are hard to access; those systems sit on infrastructure which is optimised for transactions rather than analytics.
We also have solutions which are familiar, even if they have taken different forms over the years: we pull the data out of our systems of record; we organise it into a form which is easier to analyse; and we place it on infrastructure which is optimised for analytics.
Psychological safety in teams: what can you achieve when you stand on solid ground?
This week, it snowed in the town where I live. I know that all my friends and colleagues in much colder parts of the world will tell me that it didn’t really snow: we just had a couple of inches. But even that small scattering changed the way the world looked, changed the way I interact with the world, and also prompted some thoughts about psychological safety, confidence and my own response to challenges in the workplace.
For the first couple of days, the world was transformed. The streets had that special quality they have after the first snowfall, when everything seems soft, quiet and pristine. I couldn’t wait to get out and walk in the snow (to the extent allowed by current lockdown restrictions). It was cold, but the snow was powdery and I felt completely safe to explore the changed environment.
For digital transformation, learn to care about code (and people)
For my 12th birthday my parents bought me an Acorn Atom microcomputer (yes, I am that old). This meant that I learnt to code at a young age, and acquired a love for computing which has stayed with me throughout my career.
As the world changes, and more and more companies attempt digital transformation, I am ever more grateful to my parents for the gift of my first computer, not just because it led me to a rewarding career, but because it gave me an understanding of the technology that runs more and more of the world. Modern computers are many times more powerful than that first little machine, and I doubt that anybody codes in Atom BASIC any more. Coding projects start with frameworks and libraries rather than a program printed in a magazine, and CI/CD pipelines involve rather more than typing RUN. And yet, code is still code.