Return

Pattern: Manage for Proficiency

Teams delivering stable and highly repetitive or algorithmic work should be managed for high quality and optimal efficiency

A transformation is underway. Some teams are working creatively to build the new system while other teams remain focused on keeping the existing system delivering the company’s core products/services. Alternatively, a cloud native transformation is at its end, and all the teams onboarded to the platform know very well what they are doing. They are ready to deliver excellent products to customers as fast as needed.

In This Context

When the teams responsible for delivering stable and scalable products are given too much freedom to innovate and explore, they introduce new risks that harm product quality and increase the cost of development. In many cases the new cloud native platform is not yet ready or stable enough to accommodate all the new teams, while most of the teams have to maintain old systems and release new incremental updates. Allowing those teams to start innovating too early may come at a significant cost to productivity and product quality.
• Established companies desire creativity because usually they don’t have enough of it.
• Startups are highly creative yet desire proficiency because they are striving to build a consistent, deliverable product.
• The typical enterprise culture strongly supports a proficient, even algorithmic, way of working.

Therefore

Run the execution teams the way they have always been run. Focus on repeatability and optimize on quality and speed of delivery. As an organization transforms itself into a cloud native entity, most teams will eventually need to evolve to cloud native’s more flexible, intuitive, and problem-solving way of working. During the transition, however, there will be teams still tasked with delivery of the core business on the existing system while the new platform is built. It’s important to keep the proficient teams proficient and run them as they have always been run, not changing to cloud native techniques yet. Once a system (or new product) has left the innovation phase and is in steady production, most resources can typically be moved away from research and experimentation, and back to a mostly proficient approach.
• Let them know that they are valued: keeping existing product lines going at high quality is important to the business.
• Promise them that they will be onboarded to the new system when the time is right.
• Aim to create team pride around the best possible results and highest-quality products.
• Management of proficient teams requires high repetition, high feedback, and a strong sense of belonging.
• Emphasize that both types of teams are needed and important to the organization; avoid the perception or reality that creative work is rewarded more.

Consequently

Teams in charge of delivering the company’s profit-generating products/services in a proficient way are being managed to optimize this. Proficient and creative teams are loved and appreciated equally.
+ If the market changes in a large and/or frequent way, the company can shift resources into creativity and innovation when necessary. But creative is expensive, so drop back to proficient when things are stable/predictable.
− Some teams may need to work in the legacy codebase permanently (see “Lift and Shift at the End”).