1.
Tips & Tricks for Being
a Successful Tech Lead
Ben Limmer

2.
– Patrick Kua
Author of "Talking with Tech Leads: From Novices to Practitioners"
“A tech lead is a developer
who is a leader.”

3.
DISCLAIMER

4.
Programming
People
Process
Project

5.
Project
what problem are we trying to solve?

6.
The Project
• Identify
• the goals, non-goals and anti-goals
• the stakeholders
• the risks
• any unclear requirements

7.
Goals, Non-Goals and
Anti-Goals
• Goals
• What do we want to make (better)?
• Non-Goals
• What is out-of-scope for this project?
• Anti-Goals
• What could happen that would make the situation
worse?

8.
Stakeholders
• They can tell us if we're on track with what we're building
• They help define success & accept milestones
• Do they change over time?

9.
Risks
• What are the technical risks of this project?
• Stakeholders help prioritize risk
• Is there another, less-risky way of accomplishing the
goals?

10.
Unclear Requirements
• Identify them early
• Provide context and information that can help clarify
• If we can't clarify them...
• Do we need more data?
• Can we move the decision out until later?

11.
What is the Minimum
Viable Product (MVP)?

12.
– Eric Ries
Creator of the Lean Startup Methodology
“A minimum viable product (MVP) is a product with
just enough features to satisfy early customers, and
to provide feedback for future development.”

13.
What is the Minimum Viable
Product (MVP)?
• What is the smallest thing we can build to prove out that we're on
the right track?
• Get something out quickly and iterate
• Are we starting to make progress on our goals?

14.
What is the Minimum Viable
Product (MVP)?
• Often times all requirements feel "MVP"
• It's a bit of an art to break up requirements
• Identify what can move out to fast-follow releases
• Custom administration
• Supporting behaviors
• Tech Debt Cleanup / Refactoring *
• What are the MVP workarounds?

15.
Example MVP
Scoping

16.
single-page
app setup
workflow
analytics script
trigger
dynamoDB
storage
spark jobAPI service
brazeboy
reporting
kill
switch
anonymous /
user creation
tracing
website
implementation
reporting
interface
"it needs to..."

17.
single-page
app setup
workflow
analytics script
trigger
dynamoDB
storage
spark job
API service
brazeboy
reporting
kill
switch
anonymous /
user creation
tracing website
implementation
reporting
interface
MVP Phase 2 Beyond

18.
analytics script
trigger
dynamoDB
storage
spark job
API service
MVP

19.
single-page
app setup
workflow
analytics script
trigger
dynamoDB
storage
spark job
API service
appboy
reporting
kill
switch
anonymous /
user creation
tracing website
implementation
reporting
interface
MVP Phase 2 Beyond

20.
Phase 2
appboy
reporting
kill
switch

21.
Phase 2
appboy
reporting
kill
switch
🤔
Minimum Desirable
Product?

22.
single-page
app setup
workflow
analytics script
trigger
dynamoDB
storage
spark job
API service
appboy
reporting
kill
switch
anonymous /
user creation
tracing website
implementation
reporting
interface
MVP Phase 2 Beyond

23.
People
how do we leverage our team?

24.
People
• Leverage different experience
• Be available
• Be communicative
• Be explicit

25.
Leverage Different
Experience
• Diversity of backgrounds at Ibotta
• Ask for opinions
• Ask for background / historical information
• Challenge teammates to push themselves
• Delegate research / implementation details
• Listen to different ideas; be aware of "Be Like Me"
Syndrome

26.
Be Available
• You will write less code while you're tech leading
• Time management
• Review PRs quickly
• Answer any questions
• Pair / Whiteboard
• Handle issues as they come up

27.
Urgent Not Urgent
Important Do it
Decide when
to do it
Not Important Delegate it Delete it
* Eisenhower Matrix

28.
Be Communicative
• You are the face of the technical implementation of the
project
• Make sure everyone's aware of project status
• Stakeholders
• Developers
• Other Tech Leaders
• Know Your Audience

29.
Be Explicit
• Don't assume; if in doubt, talk about it!
• Titles (EM, PM, Tech Lead) vary by company
• "Who is the tech lead?"

30.
Programming
how do we build software to solve the problem?

31.
Programming
• Read
• Brainstorm
• Prototype
• Present and Listen

32.
Read
• Third Party Docs
• Legacy Code
• Living Design Docs
• Documentation mode for specs
• Find the seams
• OSS Examples
• Find patterns in the absence of legacy code
• Take Notes

33.
Brainstorm
• What are the different options?
• Pros / Cons
• Differing Levels of Effort
• Parallelizability
• Plan to continuously integrate and deploy
• Feature Flags
• Rollout Plans

34.
Brainstorm
• Plan out the escape hatches
• How do we turn it off if needed? How will we know if it
needs to be turned off?
• What if the option we choose doesn't work - can we
reuse anything?

35.
Prototypes
• Tackle the hard stuff first in a prototype
• Make it throw-away

36.
Present & Listen
• Include...
• The people working on the code
• At least one other tech leader
• Send out background material early
• Propose options, be flexible
• Decide on next steps

37.
Process
how do we execute the plan?

38.
Process
• Documentation
• Stories
• Communication
• Iteration Progression
• Iteration Finalization / Retro

39.
Documentation
• Extremely helpful to...
• Communicate decisions made
• Provide living design docs
• Reiterate the "why"
• Provide visual representations of the solution

40.
Project Confluence Page
• One-Stop for all the project info
• Product Briefs
• Diagrams
• MVP Descriptions / Decisions
• Breakdown of phased rollouts
• Example

41.
Stories
• Are owned by the team
• Help with team buy-in on the project
• Write stories from high-level design docs
• Identify cases you didn't think about
• Definition of done

42.
Communication
• Decide how to call out issues and risk we didn't originally
consider
• Decide the checkpoints for stakeholders
• Add additional resources for communication
• Standups / Check ins / Slack Room

43.
Iteration Progression
• Make sure we're on track
• Consider the timeline
• Do we need to re-scope or reconsider MVP?
• Are there risks to be prioritized by the stakeholders?
• Beware of external events that might affect the project

44.
Iteration Finalization / Retro
• Are we done?
• Did we hit our goals? What about anti-goals?
• Did we complete all necessary fast-follow work / feature flag cleanup?
• What do we move to next?
• Safe-Space Retro
• Are people happy with the solution we built?
• Did everyone have the information needed?
• What could I do (better) next time?

45.
Programming
People
Process
Project

46.
every project is
different
and
people have different
leadership styles

47.
you will make
mistakes

48.
* Credit Patrick Kua's "What I Wish I Knew as a First Time Tech Lead"

49.
Resources to Help
• Your Peers
• Your EM
• Other tech leaders
• Development Lifecycle Best-Practices

50.
thanks!
let's have a group discussion
with the remaining time