- 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
When is the full stack too full?
Which prefixes would you like with your Ops?
Would you like some DataOps, some FinOps, some GitOps, some ChatOps, some DevSecOps, or would you prefer to go with classic DevOps? (You may, not, by the way, simply choose Ops.)
Since the dawn of the DevOps movement, the technology profession has seized on the idea that capabilities which were previously siloed and separated should be held by empowered teams with full accountability for what they build and what they run. This is a good idea. The alternative is to have diffuse accountability, degraded quality, teams that communicate with each other by queues and messages, long wait times and fragile systems.
DevOps and the case of the non-fungible DBA
The problem with many traditional, but wrong, ways of organising technology work is that they appear so reasonable.
If you have never organised the work to build a software system before, then it seems reasonable to organise it in the way that you would build a physical building, such as a house or a bridge. You make your plan out of tasks, dependencies and milestones, with blueprints written in advance, planning permission obtained, and predictable estimates for predictable work. Then you wonder why your plans are in pieces, your estimates are blown, and your bridge looks like a cross between a tunnel and a spaceport.
Similarly, if you are defining the operating model for a technology organisation, then it seems reasonable to group scarce, expert resources into pools, so that they can serve multiple needs at the same time. You create all the constructs that go with such a team: ticketing systems, SLAs, queues and prioritisation mechanisms. Then you wonder why everyone is waiting on everybody else, and no-one takes accountability when things go wrong.
Thinking differently about . . . DevOps
Last week, I claimed that technology leaders attempting to change the culture of their organisations should start with themselves. I think that this is especially true for technology leaders who are trying to introduce DevOps to their organisations. I am one of the people who have tried to do just that, and have not always been successful: as usual, this article is inspired by the opportunities I have had to make mistakes.
The concept of DevOps has been around for over ten years now, and has been described by more expert people than me, so I won’t attempt to give a precise definition here. (And I will also take this opportunity to say that, although I work for Google, a company which exemplifies many of the practices attributed to DevOps, the views in this article are my own.) I will, though, offer two ways in which I think about DevOps.
Double, half, quarter: a lesson from the book of Richard
A few months ago the HSBC Technology leadership team had the privilege of spending time with Jez Humble, author of iconic books such as Accelerate and The DevOps Handbook, and the co-founder of DORA (DevOps Research and Assessment ), now working at Google. Jez had many valuable lessons to share about the theory and practice of DevOps - all backed up by empirical data.
However, what stayed with me most from that day was not what Jez said (sorry Jez) but what Richard Herbert, our CIO for Global Banking & Markets said when he opened the session.
I didn’t have the presence of mind to record his words, but in my memory Richard’s introduction went something like this:
'I believe that our teams come to work every day to do the best job they can.
I believe that if we give our teams ambitious goals and let them figure out how to reach them, they will achieve things we never expected.
I believe that if we empower our teams and trust them, they will repay our trust many times over.
I believe that it is possible to go faster and break less - and we break less because we go faster.
In GB&M, we express these beliefs by setting every team the goal to double, half and quarter every year: double the frequency of releases, half the number of low impact incidents, and quarter the number of high impact incidents.'