I’m David Knott. I’ve been working in enterprise technology for over forty years and I’m still learning. This blog is based on mistakes, failures, lessons and some things I find interesting:
Building the leadership team: more than a seat at the table
How inclusive is your leadership team? Hopefully it is inclusive in all the dimensions of diversity, but do you actually include all of your leaders as genuine parts of the team? Or do you think of some parts of your leadership team as ‘core business’ and other parts of your leadership team as ‘support functions’?
Regarding your team in this way creates an implicit hierarchy of leadership positions, even if all leaders enjoy similar grades and reward packages. Metaphorically, the CEO, or head of the business division sits at the head of the leadership table. The people who run revenue generating business divisions are clustered close by. The CFO may sit at the leader’s right hand, depending on the financial position of the organisation. But the head of HR is probably further down the table, while the head of IT is down the corridor fixing the printer, and the head of procurement is out at the shops, haggling over prices.
Learning the fundamentals: beyond the IT slot machine
Business executives often experience their IT department as a slot machine: something that consumes money, occasionally gives a payout, and whose inner workings are opaque and inscrutable.
Sure, sometimes the slot machine gets new lights and buzzers which claim to give an idea of what it is going to do (project plans, progress reports and dashboards), and sometimes it gets new buttons which make players feel as if they are in control (steering committees, governance processes and change boards). But the machine still seems to keep on doing the same old random things, as if the lights, buzzers and buttons weren’t actually connected to anything.
A suggested New Year’s resolution: be more curious
When I was growing up, my Dad and my uncles were always working on cars and motorbikes. This was partly through need: they didn’t have much money and they had to travel for work, studies and family life, so fixing a car using spare parts, ingenuity and improvisation was an essential skill. They also enjoyed it: it was as much of a hobby as a necessity.
It was not a practice I ever acquired the skill or the appetite for. I was much more interested in reading books than getting my hands covered in grease and oil. I enjoyed spending time with my Dad and Uncles as they struggled to fit strange shaped pieces of metal into strange shaped spaces, and as they scoured scrap yards to find an old car with the right part. But I never really understood what they were doing.
This Christmas, give yourself the gift of knowing that your work isn’t boring
‘Sorry, this is the boring bit.’
When I hear those words, my heart sinks almost as much as it used to when I heard someone declare that they were not technical. In the field of enterprise technology, they normally mean that the speaker is about to attempt an explanation of technical detail to an audience which includes non-technical people.
Perhaps they are going to explain to a product manager why the system built for a hundred users can’t scale to a million without extra infrastructure. Or why it’s not a good idea to put a system which holds customer’s personal details into production without security testing. Or why, while it might be tempting to make the chat interface available to every user, someone has to pay for all those tokens.
Don’t settle for horses when you could have dragons
Sometimes, when we are talking about technology, we quote Henry Ford, who said, ‘If I had asked people what they wanted, they would have asked for a faster horse.’
Except that Henry Ford never said these words. They were first associated with him in 1999, when an article by John McNeece suggested that, ‘There is a problem trying to figure out what people want by canvassing them. I mean, if Henry Ford canvassed people on whether or not he should build a motor car, they’d probably tell him what they really wanted was a faster horse.’
Learn to fail fast? Technologists fail all the time
From time to time, organisations attempt to learn new ways of working. They attempt to become digital or agile or data-driven or innovative. These attempts come with some familiar ideas: that we should execute through cross-functional teams who are empowered to experiment. One of these ideas is that we should not be scared of failure, and that we should learn to fail fast.
These attempts sometimes elicit eye rolls from the technology teams, especially the idea that we should embrace failure. This is not because these ideas are invalid: in fact, they are welcome to technology teams, and reflect their preferred ways of working. However, technologists have a different relationship with failure than non-technologists.