In this article, Dr. Heuer outlines the core work unit for a modern Research & Development organization: the inNode. This team structure is a departure from the traditional functional separation of skills and responsibilities. In his experience, it generates better results faster with less waste.

Tradition

The traditional approach for Advanced Product Development in R&D functions is to gather a team of scientists and engineers and let them play with the latest technological discoveries. When they are done, they propose a few new product ideas. Usually, this is done in a Dog & Pony-type show with executive management. Suitably impressed with the whiz-bang on display, these executives are renewed in their conviction that R&D produces some interesting ideas. They also order the mainstream organization “to do something about this”.

And they will do “something”.

Mostly, these prototypes will go the way of Bruce Banner’s equipment cellar: they gather dust. Not because they are bad, but because the core organization does not see the benefits for them, a way to make it happen or even understands what they could do. They need product innovation in a digestible form.

This is a classic example of communication going utterly wrong.

Communication at the Root

Based on my experience, I propose to attack the root cause of this dilemma by molding teams that make communication and collaboration across functions their main purpose. I call those teams inNodes (for Innovation Nodes).

The Makeup of an inNode

An inNode is made up of six roles or skill bases that need to collaborate to make innovative product development more efficient:

If you pick the right people and give them the opportunity to spread their wings and put compensation as a carrier behind it you almost don't have to manage them.

Jack Welch

• Product Developer / Project Manager
• Finance Professional / Business Modeler
• Marketer / Business Developer
• Application Engineer
• Applied Scientist
• Quality Assurance Professional

These six form a stable team, building trust and enhanced collaboration over several projects.

Roles and Responsibilities

Each team member brings specific skills and responsibilities to the team. Together, they can tackle all challenges that might occur.

• Product Developer / Project Manager (PD/PM)
  The “master mind” behind the project, responsible for pulling it all together. She establishes and drives the project plan, integrates the requirements and man­ ages the overall delivery. The PD/PM is also responsible for managing the relationship with the core’s PD/PM function.
• Finance Professional / Business Modeler (FP/BM)
  Far from being a “random number generator”, she is responsible for assembling the business case and explicit assumptions. No product development project should be undertaken that cannot be explained in terms of a business case. The FP/BM is the main conduit back into the respective finance functions.
• Marketer / Business Developer (Mkt/BD)
  The Mkt/BD is responsible for creating a product that can be inserted in the existing markets or start developing a new market together with the core. Her main constituents are the brand and sales organizations in the core.
• Application Engineer (AEng)
  The AEng is drives the implementation of the technology into the product. She is responsible for helping to assemble the requirements and then to deliver them. Her main contacts are in the core technology functions, those that will have to get the product market-ready.
• Applied Scientist (ASci)
  The ASci is the main technology importer of the team. She is responsible for finding appropriate technologies in the internal or external knowledge pools. Her constituents are the other scientists in the corporation.
• Quality Assurance Professional (QA)
  The QA is responsible for validation and quality of the prototype. This includes ensuring that requirements are clearly stated and met. The QA also ensures that the prototype is a valid representation of a later production version in all the areas important for the core. She maintains tight integration with the quality management of the company.

Reporting

The inNode reports operationally to a dedicated Community of Practice.[1] This CoP is responsible for the inNodes, including best practices, status reporting, and resource allocation & budgeting.

The tactical activities of the inNodes, that is the selection of projects, is managed by the CoP for the Innovation Pipeline. This CoP is responsible for the cadence of innovations, setting focal points and maintaining the general roadmaps for advance product development, technologies and skills. They also select mentors for the inNode members. The CoP’s members are representatives from marketing, technology, quality, and finance.

The long-term careers of the inNode members lie back in their respective functions. A standard career path leads through the assignment of ever more complex projects as well as ever increasing levels of responsibilities in the CoPs back to their functions. They act as either counterparts for junior inNode members or take up senior management functions. The exposure to a broad representation of functions inside the company during their inNode times will serve them well.

Incentives

The final piece in the puzzle is the incentive structure. The new structure cannot survive with the old incentive system in place.

The objectives of the inNode approach are the improvement of conversion of ideas to product launches, the integration of core functions into the advanced product development process, and the professional growth of the members.

The inNodes primary incentive system is variable pay. There is a team and an individual component. Here are my suggestions:

The team component is 50% of this bonus. It is based on their project performance against the deliverables they signed up to receive. Here a comparative bonus system is preferred, where the inNodes are compared amongst each other. Those with the highest performance get the highest compensation.

The first individual component is 25% of the bonus. It is based on how well the constituents are kept in the loop. This is measured through a mixture of formal metrics and qualitative feedback.

The remaining 25% is based on how well the individual participates in the CoPs. This included management assignment, mentoring, or additional qualifications.

Transitions

Transforming an existing traditional R&D function into the inNode approach can be achieved with varying speeds. One can “flip a switch” and convert a whole organization at the same time. This is a risky approach, though it avoids redundancy.

I favor a more gradual approach.

The talent pool needs to be accustomed with the new way of operating. The functions need to learn to work together through the vehicle of CoPs, as well as through the system of inNodes itself.

I propose to implement the framework with a 6-9 month timeframe. Any new project that comes along that is met with man power on the inNodes will be transferred to such a context. Ongoing projects will run their course, unless there is a way to transition them at a natural break point like a tollgate. New projects that cannot be staffed according to the inNode approach will be delayed until they can be. The organization needs to realize that the inNode approach is the way of the future, and they only way to get things done from now on.

The CoPs need to be implemented and resourced within the first 2 months. The operational CoP is the most important to get off the ground. Here I propose to use the active inNodes to staff the CoPs. This will generate interest and drive to join and work in inNodes.

More about incentives for change in “The True Nature of Flat”.

[1] More on the topic of Community of Practices in our forthcoming article „The True Nature of Flat”.