- 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
Warning: philosophers at work
I’ve bumped into a couple of conversations about philosophy this week. The first was in the Economist, in an article which claimed that philosophy graduates may have a better chance of getting hired then computer science graduates, especially by AI companies. It’s not clear whether those philosophy graduates are expected to teach the models, coach the executives, or advise the developers, but it’s nice that they have jobs.
On the face of it, I should feel positive about this development. For the last ten years, since AI (in its pre-generative, pre-transformer incarnation) started to be used in the companies I was working for, especially in data-rich decision making use cases, such as fraud and financial crime detection and customer needs analysis, I have believed that AI ethics was an urgent problem.
More than just a job
Was this the right decision?
In mid-2022, I got a phone call, asking whether I would like to apply to become CTO for the UK Government. I had only been in my current job for a short time, so I said no. That wasn’t the only reason: I had spent almost all of my career in the private sector and understood enough about how things worked in that world to be reasonably helpful and successful. I must also admit that, coming from that world, I did not (yet) perceive work in the public sector as particularly attractive or exciting.
However . . .
At the back of my mind, I felt that I had a debt to pay. My very first paying job in technology was as a COBOL programmer for HM Customs & Excise. Before that job, I was an amateur programmer, but had no degree and no professional qualifications in computing. After two years, I was trained and experienced, and capable of working in a professional technology environment - and, like many of my peers, I took my skills to private industry. I hadn’t been back since.
Twelve firsts: lessons learnt from a few decades in technology
What have you learnt in your career?
I was privileged to be asked this question by some of my colleagues in the Central Digital and Data Office, in the hope that some of my stumbles, trips, outright failures and occasional successes would provide useful lessons. I’ve worked for about twenty organisations over more than thirty years, so there were a lot of examples to choose from, but twelve firsts stood out for me - things which shaped me when I experienced them for the first time.
The first time I used a computer was a ZX81 which one of my father’s friends had lent us. We only had it for a few days, but it taught me that if I put instructions into the machine, it would do what I told it to do. I’ve carried on putting instructions into machines, either directly or indirectly, ever since.
My first full-time job was in a lab while taking a year off before studying biology. It taught me that I was not cut out for the precision and repetition of lab work, and that maybe this field was not for me. I did like working with the computers that ran the lab equipment, though.
Three things I’ve learnt at BCG
Today is my last day at BCG. (I’ll share what I’m going to do next in the near future: let’s just say that it had to be something pretty special to tempt me away from BCG.) My time here has been one of the most intense learning experiences of my life: I’ve learnt about new industries, new technologies, and got to see how one of the world’s leading consultancies works from the inside. But there are three things which have particularly stayed with me, and which I plan to add to the box of conceptual, practical and technical tools I have built over my career.
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.
Should we teach the green field or the space capsule?
How do we help people become technology architects?
I think that we should start by asking ourselves what it’s like to be a new technology architect. Which of these best describes your first day as a solution architect?
This . . ?
You step into your new realm. The grass is lush and green. Crystal waterfalls sparkle in the background. Hills, forests and valleys stretch away into the distance. You know that the landscape is beautiful: you just need to find a vantage point from which to see it all. You need to build a tower high enough to gain perspective, but what should you build it from? Ivory?
Or this . . ?
You wake up with a start. Your surroundings are lurching and spinning around you. You seem to be in some sort of spacecraft. Looks something like Apollo 13. Gas is venting and there is smoke in the air. You spot your crew mates: they are frantically flipping switches, pressing buttons and turning dials. They turn to you in relief when they see that you are awake: ‘Help!’ they say. ’Tell us how this thing works!’
When did you first know that you wanted to be a technology architect?
It can take a long time to figure out where you fit. It needs self-awareness, often earned through a success and failure, elation and disappointment. It needs a dose of self-confidence, a shedding of self-doubt and false modesty, to admit that you are actually good at something, perhaps better than many other people. And it needs a big helping of humility, to admit that there are plenty of things that you are not good at, and which are best left to other people.
However, if you are a successful technology architect, I suspect that there was a moment early in your career where you figured out that this was the work for you. You discovered that there was something in the combination of problem solving, persuading and explanation that motivated you; that you had an itch made of equal parts curiosity, persistence and a desire to see things done right that could only be scratched by doing architecture work.
I can remember when I first realised that I wanted to be a technology architect. Except that this was so long ago that we didn’t call it architecture: if we called it anything, we called it analysis, design or Figuring Stuff Out.
Tinker, tailor, strategist, innovator
What do you want to be when you grow up?
I’m still not entirely sure that I know, so it’s slightly scary when people ask for my advice on their career choices. Fortunately, being a technology architect means that I’m always prepared to express an opinion on something I don’t completely understand.
Two of the career choices I am asked about most frequently are technology strategy and innovation (probably because I have people that do both of these types of work in my team). Here is some of the advice I offer people to help them figure out whether these choices are good for them, and what kind of qualities they need to do this work well. (Like all advice from a technology architect it is well meant, but possibly wrong.)
Lessons last: how one small idea helped shape my career
It is strange how a small lesson learnt early can last your whole life.
Forty years ago, I found myself staring at a piece of text which made no sense to me, wondering whether I had made a terrible mistake. My school offered Russian as a language and, attracted by difference and by the strangeness of the alphabet (and the prospect of a school trip to Moscow and Leningrad), it was the option I had selected. Now I felt like I was illiterate again: I could only recognise some of the characters in the alphabet, and even they didn’t sound like I thought they should sound.
That first lesson made a big impression on me. First, it helped me to decode text that was previously impenetrable: even if I couldn’t understand the words, I could start to figure out the sounds. More importantly, though, my Russian teacher, Mr Clark, pressed home on us the importance of being conscientious. He expected us not just to learn the alphabet, not just to write it, but to write it well. He would mark our work not just on grammar and spelling, but on the care and attention we took in writing. This wasn’t because he was an especially tough teacher: it was because he knew that time invested in the basics would embed the skills, and would help us develop habits of excellence and diliigence. To impress these habits in us, he asked us time and time again whether we were being conscientious, and let us know very clearly when we were not.
Anti-Shunya for careers
I knew that the concept of zero (at least as a positional notation) was invented in India, but I didn’t learn the Sanskrit term for zero (Shunya) until last month. My friend and colleague Balasubramanian Ganesh (HSBC’s CIO for Retail Banking and Wealth Management) introduced me to this term, and explained how we are using this concept (and a load of cool instrumentation) to drive zero defects, zero incidents and zero vulnerabilities for software engineering.
Ganesh also asked me on stage at our Engineering Summit in Pune, India, to share some reflections on my career, and to offer advice on what has helped me reach my current position of Chief Architect for HSBC.
My reflection was that, while Shunya is a great goal for software, it’s not something I have followed in career terms: my career has been full of defects, incidents and vulnerabilities. That’s because it has taken a while to figure out what I am good at, and it turns out that, to figure out what you’re good at, you have to do some things that you’re not good at.