Using constraints to deliver

I’ve always liked Parkinson’s Law. It’s a fictional law that captures something true about how we operate: work expands to fill the time available for its completion. Give a team a year, and the project will take a year. Give that same team a quarter, and somehow it will take a quarter. The scope, polish, and ambition change depending on the timeline. Time allocated changes the outcome.

Many teams begin with the question: “How long will this take?” They start by imagining an ideal solution, then break it down into components to estimate the overall duration to delivery.

I’ve found it can be powerful to invert the equation. Start with an aggressive timeline to deliver value and impact. Then start work to deliver within that timeframe. If too many tradeoffs surface, and the final result will lack resiliency, features, or security that is not acceptable think about how to manage those tradeoffs. You could enumerate the tradeoffs and plan for a fast follow up, change the deadline, or ruthlessly prioritize other features. This shift forces you to prioritize the most impactful features for the end user.

Consider a thought experiment. If I ask you to build a house and give you two years, you’ll behave like an architect. You’ll debate materials, optimize floor plans, think about natural light, and plan the landscaping. The result may be thoughtful and beautiful. But if I give you three months, you’ll behave differently. You’ll focus on:

• A solid foundation
• Framing and structural integrity
• A roof
• Basic utilities

No fancy materials. No custom cabinetry. No elaborate landscaping. The goal in both cases is the same, but the outcome is drastically different. It’s our job as engineers to identify where we’re spending too much time and where we’re required to cut critical features from our final product.

Short timelines are not inherently good. Shortening the timeline can help you deliver more quickly, but may degrade quality. In software, when moving quickly teams may be tempted to skip:

• Threat modeling
• Observability and logging
• Hardening and abuse prevention
• Proper access control design

The damage may not show up immediately. It can surface months later when you get your first spike in traffic or awareness of your product rises in the hacker community. It may surface in your next audit that will probe into your ability to respond to threats and test your resiliency planning.

When someone says, “We need this in three weeks,” the mature engineering response isn’t compliance or rebellion. It’s clarity:

In three weeks we can ship A and B.
We will not have time for X, Y, or Z.
Here are the risks those omissions create.

Now the deadline becomes an active, explicit decision. Leadership is choosing speed over completeness with eyes open. That’s very different from quietly absorbing risk.

Security rarely fails loudly in the moment; it fails later. A deferred rate limiter becomes an abuse incident. A “temporary” permission model becomes a compliance issue or a maintenance headache. Logging that was “good enough” becomes insufficient during investigation, or causes an incident when secrets are persisted to logs. It’s our job as security professionals to surface these tradeoffs early. In the same breath we should come with solutions, are there ways to reduce blast radius that will give confidence to the faster solution?

The upside to tighter deadlines is that constraints often produce great results that include only the most important features. You focus on the smallest thing that creates real value. I’ve been part of many projects with seemingly impossible deadlines that have met and exceeded our customer’s expectations. The team prioritizes aggressively and cuts out cruft.

You can solve any problem with more time or better prioritization. Adding engineers or time to a project is helpful to a point, but can introduce inefficiencies, ship low value features, or spend time on things that don’t move the needle for the user. Most organizations don’t have a time problem they have a prioritization problem.

Parkinson’s Law reminds us that work will expand if allowed. The real skill, especially as an engineer or leader, is deciding what deserves to expand and what must remain constrained.