- 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
Build a movement, not an enclave
The current wave of AI products have been around long enough for enterprises to launch ‘AI transformation’ initiatives, to wonder why those initiatives aren’t yielding the results they hoped for, and to reach for new ways of working to try to jolt them into life.
For people who have worked in technology for more than a few years, this cycle is familiar: a new technology becomes generally available (cloud, mobile, web, Big Data and so on); bold claims are made for the impact of that technology (cut costs, improve customer engagement, make better decisions and so on); initial projects fail to make that impact; big transformation programmes also fail to make that impact; enterprises make organisational changes to try to get the benefits they were promised.
If you have seen this cycle many times, you have probably developed several survival tactics: try to get behind the hype and learn the fundamentals of the new technology; learn what it can do and what it can’t do; calm unrealistic expectations; salvage value from failures; and, ultimately, work with your peers to develop sustainable professional practice.
Locally rational; strategically irrational
Enterprises frequently find themselves sliding down the slope from strategic rationality to strategic irrationality, while acting in ways which seem locally rational. To put it another way: if everyone’s so busy, how come we’re not going anywhere?
Working for a large enterprise can feel like being on a ship where the boiler is being stoked, the engines are churning, the propeller is turning, the kitchen is turning out meals, the brasswork is being polished, but, when you look out the window, you are still at the dock.
Actually, that might be too optimistic: many enterprises feel like a ship where the coal is being delivered to the kitchen, the stewards are working in the boiler room and the navigator is holding the charts upside down.
And if you work in technology, it often feels like the engines are overdue for a service, steam is escaping from the valves, and the pumps are struggling to keep the water at bay, but despite the constant, frantic activity, basic maintenance does not seem to be anyone’s job.
Build systems like you hire teams
Despite advances in AI, software systems are not people. But perhaps we should sometimes treat them like people - at least when it comes to budgets and financing.
A couple of weeks ago, I claimed that building software is not like building a bridge, and that the analogy of construction which we use - which I use - so frequently, may be harmful rather than helpful. Rather less usefully, I also suggested that there aren’t any perfect analogies, and that the best way to think about building software is to understand the business of building software. I’m now going to contradict myself and suggest another analogy: that we should think about building software in the same way that we think about hiring teams.
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.
Five pieces of advice for technical leaders
What advice would you give someone taking on a new technical leadership role? As I wrote a few weeks ago, technical leadership matters, but there are few resources to learn technical leadership, so we have to rely on what we can learn from each other. I’ve been privileged to work with and for some great technical leaders who have been generous with their advice. Fortunately, advice is one of those things which gets more valuable the more you pass it on, so I thought it might be helpful to share a few bits of advice which have helped me.
Don’t panic
In the field of enterprise technology, things go wrong. All the time. If you have an operational role, then you spend much of your time dealing with incidents. If you have a change role, then you spend much of your time dealing with obstacles to delivery. And if you have embraced DevOps (as we all should) then you get to deal with incidents and change obstacles at the same time.
Give your legacy teams room and respect
What’s the best thing to give the teams looking after your legacy systems?
I was fortunate to be invited to sit on a panel at techUK's Building for a Smarter State conference last week. The topic was legacy, and the discussion prompted me to consider this question.
I’ve heard many answers to this question in my career, on a sliding scale from optimism to cynicism. I’ve heard optimists say that the best thing to give these teams is hope: the opportunity to learn new skills, to adopt new ways of working, to embrace new challenges and new solutions. And I’ve heard cynics say that the best thing to give these teams is the sack: they are stuck in the past, burdened with outdated skills and ways of thinking, and unwilling to change. Fortunately, the optimists have outnumbered the cynics, and we had no cynics on last week’s panel.
However, I think that there are two more things that we should give the teams running legacy systems: room and respect.
5 Ps: ingredients for technology success
There are lots of ways of organising a digital or technology capability, and I’ve tried many of them. Most of them don’t work, resulting in slow, bureaucratic organisations which fail to realise the full potential of technology. However, over time, through difficult lessons learnt in many different places, I have come to believe that there are five ingredients of a successful technology organisation. They all begin with the letter P, so let’s call this the 5 Ps model. It can be described something like this:
Platforms are highly homogenous, standardised, software-defined technology capabilities which enable products to be built at speed, with confidence that they will scale and be reliable and secure.
Products are highly specialised functional capabilities which deliver value to end users.
People are people! But the talent and capabilities of the people who do these jobs matter, as does the level of trust and autonomy they are afforded. In this model, people are expected to to be trusted experts with the power to manage, develop and continuously improve their products and platforms.
Practices are common ways of working which unite people who are otherwise distributed into autonomous platform and product teams. They are at least as much cultural as they are formal, and are driven by the pride and experience of expert professionals.
Performance comprises a set of meaningful metrics which describe the success of platform and product teams, and which are owned and driven by those platform and product teams.
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.
Is there a human shaped hole in your technology plans?
If you’ve been watching The Last of Us then one of the things you will have noticed (alongside the great acting and story) is the eerie feeling of a human world with no humans: an empty world except for nature, a few survivors and, of course, the infected. I sometimes get that same eerie feeling when looking at plans for technology change: where are all the humans?
This is strange, because humans have been at the heart of new movements in the ways we build and run technology for decades.
The Agile Manifesto was published in 2001. Almost all of its 73 words (including the title) concern people, behaviour and communication rather than technology and tools. (Indeed, people and behaviour over technology and tools could almost be a line from the Agile Manifesto.)
The first DevOps days conference was held in 2009. You can still go and read the program (although if you try to follow the links to other sites in the reactions section, you get a great demonstration of link rot). While a lot of the agenda was clearly quite technical, much of it was focused on people, behaviours and communication. Do user stories really help express non-functional requirements? What does automation mean for sysadmins and development teams? How can practices followed by software developers be applied to operations?
Conway’s law: power, money, capability and the duty to explain
Conway’s law is one of those, ‘Of course!’ concepts: a concept where, the first time you hear it, you say, ‘Of course!’ It reveals something which you always suspected about the world, but couldn’t quite put into words.
Conway’s law answers the question, ‘why are so many computer systems so strangely organised?’, with the idea that the structure of systems follows the structure of the teams that build them. Melvin Conway didn’t quite put it like that in 1967: he said, ‘Any organisation that designs a system (defined broadly) will produce a design whose structure is a copy of the organisation’s communication structure.’ (If you haven’t heard of Conway’s law before, but have encountered many strangely designed computer systems, you may be experiencing your own, ‘Of course!’ moment.)
There’s plenty of room on the cloud: enough room to make mistakes?
We all make mistakes, especially when we are building and running enterprise technology.
Sometimes mistakes happen because we simply get something wrong (remember that time that you ran the script to delete test data, forgetting you were working on the production system?).
Sometimes mistakes happen because we haven’t got enough information to be right (remember that package you bought just before the vendor was acquired and the product discontinued?).
Sometime mistakes happen because we haven’t acquired enough experience to know how to avoid them (remember when you kept applying the old security policies to the new environment before realizing that they weren’t needed any more?).