Ask the Tech Lead: I have to make a technical decision but I can’t know the right answer

Engineer debates choosing AWS vs GCP (via Justin Luebke on Unsplash)

The question: How do I make an impossible technical decision wisely?

The Solution: Think like a scientist

  • The decision is often between the status quo and some option we have no or little experience in.
  • Sometimes the best and worst case outcomes are either unknown or have a scary amount of variance.
  • Sufficiently new or different ideas often imply unknown challenges lurking. What if those unknown challenges are really bad and make it unappealing in hindsight?
  • New ideas might imply major architecture changes that are outright dangerous. If we fail to control risk, it may not matter how good a choice we make.
  1. Frame the big question and take an opinionated stance on the answer based on whatever data is currently available.
  2. Come up with an initial experiment to partially vet that stance. It should be quick (~1 quarter) to accomplish, give meaningful directional feedback on whether the opinionated stance is still correct, and hopefully provide engineering leverage to test the next experiment more easily/quickly/safely.
  3. Evaluate the experiment’s result. Does it suggest our opinionated answer to the original big question was right? Wrong? Have you learned something that needs to alter your answer to the big question?
  4. If needed, update our best current proposal from this feedback.
  5. Rinse and repeat steps 2–4 until you’ve answered the big question empirically.

Applying this to a concrete problem

Frame the big question, take a stance

Come up with an initial experiment

  • How do we deploy and monitor lambdas?
  • Should we use any frameworks?
  • Is the serverless framework a good tool to leverage to build Lambdas?
  • Can we build a CI/CD pipeline that feels like best-in-class service tooling that actually deploys Lambdas instead of our normal SOA setup?
  • Are Lambdas performant in production?
  • In the end, will this change let us get a functional change through the coding lifecycle faster, without sacrificing safety or architectural sanity?

Evaluate the experiment’s result

Update our overall proposal and iterate

Final thoughts

  • What’s the big idea? (add historical context, frame the opportunity)
  • Who are the owners this project(s)? (clear ownership helps avoid death by analysis and offers clear points of contact)
  • What’s my best guess at the right answer? (doesn’t have to be correct in hindsight, just has to be a useful, opinionated stance that implies action)
  • What experiments have we already done in this effort? What did we learn from them?
  • What is the next, most valuable experiment we should try?

--

--

--

engineer @yelp, public speaker, lover of affogato

Love podcasts or audiobooks? Learn on the go with our new app.

Recommended from Medium

Scale and Resilience Aren’t Just Buzzwords

BEST Tech Stories of 2018 (so far)

Database crisis: How we improved performance for large database inserts

Angular — Four Approaches to Implement Interdependent Components

Why we switched from Feature Teams to Component Teams

Treaps: Probabilistic Binary Search Trees

The most clicked Node links of 2017

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Scott Triglia

Scott Triglia

engineer @yelp, public speaker, lover of affogato

More from Medium

Developer Productivity is Really About Empowerment

Three individuals looking at some code on a computer screen.

Building the best team

How to be a Great Managee

Complete Guide To Being An Empathetic Software Team Lead