[{"data":1,"prerenderedAt":133},["ShallowReactive",2],{"\u002Fnotes\u002Fvelocity-as-design-constraint":3},{"id":4,"title":5,"body":6,"description":12,"extension":117,"kind":118,"meta":119,"navigation":120,"path":121,"pinned":122,"publishedAt":123,"quotedAuthor":124,"quotedSource":124,"quotedUrl":124,"readingTime":125,"seo":126,"stem":127,"summary":128,"tags":129,"__hash__":132},"notes\u002Fnotes\u002Fvelocity-as-design-constraint.md","Velocity as a design constraint",{"type":7,"value":8,"toc":108},"minimark",[9,13,16,19,24,27,35,42,46,49,56,59,63,66,73,76,79,83,86,89,93,96,102,105],[10,11,12],"p",{},"Most teams treat speed as a virtue. They want to move fast. They reward the people who move fast. They put \"move fast\" in their values deck.",[10,14,15],{},"But virtues are aspirational. They sit beside other virtues — quality, rigour, thoroughness, consensus — and everyone has to decide in the moment which virtue to honour. Most of the time, when the moment comes, speed loses. There are always good reasons to take another week.",[10,17,18],{},"B3n does not treat speed as a virtue. We treat it as a design constraint. And that changes everything downstream.",[20,21,23],"h3",{"id":22},"the-difference","The difference",[10,25,26],{},"A virtue is a goal you aspire to. A constraint is a limit you have to design within.",[10,28,29,30,34],{},"When speed is a virtue, the question is: ",[31,32,33],"em",{},"how fast can we go?"," The answer is always context-dependent, often compromised by competing priorities, and usually slower than it could be.",[10,36,37,38,41],{},"When speed is a constraint, the question is: ",[31,39,40],{},"what can we build, given that we have two weeks?"," The constraint forces scope discipline. The constraint forces partnership choices. The constraint forces decisions to close. The constraint is the design input that makes the rest of the work sharp.",[20,43,45],{"id":44},"how-it-reshapes-scope","How it reshapes scope",[10,47,48],{},"The engagements that go wrong almost always start with over-scoped ambitions. \"Let us redesign the entire operating model\" is an ambition that cannot be served in two weeks, so serving it in two weeks produces a slide deck instead of an operating model.",[10,50,51,52,55],{},"When we scope a Sprint, the constraint is explicit: ",[31,53,54],{},"this will take eight weeks maximum, and something will be in production at the end."," That constraint forces a different scope conversation. Not \"what is the right operating model\" but \"what is the one structural change we can install in eight weeks that will meaningfully move the business.\"",[10,57,58],{},"The conversation is harder. The answer is sharper. The work is shippable.",[20,60,62],{"id":61},"how-it-reshapes-decisions","How it reshapes decisions",[10,64,65],{},"Decisions under velocity pressure are not worse decisions. They are often better, because the time pressure eliminates the fake optionality that clogs up most strategic conversations.",[10,67,68,69,72],{},"Fake optionality sounds like: ",[31,70,71],{},"we need to evaluate three partner options before deciding."," In practice, nine times out of ten, the right answer is evident by the end of option one. The other two evaluations are a deferral dressed as diligence.",[10,74,75],{},"When velocity is a constraint, the team makes the call on option one and watches what happens. If the call was wrong, we know within two weeks and can correct. The correction is faster than the three-way evaluation would have been.",[10,77,78],{},"This only works if the organisation is operationally willing to ship before it feels sure. Most are not. The ones that are — the ones that treat velocity as a design constraint — move 3x to 10x faster than the ones that treat it as a virtue, for no loss in decision quality.",[20,80,82],{"id":81},"how-it-reshapes-the-team","How it reshapes the team",[10,84,85],{},"A team designed around velocity as a constraint looks different. It is smaller. It has fewer hand-offs. It has shorter feedback loops. It does not use meetings to drive decisions; it uses working sessions where the decision is made and the first action is taken before people leave the room.",[10,87,88],{},"At B3n, engagement pods are three to six people. Anything bigger slows down. If a problem needs more people, we break it into parallel smaller pods, each constrained, each shipping.",[20,90,92],{"id":91},"the-discipline","The discipline",[10,94,95],{},"Velocity as a constraint requires the leadership to protect the constraint. The hardest thing is not moving fast in the first two weeks. It is refusing to let the engagement expand in weeks three through eight. Every engagement has a moment around week four where the scope tries to triple — someone notices an adjacent problem, someone wants to \"also fix\" something, someone's boss joins the meeting and adds a requirement.",[10,97,98,99],{},"The right answer is almost always: ",[31,100,101],{},"not this engagement. We can scope another one after this ships.",[10,103,104],{},"Holding that line is the discipline. It is also the product. The clients who get what B3n actually does hire us again. The ones who wanted us to solve everything at once usually do not.",[10,106,107],{},"Move fast is not a mantra. It is the shape of the work.",{"title":109,"searchDepth":110,"depth":110,"links":111},"",3,[112,113,114,115,116],{"id":22,"depth":110,"text":23},{"id":44,"depth":110,"text":45},{"id":61,"depth":110,"text":62},{"id":81,"depth":110,"text":82},{"id":91,"depth":110,"text":92},"md","essay",{},true,"\u002Fnotes\u002Fvelocity-as-design-constraint",false,"2026-02-14",null,"6",{"title":5,"description":12},"notes\u002Fvelocity-as-design-constraint","Most teams treat speed as a virtue to be encouraged. B3n treats it as a constraint to be designed around. The distinction changes everything downstream.",[130,131],"move-fast","operating","2CkgyizlMQdiAnFyAjHj-51ynXapAAomWm9EUs-2UyY",1776610212958]