The Engineering Manager

The beauty of constraints

September 30, 2025

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:

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.
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.
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.
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.
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:

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.
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.

Going direct

August 30, 2025

by James Stanier

comment 1

Managing managers

After a series of posts on LLMs, we’re returning to management fundamentals.

This month, we’re building upon the cultural shift that management has experienced recently: smaller, leaner and tighter orgs. We’ll build upon concepts from our previous articles: new advice for aspiring managers, should managers still code?, and being in the details.

This article, plus those listed above, reflect a new and expected management style for the current era: more hands-on, detail-oriented, and direct. This shift is driven by tighter economic conditions and the push for AI-driven efficiency.

Let’s examine the concept of “going direct.”

What is going direct?

Going direct means empowering everyone on your team to communicate openly and directly, without unnecessary intermediaries. This communication can be lateral (peer-to-peer) or diagonal (across different departments and levels), bypassing formal reporting chains.

Org charts are essential for defining roles, ownership, and facilitating performance management. However, people often mistakenly believe these charts also dictate communication paths, feeling obligated to follow the hierarchy. At best, this requires irritating message-passing. At worst, it dramatically slows down work and fosters bureaucracy.

An example best illustrates why this is an anti-pattern. Imagine person X in Team A needs to talk to person Y in Team B. These teams are in different departments, led by peer managers M and N, respectively.

When communication follows the org chart, X must tell their manager, who tells their manager M. M then talks to N (or perhaps even their shared manager) to pass the message down N’s reporting line to Y.

Wow, that was a mouthful.

As you can see, this is incredibly inefficient. When you read it back, it’s borderline ridiculous. X should be able to talk to Y directly. Not only should there be no barriers to this, but it should also be actively encouraged.

The benefits of going direct

The consequences of not going direct extend far beyond annoying message-passing. It implicitly sets a cultural precedent that approval is required for every action. This creates a bureaucratic culture and undermines your team’s sense of autonomy and efficacy.

Furthermore, forcing every decision up the chain can lead to counterproductive behaviors, like hiding or distorting information to secure a sign-off. Over time, staff spend more energy navigating internal politics than on what matters most: building great software (or hardware or toys or cars).

Going direct has a ton of benefits:

Faster communication and decision-making. When the people closest to a problem can talk directly, they can make the right decisions quickly amongst themselves.
Increased collaboration and knowledge sharing. It encourages direct collaboration across the organization, building connections, trust, empathy, and shared knowledge.
Reduced bottlenecks. By removing intermediaries, fewer people are needed to make a decision, reducing bottlenecks from communication delays or availability issues.
Increased trust. Allowing staff at all levels to talk to anyone they need signals a high degree of trust and autonomy. Conversely, requiring hierarchical approval implies superiors must ratify every decision.
Increased initiative and accountability. When people are empowered to make decisions directly, they are more likely to take ownership of their work and be accountable for the outcomes.

Managers save time too. As we discussed in the opening of the article, the management landscape has changed. When teams go direct, managers reclaim time to be more hands-on and in the details, which is a win-win for everyone.

Putting guardrails in place

So far, so good. We want our staff to go direct whenever they need to. The reasons are clear.

However, if you’re going to implement a culture of going direct (and you certainly should) you must put appropriate guardrails in place. These clarify how to go direct and when to revert to hierarchical communication.

When you announce this cultural shift to your team, it’s crucial to establish these guardrails upfront. You should:

Clarify decision-making authority. Define who has the authority to make certain decisions. The goal should be to maximize the number of decisions that don’t require management approval. Spell these out with examples related to your organization, such as prioritizing tasks, defining feature specifications, or architecting code.
Clarify when to seek approval. Conversely, define situations where approval is necessary. It also helps to provide examples. Frame these as “one-way door” decisions: choices that are difficult to reverse or that carry significant risk, such as potential downtime or exposure to security vulnerabilities. These types of decisions should be escalated up the management chain, or to the right group of domain experts.
Establish a process for sharing decisions. As more decisions are made locally, you need a system for documenting and sharing them with the wider organization. This could be done through regular written broadcasts or dedicated decision logs.

With these guardrails in place, you must also lead by example. Practice going direct yourself to show the organization what it looks like and why it’s beneficial.

You can do this by having skip-level meetings, talking to your engineers directly about their work (because you are in the details), and encouraging people to come direct to you with anything on their mind at any time (see: Jensen Huang’s “top 5 things” practice).

Additionally, always provide positive reinforcement when people go direct. This can be one-on-one praise or public recognition for a team that resolves blockers quickly or delivers at a fast pace. Call it out, give praise, and ensure that everyone knows that this is the right way to operate.

Some examples

With the reasoning and guardrails in place, let’s look at some examples.

Imagine a direct report asks if someone from another team can help with a task. This is a great opportunity to encourage them to go direct. You could say:

“I’d recommend you ask them directly. If you don’t make progress, or if it turns out the decision is a one-way door, then loop me in.”

Similarly, if you detect an issue that could be solved by direct communication, reinforce the principle. For example, if you were asked:

“Can you help me unblock this ticket? We’re waiting on a code review from the widget team.”

You could respond with:

“Have you asked them directly to prioritize it? Let me know if you don’t get a response.”

As you shift the company culture, you’ll find yourself repeating these responses. This is a good thing; you’re reinforcing the right behavior. Over time, people will message you less and resolve more issues themselves.

Coaching everyone on how to go direct

Simply telling direct reports to “go direct” isn’t enough. As a manager, your role is to equip your whole department with the tools to do it effectively so they build bridges, not friction. When people feel confident in their ability to communicate, they are far more likely to take the initiative and sort problems out themselves.

So coach them to make their requests easy to answer. A poorly phrased request creates more work for the recipient and is likely to be ignored. Encourage them to follow a simple structure: context, problem, and a clear ask.

Compare these two ways, the latter using that approach:

The ineffective way: “Hey, can you look at the widget API? It’s not working.” This message is vague, lacks context, and forces the recipient to start a fact-finding mission.
The effective way: “Hi Alex, hope you’re having a good week. I’m on the new reporting dashboard, and I’m seeing a 502 error when I call the /widgets/summary endpoint. This is blocking me from finishing my ticket. Could you point me to the right person on your team who knows about this endpoint? Thanks!” This is perfect. It provides context, defines the problem, and has a specific, low-effort ask.

Next, establish the etiquette. Encourage a “public by default” mindset. If a question isn’t sensitive, asking it in a shared channel like #team-widgets instead of a DM means others can learn from the answer, and it doesn’t get lost if one person is unavailable. Remind your team that “direct” doesn’t mean “instant.” Everyone is busy, so they should send their message and move on to another task.

Finally, give staff a simple escalation path. I often tell my team to follow up once, politely, later in the day if they haven’t heard anything (and assuming the person is not on vacation). If they’re still blocked after that, it’s no longer a communication issue; it’s down to priorities. That is the perfect time to offer your own assistance, perhaps by looping in their manager too.

Things to look out for

Be mindful of a few potential issues as you encourage direct communication.

First, some managers may feel uncomfortable. They might feel out of the loop, especially if they’re used to bureaucratic environments where they are involved in every step of every decision. The solution isn’t to reinstate that communication chain. Instead, encourage those managers to be so in the details that they already know what’s happening. If a manager is sufficiently in the details, no decision should catch them off guard. If it does, work with them on improving their awareness and involvement.

Second, watch for people currying favour. A common example is a team member who constantly goes to a specific senior manager because they know that leader is biased towards their opinions. In this scenario, the senior manager must ensure that no special treatment is given.

Coach leaders that their decisions must align with the company’s mission and values, not individual favoritism. This prevents back channels that subvert company priorities (e.g., prioritizing work due to a favorable relationship), which you will need to course-correct immediately.

And remember, you’ll need to follow exactly the same advice if particular individuals always come to you.

So, go direct

Going direct is an essential tool in an age of flatter hierarchies and hands-on, detail-oriented managers. Autonomous organizations always go direct, knowing when to escalate important or “one-way door” decisions.

By fostering the right culture, you create an environment where going direct is the norm. Your staff will feel empowered to communicate openly, enabling you to move faster than your competitors. As a leader, your job is to set the guardrails and cultural tone that empower everyone while ensuring they know when to escalate.

When done right, you’ll not only move faster but also free up significant time to focus on more impactful, strategic work, or even get your hands dirty in the code. You don’t have to be just a message queue.

So, go direct. The org chart does not control the flow of communication. In fact, you’re faster if you ignore it entirely.