[{"data":1,"prerenderedAt":502},["ShallowReactive",2],{"catalog":3,"learn":60,"learn-mgmt-debt":483},[4,12,19,26,33,39,48,55],{"slug":5,"name":6,"title":6,"description":7,"hue":8,"kind":9,"aliases":10,"order":11},"growth","Growth","Learn about growth and what an institution should refuse in order to keep it.","green","topic",[],10,{"slug":13,"name":14,"title":14,"description":15,"hue":16,"kind":9,"aliases":17,"order":18},"decay","Decay","Learn about institutional decay and how organizations lose the ability to act.","orange",[],11,{"slug":20,"name":21,"title":21,"description":22,"hue":23,"kind":9,"aliases":24,"order":25},"leadership","Leadership","Learn about leadership and who is accountable for a decision.","pink",[],12,{"slug":27,"name":28,"title":28,"description":29,"hue":30,"kind":9,"aliases":31,"order":32},"teams","Teams","Learn about teams and how a group holds a problem.","cyan",[],13,{"slug":34,"name":35,"title":35,"description":36,"hue":30,"kind":9,"aliases":37,"order":38},"architecture","Architecture","Learn about architecture and how a system is cut into parts people can own.",[],15,{"slug":40,"name":41,"title":42,"description":43,"hue":16,"kind":44,"aliases":45,"order":47},"ddd","DDD","Domain-driven design","Learn about domain-driven design and how a domain is cut into models people can own.","book",[46],"domain-driven-design",16,{"slug":49,"name":50,"title":50,"description":51,"hue":52,"kind":44,"aliases":53,"order":54},"team-topologies","Team Topologies","Team Topologies by Matthew Skelton and Manuel Pais explores four fundamental team types and three essential team interaction modes, providing practical guidance for structuring technology organizations to improve flow and reduce cognitive load.","blue",[],9007199254740991,{"slug":56,"name":57,"title":57,"description":58,"hue":52,"kind":44,"aliases":59,"order":54},"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",[],[61,97,174,430],{"id":62,"title":63,"body":64,"category":78,"date":79,"description":70,"draft":80,"extension":81,"lead":82,"listed":80,"medium":83,"meta":84,"navigation":85,"notion":75,"path":86,"related":87,"seo":88,"sources":89,"stem":93,"topics":94,"__hash__":96},"learn\u002Flearn\u002Fbrooks-law.mdc","Brook's law",{"type":65,"value":66,"toc":74},"minimark",[67,71],[68,69,70],"p",{},"Brooks's law is an observation about software project management that \"Adding manpower to a late software project makes it later.\".",[68,72,73],{},"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":75,"searchDepth":76,"depth":76,"links":77},"",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":63,"description":70},[90],{"title":91,"url":92},"The Mythical Man-Month, Fred Brooks, 1975","\u002Flearn\u002Fthe-mythical-man-month","learn\u002Fbrooks-law",[20,49,56,95],"fred-brooks","7yINom0mlmMo3Q5LUj0yorpJs9tpxidtzpq-OyavF9E",{"id":98,"title":99,"body":100,"category":165,"date":166,"description":75,"draft":80,"extension":81,"lead":167,"listed":85,"medium":83,"meta":168,"navigation":85,"notion":75,"path":169,"related":87,"seo":170,"sources":87,"stem":171,"topics":172,"__hash__":173},"learn\u002Flearn\u002Fproblem-spaces.mdc","Accountable problem spaces",{"type":65,"value":101,"toc":160},[102,106,111,114,117,120,124,131,140,148,152,157],[103,104],"img",{"src":105},"\u002Flearn\u002Fproblem-spaces.svg",[107,108,110],"h2",{"id":109},"intro","Intro",[68,112,113],{},"Splicing your business into clearly defined and accountable problem spaces is the best way to ensure you know who are responsible for exactly what.",[68,115,116],{},"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.",[68,118,119],{},"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",[107,121,123],{"id":122},"case-product-teams","Case: Product teams",[68,125,126,130],{},[127,128,129],"strong",{},"Alias for problem space here:"," Product",[68,132,133,134,139],{},"Within a product team for instance, the product lead needs to take full accountability and ownership over the whole product, the ",[135,136,138],"a",{"href":137},"\u002Flearn\u002Fprioritizing","prioritized features and improvements",".",[68,141,142,143,147],{},"The tech lead needs to take full responsibility for ",[135,144,146],{"href":145},"\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.",[107,149,151],{"id":150},"case-platfom-team","Case: Platfom team",[68,153,154,156],{},[127,155,129],{}," Domain",[68,158,159],{},"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":75,"searchDepth":76,"depth":76,"links":161},[162,163,164],{"id":109,"depth":76,"text":110},{"id":122,"depth":76,"text":123},{"id":150,"depth":76,"text":151},"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":99,"description":75},"learn\u002Fproblem-spaces",[20,27,5,49,40],"S-Dl3-pL7-c-VHbk8OJROBAlxYT2rr6JDjHhn0phF7c",{"id":175,"title":176,"body":177,"category":165,"date":406,"description":75,"draft":80,"extension":81,"lead":407,"listed":85,"medium":83,"meta":408,"navigation":85,"notion":75,"path":145,"related":87,"seo":409,"sources":410,"stem":427,"topics":428,"__hash__":429},"learn\u002Flearn\u002Ftech-debt.mdc","The magical solution to end all technical debt discussions and prolification",{"type":65,"value":178,"toc":394},[179,182,186,203,206,211,228,239,242,286,290,293,299,310,314,317,322,336,339,343,346,349,364,371,379,385,388,391],[103,180],{"src":181},"\u002Flearn\u002Ftech-debt.svg",[107,183,185],{"id":184},"the-landscape","The landscape",[68,187,188,189,193,194,193,198,202],{},"There are many types of debt ",[135,190,192],{"href":191},"\u002Flearn\u002Forg-debt","org debt",", ",[135,195,197],{"href":196},"\u002Flearn\u002Fprocess-debt","process debt",[135,199,201],{"href":200},"\u002Flearn\u002Fmgmt-debt","management debt",", the whole idea is that some form of decay has happened, either deliberately or accidentally, and you must invest in order to get rid of it, otherwise you will incrementally lose the ability to generate value.",[68,204,205],{},"In this article we cover how to elegantly and implicitly handle technical debt in your organization. Removing the need to debate the definition internally, have special meetings to handle technical debt, and demystefying the whole idea of technical debt.",[207,208,210],"h3",{"id":209},"tech-debt-is-changed-assumptions-that-can-turn-into-decay","Tech debt is changed assumptions, that can turn into decay",[68,212,213,214,217,218,222,223,227],{},"Defining tech debt is a hard excercise as the term has been misused so much. Just like other ubiquitous industry terms like ",[135,215,34],{"href":216},"\u002Flearn\u002Farchitecture"," and ",[135,219,221],{"href":220},"\u002Flearn\u002Fagile","agile",". The term ",[224,225,226],"em",{},"technical debt"," has been so violently overused it has become so vague it has seized being useful.",[68,229,230,231,234,235,238],{},"But since writing code requires making assumptions, assumptions about code change over time, ",[127,232,233],{},"the delta in assumptions is technical debt",". Building on that definition, we can add that if those changed assumptions ",[127,236,237],{},"risk reducing velocity",", then it is technical debt.",[68,240,241],{},"In order to use the term, we also need to definitively describe what tech debt is not, and what it is.",[243,244,245,269],"columns",{},[246,247,249],"column",{"title":248},"What is not technical debt",[250,251,252,260,263,266],"ul",{},[253,254,255,256,259],"li",{},"Working code that looks ",[224,257,258],{},"ugly"," or uses an older programming style that a new hire dislikes.",[253,261,262],{},"A framework that is one major version behind but receives security patches and performs reliably.",[253,264,265],{},"Features or scale the business might need two years from now (that is missing future-proofing, not debt).",[253,267,268],{},"Outright defects or bugs in active feature logic (those are defects, not architectural debt).",[246,270,272],{"title":271},"What is technical debt",[250,273,274,277,280,283],{},[253,275,276],{},"Core workflows that lack automated test coverage, turning every release into manual QA roulette.",[253,278,279],{},"Architectural coupling that forces three teams to coordinate deployments for a single button change.",[253,281,282],{},"Hardcoded business logic reflecting pricing models or constraints abandoned two years ago.",[253,284,285],{},"Brittle, slow build pipelines that waste 45 minutes of developer time per pull request.",[207,287,289],{"id":288},"tech-debt-is-similar-to-real-debt","Tech debt is similar to real debt",[68,291,292],{},"Technical debt is just like financial borrowing, not all debt is inherently reckless, but every loan carries an interest rate, repayment terms, and the non-negotiable requirement of making payments. The danger lies in failing to recognize which kind of debt you are taking on:",[68,294,295,298],{},[127,296,297],{},"Low-interest debt","\nDeliberate, phased architectural compromises designed to hit a critical company milestone or capture an urgent market opportunity. You know you owe it, the risk profile is well-understood, and you have a realistic plan to service the balance over time.",[68,300,301,304,305,309],{},[127,302,303],{},"High-interest debt","\nFast, tactical shortcuts—such as intentionally ",[135,306,308],{"href":307},"\u002Flearn\u002Fdo-things-that-dont-scale","doing things that dont scale"," can be healthy when short lived and is there to quickly validate a product hypothesis. It buys velocity, but carrying a balance from cycle to cycle or even worse, continually increasing it, causes interest to compound rapidly.",[207,311,313],{"id":312},"you-pay-the-debt-or-suffer-decay","You pay the debt, or suffer decay",[68,315,316],{},"In finance, the fastest way to go bankrupt is to just stop making payments entirely. In tech, rot from the foundation will engulf and kill both your ability to innovate and team happiness.",[68,318,319],{},[127,320,321],{},"We need to stop living in the two fantasies:",[323,324,325,333],"ol",{},[253,326,327,328,332],{},"That we just need to ",[135,329,331],{"href":330},"\u002Flearn\u002Fplanning-paradox","plan things better"," and build things perfectly the first time, and have it stary right forever.",[253,334,335],{},"That tech debt does not carry a compounding interest rate, and can be handled \"later\".",[68,337,338],{},"Compounding interest doesn't wait. If you skip your monthly minimum payment, the interest is immediately compounded onto the principal. If you don't continually service tech debt as you go, by the time you finally dedicate time to it, all you end up making a dent in is the accumulated interest.",[107,340,342],{"id":341},"the-solution","The solution",[68,344,345],{},"By giving the tech lead full discretion to allocate the capacity of a set percentage of time for the team to prioritize and spend time on the most important techincal debt.",[68,347,348],{},"It solves three problems:",[323,350,351,354,357],{},[253,352,353],{},"Eliminates engineering using \"tech debt\" as a vague catch-all excuse for slow delivery.",[253,355,356],{},"Forces engineers to develop commercial discipline: once they own the budget, they have to decide what actually matters rather than demanding an unrealistic rewrite.",[253,358,359,360,363],{},"When the wrong debt is prioritized, the accountability for a systems failure and the ownership around that ",[135,361,362],{"href":169},"problem space"," is actually clear.",[68,365,366,367,370],{},"The allocation of 15% per sprint needs to have a strict ",[224,368,369],{},"use it or lose it"," expiration. This prevents capacity hoarding and guarantees product managers a stable, reliable cadence of feature delivery every cycle.",[207,372,374,375,378],{"id":373},"consequence-of-prioritizing-the-wrong-debt","Consequence of ",[135,376,377],{"href":137},"prioritizing"," the wrong debt",[380,381,382],"blockquote",{},[68,383,384],{},"Autonomy without accountability is indulgence; accountability without autonomy is micromanagement.",[68,386,387],{},"Giving the tech lead full autonomy over this budget means that they own the operational outcome of their choice.",[68,389,390],{},"If a tech lead spends three months of debt allocation migrating to a trendy new build tool for marginal DevEx gains while ignoring degraded database performance, the consequence is standing in front of the organization during the post-mortem when production collapses under peak load, explaining why vanity refactoring took priority over systemic stability.",[68,392,393],{},"True autonomy requires living with the blast radius of your decisions. Do not infantilize engineers by shielding them from that trade-off.",{"title":75,"searchDepth":76,"depth":76,"links":395},[396,402],{"id":184,"depth":76,"text":185,"children":397},[398,400,401],{"id":209,"depth":399,"text":210},3,{"id":288,"depth":399,"text":289},{"id":312,"depth":399,"text":313},{"id":341,"depth":76,"text":342,"children":403},[404],{"id":373,"depth":399,"text":405},"Consequence of prioritizing the wrong debt","2023-04-13","You've likely heard technologists continue to use the term, its not clear exactly what it means, its not clear exactly how you treat it. But it sounds really bad.",{},{"title":176,"description":75},[411,415,419,423],{"title":412,"detail":413,"url":414},"How to Manage Technical Debt: A Practitioner's Guide","OpenHands, 2026","https:\u002F\u002Fwww.openhands.dev\u002Fblog\u002Ftechnical-debt-management",{"title":416,"detail":417,"url":418},"Technical Debt","Martin Fowler, 2019","https:\u002F\u002Fmartinfowler.com\u002Fbliki\u002FTechnicalDebt.html",{"title":420,"detail":421,"url":422},"Technical Debt Quadrant","Martin Fowler, 2009","https:\u002F\u002Fmartinfowler.com\u002Fbliki\u002FTechnicalDebtQuadrant.html",{"title":424,"detail":425,"url":426},"In your own words: What is technical debt?","orebright, r\u002FSoftwareEngineering, 2023","https:\u002F\u002Fwww.reddit.com\u002Fr\u002FSoftwareEngineering\u002Fcomments\u002F1235mru\u002Fcomment\u002Fjdwf1s7\u002F","learn\u002Ftech-debt",[20,13],"t39NgyhUV6sUKvMC19BMfmJEQlYg9ZU001r1VB2X2PU",{"id":431,"title":432,"body":433,"category":165,"date":471,"description":75,"draft":80,"extension":81,"lead":472,"listed":85,"medium":83,"meta":473,"navigation":85,"notion":75,"path":474,"related":87,"seo":475,"sources":476,"stem":480,"topics":481,"__hash__":482},"learn\u002Flearn\u002Fscoping.mdc","Scoping down",{"type":65,"value":434,"toc":469},[435,438,445,448,453,461],[103,436],{"src":437},"\u002Flearn\u002Fscope-down.svg",[68,439,440,441,444],{},"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 ",[135,442,443],{"href":86},"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.",[68,446,447],{},"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.",[68,449,450],{},[127,451,452],{},"By scoping down you will:",[250,454,455,458],{},[253,456,457],{},"Eliminate the need for release management",[253,459,460],{},"Reduce the need for test teams",[68,462,463,464,468],{},"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 ",[135,465,467],{"href":466},"\u002Flearn\u002Fexecution-bias","execution bias"," and prioritize deliviring value above all else.",{"title":75,"searchDepth":76,"depth":76,"links":470},[],"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":432,"description":75},[477],{"title":478,"url":479},"Linear Method: Scope projects down","https:\u002F\u002Flinear.app\u002Fmethod\u002Fscope-projects","learn\u002Fscoping",[20],"IhRr0FuPMLX5H-HKeQJO3bxcoXnRc24k6FywBBn-OdY",{"id":484,"title":485,"body":486,"category":165,"date":406,"description":495,"draft":85,"extension":81,"lead":496,"listed":85,"medium":83,"meta":497,"navigation":85,"notion":75,"path":200,"related":87,"seo":498,"sources":87,"stem":499,"topics":500,"__hash__":501},"learn\u002Flearn\u002Fmgmt-debt.mdc","How to identify and treat organizational debt",{"type":65,"value":487,"toc":493},[488],[68,489,490,491],{},"Organizational debt almost always precedes ",[135,492,226],{"href":145},{"title":75,"searchDepth":76,"depth":76,"links":494},[],"Organizational debt almost always precedes technical debt","While not as trendy as tech debt, organizational debt will more often lead to horrible outcomes",{},{"title":485,"description":495},"learn\u002Fmgmt-debt",[20,13],"FftIjRFESgbrkyD2DQhV3cunxQLKVqYJyCIIexVswvY",1792131441828]