Innovation Incubator at Trustbit

Trustbit has a policy that we could spend 10% of time on learning new things. There is no need to ask for approval, but you are encouraged to share your learnings with your colleagues.

That process works, but it is limited to learning software-specific skills by individuals in small increments. It tends to lack the team collaboration.

At the same time, we want to move Trustbit towards its vision, connect people in different teams and run larger experiments. All that in a remote-first company that is 30+ people right now.

Solution

We are starting a new experimental process, called "Innovation Incubator". 

Anybody in the company can come up with an idea for an experiment - something that could be done by a team of 3-4 people working for a whole week. Each round we encourage anybody to shape and pitch their ideas, select one and then assemble a team of volunteers to get it done. Review and repeat.

This is the high-level perspective.

Fig 1: High-level perspective

The process is open for everybody across the company: to pitch the ideas and work together on getting them done. Differing perspectives should allow us to explore a wide range of possibilities as a company. Perhaps, even explore niches that are missed by the software industry in general.

Appetite

This is an experimental process to drive innovation within the company. This is a long-term investment that doesn't help to pay the bills and salaries right away.

As such, we limit our appetite to a small team of volunteers. This team will work one day per week for five weeks. After each day they will come back to their original projects, hopefully bringing new ideas and company connections with them.

Nuances

There are a few important nuances to this process

First of all, the experiment idea has to deliver value, limit the problem space to fit 5 work days and leave enough room for creativity. We use ShapeUp methodology from the Basecamp as a guidance in shaping the idea, de-risking it and pitching to the company. It also works well for organising remote-first work.

Trustbit is currently at the first round of the process. Two experiments were designed, then pitched during the weekly dev call:

• Build 4th exercise for the DDD Transport Tycoon Kata as an offline competitition where developers need to build bots and deliver most cargo in a fixed time.

• Photo cloaking is a process that subtly manipulates photos and makes them unrecognisable by the trained ML models. Implement a photo cloaking library in JVM (porting an existing project from Python) to make this functionality available for the Android devices.

Each submitted pitch has to identify the specific problem, explain the solution, highlight potential pitfalls of the solution and rabbit holes.

In order to answer these questions, the author of the pitch has to do some upfront design and shape the work:

• identify interesting problem;

• figure out the minimum viable solution;

• highlight potential rabbit holes of the solution;

• spell out "no-gos" - things that we are excluding from the solution.

Initial design happens alone, at high speed. Drafts are then presented to the colleagues to poke holes and identify weak spots. Running the design through multiple perspectives de-risks it and makes it more robust.

One pitch is selected for the implementation. This selection process helps to align the experiment process with the strategic goals of Trustbit.

For example, the selected round 1 proposal was: "Implement a photo cloaking library in JVM (Kotlin) that reduces recognition accuracy of Azure and Amazon Image ML API".

This pitch has multiple synergies with our current work and future interests:

• ML Engineering;

• deployment of ML models on the edge devices (JVM isn't that far from Android);

• Kotlin;

• working with the cloud ML APIs;

• pushing a social cause forward (it is up to the people to decide if their photos can be scraped and used for photo recognition).

Rabbit Holes

It is assumed that pitch designers have done their due diligence and designed an experiment that is achievable within the time frame. More credible pitches will fare better in the selection process.

As such, should the team run out of time, the experiment doesn't get any time extension by default. This is our circuit breaker. It prevents from falling into the rabbit hole of pursuing an experiment that needs to get back to the drawing board.

It is also possible that multiple people from the same project might want to jump on the experiment. This will put unnecessary pressure on the project itself, while making the "learning and sharing" part less useful. That's why we also have an explicit team approval step.

NO GOs

The process of running this innovation incubator is still experimental, so it could fail. To reduce the risk of failure and manage expectations, we set up some specific NO GOs.

First of all, this process cannot be used for a product delivery within the company. It is too slow, focuses on exploring new directions, building new relations with the company and spreading ideas.

Second, we don't want to tie up too much of company’s resources and people’s attention with experiments. The Innovation Incubator is currently limited to a single development track that happens at a slow pace.

Status

The process was approved and launched a few weeks ago. We are currently at the step 3, as shown on Fig. 1 : assembling a team. If all goes as planned, the project will be kicked off next week. Then, in 5 weeks we’ll do a retrospective.

Before launching the second round, there will be a short retrospective and a review. Perhaps, another blog post.

Acknowledgments

Christoph Hasenzagl and Harald Beck for working together on the Innovation Incubator.

Christoph Walcher and Ian Russell for reviewing this article.

Vlad Tchompalov for the photo used in the social media thumbnail.