Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Tips & Tricks for Being a Successful Tech Lead

24 views

Published on

In this talk, I present four key areas to consider when tech leading a software project: Project, People, Programming and Process.

Published in: Software
  • Be the first to comment

  • Be the first to like this

Tips & Tricks for Being a Successful Tech Lead

  1. 1. Tips & Tricks for Being a Successful Tech Lead Ben Limmer
  2. 2. – Patrick Kua Author of "Talking with Tech Leads: From Novices to Practitioners" “A tech lead is a developer who is a leader.”
  3. 3. DISCLAIMER
  4. 4. Programming People Process Project
  5. 5. Project what problem are we trying to solve?
  6. 6. The Project • Identify • the goals, non-goals and anti-goals • the stakeholders • the risks • any unclear requirements
  7. 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. 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. 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. 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. 11. What is the Minimum Viable Product (MVP)?
  12. 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. 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. 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. 15. Example MVP Scoping
  16. 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. 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. 18. analytics script trigger dynamoDB storage spark job API service MVP
  19. 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. 20. Phase 2 appboy reporting kill switch
  21. 21. Phase 2 appboy reporting kill switch 🤔 Minimum Desirable Product?
  22. 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. 23. People how do we leverage our team?
  24. 24. People • Leverage different experience • Be available • Be communicative • Be explicit
  25. 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. 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. 27. Urgent Not Urgent Important Do it Decide when to do it Not Important Delegate it Delete it * Eisenhower Matrix
  28. 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. 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. 30. Programming how do we build software to solve the problem?
  31. 31. Programming • Read • Brainstorm • Prototype • Present and Listen
  32. 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. 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. 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. 35. Prototypes • Tackle the hard stuff first in a prototype • Make it throw-away
  36. 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. 37. Process how do we execute the plan?
  38. 38. Process • Documentation • Stories • Communication • Iteration Progression • Iteration Finalization / Retro
  39. 39. Documentation • Extremely helpful to... • Communicate decisions made • Provide living design docs • Reiterate the "why" • Provide visual representations of the solution
  40. 40. Project Confluence Page • One-Stop for all the project info • Product Briefs • Diagrams • MVP Descriptions / Decisions • Breakdown of phased rollouts • Example
  41. 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. 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. 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. 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. 45. Programming People Process Project
  46. 46. every project is different and people have different leadership styles
  47. 47. you will make mistakes
  48. 48. * Credit Patrick Kua's "What I Wish I Knew as a First Time Tech Lead"
  49. 49. Resources to Help • Your Peers • Your EM • Other tech leaders • Development Lifecycle Best-Practices
  50. 50. thanks! let's have a group discussion with the remaining time

×