- 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
The round trip question: what is a computer?
It is the secret that everybody knows: a story which has rightly become a legend. During the Second World War, Alan Turing and a team at Bletchley Park invented the computer in order to crack the Enigma code, shortening the war and saving millions of lives. Turing was persecuted for his sexuality and died tragically, to be recognised as a national hero decades later.
Except that, while Turing deserves all the acclaim we can give him, part of this story is wrong. Turing did not invent the computer to crack the Enigma code. The difference between the device used for Enigma, the Bombe, and the real first computer, Colossus, as well as the original thinking that Turing did before the war, help us understand what makes a computer a computer, and why they make such a difference to the world.
The round trip question: a tale of two computers
Let’s start with a problem. You think some bills have just been paid out of your account. You want to check how much money you have left. You have a computer in your hand - your mobile phone - but that computer does not currently know your balance. There is at least one computer that does know your balance, but it does not belong to you, and it sits in a large building hundreds of miles away. How does the number that represents your balance get from your bank’s computer to the mobile phone in your hand?
This is one of a series of articles which explores how we use computers to run the world by considering the round trip question: what happens when we press a button on a mobile banking app which tells it to do something with our money?
Simply by virtue of being computers, the phone in your hand and the machine in your bank have a lot of similarities. For now, though, I’d like to explore their differences, as those differences are what makes the round trip question interesting.
The round trip question: a duty to explain
Something has been bothering me: I have been designing, building and running computer systems for over thirty years, and believe that the explosive growth of information technology in that time is a net good for the world. At the same time, I have observed a growing gap in understanding between the people who build and run technology for a living and the people who use it. Information technology touches more people’s lives more deeply every day - yet is increasingly difficult to understand.
I sometimes test this feeling by asking what I call ‘the round trip question’. The question is: when you hit a button on your mobile banking app which tells it to do something (get your balance, make a payment, or some other function), what do you imagine happens? (It doesn’t have to be banking, but it’s the industry I happen to have worked in for longest.)
Use both feet to step on to the cloud
The early days of Cloud adoption in many large companies are dominated by the creation of Landing Zones (LZs). This term can mean a lot of things, but encapsulates the set of configuration, controls and instrumentation a company uses to set up a Cloud platform to its liking and needs. If a Cloud platform is like an apartment block, setting up your LZs is like moving your furniture in, putting the locks on the doors and arranging your utilities. You may have people to help you (integrators and consultants in the Cloud, moving companies and interior designers for your apartment), but you are the one who is going to live there.
Many companies struggle in this early stage, as it can feel like they are making their most important decisions at the time they have the least expertise. I have seen this lead to two anti-patterns: the free-for-all and the gold-plated LZ.
Who are you optimising for?
A long time ago, one of my colleagues gave me a reality check. I was working as an architect and he was working as a methods specialist. I thought that our jobs were important, but he reminded me what was really important when he said, ‘We’re here to deliver working software. If we’re not doing that directly, we have to ask whether we’re doing our best for the people who do deliver working software.’
A few months ago, I wrote an article which asked the question, ‘what are you optimising for?’ when attempting Cloud transformation. Today I’d like to ask a question which I think is even more important: ‘who are you optimising for?’
Architecture year one: measuring success
I have a flippant answer when asked how to measure the success of an architecture team: just check how often your phone is ringing. (I realise that this dates my advice - please substitute ringing phones for the messaging app of your choice.) If you and your team are in demand, if you are the first call whenever your company faces a big challenge or opportunity, then you are doing something right. If your phone (or messaging app) is silent, if you have to push to insert yourself into the room with tough problems, then you have more work to do.
However, recently I was talking to a friend and colleague who has just taken on a Chief Architect role in a new company, and who is attempting to design measures of success for their team. In that conversation, I realised that we needed to come up with something a bit more sophisticated than the number of messages on your phone.
To hire and retain software engineers (and other great technologists): your first steps should be trust and value
Many traditional companies are asking the same questions. Why can’t I hire the software engineers (and other talented technologists) I need? Why don’t they stay? Why do my best people keep leaving once I’ve trained them?
There are a lot of obvious answers to these questions. Talented technologists are in demand by traditional companies and digital natives. Traditional companies are often perceived to lack the brand, mission and feeling of excitement that newer companies have. Newer companies may have different compensation structures.
I believe that these reasons are largely valid. However, I think that there is a deeper reason that is more important: many traditional companies have not yet learnt to truly value and trust their technologists. And I believe that this reason is rooted in the history of how technology functions have evolved in large, traditional companies.
Planning for the future: taking the science fictional view
In 1978, Isaac Asimov wrote in his essay My Own View, ‘No sensible decision can be made any longer without taking into account not only the world as it is, but the world as it will be. This, in turn, means that our statesmen, our businessmen, our every man must take on a science fictional way of thinking.’ Reading this in 2021, this quote is both relevant and an example of the short term thinking it warns against: apparently, taking a science fictional view in 1978 didn’t include a world run by anybody but men.
The circumstances in which I came across this quote further illustrated the importance of taking on a science fictional view. I was reading a book on AI ethics, addressing the implications of living in a world where artificial intelligence is already woven into many aspects of our lives, where we contemplate giving AI agents responsibility for life and death decisions in industries such as transport, and where there seems a strong chance that, within our lifetimes, AI agents will exhibit properties which lead us to hard questions about rights and consciousness. Moreover, I was reading the book on a device that fit in the palm of my hand, connected to a global network that gave me access to the world’s knowledge - as well as playing videos and letting me talk to people. A long way from 1978, and not just in social attitudes.
When evaluating startups, evaluate yourself. Will you be a good customer?
Last week, I was privileged to support the annual Female Fintech Founder competition run jointly by Google, Deutsche Bank and Atos. The competition seeks to find the most promising early stage fintech companies founded by women, and to provide the winners with support for the next stage of their success. (And to provide all the participants with advice and networking opportunities.)
At the heart of the session I attended was a great presentation by my colleague Prue MacKenzie. You can read more about that here.
I can’t improve on Prue’s advice, but the session did prompt me to think about how established companies work with new companies, and whether they always get it right. Many of the founders taking part in the competition will offer their services directly to consumers, but many will have corporates as customers or partners. Founding a company takes great courage, especially in times of great uncertainty. Whether they win the competition or not, all of the founders have already taken a greater risk than any I have ever taken in my career. I think that they deserve customers and partners who think deeply about how to work with them.
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.