There are a lot of engineering techniques that are not specific to running a Disruptive Innovation team. Still, continually guiding these teams to be relentlessly focused on producing business value has made a handful of tricks worth sharing.  Boiling it down, the focus is on the value of the product being delivered, on learning more about the market and reducing the risk that one or more of our assumptions about this product are incorrect. We’ve already covered A/B testing and other experimentation tools, but there’s so much more to it than that. 

Team Size

We first need to address the optimal team size for Disruptive Innovation teams. Jeff Bezos and Amazon are famous for their two-pizza teams, meaning two pizzas would feed the entire team, and this is a good thought. Assuming everyone eats, on average, two slices, and each pizza has about eight pieces, we’re sitting with about eight team members. But let’s break that down a bit more. If we have eight spots on the team to fill, we’ll start with one Product Manager, User Experience Designer, Marketing partner, and one representative from Sales. That leaves us just four spots to fill, and depending on the product you’re trying to build, perhaps four engineers is the correct number. If you have other disciplines that need to be involved in the development, say Legal, Program, Client Success, etc., you may have fewer “seats” for Engineers, and perhaps that’s OK. However, if we get to a place where we feel less than two engineers is necessary, we should seriously reconsider whether we need a full-time engineering team. 

A team of one is no team at all. Adding a second engineer helps with a few different things. First, it encourages higher-quality code reviews. If the code reviewer for your application’s changes is not regularly involved in the deployment and maintenance of the product, they may cut some corners or allow the team to ship code that isn’t thoroughly thought out. Beyond that, having a second engineer on the team enables either of the engineers to take time off and not feel guilty that the product is not advancing. Of course, you can have more than two engineers on a team, but it should almost always be your lowest level of investment in any Disruptive Innovation team.

There are exceptions, of course. Sometimes, it’s helpful to start without any engineers at all on the team. For example, if you have quality low-code/no-code tools to test assumptions. Other times, you may have a strong indication from the market that this will be a high-stakes product, and you want to start with a larger team to lay down solid platform components as you launch this new product. The key is to strike a healthy balance between the team size you need to move the product forward successfully without allowing the team to become too large too early and get bogged down in communication and other processes. 

We regularly consider the team size and Metcalfe’s Law: “The value of a telecommunications network is proportional to the square of the number of connected users of the system.” Said another way, you add N more communication points for every person you add to an N-person team. As an example, if you have a four-person team, you have only six points of communication (A->B, B->C, C->D, D->A, A->C, and B->D), but adding another person, E, add’s four more lines of communication (A, B, C, and D now each need to communicate with E) bringing the total lines of communication to 10. Every additional line of communication has a potential for mistakes or translation errors between the start and end of a discussion. 

Let’s take an example. Suppose Product Manager A is planning a new feature and has the experiment specification. First, they must communicate that with the Designer, B, and get their input. A & B then need to share their ideas with the developers who’ll build this feature, C & D. Once C & D finish building the feature, they can quickly confirm it’s correct with A and usable with B, and then ship it to production. Simple as can be. With only six lines of communication and the ease of fitting everyone into a tiny room, office, or Zoom call, you can efficiently communicate and deliver software.

Now, instead, imagine we have a Product Manager A, Designer B, five Engineers (C through G), two QA engineers (H & I), and two Release Engineers (J & K). Now, we have 55 possible communication points, some more used than others, but all are still available. Any of these points of communication can introduce noise into the transmission, which can result in either a need for repeated communication or a mistake being delivered. Perhaps a misunderstanding in the requirements for the feature was introduced by one of the engineers, or a change in the requirements along the way was not captured, and the QA engineers flagged it as a bug. No matter what the miscommunication is, you can see that the opportunity for miscommunication has risen incredibly, and you can also imagine that it results in more time taken for the feature to be delivered. To help mitigate this, you might consider standardizing the communication processes, e.g., the Product Manager writes down what they’re proposing, the UX designer captures mockups in a graphical tool, Engineers produce design reviews or other specifications, QA writes test plans, etc. These are practical tools; however, they are supplemental deliverables that have increased the time required to deliver a feature as you generate more and more metadata about the feature to live alongside it. Still, they do not directly provide any business value in and of themselves.