Blog

Granted. We do not know where we end up with our digital revolution. We do not see our emerald city. And we do not know how we get there. Moreover, we do not know our yellow brick road.

This reminds me of the problem to be solved by my diploma thesis in mathematics. There are mathematical equations, here so-called hyperbolic partial differential equations with boundary conditions, which are by nature of the beast unsolvable. Hence you are reverting to numerical methods to determine an approximated solution which is close enough to the real solution. Obviously you want to know how close you have come to the real solution. Which is a good question if you do not know the real solution, right? Unfortunately, these equations can be pretty relevant in the real world. For example, hyperbolic differential equations describe the vibration behaviour of aeroplane wings. In this situation, you want to be damned sure how correct your nearby solution is. Fortunately, with the help of pure mathematics, you can calculate the error you are making in your approximation. In essence, you are observing the behaviour of the equations rather than the actual solution. Out of this behaviour, for example the easily to be determined continuity in a so-called Sobolev space of n^th degree, you can derive how many iterations of the numerical method are sufficient.

So, what about finding a similar method to determine wether we are on the right path with respect to our own digital revolution? Wouldn’t that be wonderful?

As the saying goes, the devil is in the detail.

Common pitfalls

• How do we know whether a certain functionality should be built digitally or classically? (by the way; what is the difference anyhow?)
• How do we know whether we are investing too much into technology versus application functionality?
• How do we know whether a standard software offering advances our digital efforts or increases our technical debt (likewise for offerings of our system integrators)?
• How do we know whether a hyped technology, such as RPA and Low-Code, for example, is accelerating or delaying our digital journey?
• How do we avoid overlong vendor selection cycles? (Those have become years quickly meanwhile).
• How do we know whether our software product extensions, for example, machine or device control software, are a steppingstone forward or a future millstone dragging us down?
• How do we know whether our e-shop activities are future-proof or not?
• How do we know whether we have to build multi- or single tenant (which is of the essence if we want to sell software services as product)?

So, how do we know whether we are making a good or a bad investment on our digital journey? Keeping in mind that, of course, also suitable investments can fail, but at least we would have learned a valuable lesson then.

Let’s bring in some of the standard criteria:

• The customer is always right
  • Yes – but also when unequivocally piling up more technical debt?
• MVP* is the answer to all questions
  • Maybe – On the one hand agreeing on content and subsequently building an MVP takes too long due to classical wiring of engineers (I have seen three years MVPs which is an oxymoron by all means) and on the other hand an MVP which is like cement; i.e. cannot be changed anymore; is counterproductive, too.
• Applying at least one of the big four technologies (cloud, big data, AI/ML, IoT)
  • Yes – this goes a long way – but pure technology is never good enough.
• Living DevOps
  • Yes – great bet – but not sufficient because it does not determine the content.
• Employing “real” product managers
  • Yes – this is an excellent strategy – just a matter to find these rare species.

Hmm – sounds a lot like a new breed of software we must build for being digital …

I would venture that the gauge for progress in our digital journey is frequency of releases; i.e. how often do users get new experiences. This way we could table our progress:

(*) on average over three years at least

The implications of frequent releases are all-encompassing. They solve three fundamental problems of our digital revolution:

• Frequent releases ensure the right level of quality for our software services.
  • We just have not been used to those high standards in our IT efforts so far.
• Frequent releases ensure that we forget about the traditional way of planning.
  • Since we do not know where we end up any rigorous planning is futile.
• Frequent releases ensure overall simplicity.
  • “Everything should be made as simple as possible, but no simpler.” (Einstein)

The management operationalization of frequent releases is straightforward.

• We can set quantitative goals (which can morph into performance indicators as well).
• We can measure quantitative goals.
• We can control quantitative goals.

Last, but not least, creating such level of transparency goes a long way in (re-)creating the desperately needed trust into each other’s undertakings.

Have a beautiful journey.

Afterword

Probably you noticed that I discourage to attempt classical ROI** justifications at all. Instead, since becoming a software company anyhow, why not do it like them, too. In software companies, you set a top-down R&D cost budget which is a fixed percentage of the company revenue. This way of operating ensures that people take more risks while hedging the impact on the bottom line.

As you may have noticed, this piece is about the management operationalization of the Dreams & Details approach, see consultancy. Because for our managers we have to build bridges. Bridges which are connecting the classical world, which is still needed to guarantee our living, and the digital world, where things look different. Hence this paper tries to “rescue” some proven ways of managing. Is this perfect? Probably not. But maybe it helps.

(*)MVP – Minimum Viable Product, is a version of a product with just enough features to satisfy early customers and provide feedback for future product development.

(**)ROI – Return Of Investment. Financial measurement classically used in software companies to determine the use of resources for maximum profit.