After finding my reading mojo pretty much absent in 2020 I’ve been enjoying getting back into books this year. Part of that has been helped by two decisions. To get back to reading actual paper books to get some escape from screens and to avoid ‘work’ related books.
Then I saw this tweet from Aaron →
..and the next thing you know both titles had been ordered.
‘Kill it with Fire’ landed on my doormat first and as I was in a bit of a liminal time between projects I decided to dive straight in.
A book about how to deal with legacy software is probably not destined for the bestseller list but it definitely should find an audience amongst those of us making a living ‘transforming’ Government technology and services.
This book has jumped right into my list of books I’ll be recommending (and often gifting) to colleagues and clients. In fact I am seriously considering sending copies to all my team at Foundry4. While it is clearly aimed at Engineering Managers and the like I found it endlessly valuable as a product person. It flirts with being a technical book and definitely flutters its lashes at being ‘strategic’ but it is primarily an understandable collection of tactics, tricks and tools for succeeding when you are faced with big legacy technology that needs updating.
The fact that much of the authors experience has been in Government, NGOs etc means it feels particularly targeted at the kinds of issues I’ve faced over the years (and probably the same for most of you reading this.)
I think what I enjoyed most about it is it is endlessly pragmatic and gives as much attention to the people and political (with a small ‘p’) pressures these projects face as it does the technical ones. It makes suggestions on how to work with senior stakeholders (including some pleasingly Machiavellian options), how to maintain momentum and enthusiasm with engineering teams working on unglamourous hard projects, how to avoid change for changes sake (especially how not to just jump to the trendy tech of the day) as well as approaches for handling technical debt, design thinking for engineers and communicating ‘failure’….and much more.
Here are a few of my favourite (out of context) quotes just to give you a flavour →
“In poker, people call it resulting. It’s the habit of confusing the quality of the outcome with the quality of the decision…When things go well, we overestimate the role of skill and ability and underestimate the role of luck. When things go poorly, on the other hand, it’s all bad luck and external forces.”
“…digital forms frequently were built to leverage Acrobat-specific PDF features…A famous story about this…Department of Veteran Affairs’ websites refused to work unless you downgraded your version of Acrobat.”
“Particularly when the organisation is big, the pressure to run projects the same way everyone else does, so that they look correct even at the expense of being successful, is significant.”
“Too often, meetings are maladapted attempts to solve problems. So if you want to know what parts of the project are suffering most, pay attention to what the team is having meetings about, how often meetings are held, and who is being invited to those meetings. In particular look for meetings with long invite lists.”
“Metawork is more interesting than work.”
“I would, from time to time, run war rooms filled with senior executives…In that situation my team would run two war rooms: one where engineers were solving problems together and one outfitted with lots of fancy dashboards where I was babysitting the senior executives. The most valuable skill a leader can have is knowing when to get out of the way.”
“Don’t assume success is obvious.”
Digital by Default 