Plato Elevate Winter Summit has been announced (Dec 7th-8th)

🔥

Back to resources

The Problem of a Time-Quality Tradeoff

Managing Expectations
Internal Communication
Cross-Functional Collaboration

18 August, 2020

Lakshmi Baskaran
Lakshmi Baskaran

VP of Engineering at SEDNA Systems

Lakshmi Baskaran, VP of Engineering at SEDNA Systems, explains how to successfully solve the problem of a time-quality tradeoff by introducing a “time-quality sensitivity rubric” during early and conceptual stages of development.

Problem

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.

Actions taken

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.

Lessons learned

  • 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.

Discover Plato

Scale your coaching effort for your engineering and product teams
Develop yourself to become a stronger engineering / product leader


Related stories

Preparing Your Team for the Remote Workplace

29 November

Vadim Antonov, Engineering Manager at Meta, dictates how he brought a brand new team into the remote learning process by ramping up onboarding and creating a mentor system.

Alignment
Remote
Internal Communication
Coaching / Training / Mentorship
Data Team
Cross-Functional Collaboration
Vadim Antonov

Vadim Antonov

Engineering Manager at Facebook

Increasing Collaboration Within Your Team

2 December

Anurag Jain, a leader at Fortinet, discusses his strategy to promote growth within his teams, using servant leadership concepts.

Scaling Team
Personal Growth
Leadership
Internal Communication
Collaboration
Anurag Jain

Anurag Jain

Leadership Role at Fortinet

Delegate successfully as a first time manager of Product Managers

24 November

Andrew Tsui, a Product Leader, works to build great teams that are independent, demonstrate mastery of their domain, and fully commit to their purpose.

Scaling Team
Building A Team
Delegate
Coaching / Training / Mentorship
Psychological Safety
Cross-Functional Collaboration
New Manager
Andrew Tsui

Andrew Tsui

Director of Product at Startup

Specialization vs. Wearing Many Hats

23 November

William Bajzek, Director of Engineering at Sapphire Digital, compares and contrasts a team structure that utilized siloed skill sets and one where everybody’s duties overlap at the edges.

Internal Communication
Collaboration
William Bajzek

William Bajzek

Director of Engineering at Sapphire Digital

Why Overloading Product Teams Never Work

23 November

Adi Purwanto Sujarwadi, VP of Product at Evermos, shares how he identified the symptoms of his overworked product team and worked towards defining conflicting priorities.

Managing Expectations
Product Team
Deadlines
Stakeholders
Adi Purwanto Sujarwadi

Adi Purwanto Sujarwadi

VP of Product at Evermos

You're a great engineer.
Become a great engineering leader.

Plato (platohq.com) is the world's biggest mentorship platform for engineering managers & product managers. We've curated a community of mentors who are the tech industry's best engineering & product leaders from companies like Facebook, Lyft, Slack, Airbnb, Gusto, and more.