You have two choices when new challenges emerge:
- Offer several reasons why things wouldn’t work
- Seek growth opportunities from the challenge
Let’s talk about the latter option.
Scenario
Your team dances through complex rituals every month before it can successfully deploy a big batch of changes. Engineers dread the drain on developer productivity and attendant customer downtime; no one wants to do it.
Finally, management decides to solve this problem and provide funding for instantaneous deployments. Success on this project means production clusters can be updated at 10 second intervals with zero downtime.
Hurrah! You immediately volunteer to lead the charge – the knight in shining Armour coming to save the day. The euphoria soon washes away and you immediately develop cold feet as you ponder over the gargantuan task. Can you do this? You ask yourself for the millionth time.
Several questions race through your mind:
- What does success look like?
- What is the problem space?
- What are the exit criteria for completion?
- Who are the stakeholders to convince?
- How do you convince people to get this done?
- How do you choose the solution with the best ROI?
Good news! You are not alone and the following steps describe my approach to such challenges.
1. Define the end goal
Take the time to think deeply about the problem and goals. Defining clear targets takes time but offers disproportionate returns.
Book adequate time to research unknown fields – read books, watch tutorials and synthesize insights. Share findings with peers to get diverse perspectives and address blind spots.
This stage makes or mars the entire enterprise so do your best to get it right.
2. Define the road map
This stage is focused on the tactical actions that lead to the strategic goal. Now that you know what success looks like, how will you get there?
Potential actions at this stage includes identifying stakeholders, adding milestones and timelines to provide early warning signals of slippage risk.
Always create buffers – having a super tight schedule means that the smallest delay has a huge impact on the entire project because of ripple effects.
What tactical actions can you take that align to the bigger strategic goals outlined in 1? This could involve identifying the key stakeholders you need to achieve to success; setting up meetings and deadlines for certain activities (if they slip, then your success slips too); coming up with plans to mitigate known unknowns and also buffers to address unknown unknowns.
3. Identify the smallest possible change that can be made
Now you have identified the problem to solve from 1 above and probably have a strategy in mind for solving the problem. The next important thing is to find the smallest easiest problem that can be solved with the highest impact.
I typically call this running experiments; at this stage, you are still groping in the dark and trying to validate your assumptions. The rule of thumb is to figure out what will fail cheaply. You do not want to discover late into the game that you started on the wrong footing.
Figure out the smallest highest impact thing that aligns with the goal in 1 and work towards it.
4. Just do it until blocked
The best way to eat the elephant standing in your path is to cut it up into little pieces.
Unknown
Now you know what to do but the momentum doesn’t exist. So just take a step; do anything small and easy: create a repo; create one file, push one commit. Just make progress: over time, things will accelerate.
A plane will take some time to accelerate to cruising speeds so just continue focusing on building momentum.
- Repeat from 1
- Gotten to a significant milestone? Pat yourself on the back, go back to 1 and start again!
5. Do a retrospective once you ship
Hopefully you successfully shipped the project and you should set up some focus time to learn about what went well, what could be 10X better and what went wrong. Most times, teams focus inordinately on what went wrong however success also offers great learning insights. Did you document the decisions and assumptions that went right during the project? Sweet! That is a learning opportunity.
If otherwise too and the project goes south or gets cancelled, what have you learnt? What decisions would you change given the hindsight? That way you are iteratively learning and improving.
CodeKraft 