Digital transformation is still top of the agenda for many CxOs. All of a sudden, competitors, who were previously not even on the radar, are tapping customers using software-supported services. The value created so far is at risk of becoming a dependent ancillary service. This does not apply to the same extent to all value creation models. An airline, for example, enjoys more protection from substitution than a taxi company. However, the widespread availability of low-cost computing devices represents a potential substitution for nearly every kind of measurement, control or distribution system. The opportunity to provide supplementary analysis information within the application context is an invitation to enter the market for clever software solutions, which in turn represents a threat to the direct customer relationship.

I therefore recommend that all companies familiarize themselves with the basic principles of the “digital” company, to ensure that necessary changes will be implemented as soon as possible.

At EACG we have helped several companies over the past few years to deal with innovative approaches and business models. In doing so we have made a number of observations, which differentiate the more successful from the less successful approaches. I would like to share and discuss some of the most important observations in this series of articles.

Organizational characteristics of a “Digital Company”

Although we at EACG have been using the term “digitization” since 2012 for our consulting practice, I am not completely happy with this rather unspecific (and also actually incorrect) term for such an upheaval. In my opinion, the term “eBusiness”, coined at the beginning of this millennium, suits much better and also sounds more charming. But let’s focus: What does the “digitization” of a company actually constitute?

To outline some of the key changes, I will highlight the differences between a digital and a traditional company by looking at the following few aspects.


A traditional organization relies on resource pools and project organization. During the eighties and nineties, the line organization had to learn from the project organization. Flexibility and specialization were the driving forces. And this was correct at a time when repetitive activities involving mid-level skills were organized or optimized with the help of projects.

A digital organization can be seen as a unit comprising of knowledge domains and intelligent employees owning and operating them.

A digital organization, on the other hand, can be seen as a unit, which comprises of knowledge domains and intelligent employees owning and operating them. It therefore replaces the paradigms of the project organization and instead favors dedicated teams. Members of a team stay together, get to know each other and optimizes themselves. The team assumes full responsibility for the development and operation of the services it creates.

The change of focus and the responsibility nirvana associated with the end of a specialist assignment, a typical phenomenon of a resource pool organization, should be prevented. The tying of a team to its performance serves to ensure that it can identify with what it has created while motivating quality assurance and growing experience. This form of organization incorporates the understanding and, implicitly, the experience that mistakes will fall back on you. Thus error-free production will increase output and as such directly visible success.

Processes and players

It has long been known that a software development process can be designed efficiently when using a SCRUM-based approach. However, the extent to which the SCRUM methodology can determine the organization may vary strongly. I do not want to praise SCRUM as the cure for everything, and I would not dare to claim that an effective application of SCRUM, up to and including SCRUM of SCRUMs and maybe even SAFe, will digitize the company. In fact, by focusing on the methods, there is the risk that key design aspects might be missed.

Neither SCRUM nor SAFe alone will turn an organization into a digital company.

On the other hand, a lack of SCRUM can be an indicator that a company is clinging to traditional values and ways of thinking. If, for example, only the development unit is working with SCRUM-based methods, but not the quality assurance unit, the principles of responsibility intrinsic to the SCRUM methodology cannot take hold. But even if supplied with testers, if the SCRUM teams do not operate their solutions by themselves, they will not receive the feedback from operations; the team is no longer linked to the business itself, lacking the required corrective.

However, it is not just the production function itself may be flawed, also at the input side of the function a lot can go wrong. A key function within the SCRUM approach is assigned to the “product owner”. This person identifies the user stories, the work basket which the team needs to resolve. The term “shit in, shit out” applies here, just as it does to any normal production activity. The quality of the activity is crucial for the success of the company.

Whereas traditional companies still like to send a representative of the actual production manager, in a digital company the product owner has a lot of decision-making powers and usually works in close cooperation with the customer. Ideally, the product owner will be responsible for the product, can make decisions quickly, and has backers who can help to create user stories and acceptance criteria based on the product owner’s product vision. In a truly digital company the product owner must also report to the investment committee. This makes him a real driving force behind the development of the product and the company.

The traditional line managers take a step back and assume supporting roles, such as the provision of necessary basic conditions: a motivational environment, a well-organized team, coaching and employee development or support with escalations.

Continuous improvements

I would like to mention one more aspect, which is actually similar in both worlds, but often seems to be interpreted differently, most likely due to different designations and characteristics: Every good production company is aware of continuous improvement (CIP) meetings, in which QA managers and industrial engineering experts review performance indicators and seek for further optimization. Process compliance and the foresighted creation of key figures are at the heart of every successful CIP.

All this applies to the same degree to software development. With SCRUM, a hard-as-nails procedure has been developed, that matures software development with a continuous improvement process. Taking the human production factor into consideration, suitable mechanisms for increasing efficiency have been established, which, when used altogether, will generate productivity. Unfortunately, this is rarely correctly understood. Presumably nobody would think about implementing a CIP without a quality manager. However, the need for a SCRUM master is still often questioned. Nobody could imagine CIP without key performance indicators (KPIs), but SCRUM without sincere estimations and velocity tracking can be found surprisingly often.

Nobody would imagine CIP without KPIs, but SCRUM without sincere estimations and velocity tracking can be found surprisingly often.

Every success-oriented organization needs a continuous improvement process. The implementation of a solid, comprehensive SCRUM approach within a software organization is just as important for the effectiveness of software development as the implementation of a CIP for production. It should be carried out with the same level of priority and taken just as seriously.


Another key aspect of creating agility: funding vs. budgeting. Traditional organizations muddle through their annual budget rounds. Depending on the size of the organization, such a process may take 3 to 6 months to complete. Only after the official agreement, the allocated project budgets can be spent, enabling teams to look forward again and start implementation. In any case, it will all become critical and difficult for anything that had not previously been identified or known of. At the end of the financial year, the carefully saved budget funds then are spent as quickly as possible to avoid future cuts.

This is something that is unheard of in a digital company. Such companies have continuous portfolio and funding management. Good business cases receive the required budget as soon as an investment committee has accepted an idea. And of course only good employees provide good business cases. The preliminary work for a good business case needs between 6 and 12 weeks to complete, depending on the domain. If a product manager is able to invest this time in an idea – methodical advice and support could be provided – and if they believe in their idea, then they will also have the ambition to deliver the MVP successfully. If the MVP is positively received, and the agreed KPIs are be reached, funding can be provided to ensure product success. This opens up significant opportunities for capable employees, and therefore increases the attractiveness of the company for talented people.

The necessary restructuring of the financing mechanism, from budgeting to funding, can only be driven from the top

The restructuring of project financing, from budgeting to funding, can only be driven forward from the top. The mere idea of interfering with or even touching the traditional budget process is enough to let even senior managers shake in their boots. To ensure that quick progress is made in spite of this, we at EACG first of all recommend talking to the CFO to agree on the provision of an appropriate amount of funding within the scope of the existing budgeting process and test the procedure.

Success must be wanted

The fundamental principle of the digital organization – trusting employees and their skills – needs the space that is created by using agile methods, allowing the creative potential of the employees to unfold. However, like a state, the organization must ensure that behavior is in compliance with rules. Simply announcing new rules is not enough. Only if everyone has a common understanding of the rules, and everybody can rely on them being applied, trust will start to grow and creativity will be mobilized. Line managers and SCRUM masters are responsible to achieve this trust. To motivate and guide them, is the responsibility of top management.

Therefor the same applies to Digital Transformation as to all organizational changes: it must really be wanted and understood from the top in order for it to be successful.

For Digital Transformation applies the same as for all organizational changes: To be successful, it must be really understood and wanted from the very top.

A lot of courage and determination is needed to restructure an existing organization, that probably has not even yet experienced any pain. Not all employees will welcome the new responsibilities or recognize this as chance. Such candidates should be identified and inspired.

An insufficiently developed culture of error tolerance, the missing ability to learn from mistakes in an open and honest manner, will lead the digital transformation to failure. A culture of blame and finger pointing eliminates the space for experimental failures and kills the desired creativity. This is true for all forms of organization, but no other form is so dependent on creativity as the driving force. Understanding and realistically assessing one’s own situation is therefore extremely important when it comes to choosing the most appropriate transformation measures. Probably “all digital” is not always the best next step.

Probably “all digital” is not always the best next step.

Parallel organization

As a responsible decision-maker, the concept of the parallel organization should definitely be taken into consideration. The basic idea is to maintain the existing business in the proven form, while at the same time setting up a new organization aside building the new culture from scratch. Let it build success and earn respect through success and gradually integrate existing products and transfer cash streams. This approach offers many advantages, but also adheres the risk of alienation. However, the latter can be managed more easily than the consequences of an unsuccessful transformation of the existing organization.

This is the second article in a series on digital transformation. The first article dealt with the values of a digital organization (Cultural Differences). In the next article I will take a look at the impacts new compensation schemes will produce and how they can be addressed.

Do you need to transform an organization but don’t know where to start?