Work without a clear outcome, finish line, appetite, or milestones expands until it consumes the quarter.
“Why isn’t it live yet?”
“It turned out to be more complicated,” the CTO says. Or another priority got in the way.
The conversation quickly becomes about urgency. Nobody said what outcome the feature should create, what that outcome is worth, or where the team should stop.
Put a Price on It
One of the most common reasons I see product-engineering teams move slowly is that nobody told them what the outcome was worth or where to stop. Engineers fill in the blanks, usually by optimizing for completeness.
I’ve even seen this happen inside organizations. You have a team working like crazy to get things done, yet a couple of peers working on some amorphous infrastructure project take months gilding lilies with no end in sight. The difference wasn’t a lack of effort or talent. One team knew what mattered and where to stop. The other had been handed an open field.
Define the expected outcome, its value, and your appetite. Smaller options appear. Trade-offs become explicit. The team knows where to stop. This assumes a basically capable team; constraints cannot compensate for missing skill.
How Work Expands
When teams are asked to provide a solution without being given an appetite, they often default to the cathedral version. We value appetites over estimates: by being told how much the business wants to invest in a problem, we can tell how grand the solution ought to be. Are you looking for a luxurious Japanese toilet or the IKEA version?
Parkinson’s Law says work expands to fill the time available. Product work expands to fill other missing boundaries, too. When there’s no business outcome (only a prescription list of features), the team has no basis for judgment. Engineers can make the implementation more complete, but they cannot decide which trade-offs serve the business.
Similarly, we need a healthy definition of done. Alright, the goal we’re after is reducing the onboarding time of new enterprise clients. The stakeholders even said it’s so important that the team can spend a whole quarter on it. After one month, the team cuts the technical setup from seven weeks to two. What then? How much lower does it need to go? Is the difference from a couple of weeks to six business days worth another couple of months of work? Without a stopping condition, it’s very hard to make this judgement call, and often stakeholders are never aware of it at all.
Having all those parameters could still result in things taking too long, and that’s because you don’t have milestones. I can’t imagine asking someone to build a house and then only coming to check the work when they tell me it’s all done. Why do we allow monster projects to be approached as one huge leap, as opposed to breaking the work down?
Milestones allow us to build trust, course correct, get feedback, and avoid getting lost. Useful milestones expose the work to reality: customers try the new flow, operations run the new process, or production data tests the assumption. “Backend complete” merely reports progress.
And one last dimension of helpful constraints is prioritization. A business owner claiming everything is critical is refusing to do their job. It’s highly unlikely that every piece of the project has equal importance or that every screen is a potential showstopper. Assign genuine priorities or don’t be surprised when things take months.
Protocol
Before meaningful work begins, the CEO and CTO should be able to answer five questions:
- What changes for the customer or business?
- How much engineering capacity is that change worth?
- What loses priority to make room?
- What observable result means we are done?
- What reaches the real world first?
Until you answer those questions together, the team does not have a finishable project. Good constraints give capable people room to exercise judgment.
Boundaries are what make the work finishable.