[{"data":1,"prerenderedAt":940},["ShallowReactive",2],{"catalog":3,"learn":66,"learn-paths":928,"catalog-doc-techniques":115,"learn-doc-none":115,"learn-author-names":938},[4,12,19,26,33,39,48,55,61],{"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},"mbo","Management by Objectives","a management model by Peter Drucker, most notably described in the book *The Practice of Management* (1954). MBO emphasizes the importance of managers and employees defining clear, measurable objectives together. Progress is assessed regularly and tasks are aligned with these objectives to improve performance and organizational focus.","neutral",[],9007199254740991,{"slug":56,"name":57,"title":57,"description":58,"hue":59,"kind":44,"aliases":60,"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",[],{"slug":62,"name":63,"title":63,"description":64,"hue":59,"kind":44,"aliases":65,"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",[],[67,131,157,190,341,426,505,573,829],{"id":68,"title":69,"author":70,"body":71,"category":106,"date":107,"description":77,"draft":108,"extension":109,"lead":110,"listed":108,"medium":111,"meta":112,"navigation":113,"notion":103,"path":114,"related":115,"robots":115,"seo":116,"sources":117,"stem":128,"topics":129,"updated":115,"__hash__":130},"learn\u002Flearn\u002Fgoodhearts-law.mdc","Goodhart's law","cb",{"type":72,"value":73,"toc":102},"minimark",[74,78,81,94],[75,76,77],"p",{},"Goodhart's law is an observation about organizational control that \"When a measure becomes a target, it ceases to be a good measure.\"",[75,79,80],{},"It was formulated by economist Charles Goodhart in 1975, and popularized in this phrasing by anthropologist Marilyn Strathern in 1997. The moment a metric is tied to compensation, performance evaluations, or quarterly status reports, people stop managing the business and start managing the score.",[82,83,84,88,91],"ul",{},[85,86,87],"li",{},"Tell developers they are measured by lines of code, and you get bloated, unmaintainable systems.",[85,89,90],{},"Measure QA by bugs closed, and trivial typos get logged while systemic architecture defects get ignored.",[85,92,93],{},"Measure sales reps by calls placed, and you get hundred-call days that convert zero real customers.",[75,95,96,97,101],{},"Measurement was originally designed by Drucker as an instrument of ",[98,99,100],"strong",{},"self-control","—a mirror to help teams evaluate their own work and adjust course. When it becomes an instrument of external surveillance, gaming the metric replaces doing actual work.",{"title":103,"searchDepth":104,"depth":104,"links":105},"",2,[],"principles","2026-10-18",false,"mdc","When a measure becomes a target, it ceases to be a good measure","article",{},true,"\u002Flearn\u002Fgoodhearts-law",null,{"title":69,"description":77},[118,121,125],{"title":119,"url":120},"Problems of Monetary Management: The U.K. Experience","\u002Fresearch\u002Fproblems-of-monetary-management",{"title":122,"detail":123,"url":124},"‘Improving ratings’: audit in the British University system","European Review","\u002Fresearch\u002Fimproving-ratings",{"title":126,"url":127},"Management by Objectives, Peter F. Drucker, 1954","\u002Flearn\u002Fmbo","learn\u002Fgoodhearts-law",[20,49],"fL3LVPoM_Jod3qf3WmYv0EUXwt1amVv7sN9-uxnXdGU",{"id":132,"title":133,"author":70,"body":134,"category":106,"date":144,"description":138,"draft":108,"extension":109,"lead":145,"listed":108,"medium":111,"meta":146,"navigation":113,"notion":103,"path":147,"related":115,"robots":115,"seo":148,"sources":149,"stem":153,"topics":154,"updated":115,"__hash__":156},"learn\u002Flearn\u002Fbrooks-law.mdc","Brook's law",{"type":72,"value":135,"toc":142},[136,139],[75,137,138],{},"Brooks's law is an observation about software project management that \"Adding manpower to a late software project makes it later.\".",[75,140,141],{},"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":103,"searchDepth":104,"depth":104,"links":143},[],"2023-07-20","An outrageous oversimplification that states \"Adding manpower to a late software project makes it later\"",{},"\u002Flearn\u002Fbrooks-law",{"title":133,"description":138},[150],{"title":151,"url":152},"The Mythical Man-Month, Fred Brooks, 1975","\u002Flearn\u002Fthe-mythical-man-month","learn\u002Fbrooks-law",[20,56,62,155],"fred-brooks","m3EujoNJKZNK9X2iHqL3UJvAjJaQaBt7iJqNV8eXJSM",{"id":158,"title":159,"author":70,"body":160,"category":181,"date":144,"description":103,"draft":108,"extension":109,"lead":115,"listed":108,"medium":111,"meta":182,"navigation":113,"notion":103,"path":183,"related":115,"robots":115,"seo":184,"sources":185,"stem":187,"topics":188,"updated":115,"__hash__":189},"learn\u002Flearn\u002Freverse-conway.mdc","Reverse Conway Manouver",{"type":72,"value":161,"toc":177},[162,167,170,174],[163,164,166],"h2",{"id":165},"definition","Definition",[75,168,169],{},"The reverse conway manouver is a way to reverse engineer the orgnaizsational strucutre around the technological architecture.",[163,171,173],{"id":172},"pincer","Pincer",[75,175,176],{},"The best way to actually do it, is to get technologists around the architecture and c-suite around the effects of it, then squeeze out every change in the middle",{"title":103,"searchDepth":104,"depth":104,"links":178},[179,180],{"id":165,"depth":104,"text":166},{"id":172,"depth":104,"text":173},"pattern",{},"\u002Flearn\u002Freverse-conway",{"title":159,"description":103},[186],{"title":151,"url":152},"learn\u002Freverse-conway",[20,56,62,155],"55DZGsWh-fRcCtxj9-ziYQdDxwPzf3eE1XBUw4_sBEU",{"id":191,"title":192,"author":70,"body":193,"category":323,"date":324,"description":103,"draft":108,"extension":109,"lead":325,"listed":113,"medium":111,"meta":326,"navigation":113,"notion":103,"path":327,"related":115,"robots":115,"seo":328,"sources":329,"stem":334,"topics":335,"updated":339,"__hash__":340},"learn\u002Flearn\u002Fdirection.mdc","The importance of defining your vision before you define your mission, or start working on small deliveries",{"type":72,"value":194,"toc":312},[195,199,203,206,209,213,216,219,222,229,232,240,245,248,257,260,264,267,270,273,279,283,286,294,297,300,304],[196,197],"img",{"src":198},"\u002Flearn\u002Fdirection.svg",[163,200,202],{"id":201},"introduction","Introduction",[75,204,205],{},"Setting direction is one of the most important things you will do when building. A clear direction aligns everyone to work towards the same objectives. A vision statement, mission statement, and an objective hierarchy can all be useful to getting there. Without direction, it will be impossible to achieve anything together, know what to prioritize, and create momentum and velocity.",[75,207,208],{},"Shipping small things does not add up to a strategy. Iteration is not a substitute for a plan.",[163,210,212],{"id":211},"vision-the-destination-vision","Vision - the destination [[Vision]]",[75,214,215],{},"Vision is not some form of corporate poetry. It is a definite, non-consensus claim about how the future must look. Most companies mistake internal ambition for a vision. They draft flattering self-portraits about market share, execution speed, or prestige. But an institutions value exist entirely on the outside. A true vision does not describe what your organization does. It describes the reality of the world once your work is finished.",[75,217,218],{},"Reaching the vision should require the collaboration and work of others as well, it is not something you can reach entirely on your own, that's the mission you are on, not the vision you have. A vision describes the reality you want to exist, defining it will let you know the direction you need to build whenever new opportunities arise etc.",[75,220,221],{},"The vision statement is a critical tool to keeping your organization aligned on the abstract future you are building. Knowing why we are doing this extremely hard thing–building a organization–will help you weather any storm along the way. And there will be storms.",[75,223,224,225,228],{},"If your vision statement contains your organizations name, you have not en",[98,226,227],{},"visioned"," a future, you are just describing your own ego. A real vision is an altered state of the world that should remain true even if your organization dies on while fighting to create it.",[75,230,231],{},"This will tell you who your collaborative partners can be, which adjacent markets can be pivoted to, etc.",[75,233,234,235],{},"This is not a per team or per product thing. Even though that is the norm today, this often results in varying versions of reality and a splintered strategy with ",[236,237,239],"a",{"href":238},"\u002Flearn\u002Fpriority\u002Fcompeting-priorities","competing priorities",[241,242,244],"h3",{"id":243},"eu-topos-vs-ou-topos-utopia","Eu-topos vs Ou-topos [[Utopia]]",[75,246,247],{},"You need to distinguish between the two Greek definitions of utopia:",[249,250,251,254],"ol",{},[85,252,253],{},"Eu-topos: The good place",[85,255,256],{},"Ou-topos: The place that cant exist",[75,258,259],{},"Do not define a vision of the world that cannot exist, sure it should feel out of reach, but not impossible.",[163,261,263],{"id":262},"mission-the-vehichle-mission","Mission - The vehichle [[Mission]]",[75,265,266],{},"If vision is the world you want to see, the mission should reflect your organizations role in realizing that vision. Once the vision is fixed, the mission is the burden this organization will carry. That role comes from heritage. A mission that could be lifted onto a competitor without anyone noticing is not a mission at all.",[75,268,269],{},"When teams start by just \"shipping small deliveries,\" they are running fast in no particular direction. Imagine we were all going to a specific island, in many tiny boats. If everyone was rowing in slightly different directions, they would all end up in vastly different locations after a year or two years.",[75,271,272],{},"A huge part of the mission is frankly to determine everything you are not going to be doing",[274,275,276],"blockquote",{},[75,277,278],{},"Planning is everyhting, the plan means nothing.\nChurchill",[241,280,282],{"id":281},"the-twin-sins","The twin sins",[75,284,285],{},"Be careful about the people that tell you aimless incrementalism through stakeholder driven prioritization or financialization of everything is the right direction for anything.",[249,287,288,291],{},[85,289,290],{},"Aimless agility",[85,292,293],{},"Financialization",[75,295,296],{},"When an organization lacks a clear mission, finance steps in to fill the vacuum. Instead of building toward a definite future, leadership manages for quarterly earnings. Aimless agile on the ground is what happens when financialization at the top and lacking leadership on the tech side lacks the courage to build big things.",[75,298,299],{},"You cannot A\u002FB test your way to breakthroughs.",[163,301,303],{"id":302},"initatives","Initatives",[75,305,306,307,311],{},"Together with ",[236,308,310],{"href":309},"\u002Flearn\u002Fobjectives","the useful objectives",", initiatives and their respective projects complete the pillars and steps to move as a cohesive unit on the same path to the same eu-topia.",{"title":103,"searchDepth":104,"depth":104,"links":313},[314,315,319,322],{"id":201,"depth":104,"text":202},{"id":211,"depth":104,"text":212,"children":316},[317],{"id":243,"depth":318,"text":244},3,{"id":262,"depth":104,"text":263,"children":320},[321],{"id":281,"depth":318,"text":282},{"id":302,"depth":104,"text":303},"practices","2023-06-20","Knowing why you are building what you are building, and where you want to go, is really important.",{},"\u002Flearn\u002Fdirection",{"title":192,"description":103},[330,331],{"title":126,"url":127},{"title":332,"url":333},"Set the product direction, Linear Method,","https:\u002F\u002Flinear.app\u002Fmethod\u002Fproduct-direction","learn\u002Fdirection",[336,337,338],"direction","strategy","method","2026-10-20","JV5XaWF-17AmDfweEHz8u04R7vtLYfc_NR0igY4dseI",{"id":342,"title":303,"author":70,"body":343,"category":417,"date":324,"description":103,"draft":108,"extension":109,"lead":103,"listed":113,"medium":111,"meta":418,"navigation":113,"notion":103,"path":419,"related":115,"robots":115,"seo":420,"sources":421,"stem":423,"topics":424,"updated":339,"__hash__":425},"learn\u002Flearn\u002Finitiatives.mdc",{"type":72,"value":344,"toc":409},[345,349,356,364,367,371,375,378,384,388,391,396,400,403],[163,346,348],{"id":347},"introduction-intro","Introduction [[Intro]]",[75,350,351,352,355],{},"Initiatives is a tool for ",[236,353,354],{"href":327},"clarifying the direction",". By going through the process of creating initiatives with projects, features, and objectives, and mapping them out in a timeline it makes the mission more practical and how to build towards it more clear.",[75,357,358,359,363],{},"This ",[236,360,362],{"href":361},"\u002Flearn\u002Fplan\u002Ftimeline","timeline"," combined with the priority sets a clear path of execution for the near future, right in front of you, and ideally a bit out of reach. Anyone in your company can look at the product initiatives to quickly understand what the most important streams of work are, why they matter, and how they are progressing.",[75,365,366],{},"This also simplifies the timelining and prioritization greatly, as projects and features become too low level to effectively do prioritization across a whole organization. By grouping it this way, we are able to effectively prioritize a few initiatives instead of tens of projects.",[163,368,370],{"id":369},"components-of-an-initaitive-components","Components of an initaitive [[Components]]",[241,372,374],{"id":373},"projects-and-programs","Projects and Programs",[75,376,377],{},"Primarily a way to effectively allocate resources: humans and capital.",[75,379,380],{},[236,381,383],{"href":382},"\u002Flearn\u002Fprojects","Read more about projects and programs",[241,385,387],{"id":386},"objectives-and-milestones","Objectives and milestones",[75,389,390],{},"A strategy alignment mechanism that demands directional focus",[75,392,393],{},[236,394,395],{"href":309},"Read more about objectives and milestones",[241,397,399],{"id":398},"features","Features",[75,401,402],{},"A group of tasks that provide a functional capability to create customer-facing value, to be completed by a product team, within 1-2 sprints.",[75,404,405],{},[236,406,408],{"href":407},"\u002Flearn\u002Fproducts\u002Ffeatures","Read more about features",{"title":103,"searchDepth":104,"depth":104,"links":410},[411,412],{"id":347,"depth":104,"text":348},{"id":369,"depth":104,"text":370,"children":413},[414,415,416],{"id":373,"depth":318,"text":374},{"id":386,"depth":318,"text":387},{"id":398,"depth":318,"text":399},"mechanism",{},"\u002Flearn\u002Finitiatives",{"title":303,"description":103},[422],{"title":332,"url":333},"learn\u002Finitiatives",[336,337,338],"lAHHDC6067tHgm2rMX6cGCUp94YEN7H8yYAHT_cFuX0",{"id":427,"title":428,"author":70,"body":429,"category":323,"date":324,"description":103,"draft":108,"extension":109,"lead":498,"listed":113,"medium":111,"meta":499,"navigation":113,"notion":103,"path":500,"related":115,"robots":115,"seo":501,"sources":115,"stem":502,"topics":503,"updated":115,"__hash__":504},"learn\u002Flearn\u002Fproblem-spaces.mdc","Accountable problem spaces",{"type":72,"value":430,"toc":492},[431,434,438,441,444,447,451,457,465,473,477,482,485,489],[196,432],{"src":433},"\u002Flearn\u002Fproblem-spaces.svg",[163,435,437],{"id":436},"intro","Intro",[75,439,440],{},"Splicing your business into clearly defined and accountable problem spaces is the best way to ensure you know who are responsible for exactly what.",[75,442,443],{},"As a leader of leaders you need to demand that your direct reports take responsibility for their whole problem space, and always hand out consequences when they dont.",[75,445,446],{},"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,448,450],{"id":449},"case-product-teams-product-teams","Case: Product teams [[Product teams]]",[75,452,453,456],{},[98,454,455],{},"Alias for problem space here:"," Product",[75,458,459,460,464],{},"Within a product team for instance, the product lead needs to take full accountability and ownership over the whole product, the ",[236,461,463],{"href":462},"\u002Flearn\u002Fpriority","prioritized features and improvements",".",[75,466,467,468,472],{},"The tech lead needs to take full responsibility for ",[236,469,471],{"href":470},"\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,474,476],{"id":475},"case-platfom-teams-platfom-teams","Case: Platfom teams [[Platfom teams]]",[75,478,479,481],{},[98,480,455],{}," Domain",[75,483,484],{},"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.",[163,486,488],{"id":487},"platform","Platform",[490,491],"platform-spaces",{},{"title":103,"searchDepth":104,"depth":104,"links":493},[494,495,496,497],{"id":436,"depth":104,"text":437},{"id":449,"depth":104,"text":450},{"id":475,"depth":104,"text":476},{"id":487,"depth":104,"text":488},"One of the most important things you do is to define the problem spaces that others should occupy and solve.",{},"\u002Flearn\u002Fproblem-spaces",{"title":428,"description":103},"learn\u002Fproblem-spaces",[20,27,5,56,40],"jWuJ8p9E3UY3ktr5xq6O3XxD-OPlVvLHzbu1NnViwbM",{"id":506,"title":507,"author":70,"body":508,"category":563,"date":324,"description":564,"draft":108,"extension":109,"lead":103,"listed":108,"medium":111,"meta":565,"navigation":113,"notion":103,"path":382,"related":115,"robots":115,"seo":566,"sources":567,"stem":569,"topics":570,"updated":339,"__hash__":572},"learn\u002Flearn\u002Fprojects.mdc","Projects",{"type":72,"value":509,"toc":556},[510,516,518,521,524,529,533,536,540,543,546,549,553],[75,511,512,513],{},"Not to be confused with ",[236,514,515],{"href":419},"initiatives",[163,517,202],{"id":201},[75,519,520],{},"Projects in our methodogology is more of a funding mechnism for feature releases and parts of initiatives. If the initiative has many projects, and asking for funding for each of them requires you to group them, then that might be a case for introducing one or more programs to fund larger parts of the initiative.",[75,522,523],{},"While we believe in durable teams, funding should still come from the finance and represent a kind of company wide  in order to ensure our capital allocation is still smart.",[75,525,526],{},[236,527,528],{"href":419},"Read more about initaitives here",[163,530,532],{"id":531},"components-of-a-project-components","Components of a project [[Components]]",[75,534,535],{},"It defines capital allocation ($), finite time (calendar), and specific success criteria (deliverable\u002Fspec)",[163,537,539],{"id":538},"objective-alignment","Objective alignment",[75,541,542],{},"Traditional project management has had a notorious past of \"the operation was a complete success, but the patient died\", with strict deadlines that are never met, a set scope that keeps changing and victim blaming.",[75,544,545],{},"This is why all projects needs to define both metrics that they will be measured on after a set period of completing the project as well as be connected to one or more clearly defined objectives.",[75,547,548],{},"To prevent runaway, disconnected rogue projects, they cannot have their own objectives. They can pick objectives from the initiatives, and have their own metrics (also known as key results), that are parts of the main metrics (also known as key performance indicators).",[241,550,552],{"id":551},"deliverables-and-workstreams-deliverables","Deliverables and workstreams [[Deliverables]]",[75,554,555],{},"A stream is a temporary grouping of mostly human resources working to deliver one or more delivarable and is bound to the project lifecycle",{"title":103,"searchDepth":104,"depth":104,"links":557},[558,559,560],{"id":201,"depth":104,"text":202},{"id":531,"depth":104,"text":532},{"id":538,"depth":104,"text":539,"children":561},[562],{"id":551,"depth":318,"text":552},"techniques","Not to be confused with initiatives",{},{"title":507,"description":564},[568],{"title":332,"url":333},"learn\u002Fprojects",[336,337,338,571],"funding","ZbJG6hxIUoL0kI_UI-toCsm_-fHFPBqJH0o8yYdLllc",{"id":574,"title":575,"author":70,"body":576,"category":323,"date":805,"description":103,"draft":108,"extension":109,"lead":806,"listed":113,"medium":111,"meta":807,"navigation":113,"notion":103,"path":470,"related":115,"robots":115,"seo":808,"sources":809,"stem":826,"topics":827,"updated":115,"__hash__":828},"learn\u002Flearn\u002Ftech-debt.mdc","The magical solution to end all technical debt discussions and prolification",{"type":72,"value":577,"toc":794},[578,581,585,602,605,609,626,637,640,682,686,689,699,712,716,719,724,737,740,744,747,750,765,772,780,785,788,791],[196,579],{"src":580},"\u002Flearn\u002Ftech-debt.svg",[163,582,584],{"id":583},"the-landscape","The landscape",[75,586,587,588,592,593,592,597,601],{},"There are many types of debt ",[236,589,591],{"href":590},"\u002Flearn\u002Forg-debt","org debt",", ",[236,594,596],{"href":595},"\u002Flearn\u002Fprocess-debt","process debt",[236,598,600],{"href":599},"\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.",[75,603,604],{},"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.",[241,606,608],{"id":607},"tech-debt-is-changed-assumptions-that-can-turn-into-decay","Tech debt is changed assumptions, that can turn into decay",[75,610,611,612,615,616,620,621,625],{},"Defining tech debt is a hard excercise as the term has been misused so much. Just like other ubiquitous industry terms like ",[236,613,34],{"href":614},"\u002Flearn\u002Farchitecture"," and ",[236,617,619],{"href":618},"\u002Flearn\u002Fagile","agile",". The term ",[622,623,624],"em",{},"technical debt"," has been so violently overused it has become so vague it has seized being useful.",[75,627,628,629,632,633,636],{},"Definition of technical debt: Since writing code requires making assumptions and assumptions about code changes over time, ",[98,630,631],{},"the delta between initial assumptions and current assumptions is technical debt",". Building on that definition, we can add that if those changed assumptions ",[98,634,635],{},"risk reducing velocity",", then that technical debt has an interest rate.",[75,638,639],{},"In order to use the term, we also need to definitively describe what tech debt is not, and what it is.",[641,642,643,665],"columns",{},[644,645,647],"column",{"title":646},"What is not technical debt",[82,648,649,656,659,662],{},[85,650,651,652,655],{},"Working code that looks ",[622,653,654],{},"ugly"," or uses an older programming style that a new hire dislikes.",[85,657,658],{},"A framework that is one major version behind but receives security patches and performs reliably.",[85,660,661],{},"Features or scale the business might need two years from now (that is missing future-proofing, not debt).",[85,663,664],{},"Outright defects or bugs in active feature logic (those are defects, not architectural debt).",[644,666,668],{"title":667},"What is technical debt",[82,669,670,673,676,679],{},[85,671,672],{},"Core workflows that lack automated test coverage, turning every release into manual QA roulette.",[85,674,675],{},"Architectural coupling that forces three teams to coordinate deployments for a single button change.",[85,677,678],{},"Hardcoded business logic reflecting pricing models or constraints abandoned two years ago.",[85,680,681],{},"Brittle, slow build pipelines that waste 45 minutes of developer time per pull request.",[241,683,685],{"id":684},"tech-debt-is-similar-to-real-debt","Tech debt is similar to real debt",[75,687,688],{},"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:",[75,690,691,694,695,698],{},[98,692,693],{},"Low-interest debt"," ",[696,697],"br",{}," Deliberate, 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.",[75,700,701,694,704,706,707,711],{},[98,702,703],{},"High-interest debt",[696,705],{}," Fast, tactical shortcuts—such as intentionally ",[236,708,710],{"href":709},"\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.",[241,713,715],{"id":714},"pay-the-debt-or-suffer-decay","Pay the debt, or suffer decay",[75,717,718],{},"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.",[75,720,721],{},[98,722,723],{},"We need to stop living in the two fantasies:",[249,725,726,734],{},[85,727,728,729,733],{},"That we just need to ",[236,730,732],{"href":731},"\u002Flearn\u002Fplanning-paradox","plan things better"," and build things perfectly the first time, and have it stary right forever.",[85,735,736],{},"That tech debt does not carry a compounding interest rate, and can be handled \"later\".",[75,738,739],{},"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.",[163,741,743],{"id":742},"the-solution","The solution",[75,745,746],{},"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.",[75,748,749],{},"It solves three problems:",[249,751,752,755,758],{},[85,753,754],{},"Eliminates engineering using \"tech debt\" as a vague catch-all excuse for slow delivery.",[85,756,757],{},"Forces engineers to develop commercial discipline: once they own the budget, they have to decide what actually matters rather than demanding an unrealistic rewrite.",[85,759,760,761,764],{},"When the wrong debt is prioritized, the accountability for a systems failure and the ownership around that ",[236,762,763],{"href":500},"problem space"," is actually clear.",[75,766,767,768,771],{},"The allocation of 15% per sprint needs to have a strict ",[622,769,770],{},"use it or lose it"," expiration. This prevents capacity hoarding and guarantees product managers a stable, reliable cadence of feature delivery every cycle.",[241,773,775,776,779],{"id":774},"consequence-of-prioritizing-the-wrong-debt","Consequence of ",[236,777,778],{"href":462},"prioritizing"," the wrong debt",[274,781,782],{},[75,783,784],{},"Autonomy without accountability is indulgence; accountability without autonomy is micromanagement.",[75,786,787],{},"Giving the tech lead full autonomy over this budget means that they own the operational outcome of their choice.",[75,789,790],{},"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.",[75,792,793],{},"True autonomy requires living with the blast radius of your decisions. Do not infantilize engineers by shielding them from that trade-off.",{"title":103,"searchDepth":104,"depth":104,"links":795},[796,801],{"id":583,"depth":104,"text":584,"children":797},[798,799,800],{"id":607,"depth":318,"text":608},{"id":684,"depth":318,"text":685},{"id":714,"depth":318,"text":715},{"id":742,"depth":104,"text":743,"children":802},[803],{"id":774,"depth":318,"text":804},"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":575,"description":103},[810,814,818,822],{"title":811,"detail":812,"url":813},"How to Manage Technical Debt: A Practitioner's Guide","OpenHands, 2026","https:\u002F\u002Fwww.openhands.dev\u002Fblog\u002Ftechnical-debt-management",{"title":815,"detail":816,"url":817},"Technical Debt","Martin Fowler, 2019","https:\u002F\u002Fmartinfowler.com\u002Fbliki\u002FTechnicalDebt.html",{"title":819,"detail":820,"url":821},"Technical Debt Quadrant","Martin Fowler, 2009","https:\u002F\u002Fmartinfowler.com\u002Fbliki\u002FTechnicalDebtQuadrant.html",{"title":823,"detail":824,"url":825},"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],"PDXVUt0a0zFl7lR6rn7pLiSUR3jFB4t98esY0FyY7F0",{"id":830,"title":831,"author":70,"body":832,"category":323,"date":916,"description":103,"draft":108,"extension":109,"lead":917,"listed":113,"medium":111,"meta":918,"navigation":113,"notion":103,"path":919,"related":115,"robots":115,"seo":920,"sources":921,"stem":925,"topics":926,"updated":115,"__hash__":927},"learn\u002Flearn\u002Fscope.mdc","Scoping down",{"type":72,"value":833,"toc":907},[834,837,844,847,852,860,868,872,876,880,883,886,889,893,896,900,903],[196,835],{"src":836},"\u002Flearn\u002Fscope-down.svg",[75,838,839,840,843],{},"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 ",[236,841,842],{"href":147},"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.",[75,845,846],{},"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.",[75,848,849],{},[98,850,851],{},"By scoping down you will:",[82,853,854,857],{},[85,855,856],{},"Eliminate the need for release management",[85,858,859],{},"Reduce the need for test teams",[75,861,862,863,867],{},"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 ",[236,864,866],{"href":865},"\u002Flearn\u002Fexecution-bias","execution bias"," and prioritize deliviring value above all else.",[163,869,871],{"id":870},"validation-is-the-most-important","Validation is the most important",[163,873,875],{"id":874},"phased-implementations","Phased implementations",[241,877,879],{"id":878},"poc","POC",[75,881,882],{},"The proof of concept is basically a \"minimal viable prototype\"\nA prototype of what can be, to prove the concept, before spending months working on it.\nValidate technical assumptions, test architecture choices.\nExplore novelty",[75,884,885],{},"It does not mean fully automated processes, most of the steps can be and should be manual. Copying database files, copy pasting e-mail addresses to an external solution, all good and should happen in the proof of concept phase.",[75,887,888],{},"The code in this part should not be reusable, it can turn out to be, but its not a goal yet.",[241,890,892],{"id":891},"mvp","MVP",[75,894,895],{},"Minimal viable product",[241,897,899],{"id":898},"cvp","CVP",[75,901,902],{},"Comercially viable product",[241,904,906],{"id":905},"iteration","ITERATION",{"title":103,"searchDepth":104,"depth":104,"links":908},[909,910],{"id":870,"depth":104,"text":871},{"id":874,"depth":104,"text":875,"children":911},[912,913,914,915],{"id":878,"depth":318,"text":879},{"id":891,"depth":318,"text":892},{"id":898,"depth":318,"text":899},{"id":905,"depth":318,"text":906},"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\u002Fscope",{"title":831,"description":103},[922],{"title":923,"url":924},"Linear Method: Scope projects down","https:\u002F\u002Flinear.app\u002Fmethod\u002Fscope-projects","learn\u002Fscope",[20],"5t-Sm96CL8nOYnBq6y-3g_7Vwy657ZI-zcD7pJXAECA",[618,929,147,930,327,709,865,931,114,932,419,933,599,309,590,934,731,935,462,500,936,595,937,382,183,919,470],"\u002Flearn\u002Fautonomy","\u002Flearn\u002Fbusines-domains","\u002Flearn\u002Fexploration","\u002Flearn\u002Fhiring","\u002Flearn\u002Fmetrics","\u002Flearn\u002Fplan","\u002Flearn\u002Fppp","\u002Flearn\u002Fproblems-with-consulting","\u002Flearn\u002Fproducts",{"cb":939},"Christer Bjørnstad",1792472548599]