The 70 + 3×10 Model

The 70 + 3×10 model is a simple but effective model for DevOps teams to distribute their time among feature development, maintenance and support, operations, and learning.

From experience as an engineer and product manager, the 70 + 3×10 (seventy plus three times ten) model is a good approximation for the desired balance required to ensure product innovation at minimal levels of customer support and operational overhead. The model splits engineering time into four groups:

• 70% development
• 10% maintenance and support (i.e. bug fixes, upgrades, user support)
• 10% operations
• 10% slack (e.g. learning)

Any undesirable movement in the direction of maintenance and support or operations can temporarily be feathered by the slack—at the cost of learning—but must to be prioritized as part of the development efforts when sustained for more than a sprint. This ensures that transient issues do not affect release plans, while at the same time ongoing issues are prioritized properly.

If reactive maintenance (user support or operations) overwhelms the team, feature development will eventually come to a halt; no more value will be added to the product from that moment on, as all time will go to ‘keeping the lights on’. Similarly, if proactive maintenance (planned upgrades and bug fixes) becomes too cumbersome, it is time to add it to the backlog instead of dealing with it on an ad hoc basis. Reduction of tech debt, operations automation, and faster or even automated handling of user requests ought to be part of any product roadmap, as it increases the team’s productivity, which in turn boosts the team’s ability to deliver value. If maintenance and support as well as operational overhead reach levels below their 10% limits, the extra time can be absorbed by development and learning.

A possible way to implement the 70 + 3×10 model is to have on-call rotations overlap with each sprint. Each sprint, a different engineer is primarily responsible for maintenance, support, and operations. The rest of the team can focus on engineering and education. The on-call engineer is assigned a recurring ticket for upgrades, non-critical bug fixes, and small automation tasks. This ensures that time is properly accounted for and the work does not slip through the cracks. At the same time, that person is responsible for ensuring continued operations and triaging incoming support requests. This frees the rest of the team from context switching. Ideally, it still leaves plenty of time for the on-call person to assist in development activities, including critical bug fixes.

The goal of the 70 + 3×10 model is to ensure there is time dedicated to providing the service at the agreed-upon levels, time for activities that add value to the product, but also time for engineers to learn and experiment, which is important to innovation and team health.