The Decision Making Framework

How My Decision Making Framework Saved a Software Project

This post may contain affiliate links. As an Amazon Associate I also earn from qualifying Amazon purchases at no cost to you. Full disclosure here.

For most of our history, we humans were food for lions, and tigers, and bears. Oh my. We were the hunted and all we had to defend ourselves were sticks, stones and millions of years of evolution creating a complex array of hormones alerting us to danger before we consciously knew it. Today we call it a gut feeling.

Your gut feeling is your body saying “careful, there may be a tiger around”.

Unless you’re living in a rural Indian village, your gut is most likely wrong and there is no tiger anywhere near you. (if you are however reading this from a rural Indian village, I’m impressed).

We can forgive our gut feeling for simply wanting to protect us and not realizing we’re no longer being hunted. Our bodies simply haven’t yet evolved to our new reality yet.

Since we haven’t evolved out of our gut feeling, many people still use a gut feeling as a barometer for whether a decision feels right or not. “Trusting your gut”, however, is nothing but a guess. It might feel right, but your gut feeling is based on fear and risk aversion.

There’s a better way.

The Project

“We need this done by March 28th in time for the event”. It was January 6th, and this was no small project.

My gut feeling spoke up. Danger.

My team of designers and engineers were working on a new project for one of our clients who wanted to show it off at one of their three big annual events. The original spec we wrote said had a timeline take about 6-8 months and I had just about 90 days.

Any engineer or engineering manager knows that unexpected delays crop up, no matter how good your requirements are. It can be even worse when you’re still maintaining a legacy system while standing up a new one.

Six months was a tight deadline already given our experience, let alone three. That left me with an important question: “How do I make a miracle happen?”

My gut feeling was that it was impossible.

My brain said otherwise.

I had to figure out which was right. I needed a framework.

The Decision Making Framework

Anytime I’m facing something new or staring down a challenge, it’s not enough to just go in whatever direction my gut says feels right. Fear is no way to make a good decision, and your gut is based on fear.

Sure, you can get lucky out every now and then, but with or without luck, the result is almost always subpar. Good managers and leaders look at data to help them make a decision. Great ones use a framework to understand the entire landscape.

One of the core philosophies to the Decision Making Framework and a thought process I use often is the following: “Define parameters and understand relationships”.

Translated into normal English, this means “What things can I change (levers) to make an impact on the outcome?”

Defining the parameters that impact the landscape, and understand the relationships between them is the key to modeling how different decisions or adjustments impact the ultimate outcome.

For the looming project deadline, it meant looking at what factors I control that can help us get this project launched on time and on budget.

Parameters, or levers, are anything you have the power to control that can affect the end result, like an input, an element, a principle or philosophy, process, or action.

Since even weather experts are wrong, and physics-bending superheroes don’t exist, things I can’t control don’t count.

Once I’ve identified all my parameters, I can look at how they relate to each other. Their relationships help to understand how changing one parameter impacts the others.

You can think of these parameters knobs on a stereo or turns in a road on a map.

There are several different types of parameters, and understanding the type you’re dealing with can make a difference in how you can adjust it.

– Parameters can be levers, meaning you can scale them up or down. Budget is a good example of this, as is time. Moving either of these without the other can affect the quality of a project, for example (You can have good, cheap, or fast. Pick two)

Parameters can be on-off switches or Booleans for you fellow engineers. These are any black and white decisions. Do or do not.

Parameters can be practices, like an HR policy, management process, or how a team uses a tool like Git.

Parameters can be elements. An example might be a plugin or framework an engineering team decides to use, like React or Bluebird. It could be a work vehicle, and deciding between a van or a truck

Parameters can be decisions. This is a one time choice with ramifications down the line. It’s a tougher one to measure since this can take many forms, and involves the fuzzy, human element. You can think of these as forks in a road.

As you’re working through a problem and looking at its parameters, understanding how a parameter works can help you to define how to adjust it to come to a solution. Levers can be scaled up or down, representing more or less. On off switches are yes or no answers. Elements can be added or removed or changed. Practices can be introduced, adjusted, or removed.

Understanding Limits

Every parameter has its limits, the highest or lowest value you can set it to. Understanding these limits helps you to understand how to set your parameters.

The most important parts of a lever are your upper and lower limits. If you were to turn the lever all the way up, or down, what quantifiable measurement does that represent? Is the lowest 0? Less than zero? Something else?

Let’s take budget for example. Since money can change hands in either direction, your lowest budget could be 0, or it could be negative where money is changing hands in the opposite direction (for most companies, this is the wrong direction). Time, on the other hand, has a hard lower limit of 0 since spending negative time would mean time traveling and that breaks all rules of physics, not to mention risking time paradoxes. Great Scott!

It can be extremely helpful to look at the extremes to understand the reasonable middle ground. Looking at a lever and considering unreasonable levels can help you consider values you might not have considered previously. Taking budget again, what if you were to triple the budget? How would that change things? What about tripling the amount of time?

The Relationships

Now that you have your parameters figured out and defined, you can start to look at the relationships between them and how they’re connected.

No parameters live in a vacuum. Every decision you make impacts the other decisions. Meaning if you change one, how does it change other parameters?

For example, looking at the project looming in front of us, I had three main levers: budget, delivery date, and quality, and two additional, very important levers: complexity, and features.

When complexity and features are the same, the three main levers adjust each other. You decrease time, you have to either increase the budget or decrease quality. If you decrease the budget, you have to sacrifice the timeline or quality.

With complexity comes trade-offs in budget or timeline. The choice of your framework or plugins comes with a trade-off in complexity, maybe time, and certainly budget. In some cases, you have an additional output of the user experience (i.e., does the application sacrifice speed for functionality?)

In almost every case, the relationship isn’t always 1 to 1 for every lever’s value. Meaning you can’t just turn a lever all the way down and expect the others to fly up to the top. For example, you can’t just increase the budget so much that the timeline is all of a sudden 48 hours. Likewise, you can’t increase the timeline so far that the budget is $0.

The Big Picture

So how did I resolve my timeline challenge? Once I understood my parameters, I looked at the relationships between them, and what I could adjust became clear and I had a framework I could use to model outcomes.

My main levers were timeline, budget, and quality. My two important levers were complexity and features, and I had two other personal levers: management, and personal time.

I knew that since we were pulling the timeline lever down, I also had to increase the budget lever. I knew since they didn’t have an unlimited budget, I had to give somewhere else, so we determined we had to decrease the quality lever.

Now, we didn’t want to deliver a bad product the customers would hate, so I had to adjust a few other things. So I looked at the ‘features’ lever and worked with the business analyst team to figure out what features we could descope for this release and quickly prioritize to deliver a V1.1. That helped us get closer to being able to meet the timeline, but there were still too many important features we couldn’t descope.

Personal Levers

So I had to dig into my personal levers. Since I was also pitching in on engineering in this project, I had to look at my own time levers. The lever of how much time I spent on this project also affected other personal time, so as I pushed my personal time lever down. Since there are only 24 hours in the day and I’m not a time traveler, I had to move down my lever on leisure time.

Finally, a picture emerged showing how we could complete the project on their timeline, though it would still be tight.

This is where I had to keep another lever in mind moving forward: management. I had to keep a close eye on progress and make sure the team wasn’t distracted by non-priority issues in the legacy system.

As the project moved forward, I was able to further adjust levers as things changed, such as scope change, personnel getting sick, and additional budget being approved.

In the end, we were able to deliver the project just in the knick of time, and the customers loved it. The event was a success, and our client went home happy, all thanks to being able to build a model based on understanding our parameters and defining their relationships. No gut feeling required.

If I had just trusted my gut, or worse, just winged it and tried my best, we would have failed. Instead, by using this framework I had the power to confirm that my gut feeling was both right and wrong. There was danger: we had a slim chance to meet our client’s needs, but there was also no reason to flee.

Using this framework, predicting the future becomes easier, no crystal ball needed. Building a model gives you clarity to know what to adjust and confidence to know what it’s impact on the outcome will be.

It’s a powerful framework you can apply to anything in your life, whether it’s a challenge, a business decision, or anything else.  



Leave a Comment

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

More Good Reads

Related Posts

person in long sleeve shirt holding a calculator

What is the Easiest Bookkeeping Method for Small Business?

As a small business owner, keeping track of your finances doesn’t have to be complicated. The easiest bookkeeping method for small businesses is using a simple spreadsheet to record income and expenses. This straightforward cash basis method can save you time and headaches compared to traditional accounting. Why Use a Spreadsheet? Spreadsheets are easy to

two women sitting in front of computer monitor

Whale Hunting – The Risk of Having One Major Client

In 2012 we shut down our startup. It was devastating and emotionally draining. Walking away from something you’ve put your blood sweat and tears into is a gut wrenching experience. Fortunately we had a team with a skillset so we pivoted to being a software consulting business. Hooray, we’re saved! Very quickly we signed a

selective focus photography of hustle and bust text

Business Name Brainstorming – How-to Guide

If the idea of finding the right name for your business fills you with anxiety, you’re not alone. Business name brainstorming can be really challenging. Fortunately, there’s a formula that makes it easier. In my years as an entrepreneur, I’ve come up with at least a dozen brand names for companies I’ve started or co-founded,