I’m often asked what skills you need to work in innovation. Despite the prevalence of the term in industry these days, it’s not a formal kind of career that, for example, a software architect or project manager role might be.
So what do you need to be able to do it? In the first of a series of posts, I’ll walk through some of my own career experiences and how that helps in being an innovator.
Part 1: Get on the ground
The inspiration for this piece came from a lockdown-led reflection on some of the common themes in my career. And one of these is my need or desire to be at the point of delivery; the moment, space or people in your business where the transaction is completed.
To explain further, think about where you currently work today, or where you even might be reading this article right now. It’s likely to be either an office or home setting, far away from the core of your business. Those transactions rarely take place in your living room.
The point here is that, nice as our modern workspaces are, you don’t learn anything about your customers, your colleagues and even your business from your office. You need to be on the ground. Early on in my career, as a software developer, we employed a practice of working on-site with our clients instead of taking requirements back to base. In terms of productivity, it was immense; I can remember sitting in the middle of a used car sales retailer’s call centre with a remote desktop connection to our staging (test) server, writing code with call handlers around me. Not only were we able to diagnose and fix issues immediately, but you could solutionise – with our client – on the spot. We weren’t saving hours in the software development cycle; we were saving WEEKS.
Yet it was the exposure to the business directly that made the difference. I was sat with the very users operating our software, not their managers or even those at a senior level commissioning the work. Delivery deadlines were also easier to manage because our client was complicit in the decision-making on-site; these were decisions taken together, rather than at opposite ends of a conference call where the battle lines are easily drawn.
The same project in my example evolved to include a car finance module that I was responsible for. I coded a front-end interface to collect the proposal data, and then wrote a separate application to send it across securely to several finance companies. It all worked okay in the week when I was employed to work on it, but our end users complained about performance glitches at weekends when they were at their busiest. There was nothing else to do, but spend a Saturday in the local finance office at one of their sites.
It was an amazing experience. I took a small space with my laptop at the end of one of the desks, and remotely accessed our live server to help diagnose any of the finance proposals that came through with issues. Not only did we – we being the finance team in the office and myself – make lots of fixes and improvements, but I had a whole new world of understanding in terms of how our software was used. It was so productive, I repeated the exercise a few months later, and my boss even become a used car salesman for the day, to test software in another part of the process.
The moral of the story here is to break down that ivory tower. It’s no use guessing what your users need or want, and listening to them on the phone or conference call is useful but doesn’t move the game on. Sit with your users, walk-the-walk; even eat your own dog food, as Microsoft calls it, to understand your business or your clients’ more carefully.
Digital Is Not Rocket Science 