On Constraints & Priorities

2025.08.17

CXIII

[Knowing What You Want, The Selfishness of Priorities, Panacea of Constraints, Postgres & Speeding, Constraints as DNA]

Thesis: Your constraints define you just as much as your goals do.

[Knowing What You Want]

The first step to getting what you want is to actually know what you want and to define it in a useful way.

Wanting to have a successful company is a terribly ill defined thing that is not at all useful at all, because it is not pinned down to anything consistent. Is successful having the most employees, the best product, the most money raised, the most revenue, the most profits?

On the other hand, wanting to personally have $10M in assets, half of which are liquid, is a pretty clear cut goal. You can measure progress towards it and you know when you hit it.

There will be no disagreement about it or question in the end if you do it.

Really, though, a lot has already been said by many writers about defining your goals*. I think the more interesting and much less talked about notion is how much the constraints with which you're pursuing your goal effects the outcome.

This is for two big reasons:

1. Adding constraints is way easier than trying to optimize for two things at once.

2. Given two exactly similar people with the same goals, different constraints can vastly effect the outcomes.

So, once you do pick your goal, you need to be just as conscious, if not more conscious, about picking your constraints.

*I think Tim Ferriss' Four Hour Workweek spends quite a bit of time on getting very concrete about your goals and what you actually want at the start of the book.

[The Selfishness of Priorities]

Most definitions of priorities are inherently selfish, and I don't mean this in a bad way.

What it means is that to really be a priority, something needs to be THE most important thing. You strive towards it at the expense of everything else.

This has to be true because the world is full of trade offs.

One of the most straightforward examples that many of you will have experienced is the difficulty of losing weight while gaining muscle at the same time.

If you are trying to gain muscle, you want to be eating a lot of food. If you are trying to lose weight, you want to be eating not as much food. So it is really hard, if not flat out impossible, to do both at the same time!

Even for things that aren't so diametrically opposed, like revenue and profits, it's still hard to optimize for both at once. While some decisions might increase BOTH profits and revenue, and you should obviously make them, many other decisions won't be so obvious and will require choosing one of the other, or sometimes worse, doing neither!

If you could 1.5x revenue, but cut your margins in half, would you do it? How would you ever decide if you were trying to both increase revenue AND profits? Sure, your revenue would increase, but your profits would both decrease! And they would go up at a slower rate in the future…

Many such joint optimization functions quickly become untenable, even if on the surface they seem aligned.

Such is the selfish nature of priorities--in practice, you can really only have one!

[Panacea of Constraints]

If we revisit both examples above, and replace the join optimization function with constraints, then we can much more easily navigate each situation.

Now, instead of gaining muscle and losing weight, we can reconsider it as optimizing for muscle gain while not exceeding some percentage of body fat, say 15%.

This is much more tenable and workable--now you can make decisions around what to eat & what workouts to do A LOT more easily than if you have to weigh to conflicting priorities. And, when you’re done, you can more or less invert it: now, maybe you are trying to lose weight while maintaining some over all muscle mass.

It’s a very similar case for revenue--perhaps you decide to maximize revenue while never dropping below some target profit margin. Now, that above decision is easy to make. If it lowers your profit margins more than you can except, then you don’t do it! And if there's a gradient where you can pick some trade off that increases your revenue by less than 1.5x but hurts your margins less, too, now you can easily pick a point that will drive you towards your goal while staying in the constraints (maybe increase revenue by 1.2x while dropping profit margins by 20% is okay).

Constraints aren't really a joint optimization function, but they can give you much more discrete decision making criteria.

Still, that's nowhere near all there is to say about constraints, because different constraints can lead to vastly different outcomes, even when the same priority is being pursued.

[Postgres & Speeding]

Two places that it's easy to see the different effect of constraints on your outcome are in SQL & when you're speeding.

If you're trying to get from Muskegon to Detroit by automobile as fast as possible, you will likely want to have some constraint around speed. After all, if you go too fast, you might get pulled over, which would wipe out your speed gains!

So, maybe you go 83MPH, because that's what a polish kid who liked to speed in highschool told you was the "magic number" at which you could go on a 70MPH highway in Michigan without getting pulled over, and in the 7 years since then, the folk wisdom has yet to be disproved.

The outcome you get from this would be quite different than the one for which the only constraint on your speed was how fast you could go without feeling like you were in constant danger (for arguments sake, say 110MPH).

If you went with the latter constraint, and also made an investment in a radar detector and laser deflector, you would likely get their substantially faster. If you invested in neither of those things, you might get there slower, after having to argue with the officer who pulled you over and then drive a reasonable speed again for a bit after seeing him or her.

Likewise, querying a database like a Postgresql instance, is somewhat similar to driving--if you change the constraints, you change the outcome.

SQL is a language that lets you query a database. It's basically english:

SELECT name FROM people WHERE email = '[email protected]'

The database then reads this and, based on some rules, comes up with a "Query Plan" to figure out how it's going to retrieve the data. This is pretty easy when it's one piece of data from one table as in the example above, but when it's a more complex query it might be a little bit less clear:

WITH n_names AS (SELECT name FROM people WHERE name ilike 'n%') SELECT p.name, c.company, h.company as holding_company FROM people p JOIN company c ON p.employer_id = c.id JOIN holding_and_company_join hc ON c.id = hc.company_id JOIN holding_companies h ON hc.holding_company_id = h.id WHERE p.name IN n_names ORDER BY c.market_cap DESC NULLS LAST

The first query just asked for the name of anyone with my email address; the second query wants to know the holding company of the employer of everyone whose name starts with n, starting with the employer with the biggest market cap.

Now, the planner has some more decisions to make, based off of indexes you have and resources available to it.

The resources available to it part is super interesting, because in some cases, as I had the misfortune of experiencing this week, you can change the constraints by giving the worker MORE resources, and it can come up with a WORSE plan!

It might decide to do a more resource intensive operation, like build a hash map, because it estimates that will be more efficient. In my case, loosening the memory constraint made a query about 10 times slower than it was when the constraint was more strict!

To reiterate, it was the EXACT SAME query, but the code deciding how to execute it had a looser constraint, so the execution path became WORSE.

If you liked this post, subscribe—I’ve been here every Sunday for the last 113 Sundays and don’t plan on stopping anytime soon…

[Constraints as DNA]

Now say you're starting a business and you have the goal of hitting $10M ARR, and so does your competitor.

Your constraints are the following:

1. Maintain x% net margins

2. Maintain x% gross margins

3. Hire no more than 5 people

4. Never sell more than x% of your business

On the other hand, your competitors constraints are the following:

1. Hit the ARR target in the next 12 months

You both will build massively different businesses, which is okay, they'll just be really different.

The competitor will 100% get their faster than you—they will be willing to spend money that you aren't on things from custom acquisition to paying third party service providers to help improve the product.

You might end up trying to make the one, core thing you do as valuable as possible (as defined by price) so you can manage it with a lower complexity business, where as they might be incentivized to throw the kitchen sink at it. And yes, they'll definitely raise a lot of money, hire a lot, and spend it fast.

The two businesses might be in the same market, but they will function and operate worlds apart.

The constraints you select are going to be just as important or more important than your priority.

Whether it's a fitness goal or how you build a business, you need to choose them wisely.

Live Deeply,