If, then, else: a foundation for good decision making

One of the things I have often taken for granted has been the ability to read and understand programming code or website script, and more importantly, the effect that has had on my offline thought processes. So am I an outlier, or do people who can code to some level of proficiency think differently and make better or more considered decisions?

I’ve managed, and worked with, lots of different types of people in my career. Most of them were not developers and most of them would have run a country mile if I’d asked them to tell me what a page of HTML script did, or showed them a page of C++ or .net or Java code. That said, many if not all of them have been problem solvers, business analysts, project managers and business function managers who have had to define and explain what they want the technology around them to do differently or start doing. Downside? Most of them have no idea how to talk to developers in a way that clearly expresses what they want the software to do, and not do, under various circumstances.

Most of my career has been spent translating these two worlds. I’m not a developer, far from it, but my understanding of the basic concepts of programming, database development and website creation has allowed me to capture and interpret business requirements and articulate them to developers. I’ve sat alongside non-code-literate colleagues doing the same role and, in my early career, was often baffled by what I saw as an inability to do this translation or, in some cases, even attempt it. It all seemed so logical to me and I struggled to understand why people didn’t think the way I did.

The need to think through a wide range of possible impacts quickly has never been more important.

It wasn’t until much later, when I began to run teams of my own, that I started to understand that the way I thought about problems was different to most other people. Most people, when you talk to them, can articulate what they want the outcome of a change to be. What they don’t do, without help, is think about all of the various permutations and variables on that outcome that need to be catered for. For a developer, that’s a pain. For a business, that’s expensive.

In today’s world, where the decisions we make as senior business leaders are increasingly real-time and the consequences felt within days not years, the need to think through a wide range of possible impacts quickly has never been more important. It’s not enough to simply say, “this is what I want to happen” and expect everyone to know what to do if something else happens instead. Customers are not as predictable as we might want them to be, and neither are our colleagues, and that’s OK. In fact, it’s better than that, it’s amazing. If we only ever got what one person thought of and wanted, we’d stifle innovation and many of our best ideas as a society would never come to fruition.

The problem with Humans is that we tend think in a linear way. And this is where my basic education in programming, combined with the demands of risk management from my project days, has stood me in good stead. Most people think along these lines: “if this happens then I want this to happen.” Simply put, I tend to worry about what won’t happen, or what might happen.

If you can plan for the exceptions, and be clear about the different outcomes in different scenarios, then you stand a much better chance of having a successful outcome

When coaching my team I try to get them to introduce some complexity to their thinking. “If this happens then I want this to happen, else I want that to happen”. Now we’re getting somewhere. But it’s not quite far enough. Gradually as you embed this thinking you can start to introduce more complex logic. For example, “I want this to happen for as long as a certain set of conditions is true, then I want to stop, or for something else to happen”.

Now, for some, this may seem obvious. Others will be baffled and see this as utter nonsense. For a few, probably those who code in one language or another, you’ll see what I’m doing. I’m embedding the basics of things like if statements and do-while loops, these bamboozling concepts that non coders assume is voodoo and terrifying, into the thought process of “normal” human beings. This helps them to translate business outcomes to developers more accurately but, beyond that, it encourages them to think about the exceptions and alternative paths their decisions might lead.

Now, if everyone in the organisation could articulate what they wanted in these terms, I predict that the success rates of projects would go up, purely because the outcomes and exceptions would be better thought through at an early stage. It takes the emotion out of the decision making process and replaces it with pure logic. If you can plan for the exceptions, and be clear about the different outcomes in different scenarios, then you stand a much better chance of having a successful outcome or at least predicting some of the other things that might happen and plan for those.

The best business analysts and project managers I’ve worked with think like this. Some of the strategists I’ve met along the way as well. They take problems and they break them down, consciously or otherwise, into these logic-driven statements and then articulate the various potential outcomes.

Recent movements in Agile methodologies have also helped, heralding the importance of prototyping which, in it’s own way, forces people to consider alternative outcomes they might not have otherwise. Frankly, anything that makes you stop and think, “what else might happen?” can only be a good thing.

For me, I’ll be forever grateful to that early education in foundation-level programming Whilst I never grew up to be a coder, the principles have stayed with me and, I like to think, made me a better business leader and decision maker as a result.

Digital real estate: who’s in your neighborhood?

The word digital has come to mean different things to different people, and the various parts of the digital ecosystem are often managed in different parts of an organisation. Does bringing it all together make sense? How do you land the right operating model and instigate a change to the current one?

It is not uncommon for a company to have its digital assets managed by different teams across the organisation. In fact it’s quite rare that they are all in one place. This isn’t necessarily wrong, but it does introduce some complexities from an operating model perspective. More importantly, it can also lead to a fragmented user experience for customers.

First let’s bracket the traditional (can we say “traditional” yet in digital?) elements of the digital ecosystem:

  1. Websites – still the cornerstone of a good digital proposition, these may be purely brochure-ware or they may have a more functional, transactional purpose
  2. Social Media – hard to find an organisation without a presence (good or bad) on social these days. Very important for customer engagement and a great tool to bring an audience to longer form content on your website
  3. Apps – an optional part of any digital real estate and will vary hugely in functionality and purpose. May be native (specifically coded for a particular device, such as Android) or wrapper (looks like an app but really just a website wrapped in an app shell)
  4. Email – don’t forget this one. Researchers into the effectiveness of email continue to contradict one another but this still remains a powerful part of a digital marketeers kitbag, if used well

Ask yourself where each of these tools are managed from in your organisation. Marketing? IT? I’ve seen many variations, up to and including a corporate LinkedIn account being managed exclusively by HR (admittedly, that was a weird day).

Whilst a case can be made for almost any operating and ownership structure when it comes to these assets, my experience is that, were you to walk into most organisations and ask why the current model exists, the answer is usually linked to evolution rather than design. It’s just how it is.

Difficulty with communication and consistency of design, tone of voice and customer insight aside, the impact on the customer is usually a fragmented and non-sensical experience. Why can I do this on their website but not on their app? Why is it really easy to navigate the app but the website is a pain? Why do I get an answer on Twitter but not on Facebook? Why do I keep getting these emails on the same day as the notifications from my app?

We’ve all experienced this kind of frustration with services that we use. One way to make sure that these kinds of inconsistencies don’t find their way to a customer is to bring together the different parts of your organisation that manage these assets into a single digital team. That way, you can bring together the design, development and marketing skills that are necessary to create, test and promote your digital services into one team. This gives them a much higher chance of collaborating successfully.

Doing so presents different challenges of course, not least that those existing structures probably won’t want to let go of what they have. However, it does cement a centre of expertise within your organisation for digital customer experience. Finding the right person to lead that team, someone who is respected and can think laterally across all of these digital arenas, is absolutely crucial. They need to be truly customer centric when it comes to the experience – to obsess over the details that transform an experience from just being ok to being something that excites and surprises.

And that, ultimately, is what it’s all about. The better the experience your customers have across your digital estate, the better they will feel about your brand. However you measure yourselves, be that NPS scores, complaint volumes, revenue targets or some other measure, defending the customer experience by seeing and treating your digital real estate as a single entity is, in my view, the most sensible step to driving those measures in the right direction.