The six-week engagement

Every engagement we run is scoped in six weeks. Not a sprint, not a quarter, not "however long it takes." Six weeks, with a fixed scope agreed on day one and a real thing in production on the last day. The number isn't magic. It's calibrated. Two weeks is too short to survive a surprise — a vendor outage, a stakeholder on vacation, a spec that turned out to be wrong. A quarter is long enough that anyone can hide inside it; by week eight of a twelve-week plan, the team has forgotten what they promised in week one. Six weeks is short enough that no week is optional, and long enough to absorb one bad week without missing the ship date. What fits in six weeks: a working contact-and-booking flow with a real database and real email. A new internal dashboard connected to two or three existing data sources. A pricing page A/B test rig with analytics that actually attribute. The migration of one system from a legacy stack to a modern one — not the whole legacy stack, one system. A small AI feature grafted onto an existing product, end-to-end, including its evaluation harness. What does not fit: rebuilding your entire stack. Replacing your team's workflows with a brand-new tool. Anything that requires three departments to agree on a definition before development can start. If the scope calls for those, we split it into a discovery phase — usually a week — that ends with a decision, and then the six weeks starts. The cutting discipline matters. Around week three we look at the plan and ask which items, if we dropped them, would still leave a shippable thing on day 42. Anything on that list is a candidate for the next engagement, not this one. Almost every project sheds one or two things in that meeting. The teams that don't do this meeting are the teams that miss the date. If a vendor is telling you their build is "about halfway done" in month four, ask them what shipped on day 42. If the answer is "well, we're still integrating…" — you don't have a build, you have a subscription to their calendar.