Second-system effect

When building products and introducing new technology, I regularly see the second-system effect: A simple, well-functioning system reaches its limits and is then replaced by a much too big, bloated, overengineered system due to exaggerated expectations and exaggerated self-confidence – and everyone is unhappy. 🙂

You may have heard of it. In my practice, for example, a small hip social media agency introduced an agency software that was designed for old, large, classic advertising agencies with print processes. Or, there was this eCommerce startup introducing Microsoft’s Navision, and then at the end of the day uses only 20% of the originally introduced functionality and has replaced or added 80% of it, with its own customization.

Branch by Abstraction

In software engineering there is the principle of Branch by Abstraction. But this can also be applied to the development of products and introduction of systems in the company.

In a Nutshell

Never change featureset and underlying system at the same time.

Only introduce new features or other processes after a new system (with old scope) is established!

Step by Step

First of all, analyze the status quo: What is currently used, what works? Is everything based on an Excel / spreadsheet? Which workarounds are currently being made?

Based on this, a lean software can be built or introduced, which, however, from the point of view of the feature set, in version 1.0 only maps the current usage and imports current data. No more and no less. This is probably implemented relatively quickly. Then the previous processes and procedures can be applied with the the new software.

Then, in short sprints, adapt the system to the actual requirements. It is advisable to use a two step mechanic here:

  1. Which processes can be optimized in principle (in the department, synchronization with other systems, etc.)
  2. How can this be represented in the system?

Finally, I would like to empathize once again that one should think here more from the user than from the technology:

Because a bad process that has been digitized is still a bad process

Bullshit from every digital transformation consultant, ever.

(This entry is based on a real email I wrote to a startup, that is currently growing out of its spreadsheet)

Published by Klaus Breyer

a CTO and Startup Founder/Advisor, living in Berlin.

Leave a comment

Your email address will not be published. Required fields are marked *