A quarter of a century ago this month, I got my first job post-university as a Technical Consultant, joining a startup as its first employee. 25 years is a long time, and technology as we know and use it has changed beyond all recognition. I’ve since worked in seven different businesses in a mixture of IT, Digital and Innovation roles and to reflect on this anniversary, I’ve picked out five principles that I’ve learnt and stuck by as my career has developed.
Spend time with users
I was fortunate in my first job to spend a great deal of time working on-site with clients. One of the solutions I worked on was an intranet-based call centre system for large used-car dealer groups. To shorten the time it took to complete or add functionality and fix things quickly, we’d work literally side-by-side with the people using our software. I’d be remotely connected to a web server in the middle of a call centre where I’d fix issues as they came through. I even gave up a couple of Saturdays to work with the car finance teams – their busiest day of the week – to improve the reliability and accuracy of our API to the finance companies.
Just watching users and listening to them was invaluable. While once helping a car dealership start using an early Kodak digital camera (that’s how long ago it was) to photograph their stock for the web, the software vendor had a requirement that the JPEGs needed to be saved with the filename as the car’s registration number. I realised quickly what a headache it was for users to do this: download the photos from the camera, open them to read the registration, close and rename each file before uploading to a server. I ended up doing a lot of this myself to try and bump-start the process. One afternoon, I thought of a way I could achieve this more quickly, so I rushed together a Windows application (in Visual Basic 6.0, if you remember it), christened it PhotoStock, and tested it with a couple of the staff. Feedback was positive, so I tidied it up, showed it to my boss and the client’s senior managers. We subsequently rolled it out to five other sites, and a new software sales stream was born. All from working on the shop floor.
And remember, your users aren’t always people tapping phone screens or clicking mouse buttons. When one of our passenger-facing trials was underway while I worked at Heathrow Airport, observation was a core discipline of any successful trial. Any spare hours in the day would be spent simply observing passenger behaviour at a distance, often with a coffee in hand, to look at their interaction with a solution. Users are unpredictable, strange and a bit mad at times, doing things you simply cannot see during regular testing, so spend as much time with them as you can. You can only learn good things.
Poachers and gamekeepers
During my career, I’ve worked with many people who have either transferred their skills into technology or are able to use their experiences to get more from it. When I worked in healthcare marketing, there were many former pharma sales reps working for our design agency. This gave them an enormous advantage when pitching at pharma clients: they’d have an acute understanding of the challenges of landing key marketing messages with healthcare professionals – because they’d done it themselves in the past. The same applies to today’s plethora of LegalTech startups; many founders I met would describe themselves as “recovering lawyers” – usually followed by a wry smile – who had spotted an opening in the market that technology could solve. Today, I work with several former civil engineers who now utilise the latest AI technology to save time and money in large infrastructure projects, because they know how a project comes together, and therefore what good looks like.
My software development experience served me well here, particularly when working closely with startups or scale-ups. Their technical and business challenges mirrored most of my own, so I find a kindred spirit quite quickly. Being able to “solutionise” (work out how to solve a problem using technology) is software design itself, and I still rely on these experiences extensively today.
The point here follows the old adage of surrounding yourself with experts. Technology is very similar across most verticals but every industry is different, so as a technologist, you need to focus on bridging the gap between subject matter experts and technical solutions.
Cloud was the silver bullet in the end
If I’m asked what the most transformative piece of technology I’ve seen in a quarter of a century, I’d have to say cloud technology. Even the success of the smartphone – probably the most obvious candidate for this award – has the cloud to thank for its scale and distribution.
Cloud computing might just have invented the word “scale”. The migration to it wasn’t really overnight, but it changed EVERYTHING in terms of technology. There was the old way: days of endlessly buying and upgrading noisy servers to sit in the corner of offices, and today the new, where performance and storage requirements are mere slider controls on your cloud host’s web pages. Cloud drastically changed the way software is built and deployed too. Distribution was always the enemy; the move to browser-based solutions helped, but you’d still need to develop, test and compile something to sit on a web server. The latest DevOps platforms continuously compile and distribute your code in the background, which saves unbelievable amounts of time and effort. Some professional roles I used to work with, such as Configuration Controllers – who would migrate and compile code between Developers, Testers and the Live environment – simply don’t exist any more thanks to the cloud.
For business, these benefits go further: the so-called “evergreen” Enterprise platforms, such as Salesforce and Oracle, never require any software upgrades by your IT team. Everyone is on the same version at the same time, everywhere in the world. No overnight outages, cost of hardware upgrades to match the latest versions – it’s all gone, and for the better.
I think AI will be the next silver bullet.
Technology is like Shrek: it has layers
A significant part of my career has been spent talking about the use of technology in non-technical ways to non-technical people. It’s patronising to gloss over just how the tech actually works itself, but complicated at the same time, so it’s best thought of using Shrek’s brilliant onion analogy from the film.
Each layer of technology is abstracted from the next in the way it is constructed, operated and authored. Think about how software operates, from the end user all the way down to the hardware chip designer. Each group will likely have nothing to do with each other, but they exist and contribute something in their own way. And over the years, those low levels of discussion with clients or end users about their software has evolved into higher level principles of guidance. For example, keeping a human in the loop as you experiment with AI.
This is also why when talking about tech, it’s best actually not to talk about tech at all. Rather, focus on the business outcomes or benefits and then tag the technology on at the end. For example, “this design optimisation software reduces the duration of the project and therefore the cost … utilising the benefits of Artificial Intelligence”. Don’t start with the tech itself – you’ll lose people.
It’s vital to try things
The last decade of my career has been in innovation roles, where technology is put through its paces to enable creative leaps forward in capability, efficiency and user experiences within enterprises. This sits well with those years of working on sites with users as we were always prototyping new things.
Barack Obama said recently “…just figure out how to get stuff done”. It’s a wonderful adage to live by, and speaks to the trial, which, in my view, is the absolute cornerstone of innovation. I’m a fan of creative thinking and approaches (such as Systematic Inventive Thinking) as they can break down problems into solutions quickly. But they’re not trials; they’re not evidence of success or something just working correctly. The trial is everything: it is the empirical evidence of benefits, insights and risks into how a solution performs. The trial teaches you how the rollout will look and how users will interact. It absolves you, your colleagues and your business of any doubt of the solution adoption risk, because the trial does the work for you.
The trial also brings people with you; arguably the hardest part of any kind of business change programme. If colleagues can see and experience the evidence of a solution, it does all the necessary convincing and stakeholder development at the same time. A demonstration of the trial in action to senior managers is vastly superior to a Word document pitched at a funding panel. Those people become advocates. At Heathrow, I worked on a trial to digitise paper cargo checks. We shared the ruggedised tablet with security officers while on their break. Their feedback was completely uniform: “when does this go live?”. The business case subsequently wrote itself.
I’ve documented those trial principles separately and at some length.
The message here is simple: try stuff out. It’s what I hope to continue doing for the next 25 years.
Digital Is Not Rocket Science 
Leave a comment