SlideShare uses cookies to improve functionality and performance, and to provide you with relevant advertising. If you continue browsing the site, you agree to the use of cookies on this website. See our User Agreement and Privacy Policy.
SlideShare uses cookies to improve functionality and performance, and to provide you with relevant advertising. If you continue browsing the site, you agree to the use of cookies on this website. See our Privacy Policy and User Agreement for details.
Successfully reported this slideshow.
Activate your 14 day free trial to unlock unlimited reading.
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?
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?
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
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?