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?

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

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

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

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

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

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

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

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

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

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

35. 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?

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

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

38. Process
how do we execute the plan?

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

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

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

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

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

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

45. 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?

46. Programming
People
Process
Project

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

48. you will make
mistakes

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

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

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