The Problem of a Time-Quality Tradeoff
VP of Engineering at SEDNA Systems
In product-first organizations one the most common dilemma is: Do I need to deliver this feature at the best quality or Do I need to deliver it within the stipulated timeline. Most organizations go through this challenge regardless of the size and maturity of their development teams. This issue is generally caused by a lack of communication between Product and Engineering teams on the nature of a feature - whether a feature is time-sensitive or quality-sensitive.
When development teams receive requirements of a new feature, there is seldom a mention if a feature is a time- or quality-sensitive. As a result, some features that need to be deployed immediately take longer than what is expected in terms of timeline, while other features that should be of excellent quality are delivered fast but would not meet the quality requirements.
During the early conceptual stage of building a product or a feature, it is important for the product leadership to have a clear understanding of when the feature should be deployed and how critical it is for its customers. This helps them to make an informed decision on whether the new feature is critical of time or quality.
Some product-based teams aim to have every product and feature built with aggressive timelines and of the best quality. It often turns out to be too optimistic. It is also not a pragmatic approach to product development. Only products and features that are very critical for an organization's success should be considered to be both time- and quality- sensitive. The other features should be prioritized to be either time-sensitive or quality-sensitive.
Our organization was no different and we suffered from a lack of alignment between product and engineering on the nature and priority of a feature. Obviously, this resulted in frustration and animosity between product and engineering teams.
We addressed this by encouraging our Product Owners to make a conscious decision of whether a feature is time- or quality-sensitive. And this decision is made before engineering teams start with development. The Product Owners communicated the decision through the Feature Vision (or Business Requirements) document or mentioned about the priorities of the feature in Jira Epic. We helped teams to organize their work such that it supports not just the requirements of the feature, but also the nature of the feature. If a product is time-sensitive, the teams were encouraged to negotiate the features that can be built and deployed within aggressive timelines. If a product is quality-sensitive, the teams negotiate the time required to build all the features and deliver the best quality outcome.
- Remove assumptions about the nature of a product criticality. Product Owners should proactive decisions about the criticality of the feature. They should communicate to the Engineering teams on whether a feature is time-sensitive or quality-sensitive.
- Build alignment and relationship between Product and Engineering teams by communicating the time and quality sensitivity of a new feature to be developed. This helps Product and Engineering to work in sync with common goals and objectives.
- Help engineering teams scope and organize their work based on the nature of the product or feature. If a product is time-sensitive, help them negotiate on the features that can be built within the stipulated time. If a product is quality-sensitive, negotiate on timelines to deliver all the features at the highest level of quality.
Be notified about next articles from Lakshmi Baskaran
VP of Engineering at SEDNA Systems
Connect and Learn with the Best Eng Leaders
We will send you a weekly newsletter with new mentors, circles, peer groups, content, webinars,bounties and free events.