- 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
- films
- 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
- science
- science fiction
- security
- shadow IT
- space
- standards
- strategy
- talent
- teams
- technical debt
- technology advocacy
- testing
- thinking
- transformation
- TV
- virtues
- vision
- writing
Do you need an umbrella or a lifeboat?
How do you prepare for things that just keep on going wrong? And how do you prepare for the day when everything goes wrong?
Last week I attempted to distinguish between reliability and resilience, claiming that reliability is the ability to keep services running despite routine failures, while resilience is the ability to restore essential services despite unexpected catastrophes. But that basic definition is not quite enough to disentangle these related but distinct topics. In this article, I’ll explore three more important differences between reliability and resilience.
Reliability protects normality; resilience strives for survival
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.
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.
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.