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?
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?
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?"
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?
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
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?