[{"data":1,"prerenderedAt":235},["ShallowReactive",2],{"learn":3,"learn-scoping":203},[4,43,67,148],{"id":5,"title":6,"body":7,"category":21,"date":22,"description":13,"draft":23,"extension":24,"lead":25,"listed":23,"medium":26,"meta":27,"navigation":28,"notion":18,"path":29,"related":30,"seo":31,"sources":32,"stem":36,"topics":37,"__hash__":42},"learn\u002Flearn\u002Fbrooks-law.mdc","Brook's law",{"type":8,"value":9,"toc":17},"minimark",[10,14],[11,12,13],"p",{},"Brooks's law is an observation about software project management that \"Adding manpower to a late software project makes it later.\".",[11,15,16],{},"It was coined by Fred Brooks in his 1975 book The Mythical Man-Month. According to Brooks, under certain conditions, an incremental person when added to a project makes it take more, not less time",{"title":18,"searchDepth":19,"depth":19,"links":20},"",2,[],"principles","2023-07-20",false,"mdc","An outrageous oversimplification that states \"Adding manpower to a late software project makes it later\"","article",{},true,"\u002Flearn\u002Fbrooks-law",null,{"title":6,"description":13},[33],{"title":34,"url":35},"The Mythical Man-Month, Fred Brooks, 1975","\u002Flearn\u002Fthe-mythical-man-month","learn\u002Fbrooks-law",[38,39,40,41],"leadership","team-topologies","the-mythical-man-month","fred-brooks","7yINom0mlmMo3Q5LUj0yorpJs9tpxidtzpq-OyavF9E",{"id":44,"title":45,"body":46,"category":21,"date":22,"description":50,"draft":23,"extension":24,"lead":25,"listed":23,"medium":26,"meta":59,"navigation":28,"notion":18,"path":60,"related":30,"seo":61,"sources":62,"stem":64,"topics":65,"__hash__":66},"learn\u002Flearn\u002Fexploration.mdc","Exploratory phases of projects",{"type":8,"value":47,"toc":57},[48,51,54],[11,49,50],{},"In the beginning its important to explore really widely.",[11,52,53],{},"In methodologies such as double diamonds people try to fence the exploration. The importance in exploration is not to fence in that.",[11,55,56],{},"Its to not document, or make it seem like a part of the actual process",{"title":18,"searchDepth":19,"depth":19,"links":58},[],{},"\u002Flearn\u002Fexploration",{"title":45,"description":50},[63],{"title":34,"url":35},"learn\u002Fexploration",[38,21,39,40,41],"WXZUKlTuJWhW899LkjNbmCwwTQUEFAkdak-gSXDatZY",{"id":68,"title":69,"body":70,"category":136,"date":137,"description":18,"draft":23,"extension":24,"lead":138,"listed":23,"medium":26,"meta":139,"navigation":28,"notion":18,"path":140,"related":30,"seo":141,"sources":30,"stem":142,"topics":143,"__hash__":147},"learn\u002Flearn\u002Fproblem-spaces.mdc","Accountable problem spaces",{"type":8,"value":71,"toc":130},[72,76,81,84,87,90,94,101,110,118,122,127],[73,74],"img",{"src":75},"\u002Flearn\u002Fproblem-spaces.svg",[77,78,80],"h3",{"id":79},"intro","Intro",[11,82,83],{},"Splicing your business into clearly defined and accountable problem spaces is the best way to ensure you know who are responsible for exactly what.",[11,85,86],{},"As a leader of leaders you need to demand that your direct reøorts take responsibility for their whole problem space, and always hand out consequences when they dont.",[11,88,89],{},"It might be a good idea to have slightly overlapping problemspaces within a team, that way the members can take on tasks from eachother, they can be active advocates, and have constructive conflicts, to find the truth",[77,91,93],{"id":92},"case-product-teams","Case: Product teams",[11,95,96,100],{},[97,98,99],"strong",{},"Alias for problem space here:"," Product",[11,102,103,104,109],{},"Within a product team for instance, the product lead needs to take full accountability and ownership over the whole product, the ",[105,106,108],"a",{"href":107},"\u002Flearn\u002Fprioritizing","prioritized features and improvements",".",[11,111,112,113,117],{},"The tech lead needs to take full responsibility for ",[105,114,116],{"href":115},"\u002Flearn\u002Ftechnical-debt","prioritizing the right technical debt",", ensuring the technology moves in the right direction, and that the product is always able to continue to innovate into the far future.",[77,119,121],{"id":120},"case-platfom-team","Case: Platfom team",[11,123,124,126],{},[97,125,99],{}," Domain",[11,128,129],{},"Platform teams might be organized around business domains or complicated subsystems (also a kind of domain), they still follow exactly the same rules of engagement as product teams. The product lead for the entire platform, should always own the consequences of the actions of even the sub-problem spaces within the domain teams, or the developers.",{"title":18,"searchDepth":19,"depth":19,"links":131},[132,134,135],{"id":79,"depth":133,"text":80},3,{"id":92,"depth":133,"text":93},{"id":120,"depth":133,"text":121},"practices","2023-06-20","One of the most important things you do is to define the problem spaces that others should occupy and solve.",{},"\u002Flearn\u002Fproblem-spaces",{"title":69,"description":18},"learn\u002Fproblem-spaces",[38,144,145,39,146],"teams","growth","ddd","k3yoWNY8_2JgCu3vaYGeHJA3FD58-F6TdQSnOWaCtCA",{"id":149,"title":150,"body":151,"category":136,"date":191,"description":18,"draft":23,"extension":24,"lead":192,"listed":23,"medium":26,"meta":193,"navigation":28,"notion":18,"path":194,"related":30,"seo":195,"sources":196,"stem":200,"topics":201,"__hash__":202},"learn\u002Flearn\u002Fscoping.mdc","Scoping down",{"type":8,"value":152,"toc":189},[153,156,163,166,171,181],[73,154],{"src":155},"\u002Flearn\u002Fscope-down.svg",[11,157,158,159,162],{},"Momentum is created and preserved by reducing the size of commitments, not by endlessly scaling team sizes or putting pressure mid-development, this only makes ",[105,160,161],{"href":29},"late projects later"," and will decay code quality over time. Keep initiatives small enough to be completed by one to four people within one to three weeks, with a clear outcome and as few dependencies as possible. Smaller scopes forces everyone to think clearly about which features to actually prioritize.",[11,164,165],{},"Smaller scopes shorten feedback loops, expose mistaken assumptions early, and turn plans into observable progress. It makes changes easier to test, releases smaller to manage, and mistakes easier to fix.",[11,167,168],{},[97,169,170],{},"By scoping down you will:",[172,173,174,178],"ul",{},[175,176,177],"li",{},"Eliminate the need for release management",[175,179,180],{},"Reduce the need for test teams",[11,182,183,184,188],{},"When work begins to stall, change the scope before adding time, people, or adjusting process. Preserve the essential outcome, remove everything that does not contribute directly to it, and deliver the smallest complete step that moves the team forward. Momentum compounds when finishing becomes a habit. Over time your team will begin to have an ",[105,185,187],{"href":186},"\u002Flearn\u002Fexecution-bias","execution bias"," and prioritize deliviring value above all else.",{"title":18,"searchDepth":19,"depth":19,"links":190},[],"2023-03-20","When work stalls, cut the scope before adding time or people. How small commitments and quick wins build an execution bias.",{},"\u002Flearn\u002Fscoping",{"title":150,"description":18},[197],{"title":198,"url":199},"Linear Method: Scope projects down","https:\u002F\u002Flinear.app\u002Fmethod\u002Fscope-projects","learn\u002Fscoping",[38],"3D2mQapHmazNRenF_Zc7_tjDTWrOssIjcY_MuLq61LI",{"id":149,"title":150,"body":204,"category":136,"date":191,"description":18,"draft":23,"extension":24,"lead":192,"listed":23,"medium":26,"meta":230,"navigation":28,"notion":18,"path":194,"related":30,"seo":231,"sources":232,"stem":200,"topics":234,"__hash__":202},{"type":8,"value":205,"toc":228},[206,208,212,214,218,224],[73,207],{"src":155},[11,209,158,210,162],{},[105,211,161],{"href":29},[11,213,165],{},[11,215,216],{},[97,217,170],{},[172,219,220,222],{},[175,221,177],{},[175,223,180],{},[11,225,183,226,188],{},[105,227,187],{"href":186},{"title":18,"searchDepth":19,"depth":19,"links":229},[],{},{"title":150,"description":18},[233],{"title":198,"url":199},[38],1791956166098]