Turning Innovation into Revenue

minimized. When our experiments succeed, they can be commercialized and supported as long-term enhancements to our organization’s revenue stream. For this reason, we never want to position our emerging technology engineers as critical contributors on transferred projects for longer than necessary. Doing so hinders the emerging technologies team to iterate and leaves technology transfer work incomplete. Of course, the one exception to this rule is when there is value in an emerging technology engineer moving to the partner team along with the technology. Some projects are so complex that they benefit from this type of arrangement, though it may leave the emerging tech team short-handed for a time.

A transfer isn't over until the partner team says so

Emerging tech teams should not be the “dine and dash” types. If a partner team isn’t successful due to a hasty transfer, then everyone’s time has been wasted. While it is important to recoup emerging tech engineers in a timely manner, transfer plans should be constructed using graduated levels of support until the partner is self-reliant with the transferred technology. Tech transfer projects shouldn’t move from one level of support to another without agreement from the partner that they are comfortable with the change.

Details vary from project to project, but generally the levels of support levels include:

Embedded engagement
Because the goal of the transfer is for the target team to integrate the new technology into the partner team’s existing productization workflows, it is often easiest for an emerging tech engineer to join the target team for a number of sprints. Embedding emerging tech engineers into the partner team allows both teams to determine the fastest path to supporting the new technology’s integration.

Consulting engagement
When the technology transfer is easy to manage, or when the partnership has been established early enough for the partner team to get up to speed on the new technology as part of their own ongoing work, then the primary role of emerging technologies teams is to provide guidance on design and implementation. This may involve some coding, but the majority of the work can usually be handled by the partner team with regular communication and meetings.

On-call engagement
When the partner team has achieved a certain level of autonomy with the new technology, the emerging technologies team should remain available to support them on an “as needed” basis. Projects that reach this stage are considered to be "graduated" from the tech transfer process, and the emerging tech engineers can begin focusing on new projects.

Everything else is negotiable

Through our tech transfer projects, my emerging technologies team has partnered with more than a dozen global engineering teams to incubate projects of varying complexities. Each partner team has its own development workflows, engineering bandwidth limitations, and technical expertise relative to the projects that we are partnering on. Consequently, the template for tech transfer agreement documents should be very simply organized and include the following:

• What is being transferred? This includes a list of specific code repositories but may also include details about open-source community roles that will also be transferred.

• Who will be involved? This should document anyone involved in the transfer—at minimum, individual contributors and engineering management—but product management and other consultants are typically included as well.

• What is the timeline? The timeline typically begins at the appropriate level of support the project will need at the forefront and will include an estimate of how long the emerging technologies team will provide support at each stage of the project until it can be considered graduated.

Beyond this baseline information, the unique details of each transfer effort should be captured in the document under relevant ad-hoc topics. Additionally, it’s helpful to think of the agreement as a living document. Though teams should avoid adjusting the scope of a project as much as possible, updating the timeline is not uncommon. Regular checkpoint meetings between the emerging tech and partner teams are opportunities to adjust the agreement as needed.

Hopefully these guidelines help demystify what success can look like when it comes to partnering with other engineering teams or upstream communities and working with them to bring promising emerging technologies into the hands of customers. I firmly believe that emerging technology teams are 100 percent dependent on other teams to make new technologies successful, and so they must be 100 percent committed to working in tandem in pursuit of their mutual goals.