[{"data":1,"prerenderedAt":316},["ShallowReactive",2],{"catalog":3,"learn":117,"learn-org-debt":309},[4,12,19,26,32,39,46,52,58,65,71,78,84,90,96,102,110],{"slug":5,"name":6,"title":6,"description":7,"hue":8,"kind":9,"aliases":10,"order":11},"institutions","Institutions","Learn about institutions: how they are built, kept, and lost.","cyan","topic",[],1,{"slug":13,"name":14,"title":14,"description":15,"hue":16,"kind":9,"aliases":17,"order":18},"financialization","Financialization","Learn about financialization and what it does to organizations.","blue",[],2,{"slug":20,"name":21,"title":21,"description":22,"hue":23,"kind":9,"aliases":24,"order":25},"management","Management","Learn about management, incentives, and how decisions get made.","violet",[],3,{"slug":27,"name":28,"title":28,"description":29,"hue":23,"kind":9,"aliases":30,"order":31},"consulting","Consulting","Learn about consulting and the markets it cannot see.",[],4,{"slug":33,"name":34,"title":34,"description":35,"hue":36,"kind":9,"aliases":37,"order":38},"platforms","Platforms","Learn about platforms, architecture, and the systems underneath.","green",[],5,{"slug":40,"name":41,"title":41,"description":42,"hue":43,"kind":9,"aliases":44,"order":45},"software","Software","Learn about software as an institutional asset.","pink",[],6,{"slug":47,"name":48,"title":48,"description":49,"hue":16,"kind":9,"aliases":50,"order":51},"markets","Markets","Learn about markets, ownership, and where value sits.",[],7,{"slug":53,"name":54,"title":54,"description":55,"hue":36,"kind":9,"aliases":56,"order":57},"organizations","Organizations","Learn about organizational design, incentives, and operating structure.",[],8,{"slug":59,"name":60,"title":60,"description":61,"hue":62,"kind":9,"aliases":63,"order":64},"ownership","Ownership","Learn about ownership and who an institution is built for.","neutral",[],9,{"slug":66,"name":67,"title":67,"description":68,"hue":36,"kind":9,"aliases":69,"order":70},"growth","Growth","Learn about growth and what an institution should refuse in order to keep it.",[],10,{"slug":72,"name":73,"title":73,"description":74,"hue":75,"kind":9,"aliases":76,"order":77},"decay","Decay","Learn about institutional decay and how organizations lose the ability to act.","orange",[],11,{"slug":79,"name":80,"title":80,"description":81,"hue":43,"kind":9,"aliases":82,"order":83},"leadership","Leadership","Learn about leadership and who is accountable for a decision.",[],12,{"slug":85,"name":86,"title":86,"description":87,"hue":8,"kind":9,"aliases":88,"order":89},"teams","Teams","Learn about teams and how a group holds a problem.",[],13,{"slug":91,"name":92,"title":92,"description":93,"hue":23,"kind":9,"aliases":94,"order":95},"team-topologies","Team Topologies","Learn about team topologies and how teams are shaped around a problem.",[],14,{"slug":97,"name":98,"title":98,"description":99,"hue":8,"kind":9,"aliases":100,"order":101},"architecture","Architecture","Learn about architecture and how a system is cut into parts people can own.",[],15,{"slug":103,"name":104,"title":105,"description":106,"hue":75,"kind":9,"aliases":107,"order":109},"ddd","DDD","Domain-driven design","Learn about domain-driven design and how a domain is cut into models people can own.",[108],"domain-driven-design",16,{"slug":111,"name":112,"title":112,"description":113,"hue":16,"kind":114,"aliases":115,"order":116},"the-mythical-man-month","The Mythical Man-Month","Essays on Software Engineering is a book on software engineering and project management by Fred Brooks first published in 1975, with subsequent editions in 1982 and 1995. Its central theme is that adding manpower to a software project that is behind schedule delays it even longer. This idea is known as Brooks´s law, and is presented along with the second-system effect and advocacy of prototyping","book",[],9007199254740991,[118,153,230,285,297],{"id":119,"title":120,"body":121,"category":134,"date":135,"description":127,"draft":136,"extension":137,"lead":138,"listed":136,"medium":139,"meta":140,"navigation":141,"notion":132,"path":142,"related":143,"seo":144,"sources":145,"stem":149,"topics":150,"__hash__":152},"learn\u002Flearn\u002Fbrooks-law.mdc","Brook's law",{"type":122,"value":123,"toc":131},"minimark",[124,128],[125,126,127],"p",{},"Brooks's law is an observation about software project management that \"Adding manpower to a late software project makes it later.\".",[125,129,130],{},"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":132,"searchDepth":18,"depth":18,"links":133},"",[],"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":120,"description":127},[146],{"title":147,"url":148},"The Mythical Man-Month, Fred Brooks, 1975","\u002Flearn\u002Fthe-mythical-man-month","learn\u002Fbrooks-law",[79,91,111,151],"fred-brooks","7yINom0mlmMo3Q5LUj0yorpJs9tpxidtzpq-OyavF9E",{"id":154,"title":155,"body":156,"category":221,"date":222,"description":132,"draft":136,"extension":137,"lead":223,"listed":141,"medium":139,"meta":224,"navigation":141,"notion":132,"path":225,"related":143,"seo":226,"sources":143,"stem":227,"topics":228,"__hash__":229},"learn\u002Flearn\u002Fproblem-spaces.mdc","Accountable problem spaces",{"type":122,"value":157,"toc":216},[158,162,167,170,173,176,180,187,196,204,208,213],[159,160],"img",{"src":161},"\u002Flearn\u002Fproblem-spaces.svg",[163,164,166],"h2",{"id":165},"intro","Intro",[125,168,169],{},"Splicing your business into clearly defined and accountable problem spaces is the best way to ensure you know who are responsible for exactly what.",[125,171,172],{},"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.",[125,174,175],{},"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",[163,177,179],{"id":178},"case-product-teams","Case: Product teams",[125,181,182,186],{},[183,184,185],"strong",{},"Alias for problem space here:"," Product",[125,188,189,190,195],{},"Within a product team for instance, the product lead needs to take full accountability and ownership over the whole product, the ",[191,192,194],"a",{"href":193},"\u002Flearn\u002Fprioritizing","prioritized features and improvements",".",[125,197,198,199,203],{},"The tech lead needs to take full responsibility for ",[191,200,202],{"href":201},"\u002Flearn\u002Ftech-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.",[163,205,207],{"id":206},"case-platfom-team","Case: Platfom team",[125,209,210,212],{},[183,211,185],{}," Domain",[125,214,215],{},"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":132,"searchDepth":18,"depth":18,"links":217},[218,219,220],{"id":165,"depth":18,"text":166},{"id":178,"depth":18,"text":179},{"id":206,"depth":18,"text":207},"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":155,"description":132},"learn\u002Fproblem-spaces",[79,85,66,91,103],"S-Dl3-pL7-c-VHbk8OJROBAlxYT2rr6JDjHhn0phF7c",{"id":231,"title":232,"body":233,"category":221,"date":273,"description":132,"draft":136,"extension":137,"lead":274,"listed":141,"medium":139,"meta":275,"navigation":141,"notion":132,"path":276,"related":143,"seo":277,"sources":278,"stem":282,"topics":283,"__hash__":284},"learn\u002Flearn\u002Fscoping.mdc","Scoping down",{"type":122,"value":234,"toc":271},[235,238,245,248,253,263],[159,236],{"src":237},"\u002Flearn\u002Fscope-down.svg",[125,239,240,241,244],{},"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 ",[191,242,243],{"href":142},"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.",[125,246,247],{},"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.",[125,249,250],{},[183,251,252],{},"By scoping down you will:",[254,255,256,260],"ul",{},[257,258,259],"li",{},"Eliminate the need for release management",[257,261,262],{},"Reduce the need for test teams",[125,264,265,266,270],{},"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 ",[191,267,269],{"href":268},"\u002Flearn\u002Fexecution-bias","execution bias"," and prioritize deliviring value above all else.",{"title":132,"searchDepth":18,"depth":18,"links":272},[],"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":232,"description":132},[279],{"title":280,"url":281},"Linear Method: Scope projects down","https:\u002F\u002Flinear.app\u002Fmethod\u002Fscope-projects","learn\u002Fscoping",[79],"IhRr0FuPMLX5H-HKeQJO3bxcoXnRc24k6FywBBn-OdY",{"id":286,"title":287,"body":288,"category":143,"date":143,"description":132,"draft":136,"extension":137,"lead":143,"listed":141,"medium":143,"meta":292,"navigation":141,"notion":143,"path":293,"related":143,"seo":294,"sources":143,"stem":295,"topics":143,"__hash__":296},"learn\u002Flearn\u002Forg-debt.mdc","Org Debt",{"type":122,"value":289,"toc":290},[],{"title":132,"searchDepth":18,"depth":18,"links":291},[],{"alwaysApply":141},"\u002Flearn\u002Forg-debt",{"description":132},"learn\u002Forg-debt","GlMJPdyQNSg3nuSz3qUFNBEnR-dRzKtBriqEK7YzaJA",{"id":298,"title":299,"body":300,"category":143,"date":143,"description":132,"draft":136,"extension":137,"lead":143,"listed":141,"medium":143,"meta":304,"navigation":141,"notion":143,"path":305,"related":143,"seo":306,"sources":143,"stem":307,"topics":143,"__hash__":308},"learn\u002Flearn\u002Fprocess-debt.mdc","Process Debt",{"type":122,"value":301,"toc":302},[],{"title":132,"searchDepth":18,"depth":18,"links":303},[],{"alwaysApply":141},"\u002Flearn\u002Fprocess-debt",{"description":132},"learn\u002Fprocess-debt","PRLdkfIJ4nGRhZ3gWYNG88CJJ81p1_htdi3Z6C_f2o0",{"id":286,"title":287,"body":310,"category":143,"date":143,"description":132,"draft":136,"extension":137,"lead":143,"listed":141,"medium":143,"meta":314,"navigation":141,"notion":143,"path":293,"related":143,"seo":315,"sources":143,"stem":295,"topics":143,"__hash__":296},{"type":122,"value":311,"toc":312},[],{"title":132,"searchDepth":18,"depth":18,"links":313},[],{"alwaysApply":141},{"description":132},1792036581071]