Taking Small Bets in Software Development

In her book Thinking in Bets, Annie Duke says, “But life is more like poker. You could make the smartest, most careful decision... and still have it blow up in your face.” She goes on to talk about how incomplete information and the complexity of life leads to uncertainty. We should accept this uncertainty and acknowledge we do not know the best strategy. With this in mind, we should take small bets, learn from mistakes, and create positive feedback loops. 

Software development is a space that is full of uncertainty. Remote environments and technical nuance create black boxes and interdependencies that complicate life as a developer or dev leader. If we can operate better within this uncertainty, we stand to gain a lot. Faster product development, better use of resources, happier teams. So, how can we take small bets in software development? Let’s walk through small bets in three areas: resource allocation, product features, and personal development. 

Resource allocation is one of the primary jobs of the software development leader in any organization. The business or product will define what needs to be done, and the leader will devise a resource plan to complete it most efficiently. Sounds simple, but with many priorities and expensive resources (developers), it is far from simple. Great development leaders make small, strategic bets in their resource allocation. Instead of committing large teams, they start with smaller focused groups. They collect feedback and scale the project only when the potential is understood and requirements defined. By doing so, they manage resources wisely and create an environment of experimentation and focused effort, crucial for driving innovation and achieving sustainable success. 

Products are constantly evolving with new technology and new customer expectations. How do we know whether we are working on something valuable to our users? Each bet we make helps us learn something. We should set up a process that allows us to take small bets quickly, cheaply, and with little risk. Feature flagging is a technique that development teams can use to take small bets. With feature flags, newly developed features can be turned on or off for the entire user base or certain companies. It lets you ship features fast, test them with your internal teams, and slowly roll them out to the user base while watching for problems. It’s not an excuse for bad testing culture or process, but a way to eliminate the fear of shipping. There’s nothing developers hate more than completing a feature and having it shelved for weeks or months. With feature flags, you learn quickly what matters and why. 

Almost all development leaders were once individual contributing developers. They are often promoted to managers with no management experience, usually because they are one of your star developers. The best dev leaders use a trial run with developers they want to promote to managers. This process is fully communicated to the developer. In addition to being “team lead,” the developer is given more managerial responsibility: one-on-ones, team dynamics, leading meetings, etc. Since they have more responsibilities, they should have fewer coding responsibilities. If it works, the developer is fully promoted. If not, you can roll it back with clear feedback on what needs to be improved. It’s a small bet that can save a top developer. 

In conclusion, embracing small bets is a transformative approach for software development leaders. Whether it's resource allocation, product feature testing, or the promotion of new leaders, small bets enable us to learn, adapt, and grow in an environment full of uncertainty. This mindset builds the culture you want and ensures that our decisions are informed and adaptable. Make small bets, learn from them, eliminate what does not work, and double down on what does. Let’s make better software development teams.

--

Take a small bet by learning more about DevClarity today! Ask for a quick demo video.