2024.10.06

LXVII

After my post last week about how rules can unnecessarily constrain you, someone brought up to me that constraints are a source of creativity.

I fully agree with that. I think the challenge is maybe in picking which constraints you’ll accept at any given time. 

-------------------

Guns & Fights 

The natural conclusion of my last post was the following: The fastest way to win a jiu jitsu match is with a gun. However, this is not the fastest to get better at jiu jitsu. The best way to get better at jiu jitsu is to find out why you’re losing and then stop losing for that same reason.

There will always be constraints. Sometimes, those constraints are “bad” rules, and they should be ignored or done away with. Other times, constraints help you actually define and focus on a problem for you to solve. 

This problem is particularly interesting in startups, where properly defining the constraints you’re going to (temporarily) accept and ones that you are going to aggressively remove informs the allocation of your time.

Start Ups as an Optimization Problem

It is totally conceivable to view startups as an optimization problem. The ultimate metric you are trying to optimize is growth, whether it manifests as growth of margins, or revenue, or users. Then, your job is to identify and remove the binding constraints that are in the way of your growth. 

While the view is in some ways limited, it is helpful in that it reframes the problem of startups as chiefly the problem of identifying and dispatching with the things that are actually blocking your growth, and operating within the bounds of the things that are not blocking your growth.

Consulting Clubs

A humorous example of focusing on the wrong constraint from my own experience was employing numerous consulting clubs when at the University of Michigan. While the employment was on paper free, if you count the time wasted managing the clubs, the endeavors were insanely expensive. 

Of the five engagements myself and the startups I was involved in managed, I think all but one was a waste of time*. That statement is not intended as a slight to the clubs by any means; rather, the tasks we had them do were inherently not solving problems that were blocking our growth. However, by spending time managing these clubs that were working on strategy, financial modeling, or market research, we were implicitly taking the stance that not having such things was blocking our growth.

Not surprisingly, the resulting surplus of power points did not solve any of our problems. 

Of course, we did not explicitly realize that we were focusing on the wrong thing. Rather, we made the naive mistake of thinking that “leverage” was inherently valuable.

Leverage is only valuable if you use it to amplify a valuable activity. In terms of constraints, leverage is only valuable if you use it to further reduce a constraint that is impeding your growth.

*The good engagement involved the creation of an options pricing calculator; it was more product development than consulting.

Faster Code

A month and a half ago, one of the constraints of BirdDog was how fast our code could run.

It would take upwards of 30 minutes to run one “job”, which is the enrichment of an account. We run such jobs on a server in my basement. When we would do so, the server's cpus would get over clocked and the code would sometimes silently fail or break. This was an impediment to getting feedback, as one user typically wants upwards of 30 accounts enriched, even for a demo.

Now, the comically bad decision would have been for Jack and I to say “we need to raise money RIGHT NOW so we can improve the power of the computer or pay for super expensive cloud computing.”

Rather, what we did was accept the constraint of the power of the computer in my basement. As we’ve strived to make the most of that resource, over the past 1.5 months, the average completion time for a job has decreased from taking upwards of 30 minutes to only taking 55 seconds*. Moreover, now, we can reliably run batches of over 200 jobs without me staring at the computer to make sure nothing breaks. 

Caption: Those like green bars with the percentages represent an easy way to monitor system resources; this was during a lighter job.

If we had unlimited resources, we could afford to have poorly engineered code (read: expensive to run and time consuming to maintain). By accepting the constraint of my machine’s resources, our creativity has gone towards reducing complexity while increasing the quality and robustness of the code itself. Moreover, I’m convinced that we’ve barely scratched the surface of what we can do with the machine. 

*This is not the throughput rate, but the throughput rate is much faster, too. Given that the newer code has consumed less than half of my computer’s resources at the current speed, I am incrementally increasing concurrency and, resultantly, average speed, until it breaks. 

The Real Constraint

The code is relatively fast now. That is cool. However, at this time, focusing on making it faster wouldn’t actually help growth anymore.

As much as I’d love to sit in the garage making our race car go faster, it makes sense to accept this new speed constraint. Because really, we’re trying to grow our startup, not make fast code. The latter only matters insofar as it accelerates the former.

This is hard to remember when making faster code is so much fun. But, I remind myself of the wise words of one of my advisors:

Unfortunately, in some ways, I’m that engineer that needs to be shot. But, I also hold the gun, and so does Jack.

Now, after much discussion, we’ve come to the conclusion that the most binding constraint to our growth is getting users to use it consistently. We’re fairly confident that speed is no longer what we should focus on, nor is the breadth of firmographic data that we’re pulling is. Instead, we are honing in on the presentation of the information in an engaging way as well as increasing the quality and quantity of what seem to be the most actionable data points–individual contact information.

In other words, we’re temporarily accepting a number of constraints, including the speed of our software, so we can aggressively focus on overcoming the constraints most in the way of growth.

-------------------

Growth is good, but growing for the sake of growing is what cancer does.

Don’t worry, BirdDog has a number of why’s.

Live Deeply,