This week we are going to take a deep dive into constraints: one of the most powerful tools that you have as a leader to help your team deliver more with less.

Now, this isn’t the first time that we’ve written about constraints, so if you’re interested in some history:

We looked at Parkinson’s Law back in 2024, which is the classic anti-pattern that occurs when people are given too much time (or no deadline at all) when asked to do something. The result is that work — like gas — expands to fill the time available, and yes, we’ve all been there with our school assignments.

We covered the iron triangle of project management in 2017, which is the classic model of the three constraints that projects typically have: scope, resources, and time. The idea is that you can only ever optimize two of the three.

We more recently explored how scope could be reframed as thoroughness in 2024, since scope alone rarely tells the whole story about what is being delivered.

But this time we’re talking about constraints as tools. Tools that you wield and can use.

Discovering places where you can add constraints to your projects is a superpower: it unlocks unconventional thinking, forces people to prioritize ruthlessly, and leads to unexpected and surprising results.

Let’s go on a journey together to explore the beauty of constraints. We’ll start by examining their paradoxical nature.

The constraint paradox

The word “constraint” often has a negative connotation. If you asked an average person, being “constrained” in general would not be seen as a desirable state. One does not wish to wear a pair of trousers that make them feel constrained.

However, paradoxically, constraints in engineering can often lead to our best work. The longstanding meme of IT projects being over budget and late is often due to a lack of constraints.

This is because projects often begin with a forward-facing process of thinking about all of the requirements that a product should have, and then estimating how long it will take to deliver them.

But the problem is that estimation of large projects (and even small ones) is essentially guesswork. If no constraints are imposed, the result is a project that stumbles along with ambiguous, bloated requirements and timelines. Walking along a path purely defined by what we want, without any constraints, is where it all goes wrong.

That is because this manner of thinking about projects — where we think about what we want and then work out how long it will take to get there, then go — very rarely makes us challenge ourselves to work in unconventional ways. There’s a difference between traveling a road to explore it and experience it versus trying to deliver a package as quickly as possible.

And talking of packages, a classic Bezos quote comes to mind here. “Frugality drives innovation, just like other constraints do. One of the only ways to get out of a tight box is to invent your way out.”

Putting oneself in a tight box, paradoxically, will make one execute better. Constraints tend to bring out the best in people.

Innovation through constraints

This isn’t just hyperbole, either. There are many great examples of products that achieved innovation through constraints. Here’s some of my favorites.

The original Sony Walkman emerged from a focused set of constraints: power, cost and size for portable travel. It’s worth remembering that at the time, cassette players and home stereos were bulky, imposing hunks of machinery and plastic.

The engineers were tasked with creating a device that could play music whilst walking and on long flights, which meant innovation in miniaturization, motor efficiency and stability, and headphone design.

Additionally, the compact form factor constraints dramatically led to stripping back requirements that were standard on home stereos, such as recording capabilities.

Another example is Twitter, which began with a strict 140-character limit, similar to SMS. This constraint forced users to be concise and creative in their communication. Interestingly, when Twitter expanded the character limit to 280, only 5% of users utilized the additional space, demonstrating how constraints can shape behavior and innovation. Looking at X today, many messages are still short and to the point, showing how the original constraint has had a lasting impact.

My favourite constraint-driven design story is that of the Dyson dual cyclone vacuum cleaner. The constraint of a bagless vacuum led to the invention of cyclonic separation on a small scale. It took 5,127 prototypes in James Dyson’s garden outbuilding to achieve this over many years of toil and no income. However, these constraints brought the first real innovation to vacuum cleaners in decades. Now Dyson is a household name and billion-dollar company.

Types of constraints

Constraints typically fall into three categories, broadly categorized by the iron triangle of project management: scope, resources, and time. I wrote about this way back in the early days of this blog in 2017, although my thinking has evolved since then.

But how?

Whereas earlier in my career I would consider those three trade-offs typically whilst wearing a project manager hat, I now consider them as categories of constraints that can be purposefully applied to projects in order to encourage teams to deliver more with less.

So, looking at each corner of the iron triangle, let’s see along which vectors constraints can be applied:

• Scope is the set of features and requirements that a project is trying to deliver. However, instead of just accepting scope for what it is, great leaders try to ruthlessly cut down scope to shrink a project to the bare essentials. We’ll look at an algorithm for doing this shortly.
• Resources typically means the number of people working on a project, which you can deliberately limit in order to force tough prioritization choices. However, resources can also mean money or other technical constraints, such as cost of infrastructure, or choice of technology. Great leaders will ensure that resources are deliberately limited in order to drive innovation. For example, instead of standing up new search infrastructure, what could you do with a simple database query?
• Time is straightforward: Parkinson’s Law tells us that work expands to fill the time available. Therefore, great leaders will encourage teams to set challenging deadlines and use them as forcing functions to keep scope and resources in check.

So the way that I encourage you to look at the iron triangle is not as an accepted set of trade-offs, but instead as a toolkit of constraints that are available to engineering leaders to help their teams deliver more with less.

At all stages of a project, from the beginning to the end, never accept the status quo. Always ask yourself: “Can we do this with less scope, less resources, or less time?”

So how can you start looking at your projects and seeing whether constraints can be applied?

Let’s look at a practical algorithm for doing that which is one of the most repeated themes in Walter Isaacson’s Elon Musk autobiography.

The 5-step algorithm

I watch this video at least once a month as a reminder to question everything that we’re doing. It’s a short (1 minute and 29 second) clip of Elon Musk explaining his 5-step algorithm for finding ways to strip projects back to their bare essentials.

This isn’t just useful at the beginning of projects. As we mentioned before, estimation is guesswork, and so as projects evolve, it’s important to continually re-evaluate whether the original constraints are still valid, and if not, change or delete them. Repeated and continual application of this algorithm will help you do that.

The algorithm touches on all three corners of the iron triangle, inviting you to insert constraints in scope, resources and time.

Here’s the algorithm:

1. Question the requirements. Musk says that the most common error of a smart engineer is to optimize things that shouldn’t exist in the first place. He stipulates that smart folk are trained to answer questions, but not to challenge the questions in the first place. So, the first step of the algorithm is to accept that some or all of the requirements are dumb, and they should especially be questioned if they come from a smart person! For each requirement, ensure that it is attributable to a specific person or user need. If not, challenge it ruthlessly. If you can’t justify a requirement, then it gets deleted with no remorse.
2. Remove unnecessary steps. Once the requirements have been stripped back to the essentials, look at all of the steps of the project or process to achieve them. Try very hard to delete every step or feature that isn’t absolutely necessary. In fact, a good rule of thumb is to remove steps until you are forced to put some back in. That’s when you know that you’ve found the bare minimum.
3. Optimize. Now you know that you’ve stripped the project back to its bare essentials, you can optimize each step. This is where you can apply your engineering skills to make each step as efficient as possible. That could be code optimization, process improvement, or tooling. But remember: the only things that get optimized are the bare essentials that remain.
4. Accelerate time-to-learning. Next, look at ways in which you can accelerate cycle time, specifically the amount of time that it takes to get something done that you can learn from so you can start your next iteration. What’s the fastest way to prototype, build, ship, measure and learn? The maxim is that if the timeline is long, it’s wrong.
5. Automate. Finally, look at ways of using automation to speed things up. Note that this is the last step. No time should be spent on automating things that shouldn’t exist in the first place. Musk tells the story of how he automated too early in his factories, resulting in expensive robots needing to be removed because the steps were unnecessary or could be done more efficiently by hand.

Try going through this algorithm with your team on your current project. You’ll often surprise yourself at how much you can simplify what you’re doing.

Your constraint toolkit

Constraints are tools, and as such, you should have a toolkit of constraints that you can use at any time. Below is a non-exhaustive list of tools categorized by scope, resources, and time.

Scope constraints

• Use the 5-step algorithm above multiple times during a project to continually re-evaluate scope. Perhaps schedule it weekly or monthly to ensure that your project remains as lean as possible.
• Use techniques such as the MoSCoW method (must have, should have, could have, won’t have) to further strip back requirements ruthlessly.
• Explicitly specify a single-sentence “success condition” for a project or feature and work backwards from there to ensure that everything is aligned to that goal. Delete any requirements that don’t align. This increases your cycle time to learn.
• Tightly constrain the number of features to cover the absolute minimum happy path for the first version. Defer all nice-to-haves and edge cases to future iterations: learning about the happy path is more important than building out the full feature set.
• Remove configuration options. Lean heavily into sensible defaults that work for the majority of users and only add configuration options later if absolutely necessary. Configurability and optionality causes complexity.
• Build and ship for one platform first. Don’t try to launch everywhere for everyone in the first version. Pick a single platform (web, iOS, Android, etc.) and ship that only to learn faster. Once you’ve learned that what you’ve built is valuable, you can expand to other platforms.

Resource constraints

• Limit the size of teams deliberately. It’s an easy escape hatch for teams to always feel like they need more people. Instead, set the challenge of being resourceful with less. It’ll force scope constraints, prioritization, and new ways of thinking. Ironically needing to hire more people often makes projects take longer; not only because of the Mythical Man-Month effect, but it takes a long time to ramp up new people (see: the contribution curve).
• Limit costs. If the scope of a project is going to incur high infrastructure costs, challenge the team to find ways of doing it with lower-cost alternatives. This will often lead to new and interesting ways of thinking about the problem than buying more RAM, CPU or instance hours.
• Limit technology choices. Instead of always reaching for another new technology or service, challenge the team to use what they already have. A huge amount can be done with simple databases, queues, and caches if you think about the problem in the right way, and your existing technology stack already exists and doesn’t need provisioned or learned.

Time constraints

• Set challenging deadlines. Instead of asking “How long will this take?” ask “What’s the fastest we can do this?” and then work backwards from there. This will often lead to new ways of thinking about the problem.
• Continually ask “What would it take to do this in half the time?” You will be surprised at how many timelines can be dramatically shaved down just by asking this question.
• Use sub-milestones as forcing functions. For example, having an expected cadence of shipping daily or demoing weekly will force teams to prioritize and shape their work in a different way.
• Use time-boxed iterations. Instead of open-ended projects, use fixed-length sprints or iterations that yield shipped software or demos to create a sense of urgency and focus.

Now you try!

It’s over to you: you now have the tools, so give some of these techniques a go.

At the very least, do the following:

1. Apply the 5-step algorithm to one of your current projects. Do it as a team exercise and see what you can shave from the requirements.
2. Challenge one timeline by asking “What would it take to do this in half the time?” and see what happens.

There are so few leaders that do the above that you’ll not only be surprised at how much time you can save, but also how much your team will appreciate the challenge.

Trust me: constraints are your friend.