How difficult is it to change decisions?
Running any business involves countless decisions but software startups are in a class of their own because of their growth potential. You’re not likely to open a small restaurant that turns into a worldwide chain in a few years. If it did, it would happen because you made it happen. With software, the users determine the scale and, as the owner, you are forced to keep up.
This concept of “keeping up with success” is what makes software uniquely challenging and forces a stronger decision-making discipline.
What makes a decision hard to change?
The primary reason that a decision becomes hard to change is its amount of dependencies. How many other decisions, processes, and efforts hinge on this one?
Examples of decisions with a lot of dependencies are: business names, programming languages and frameworks, and employee computer OS. Each of these will usually be a nightmare to change and take years before you really feel like it’s in the rear-view mirror. They’re hard because of the cascading impact that changing them creates. Consider how many domain names, contractual agreements, and marketing efforts would need to change with a business name change. How many business processes, collaboration methods, and computer training will have to be changed if you switch from Windows to Linux for your workforce? The change will be so painful for your team that there will be strong resistance. In many cases you might expect people to quit. As a result, these decisions must be well thought-out so that changes are very unlikely.
Examples of decisions that are important enough to be worth mentioning but have minimal dependencies might be office location, team structure, or even logo design. Logo design might have the most resistance of these examples, but it really is not that bad. This is how companies are able to refresh their branding from time to time. Logos are important in terms of mindshare but from a business perspective, very few things depend on the specifics of the logo design. You’ll print some new shirts and hats or whatever, but you’re not going to spend weeks or months rebuilding a critical aspect of your product because the logo changed. If things are built correctly, changing the logo and branding color scheme in your primary application should take about an hour of dev time. Same goes for the other examples. Changing your office location won’t be convenient and some employees might regret moving to their current location, but few things are really going to change and what does change might even be refreshing or welcomed.
Classify your decisions
Now that you understand the importance of dependencies, start classifying new decisions in this way. Some find it helpful to use a tree as an analogy. Your big decisions with countless dependencies are in the trunk of the tree. Things like logo and office location might be a branch. And tiny things like coffee brand in the break room are the small twigs at the very end with no dependencies at all. You might call a high dependency decision as a “trunk decision” and a medium-to-low dependency decision as a “branch decision”.
Treat Trunk and Branch Decisions Differently
When you classify a decision as a trunk decision, that means it’s a critical decision. You need to carefully choose the decision maker(s) and you’ll want to give it the time that it needs. You can’t spend two years deciding your programming language, but spending a couple weeks researching options and asking others for opinions isn’t a bad idea. Don’t move forward if you’re not confident in these types of decisions. Try to think ahead and foresee the trunk decisions before they’re staring you in the face, this will help you give them the time they need and not rush your decision.
When you come across branch decisions, you can be more relaxed. A quick decision may be fine. It might also be a good opportunity to delegate the decision to someone else who wants more responsibility. But do not waste a ton of time and resources on a decision that’s easy to change.
