Eight tips for a successful internal start-up – Centralized Protection and Control case study

Digital transformation is creating more potential for radical innovations. Internal start-up methods are strong tools which can harness this potential.

Digitalization and digital transformation are racing ahead, and no industry appears to be immune. According to Harvard Business Review, research shows that since 2000, 52 percent of Fortune 500 companies have either gone bankrupt, been acquired, or ceased to exist as a result of digital disruption. New digital and radical innovations are created and made available at increasing speed, forcing large corporations to find ways to be faster in benefiting from those innovations – to behave more like a start-up.

What are internal start-ups?

In innovation literature it is often described that radical innovations and future successes start from small teams and unconventional thinking, and from the willingness to accept higher risk levels. This is a challenging prospect for large corporations, which have the focus on predictability and incremental improvements for the existing and profitable businesses. To overcome this gap, a concept of internal start-up (also often described as ‘breakthrough teams’) has been developed for combining the speed of the start-up scene with the support from a large corporation. Internal start-up is a setup in which a company launches a separate (semi-)independent initiative to pursue an innovation or an idea. The purpose is to set up a team that has more freedom from the rest of the organization but is still integrated into the corporation.

Guidelines for a successful internal start-up

In literature there is a wide range of different recommendations related to setting up internal start-ups and/or breakthrough teams. It is also emphasized that no recommendation should be taken as-is but should be adopted and modified based on the business landscape and the radical innovation content. Due to the unpredictable nature of radical innovations there is no one formula that can be given. What works once does not necessarily work the second time.

However, the following high-level principles are common to all these recommendations:

  1. Small teams, a team setup in which the quality and relevant know-how of the team members is more important than team size
  2. More freedom in terms of corporate policies and R&D processes
  3. Physically separated from main development sites, preferably in one location
  4. Mix of new developers (new thinking) and old developers (domain know-how)
  5. Fewer interfaces with corporate and management
  6. Increased communication with end customers, connecting end customers more closely to the development process
  7. Short feedback-loop, allowing fast reactions and direction changes
  8. Minimum Viable Product (MVP) approach where intermediate results are taken into production use before the final product release

Centralized Protection and Control and the chosen approach

Currently the protection and control of electricity distribution networks is realized with protection and control relays. This paradigm is now challenged by a digital and software-oriented solution – Centralized Protection and Control. The concept as such is not new, but only the recent developments in digital technologies and standardization have made the concept technically feasible.

When the concept of Centralized Protection and Control was researched within ABB, it became clear that this concept is radical in nature. The flexibility and performance of the whole automation system was substantially increased, allowing for totally new ways to manage substation automation. To optimally grasp the innovation potential of this new concept, the R&D Technology Management in the Product Group of Distribution Automation decided to adopt internal start-up methodologies, when the time came to move from the research table to productization pipeline. The purpose was to provide more freedom and autonomy to the development team.

When the productization of smart substation control and protection SSC600 started, the core team was selected as a combination of researchers, product developers and subcontractors with relevant key know-how (first principle). Share of new developers was kept high (4.), and teams were physically separated from the main R&D development sites (3.). We started a deep cooperation with an end customer that was at the forefront of the industry, and who had good visions about the future, so that development was more directly driven by the voice of the customer (6.). The internal processes were relaxed in all other aspects except quality and reliability (2.). In fact, the quality and reliability requirements were even made stricter than normal. The solution went through full scale Product Verification Tests already in the alpha phase (8.), which is not normally done. But in all other aspects we identified the priorities directly from the customer instead of using the conventional requirement processes (5.). The chosen approach gave much more freedom and power to individual developers (7.).

The results

The result was excellent. We achieved the outcome that our partner customer valued, and the product was released to market last year. The indications from the market show that when you serve one customer well, you are likely to please other customers too. And the main benefit is the speed: you get to the market faster than with conventional processes.

Have you used internal start-up methods in your area, what were your experiences?

Categories and Tags
About the author

Jani Valtari

Jani Valtari works as a Technology Center Manager for ABB Distribution Solutions in Vaasa, Finland. He has a Doctor of Science degree in Electrical Engineering from Tampere University of Technology. He has held several development, research and management positions in ABB, and within the research community in Finland. He has authored many conference papers and been inventor in international patents. His primary areas of interest are innovations in smart grids and new substation technologies.
Comment on this article