Ops — Decision Making
The fastest way to get things done is identify what inputs are needed to make decisions, identify the smallest group needed to make the decision, form the group, empower the group, make a decision, and execute to the decision.
The best way to reduce decision complexity is to start by reducing the amount of time and energy spent on decisions, then streamline what is left.
First Let Go
All decisions have risk. Annie Duke [1] puts it beautifully in her book; there is always an element of luck, which I define as “when chance intersects with the prepared”. The more experience you have learned from or have access to, coupled with curiosity, enables rapid rejection of bad options.
Separate decisions from outcomes — you can make good decisions and still have a bad outcome, or vice versa. But, you need to know which it was, even if no one else knows or cares.
In the old days at Fujitsu, we spent 3 days in a huddle after every launch; one day to look at what we did wrong, one day on what we did right, and the last day on what we would do for the next product development cycle. Our whiteboard-to-dock time went down from 13 months to 7 months while DELL took 18 months, a record that still holds in that product category.
We launched 13 products in less than 5 years, innovating in hardware, firmware, thermals and manufacturing. We did that by eliminating decision time; our Gantt charts were milestones that identified the decisions that had to be made at each point, and we moved fast to make decisions at speed.
Decide if You Really Need to Invest Decision Effort
There are incredibly few scenarios where your choice of coffee blend will impact you. Just make a micro-decision and move on. Similarly with many other choices. Spending time on what socks to wear is a waste; pick the pair closest to your hands that function and move on.
Decide Who Needs to Decide
Don’t overload yourself. Convey standards and decision guidelines, and let your team decide as much as possible without you. Be clear about what you must decide, what you would like to have input on, and what you are offloading completely.
The logical follow on to this is to have decisions made by the team members who actually know the domain/material. In the cases where you need to make the final call, the recommendations that matter come from them. Andy Grove [2] has a really good explanation of this approach, with examples of how he used this at the real Intel.
What Does Your Decision Lock You Into?
Understanding your decision lock-in is key. Spend time on the decisions that lock you into a path. Those that are irreversible and impactful are worth the most attention.
Choosing your processor locks you into a tool-chain, specific IO and processing constraints, along with supply chain and quality profiles. This is worth spending time on. There are few companies that provide less support to startups than Broadcom, for example, leaving you with tattered tools and aspirin dependency. Intel, TI and Freescale (NXP) provide support through skilled distributors and backed up by solid documentation and tool chains.
Choosing an investor will impact your startup, your family — and your mental health. This decision also locks in potential Board Members, Investor Rights Agreements, and more. This is worth spending time on. You should already know and have reason to trust the investor. The risks from a bad investor is astronomical and potentially irreversible. Bootstrapping until the right investor is found, or funding is no longer needed seems more likely to succeed.
Choosing a co-founder also rises to the same level. This issue has been examined in detail by NFX, YC and others. This is worth reading up and spending time on.
Your law firm is less important than the partner who will actually work with you. A bad partner in a good firm is useless. A good partner in any firm is a win, and the best is a great partner in a great firm.
Your choice of cloud computing can be changed early on; as micro-service usage goes up, platform binding becomes tighter. Select the best for your needs on an ongoing basis, or go all in due to other dominant factors. But define a method for decisions in this area too.
Your choice of CTO is key; your choice of junior developer is interesting, but reversible. Spend more time thinking about your CTO. For junior developer, just hire for attitude and clarity of thinking along with basic competence and move on.
Clarity of Goals Helps with Decisions
We will ship these features by June 30th, 2021 is a clear statement. So is “we will speak with 100 potential customers in the next 60 days”.
Making this kind of statement means that our time MUST align with these goals. Establishing these goals gives both the freedom and responsibility to say No to everything than can be rejected outright, postponed or delegated.
Rejecting things like “lets add one more feature in this release” can be followed by “put this into the backlog for the next release planning session”.
That means, every decision can be evaluated against goals.
Decisions by Elimination
Go down a decision tree; as soon as a bad option surface emerges, stop, go back and look at prior decision steps and alternates. If all options are bad, then move to figuring out the least bad option. Using a decsion- tree structure also allows you to estimate probability, and the note what your decisions lock you into.
If your sales are not growing, you will have difficulty raising funds. That means you need to buy time to buy the runway needed to make changes in product or sales strategy. That means you need to cut expenses. That decision takes < 0.1 seconds to make. The next decision is what to cut and what to do to ramp up sales. That will take longer — but you need runway first.
In a startup, time is of essence — you are either funded and racing, or bootstrapping and working part-time. Either way you have limited and irreplaceable high quality work-time. Decisions that do not make sense with major variables, will not make sense by tweaking smaller variables. Decision trees tend to get you there faster.
Making Time to Think
Long ago, I was fortunate enough to visit IBM Research in upstate NY. They have the simplest tagline of all time — “Think”. Apple went with “Think Different” — at least for the first few decades. It’s worth taking the time to think about issues. Spending all your time in meetings, may not give you time to reflect and digest your increasing knowledge.
https://en.wikipedia.org/wiki/Think_%28IBM%29
What if You’re on The Road a Lot?
With the pandemic waning in the US in particular, I expect face to face meetings to resume. (Sales folks will use video — until they lose deals to the sale person who visited the client in person, especially in B2B / Enterprise.)
Not that long ago, I could easily be on the road for 4 ~ 6 hours in one day, so I needed a framework I could use while driving. Before starting off, I would remind myself of the 5 things I wanted to think through. I could then count them down while driving, which also allowed for going down into levels, also 5 deep, though I rarely made it past 3 deep on the top 3 issues :) (Sticky notes come in very useful here.)
This approach helps in looking at problems from different angles; a pre-requisite to making harder decisions in any case.
This post resulted from a request from a reader like you. Feedback and requests for new topics are always welcome.
References and Reading:
[1] Annie Duke’s book on Smarter Decisions.
[2] Andy Grove’s seminal management handbook — a MUST (re)read
