- 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
- philosophy
- physics
- platforms
- prediction
- process
- procurement
- programming
- quantum
- reliability
- resilience
- risk
- robotics
- science
- science fiction
- security
- shadow IT
- space
- standards
- strategy
- talent
- teams
- technical debt
- technology advocacy
- testing
- thinking
- transformation
- TV
- virtues
- vision
- writing
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?).
The human path to legacy modernisation
‘We just need to change the funding model.’
I heard that phrase many times when leading architecture teams, and it always made my heart sink.
It was normally said with good intent by architects who were working on a problem which required long term, multi-year investment to build shared assets. Unfortunately, resources (money, people, leadership attention) were allocated to meet the focused needs of business divisions, rather than to create enterprise capabilities. Hence the lament that, if only we could change the funding model, we could give the enterprise the architecture that it really needed.
The team is the unit of transformation
In enterprise technology we like to count things: applications, petabytes of data, physical and virtual servers, gigabits of bandwidth and so on. Even if it's often surprisingly difficult to find them all and figure out what state they're, you know where you are with things.
It's not surprising, therefore, that when we attempt transformation, we often plan and measure success in terms of these things. We are shifting to a new operating system: how many servers have we upgraded? We are unlocking access to our data with APIs: guess many APIs have we built? We are moving to the Cloud: how many applications have we migrated?
The problem with measuring transformation like this is that it leaves out the most important thing: the people.