When To Use Top-Down vs Bottom-Up Decision-Making

Many non-technical founder-CEOs ask their engineering team to do more work than they can do. When challenged, they say, “this is necessary for us to succeed, so the eng team should do it”. This is top-down thinking.

On the other hand, bottom-up thinking recognises the ability of the eng team to do only a certain amount of work, and picks work based on that, irrespective of what you need. If you have a truck that can carry 10 tons, it won’t be able to carry 50 tons. The fact that you need 50 tons transported doesn’t change the capability of the truck.

To succeed, you need to apply both top-down and bottom-up thinking, using each when required.

Top-down thinking makes sense from a strategic perspective and over long timescales:

• It lets you answer questions like: should we even do this? For example, if a project requires a year and $100,000 in the best case, we might conclude that we can’t even take afford to take it on.

• Top-down thinking lets you identify blind spots like “For this to succeed, we need research, development, UX and marketing, and I haven’t even thought about marketing”.

• Top-down thinking lets you hire people, since it’s a long game: a couple of months to find the right person, a month or two for him to join, then he may ditch you, and you’re back to square one. After he joins, he’ll take a couple of quarters to ramp up, notwithstanding the exaggerations about hitting the ground running. When you’re doing anything that requires such long timescales, you think to think strategically, for which top-down thinking works well.

Bottom-up thinking makes sense from a tactical perspective and over short timescales:

• It lets you answer questions like: among the following initiatives — improving desktop UX, improving mobile UX, improving reliability, reducing technical debt, improving scalability — how many can we take up? Maybe the answer is only two right now. How many tasks can be take up this sprint?

• Bottom-up thinking lets you say no to things you can’t do right now, irrespective of whether they’re needed, so that at least something gets done. For example, with one of my clients I’m working with, I reduced responsiveness to customer requests to make time for critical work, like making the system not crash all the time. I said no to certain expectations to make room for other work, because I was able to think bottom-up from the abilities of the engineering team.

As this infographic illustrates, top-down thinking helps us identify what we need to do, and bottom-up, what we can. When we combine these two, we’re able to identify gaps and then act to close them.

If you want me to handle all this for your company: