Jellybean Decisions

Photo by Patrick Fore / Unsplash

These kinds of decisions go by many names, but I usually call them Jellybean decisions. It's the kind of decision that teams often spend a lot of time working through, but in the long run don't have a major long term impact, or switching cost is low later.

Once you have decided to eat a handful of jellybeans, how much time do you spend picking out the colors? Sure you might have a favorite, or least favorite, but those colors don't have a major impact in the long run. There is no ANSI standard for jellybean flavor/color correlation (I checked) so your results are probably going to vary anyway. In the end you are going to eat all of them anyway right?

Many software decisions, especially early on in your development process are similar. You might spend a lot of time thinking through the pros and cons of a particular database or language decision. Maybe there are competing UI frameworks or SAAS providers. Spotting and cutting these off is a key element of getting something off the ground quickly.

The risk involved in this kind of thing is that you will spend more time and energy making the decision, than the difference between the choices is really going to make. There is the inevitable meeting, and then a decision matrix. Let's take two or three to PoC someone will say, and before you know it you have spent a couple of weeks. During this time, you not only haven't completed the work blocked by this decision, but you have this sort of pending thing that in the back of their minds, everyone on the team is waiting for. That's a cost even if you don't see it.

Worse, many of these decisions have similar impact to your jellybean flavor. The kinds of things in your decision matrix have some impact for sure, but it's not uncommon to see very small impacts from choices like this, or things that boil down to opinion.

There are some areas where you do need this kind of deep introspection; where a decision will have a large impact in time or cost, and you should make sure you work through this in a way that's appropriate and aware of that cost. It is however seldom needed at the beginning of a new project, speed is almost always more valuable there, and central to execution speed is decision making speed. Exercise the muscle of allowing individuals to make lots of small decisions quickly. If you could switch between two libraries in half a day, why would you spend five days making the decision of which one to use?

Decision making is often difficult, but you can control how difficult you make it. Remember the time you spend choosing between things needs to be offset later in the project for that time to be valuable.