"There are only two hard things in Computer Science" applied to Business

What can we learn from the famous quote from Phil Karlton in the business context?

I just recently read a book where I stumbled over the famous quote from Phil Karlton and it resonated with me. It's been a while since we had our last caching issue, but just recently I had a call with one of our architects about naming things. Then I started thinking about the quote in the business context. Here is my take.

Cache invalidation - when humans are changing their behaviour

You might also experience this. Changing behaviour is somehow rather difficult. And then making it last - even more. It is the easier way when you are trying something new and you are intrinsically motivated. But even then, it is usually difficult to stick to a new routine.

The challenge rises further when things get abstract. And in organisations, things tend to be abstract. It is not a revolutionary insight that organisations often happen to be some sort of lethargic state - this is probably why organisations have a life-cycle and only few organisations get more than one iteration. Reasons for this lethargy are manifold. According to my understanding, leaders are often already having a hard time explaining the "why". If you want change, change should lead to a better situation - to something desirable.

So let's come back to the actual tagline "cache invalidation - when humans are changing their behaviour". To make a change initiative stick, you want to invalidate the cache in that limbo state between old and new. Especially in the "valley of tears situation", when you have disrupted the old world but you are not yet reaping the benefit of the new changed ways.

I am experiencing these situations again and again. In my case, it is that limbo state when we try to evolve from a fragile to an agile state in a team. When we want to shift from micro-managing, hedging and blaming to a rewarding way of working where transparency, collaboration and safety rule. But especially in this limbo state, it is very hard to get a team to really embrace the new world and for example being OK with failing a sprint.

To succeed, it is essential to unlearn - to invalidate the cache. It may sound obvious but it still seems to be challenging for some organisations. You need to walk the talk. Whenever there is a rift between good-practices which are told and behaviour an individual can observe, you have old pieces of cached data creeping back into the minds of the members. This should be prevented. I already touched this topic in one of my last articles - the commitment of leaders is essential. If the perceived leaders do not fully commit, how should you be able to convince others to follow? I am not necessarily talking about "hierarchical" leaders - these can also be the "informal" ones. And as everywhere, the mantra of standing up and trying again is applicable as well. The agile and lean toolkit provides us with many options how continuous improvement aka encouragement and experimentation aka scenario-thinking can work to invalidate the cache.

Naming things - from domain language to job titles

This is in my opinion a rather well known issue. Humans just don't seem to be that good in naming things. Only seldom I have experienced an organisation that was really good at naming their business-objects.

There are many things that can be off. And the impact should not be underestimated. I could start with change initiatives, but I'd like to ask you a question first. How does the "process" of naming things work out in your organisation?

Sometimes it already starts with the name of the organisation. Maybe it could also be something related to your organisation's mission/vision statement which is off. Still all good? Then we could have a look at the product names and job titles. Still all good? Latest when you dive into the domain language, things usually get slightly odd.

There are classics like the logistics company where accounting, IT and operations all understood something different when mentioning the term "invoice" - which may lead to costly adventures. And most organisations happen to have issues with something similar at some point. If there would be an easy solution to it, it probably wouldn't be a difficult thing. Here as well, it is a trade-off between speed of decision, fostering shared understanding and letting everybody having hers/his say. Depending on the context, it demands a situative response, but I would say the following patterns are probably not the most successful ones - mandating from the top, deciding without telling or outsourcing decision to a "Shared Service" without involving domain experts. So since we have the anti-pattern, we can try to construct a positive pattern. Probably a simple bottom up flow where domain experts can push naming decisions while still having "shared services" involved as an active stakeholder (quality assurance, knowledge management) may be a good course of action. Your shared services could be many things - Sales, Marketing, Data Scientists, Market Research, etc. come to mind - depending on the size, structure and configuration of your organisation.

But of course, we want to drill deeper. Think about a change initiative. Think about how you want to describe and name the initial state and the desired state. Especially in forced change initiatives like a "rightsizing", when something hits close to home, naming things is very important. Hitting the right tone for a change initiative which should lead to a turnaround or defining job titles when flattening your organisation's hierarchy is essential.

So what is the take-away for business? Looking at other domains like Computer Science can always be an inspirational thing. I've been able to deduct universal relevance form what is hard in the daily life of software engineers. Cache invalidation is a rather technical topic, but also our human brains need to invalidate or unlearn things from time to time. Give people room to unlearn. If you don't foster a organisational culture where people can unlearn things, how can they be open to new impulses? Naming things seem to be a universal challenge. Maybe I've slightly raised your awareness for this issue. Surely something where business can support by providing more feedback. A good practice could be to always provide access to people who can help you naming things, making simple but effective tools readily available and maybe even investing a bit into your own and your colleagues methodologies-related skills - to learn and unlearn successfully.