The Three Lenses Framework

Overview

Every technical decision involves tradeoffs. The Three Lenses Framework helps you evaluate these tradeoffs systematically by examining every decision through three perspectives:

1. User Lens: How does this affect the user experience?
2. Team Lens: How does this affect development velocity?
3. System Lens: How does this affect system health and maintainability?

The Three Lenses

Lens 1: User Impact

Ask: "Does this make things better for users?"

Consider:

• Performance: Will users notice a difference in speed?
• Reliability: Does this improve or risk stability?
• Features: Does this enable new capabilities users want?
• Privacy/Security: Does this protect user data?

Example Decision: Migrate to a new database

• ✅ Pro: 50% faster query response times (users notice)
• ❌ Risk: Migration downtime affects users
• Verdict: User impact is positive if migration is seamless

Lens 2: Team Velocity

Ask: "Does this make the team more effective?"

Consider:

• Developer Experience: Is it easier or harder to work with?
• Cognitive Load: Does it add or reduce complexity?
• Hiring: Can we find people with these skills?
• Debugging: Will problems be easier or harder to diagnose?

Example Decision: Adopt microservices architecture

• ✅ Pro: Teams can deploy independently (faster iteration)
• ❌ Con: More complexity in local development
• ❌ Con: Distributed debugging is harder
• Verdict: Team velocity may decrease short-term, increase long-term

Lens 3: System Health

Ask: "Is the system more robust and maintainable?"

Consider:

• Scalability: Can it handle 10x growth?
• Observability: Can we see what's happening?
• Resilience: What happens when things fail?
• Technical Debt: Does this create future problems?

Example Decision: Build custom authentication vs. using Auth0

• ✅ Pro (custom): Full control, no vendor lock-in
• ❌ Con (custom): Security burden, maintenance overhead
• ✅ Pro (Auth0): Battle-tested, maintained by experts
• Verdict: System health better with proven solution

How to Apply the Framework

Step 1: Document the Decision

Write down what you're deciding and why.

Template:

## Decision
[What are we deciding?]

## Context
[Why now? What's the problem?]

## Options
1. Option A
2. Option B
3. Option C

Step 2: Apply Each Lens

Evaluate each option through all three lenses.

Scale: -3 (very negative) to +3 (very positive)

Step 3: Weight Based on Context

Not all lenses are equal in every situation.

Example weights:

• Early startup: User Impact (50%), Team Velocity (30%), System Health (20%)
• Growth stage: User Impact (40%), Team Velocity (30%), System Health (30%)
• Enterprise: User Impact (30%), Team Velocity (20%), System Health (50%)

Step 4: Make the Call

Choose the option with the highest weighted score—but also consider:

• Risk tolerance: How reversible is this decision?
• Timing: Can we defer this decision?
• Dependencies: What else does this affect?

Real-World Example

Decision: Should we rewrite our legacy monolith in Go?

Lens 1: User Impact

• Performance: Likely faster (+2)
• Features: Delayed while rewriting (-2)
• Reliability: Risk during migration (-1)
• Score: -1

Lens 2: Team Velocity

• Short-term: Months of rewrite work (-3)
• Long-term: Faster iteration once complete (+2)
• Hiring: Harder to find Go developers (-1)
• Score: -2

Lens 3: System Health

• Scalability: Go handles concurrency better (+2)
• Maintainability: Clean slate eliminates tech debt (+3)
• Observability: Need to rebuild monitoring (-1)
• Score: +4

Weighted Decision (Growth Stage Company)

Total = (0.4 × -1) + (0.3 × -2) + (0.3 × +4)
      = -0.4 + -0.6 + 1.2
      = +0.2

Verdict: Slight positive, but risky. Consider:

• Alternative: Refactor incrementally in current language
• Compromise: Extract critical services to Go, keep monolith

Common Pitfalls

1. Optimizing Only One Lens

Bad: "This makes our lives easier, ship it!"

Without considering user impact or system health, you might build the wrong thing efficiently.

2. False Tradeoffs

Sometimes you can improve all three lenses.

Example: Good logging improves debugging (Team), incident response (User), and observability (System).

3. Ignoring Time Horizons

Short-term vs. long-term impacts can differ dramatically.

Example: Technical debt hurts team velocity eventually, even if it speeds things up today.

When to Use This Framework

✅ Use for:

• Architecture decisions
• Technology choices
• Process changes
• Resource allocation

❌ Don't use for:

• Trivial decisions (overkill)
• Emergencies (no time for analysis)
• Well-established best practices (just follow them)

Conclusion

The Three Lenses Framework prevents tunnel vision by forcing you to consider multiple perspectives.

Most bad technical decisions happen because teams optimize for one lens while ignoring the others.

Remember: The goal isn't to score perfectly on all lenses—it's to make conscious tradeoffs with full awareness of the costs.

Related Concepts

• DACI Decision Making: Define who Drives, Approves, Contributes, and is Informed
• ADR (Architecture Decision Records): Document decisions using this framework
• Cost of Delay: Quantify the impact of deferring decisions

How do you evaluate technical decisions? I'd love to hear other frameworks you've found useful.