When “No” Becomes Your Best Design Tool
When “No” Becomes Your Best Design Tool
When “No” Becomes Your Best Design Tool
April 2020. Elan Lee was against the wall. His company had just sold thousands of tabletop games online as people scrambled for ways to stay busy in lockdown, but every fulfillment warehouse was shut, fast. So he rented a line of semi-trucks, parked them outside his house, and used them as pop-up distribution centers.
The constraint wasn’t subtle. He didn’t win because he had deep pockets or a perfect plan. The plan was there was no plan. Every single decision, from packing orders to handling returns, now flowed through the bottleneck of semi-truck space and home logistics. Suddenly, priorities sharpened. What could fit. What was truly urgent. What tricks actually moved the pile. When the rules changed, the constraint wasn’t a brake. It was the steering wheel.
Most engineering teams don’t get this moment to practice leading engineering teams under constraints. There’s a reflex to chase resources: more servers, another engineer, a bigger backlog. Or try to optimize every variable at once. It sounds like progress, but what actually happens is you diffuse priorities, slow execution, and make systems so brittle that a single change sends everyone scrambling.
Elan recapped this on My First Million a few months back, admitting the workaround wasn’t some clever master plan. It was a direct response to being boxed in—warehouse doors shut, clocks ticking, orders piling up, and one obvious lever left to pull.
I keep thinking of all the times my team had to optimize around constraints. Like literally putting posters in urinals to get engineers’ attention, or moonlighting as grocers because the supply chain tanked. Elan won because people kept saying no, and he built around it: semi-trucks, living rooms, hand-labeling.
These weren’t quirky stunts. They were smart, scrappy solutions born from the realities of leading engineering teams under constraints. If you’re leading a team today, don’t wait for resources. Use the constraint. It’s the starting point, not a setback.
Constraints Aren’t Limits—They’re Leadership Instruments for Leading Engineering Teams Under Constraints
Let’s call it out. Constraints shrink the decision space. When you put a single, real boundary in front of your team, you cut through endless possibilities and force the hard tradeoffs, now—not later. Constraints don’t just keep teams focused, they turn vague intentions into clear actions. Instead of drowning in options, the team moves as one. You get alignment, not consensus. The right limits bring out creativity that no bottomless resource can match.
It took me years (and more than a few burned-out teams) to see what was happening. Every time I chased more resources—headcount, budget, server capacity—the scope ballooned. Progress slowed. People started second-guessing everything. So I did something that still feels counterintuitive. I started chasing constraints instead. The best, most inventive answers have always shown up before you scale. Once you have too much runway, you lose the urgency that drives real invention.
A quick tangent—maybe this is just me, but I once spent a week trying to shave five seconds off a trivial response time metric. Nobody cared. The users didn’t notice. By Friday, the team was exhausted from chasing paste-thin optimizations. We missed a real bug in signups because we were too busy polishing a vanity number. That was one of those “never again” moments, and now when someone pitches endless tuning, I remember the wasted week, not the chart.
Here’s why: designing without limits sends teams into a noise storm. Every decision feels open-ended, so you optimize everything, but only on paper. You start building for traffic you don’t have, spinning up services for “future scale,” and it gets fragile. Systems collapse fast when what you built wasn’t tested against real friction but theoretical abundance. Deadlines slip. Edge cases multiply. Team energy seeps away chasing scenarios that might never show up.
Pick a primary constraint. One real boundary that defines the project. Not a laundry list of stretch goals. When you choose a single, explicit limit, you clear the fog. Every tradeoff becomes visible, and the team finds the best possible answer inside that frame.
Six months ago I thought endurance was the answer—just push until resources catch up. Now I see constraints as the catalyst. The most inventive work rarely happens when you have everything.
So let’s turn this into practice. You know what a constraint can do; next, let’s use it to drive constraint-based engineering decisions that make your choices sharper—right now.
How to Pick—and Pressure-Test—Your Primary Constraint
When you choose a primary constraint for your team, it comes down to one simple question. What is your user counting on? Start with what actually matters to them—a 100ms response, shipping weekly, a fixed compute budget. The heart of the model is always: ‘What do my users care about?‘ That question should guide which constraint you pick and how you pressure-test it. Resist the urge to optimize for everything. Instead ask, “What does failure look like on our worst day? What’s the single thing we have to get right, every time?”
But picking isn’t the end of the work. You need to see what happens when that one constraint runs headlong into the thousand daily curveballs that real systems face. Run scenario drills.
What happens when GCP throttles your compute budget, or traffic triples on a random Sunday, or you lose half your SREs to external interviews? Play these out before they’re real. If your latency SLO is the anchor, can your stack hold it during a regional failover and a product launch in the same week? Does your weekly release rhythm crack under PTO season or surprise compliance asks? Pressure-testing upfront means you catch brittle spots before the world does. Your team moves faster because they’ve already lived the bad days in rehearsal, not production.
This principle isn’t just for tech. Think about cooking with one pan (suddenly every step matters) or backpacking with a strict weight limit (your route and meals shift overnight). The experience changes—because of the constraint. Constraints shape taste and routes the way they shape architectures. By giving us something real to build against.
Enforcement is where so many teams slip up. Use an engineering tradeoff framework with decision rules that prioritize your primary constraint. Every roadmap and retrofit should start from there. Escalate only when you see clear risk to that constraint; otherwise, scope creep gets a hard ‘no.’ Escalation works when SLOs and budgets connect to consequences with executive support—without that, the primary constraint is just a suggestion.
What does this look like for AI systems? Say you set a training compute budget—protect it. Validate your model regularly against data drift so you know your answers stay relevant, not just on day one. Make sure your serving path isn’t just fast when things are calm, but resilient when traffic spikes, GPUs flake, or contracts force you to run lean. The game doesn’t change. Set your north star, pressure-test for sideways weather, and keep building. That’s how solid, creative systems survive the real world.
Make Constraints Routine—Not a One-off Hack
Start simple. Every retro or review should include a constraint checkpoint. Put the primary constraint on the agenda, jot down the tradeoffs you actually made, and be honest about what held or cracked under pressure. You’re looking for patterns, not perfection. Month by month, this turns a vague principle into company muscle.
Take it further—carry your constraint into roadmap and quarterly planning. Instead of pretending you can do everything, frame up the key guardrails upfront. Clarify where you can compromise, and document those decisions before debate starts. For example, “This quarter, we won’t breach our latency SLO, even if it means holding back on features.” No more sneaky scope creep or subtle drift. People know the rails and can steer inside them.
Here’s the culture shift. You should lead with constraints and reward choices that stick to the constraint, even when the result isn’t shiny or “optimized” in every corner. Great leadership rewards smart, timely compromises, not endless optimization. Shipping a working, aligned system always beats chasing the flawless fix forever.
If you want to kill this approach, there’s a clear way. Let the scope balloon until nobody remembers what the original constraint was. Chase last-minute resources mid-build. Escalate every single tradeoff to the top. I’ve done all three (painfully). You’ll get slow, brittle delivery guaranteed.
Get the constraint on the table. Make it a habit. Don’t let it fade when things get hectic. Like those semi-trucks and pop-up logistics, the messy workaround sometimes works better than anything you drew up on the whiteboard.
This is how teams get resilient, not just resourceful.
If you need crisp updates, docs, or posts fast, our AI turns your ideas, constraints, and voice into ready-to-share content without extra overhead.
Friction Points and Fresh Starts: Recalibrating Constraints as You Grow
Let’s be direct. If you’ve led an engineering team, you know the classic objections. “This sounds slow—don’t constraints hold us back?” Or, “What if this kills our best ideas, or we pick the wrong north star and lock ourselves in?” I get it, and I’ve had those worries myself.
The reality is, limits spark creativity—not kill it. When you introduce well-designed constraints in real problem-solving, people actually broaden their thinking and get more creative, not less source. When you hear, “We can’t do it that way,” that’s often the start of your best answer. Constraints force us to build around the obvious no, and that’s where true invention shows up. Sticking to a constraint doesn’t mean locking it in forever. Reset it as evidence accumulates or when reality pushes back.
If you want a healthy rhythm, bake in resets. Review your primary constraint every quarter, or any time a shock rolls through—traffic spike, compute cost surge, a sudden team reshuffling. Mark the change, document why, and use it as a learning checkpoint before the next cycle. If you’re treating constraints like living guardrails, not dead policy, you’ll stay nimble.
One thing I still wrestle with—sometimes, when deadlines loom and the stakes feel high, there’s a pull to ditch the constraint and chase the “heroic fix.” Part of me knows that urge isn’t going away. Maybe that’s just something leaders carry around: the tension between sticking to the rails and making the wild swing. I’ve gotten better at catching it, but the temptation doesn’t quite leave.
Here’s your move. Pick one constraint, make it explicit, then pressure-test it—against your secondaries, your real-world chaos, everything. Ship before you chase perfect coverage. The teams that do this deliver simpler, faster, more robust software—built to handle whatever tomorrow throws their way.
Enjoyed this post? For more insights on engineering leadership, mindful productivity, and navigating the modern workday, follow me on LinkedIn to stay inspired and join the conversation.
You can also view and comment on the original post here .
