I like setting high goals that are challenging and that I don’t know for sure if I can hit. It motivates me to work not just harder, but smarter and gives a lot more satisfaction when you do hit these goals.
I also know that over promising and under delivering is way too common with software development. To really provide top software & service, we need to over deliver on our promises so its tempting to set low goals that we know for sure we can hit, just to make sure that we can meet our promises to customers.
Setting challenging goals carries higher risk, setting easy goals carries lower risk. High risk = high reward, but also a higher chance of missing the goal and letting people down. So how risk adverse should we be when it comes to building software?
There are three types of goals:
- Business goals – what the business and customers are asking for and/or demanding
- Development goals – what the development team are striving to deliver
- Estimates - how long should it take to deliver
Often business goals are widely different from estimates and this leads to high risk of those business goals not being hit. Our development goals sit in the middle and should always be challenging the development team to deliver a better product and rewarding them accordingly.
We also can’t ignore business goals – if there’s a trade-show on a certain date, then the software has to be ready in time even if risk is high.
So, the goal is to set high development goals, but keep the risk between business goals and estimates low by:
1. Acknowledge business goals and organise milestone deadlines around these dates. Business goals may also drive the roadmap, so they may decide the priority of features – but not the complexity.
2. Identify what functionality and complexity can be delivered in time with low risk and promise this. Typically, this will be a cut down version of the feature, but allows you to promise the feature without going into detail.
3. Set goals that are a challenge, but achievable and will deliver much more than the low-risk functionality. Reward the team for hitting these goals. Make sure that the low-risk functionality is finished early and can be released independently of the higher goals, but focus the team on the higher goals.
Either way – don’t fall into the trap of pushing against business goals and setting easy to achieve development goals just so you can hit them every time and look good. It might feel like a win, but the dev team and the business will be the losers.
