Few years back, I was sitting in Bunker Coffee with Luke for our 1:1.
Luke tells me, “you know, no matter how hard you plan, the error rate of our decision doesn’t change much. If we take path A today versus next week, after having a whole lot more meetings, we still don’t know what we don’t know. What do you think?” He’s always polite to leave space for me to respond.
We were just coming from a team discussion on how to implement a feature. The team couldn’t arrive at a decision. Our most experienced devs wanted to spend more time thinking and white-boarding a solution.
Luke was right of course. We needed to move forward and discover unknowns. But when do you “just start” versus spend time in the drawing board?
Luke doesn’t just write code. He also builds houses. He’s worked through many building projects to know that there has to be a solid plan. However, software is far more malleable. Most decisions made in code can be changed. What truly matters is understanding dependencies in the work being performed. Dependencies can make altering decisions far more challenging.
Generally speaking, further down the stack you go, more upfront thinking is required. In other words, volatility in code and product increases as systems get closer to customers. Remember images like below that encouraged us to front load all issue tackling to save money? Well, they are wrong. Most solutions can do with making mistakes and validating assumptions sooner than later.
Not everything fits this model
The feature we were debating was for a mobile app that didn’t have a large number of users at this stage. That is the second piece to consider: customer impact. For systems that have broad customer impact, more consideration needs to be taken. If millions of users are going to be affected by a certain identity verification system, perhaps more thought should have been given. This is why as products scale, feature development does take a little longer.
Even when there are changes that are high impacting, there are tricks to go faster. It is even more important to learn about unknowns and arrive at informed decisions in these products. A simple way to get there is to reduce scope of changes. Scope can be reduced by either limiting customer exposure or breaking the change down to small iterations.
If you are running a project, always ask your team how something can be delivered in half the time. You can’t bend time and space; things will take longer than predicted. But you can have achieve outcomes sooner than you think.
Dependencies and customer impact
Many tend to be very risk averse, especially in high revenue environments. Like I talked about in “Companies Grow” post, this can become an attribute of growing companies, even to the point of rejecting innovative ideas altogether. More planning becomes the answer to please this conservativeness.
Moreover, developers are always looking to develop the ideal system; they hate writing throwaway stuff. There is natural inertia towards being careful with every change.
We should always keep in mind that these actions have a price attached to it. Being agile fundamentally requires us to try things, learn from them, and try again. We are always wiser for having reworked our solutions with new insight. Mature teams understand this. They aren’t afraid to test solutions, validate assumptions and go back to the drawing board. They aren’t afraid to fail. Like Luke reminded me, there is just always a chance of failure.
Lastly, remember… (maybe this is a construction industry thing) …as my house builder points out, “a plan is just a starting point.” Actual work lays ahead of you.