Like all those of my generation, born in the 1970s, we entered a world without the internet, with no mobile phones and only three channels to choose from on TV. None of my friends had BMX bikes – which we all wanted – and in my formative years, I was the only one in my neighborhood who also dreamed of getting a home computer. At the age of 10, I recall using my parents’ typewriter to transcribe code copied from a computing magazine. Utterly futile of course, but such was the desire to become a programmer.

Fast forward six years and I took my first summer job prior to starting sixth form working as a programmer for a small consultancy firm. It was endlessly exciting. Writing a computer program is fundamentally about solving a problem. It’s an act of creativity to be asked, “Can you write a program that does X,” and then thinking through how, trying out different approaches until you get the desired result. Invariably the programs wouldn’t work. This was often because in the early days, computers were about as helpful as typewriters in spotting missing quotation marks, brackets or incorrect line number references. It required painstaking analysis, reading and re-reading each line of code to spot typing errors that were stopping the program from working. Another problem to solve!

Today, I work in delivery management running large-scale programs and services. While I no longer write computer programs for work (although occasionally tinker with PHP and Javascript in my spare time), looking back on my career, it now makes sense that progressing from programmer to program manager is not a path away from the creativity, fun and frustration of problem solving, but an extension of it. Program management and delivery management is – just like programming – all about solving problems. They are just different problems.

With programming, the question is, “Can you write a program that does X?” With program management, the question is, “Can you deliver a program that achieves X?” The difference here is one between outputs and outcomes. A programming success is usually binary: It either works or it doesn’t. A program management success is rarely so black and white. Successful outcomes are defined in value terms such as “improve customer satisfaction,” “reduce time to market,” “increase speed of innovation,” and so on. Understanding what success means in a program is one of the fundamental problems to solve. One of many, quite frankly, but knowing whether what you are doing is working or not is nowhere near as straightforward as checking lines of code for errors. This is a people business, where individual perspectives and opinions matter, and across the board. Multiple people, and groups of people, have a vested interest in the success of a program – sponsors, employees, end customers and the list goes on. Aligning these interests is one thing. Keeping them aligned is quite another. People’s opinions change, funding may change and even the people assigned to a program can change.

Dealing with change, uncertainty, complexity and sheer unpredictability is what delivering programs and services is all about. As with writing a new computer program, at the outset, you won’t know precisely the journey ahead and the challenges you’ll have to face. It’s an act of creativity, albeit bounded by best practice, proven methods, and so on. In delivery management, each day typically presents fresh problems, but they almost always do get solved. It’s how they get solved that matters. The tough ones invariably require teamwork, and it’s when you’re working with like-minded people who are dedicated and experienced in troubleshooting that you really get to appreciate being part of the amazing transformation involved – the passage from aspiration to actualisation. It’s an art.