Implicit Versus Explicit Tradeoffs
November 11, 2020•455 words
Far too often I see teams make implicit trade offs in their decisions versus explicit ones. What's the difference between the two and why does it matter?
First, let's agree on what I mean when I say trade off? A trade off is when a decision is made to optimize for a specific thing (metric, goal, etc.) at the cost of another. Examples include releasing a product sooner at the cost of polish or quality, having a higher cost of user acquisition in the name of acquiring more users, delaying maintenance of system X because of reason Y, etc.
Explicit trade offs happen when the decision maker understands what the average and worst case downsides for a given trade off are, how they will mitigate those downsides, and why the potential upside outweighs the cost. You are taking a calculated risk by methodically considering the repercussions of your choice. It takes a fair bit of thought and consideration to make an explicit trade off.
Implicit trade offs happen when people choose to optimize for a specific thing (speed, cost, etc.) and have not considered the risks and long term cost associated with that trade off. The issue with implicit trade offs are that the downside risk of the trade off is unknown and therefore unbounded. Unbounded risk tends to blow things up in unpredictable ways on an unpredictable cadence.
The good news is that making a trade off explicit is pretty easy. Any time you notice you are making a decision that is biasing heavily towards a specific metric, set of qualities, or narrowly scoped outcome, make a table that lists out risks associated with that decision. Then list out a set of mitigations for those risks, as well as how likely the risk is and the potential downside impact it could have. Then take 5 ot 10 minutes to review that list with someone and get feedback on if it passes muster.
Example
Goal: Release our feature a quarter early
| Risk | Likelihood | Impact | Mitigation |
|---|---|---|---|
| We don't have time to implement a scalable solution, leading to major performance issues in app | Low | High | we will roll the feature out incrementally via a beta. |
| We won't have enough time to build out analytics that let us understand how the feature is performing | High | High | We can deprioritize certain lower priority features to make room for this work or hire a contractor to support. |
| The feature won't hit the visual quality we normally release | High | Med | This is a risk we will accept the impact for. |