- 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
What was I thinking?
A few months ago, I decided to set up this blog site to hold all of the articles I have published on LinkedIn, whether in the A Lot to Learn newsletter or standalone articles from before LinkedIn used newsletters.
That might seem like a self-indulgent exercise, but I thought, first, that it might be useful, and, second, that, if it was useful, I might need a content lifeboat. Unfortunately, social media platforms tend to decay, and I anticipated that there might come a point in the future where I didn’t want to be on this platform any more. (I won’t comment in depth here about the quality of LinkedIn, other than to say that I have a mental threshold for the number of toxic, divisive posts I’m prepared to see, and, sadly, the content here increasingly approaches that threshold.)
Whatever the motivation, I found the process of transferring articles across to the new site interesting. I kept thinking that this is exactly the sort of busywork that I should be using AI to help with, but found that I enjoyed the process of reviewing what I had previously written and trying to figure out what I thought about it.
Sometimes I just want a blank sheet of paper (and sometimes I don't)
I call it the pushback moment.
It’s that moment when I am writing something - it might be a work document, or a presentation, or one of these articles - when it’s just not working. The sentences are tangled, the meaning is muddy, and I am not getting my point across.
That’s when I push back all of the papers and references and notebooks from my desk and reach for a fresh, blank sheet of paper (or, digitally, open another browser tab and create an empty document). And I ask myself a question: ‘What am I trying to say?’
Lessons learnt from five years of learning lessons
In September 2018, I challenged my architecture team to publish their thinking in public. I thought that, as people who aspired to set the technical direction for one of the largest banks in the world, we should have a clear, distinctive voice, and we should make that voice heard outside our own organisation.
My team quite rightly challenged me back. After you, they said. Why don’t you go first? they asked. I couldn’t think of a reason to say no, so I committed that I would write some articles and publish them on LinkedIn. They pushed me: how often will you write? I said that I’d try to do it weekly. How hard could it be?
Five years later, publishing this weekly newsletter has become part of my routine. As I approach that five year anniversary, I thought it might be interesting to spend a couple of weeks reflecting on everything I have learnt over those five years, and taking the risky step of making some predictions for the next five years. First, though, I’d like to write down the answer to a question many of my colleagues have asked me: how should they go about writing their own articles?
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.
Thinking differently about . . . collaboration
How often have you accidentally hit ‘reply all’ when sending an email? Or included someone on the cc: list that you didn’t intend to? I think that we all know the feeling of making that mistake.
I had a similar experience in my new job at Google last week - but it turned out to be a lesson about collaboration instead of a mistake.
I was editing a document using Google docs, and when I hit the share button, I was asked whether I wanted to share it with the same people as the document I had copied it from. I hit ‘yes’ - then realised that I had shared the document with about a hundred people, rather than the half dozen I had intended it for. I had a sinking feeling for a moment - then remembered that I needed to think differently about collaboration.
New Year’s resolution day two: suggestions for making your documents better
Last week I suggested a New Year’s resolution for technology architects: to improve how we present and format documents. I suggested this not just because I am pernickety about document formatting (I am), but because good formatting makes our ideas easier to understand, helps those ideas compete on a level playing field with others, and express our identity as professionals who care.
On the dangerous assumptions that that, first, you were persuaded by this blog post, and, second, that you are interested in keeping this resolution beyond 2nd January, here are a few further suggestions from me on how to put it into practice. As ever, these suggestions come with the caveats that they work for me, but may not work for you, and that I am frequently wrong.
A suggested New Year’s resolution: don’t let bad formatting hide good ideas
My parents gave me many gifts: a loving home and all the support I could ask for. There is one gift, though, which they didn’t plan: a low tolerance for poorly formatted documents, to an extent which has enabled me to irritate every team which has ever worked for me throughout my career.
This started back in the 1980s, when my Dad, who sold print and reprographic equipment, had two realisations. First, he spotted that the shift from hot metal (blocks of lead type set by hand) to phototypesetting (photographic images of type produced electronically) was an inevitable trend. Second, he realised that he’d far rather work for himself than for an employer. As a result he and my Mum founded a typesetting company based out of our home.
Growing up in the same house as my Mum and Dad’s typesetting business taught me many things. It showed me the evolution of a business through technology: as the years passed, I saw the equipment change from its original incarnation (an electric typewriter with an interchangeable ‘golf ball’ for different fonts, to produce paper copy physically cut and paste with scalpels and glue on a light table) through our first proper computers (green screens attached to big orange boxes, which still produced paper for the light table) to its first fully electronic form (Macs with giant screens that produced files(. I also saw the impact on businesses and ways of working: how the flow of motorbike couriers to pick up copy at any time of day and night (print was always a deadline driven business) slowed and stopped as they were replaced by file transfer and email (but still at any time of day or night).
Architecture as balance #4: finding the time
Last week, Manoj Chugh asked me for my view on how architects should balance their time between strategic and tactical priorities.
I suspect that Manoj’s question was motivated by the feeling we all sometimes have, that there is simply not enough time: we set ambitious strategic goals and have lofty intentions to realise them, but those ambitions get overtaken by the sheer quantity of decisions we must take and problems we must solve every day.
I can’t even pretend to have a perfect or comprehensive answer to this problem. I could try to point out that strategy and tactics should not be enemies, because good tactics are just the actions which are taken to implement strategy. However, even when strategy and tactics are perfectly aligned, it is easy to feel as if there is just not enough time to get everything done.
I think that we have to accept that this is just part of life as a technology architect (and many other technology roles). If our job is to figure out how to deploy rapidly changing technologies in the service of customers and of business goals, then the number of things we could do will always exceed the number of things which we can do. In this case, then the best we can hope to do is to make the best possible use of the time we have.
Rough and ready rules for writing
In the HSBC Architecture team, we try to live up to the three principles of Zang Jing Ge: technical skill, communication mastery and leadership power. All of these dimensions are important, but in a Technology team of over 40,000 people, distributed around the world, communication is particularly important. Although it helps to work things out by writing them down, architects are often accused of being unclear in their written communication. In order to get better at this, we have built thirty two rough and ready rules which we try to practice every time we write a document or produce a presentation. They are not formal and not perfect and many of them may seem incredibly obvious, but they seem to help us, and I’d like to share them here:
Work things out by writing them down
On 28th February 1571, Michel de Montaigne retired to a tower in the Dordogne and began to write his Essays: reflections and explorations of such grand concepts as age, friendship and vanity, as well as more basic matters such as smells, drunkenness and the custom of wearing clothes. Montaigne called these explorations essays (essais in French) as he considered them to be trials (from essayer): ways of testing his own ideas, particularly his own understanding of himself, by writing things down. As a result, these essays - these trials - are digressive, discursive and full of both insight and contradiction.
There are many lessons we can learn from Montaigne, and many of his essays are surprisingly readable near 450 years later. However, I believe that the most important lesson which IT architects can learn comes from the nature of Montaigne’s whole endeavour: the importance of working things out by writing them down.
Rule zero: break any of these rules sooner than do anything outright nonsensical
In his essay Politics and the English Language, George Orwell proposed several rules for writing clearly: avoid dead metaphors, cut out unnecessary words, use the active rather than the passive tense and so on.
I think that the most important of these was Rule Six: ‘Break any of these rules sooner than say anything outright barbarous.’
In fact, I think that this rule is so important that those of us in the technology architecture profession ought to promote a modified version of it to Rule Zero, and let it stand at the head of any list of rules: ‘Break any of these rules rather than do anything outright nonsensical.’