[{"data":1,"prerenderedAt":1405},["ShallowReactive",2],{"books":3,"tags":100,"book-citations":157},[4,28,42,59,72,85],{"id":5,"title":6,"aliases":7,"body":9,"description":16,"extension":17,"hue":18,"image":19,"meta":20,"name":21,"navigation":22,"order":23,"path":24,"seo":25,"stem":26,"__hash__":27},"books\u002Fbooks\u002Fddd.mdc","Domain-driven design",[8],"domain-driven-design",{"type":10,"value":11,"toc":12},"minimark",[],{"title":13,"searchDepth":14,"depth":14,"links":15},"",2,[],"Learn about domain-driven design and how a domain is cut into models people can own.","mdc","orange",null,{},"DDD",true,16,"\u002Fbooks\u002Fddd",{"title":6,"description":16},"books\u002Fddd","A8xppL2k4Hr3qHPx1FaUbQw_XypB3QANZ77r3r5I308",{"id":29,"title":30,"aliases":19,"body":31,"description":35,"extension":17,"hue":36,"image":19,"meta":37,"name":19,"navigation":22,"order":19,"path":38,"seo":39,"stem":40,"__hash__":41},"books\u002Fbooks\u002Fhigh-output-management.mdc","High Output Management",{"type":10,"value":32,"toc":33},[],{"title":13,"searchDepth":14,"depth":14,"links":34},[],"High Output Management is a book by Andrew S. Grove, the longtime CEO of Intel, first published in 1983. It treats management as a production process, where a manager's output is the output of the organization they run and influence. It covers leverage, indicators paired with counter-indicators to guard against overreacting to a single number, one-on-ones, meetings, decision-making, and task-relevant maturity.","blue",{},"\u002Fbooks\u002Fhigh-output-management",{"title":30,"description":35},"books\u002Fhigh-output-management","Fw7RDMgt9zMmhUex-mkJhB14V5y9PErbpmtMl_xr3CA",{"id":43,"title":44,"aliases":19,"body":45,"description":49,"extension":17,"hue":19,"image":19,"meta":50,"name":19,"navigation":22,"order":19,"path":55,"seo":56,"stem":57,"__hash__":58},"books\u002Fbooks\u002Fmbo.mdc","Management by Objectives",{"type":10,"value":46,"toc":47},[],{"title":13,"searchDepth":14,"depth":14,"links":48},[],"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.",{"author":51,"year":52,"category":53,"type":54},"Peter F. Drucker",1954,"management","book","\u002Fbooks\u002Fmbo",{"title":44,"description":49},"books\u002Fmbo","2yWYUEiB-3fjz1Xz0-G0DWISfFFfPuzeFIErm5Els1w",{"id":60,"title":61,"aliases":19,"body":62,"description":66,"extension":17,"hue":36,"image":19,"meta":67,"name":19,"navigation":22,"order":19,"path":68,"seo":69,"stem":70,"__hash__":71},"books\u002Fbooks\u002Fteam-topologies.mdc","Team Topologies",{"type":10,"value":63,"toc":64},[],{"title":13,"searchDepth":14,"depth":14,"links":65},[],"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.",{},"\u002Fbooks\u002Fteam-topologies",{"title":61,"description":66},"books\u002Fteam-topologies","K_U6GEEmZJHUG_Blk2GVuCwfDEB68EfKln3pwQm3iY8",{"id":73,"title":74,"aliases":19,"body":75,"description":79,"extension":17,"hue":36,"image":19,"meta":80,"name":19,"navigation":22,"order":19,"path":81,"seo":82,"stem":83,"__hash__":84},"books\u002Fbooks\u002Fthe-mythical-man-month.mdc","The Mythical Man-Month",{"type":10,"value":76,"toc":77},[],{"title":13,"searchDepth":14,"depth":14,"links":78},[],"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",{},"\u002Fbooks\u002Fthe-mythical-man-month",{"title":74,"description":79},"books\u002Fthe-mythical-man-month","SwIjOvgg0-eLFZe-dsTatXzQHkatz0V1OkHZn0ZDoxo",{"id":86,"title":87,"aliases":88,"body":90,"description":94,"extension":17,"hue":36,"image":19,"meta":95,"name":19,"navigation":22,"order":19,"path":96,"seo":97,"stem":98,"__hash__":99},"books\u002Fbooks\u002Fthe-practice-of-management.mdc","The Practice of Management",[89],"practice-of-management",{"type":10,"value":91,"toc":92},[],{"title":13,"searchDepth":14,"depth":14,"links":93},[],"The Practice of Management is a book by Peter F. Drucker, first published in 1954. It was one of the first books to treat management as a distinct discipline, and it introduced Management by Objectives and self-control, where managers and their teams agree on clear objectives and measure their own progress against them. It also argues that the purpose of a business is to create a customer, and includes the parable of the three stonecutters.",{},"\u002Fbooks\u002Fthe-practice-of-management",{"title":87,"description":94},"books\u002Fthe-practice-of-management","Qk8fKma5qRygIoXeNcJzabdui0J0131nUIw1-9pwe_c",[101,108,114,121,128,134,139,142,145,148,151,154],{"slug":102,"name":103,"title":103,"description":104,"hue":105,"aliases":106,"order":107},"growth","Growth","Learn about growth and what an institution should refuse in order to keep it.","green",[],10,{"slug":109,"name":110,"title":110,"description":111,"hue":18,"aliases":112,"order":113},"decay","Decay","Learn about institutional decay and how organizations lose the ability to act.",[],11,{"slug":115,"name":116,"title":116,"description":117,"hue":118,"aliases":119,"order":120},"leadership","Leadership","Learn about leadership and who is accountable for a decision.","pink",[],12,{"slug":122,"name":123,"title":123,"description":124,"hue":125,"aliases":126,"order":127},"teams","Teams","Learn about teams and how a group holds a problem.","cyan",[],13,{"slug":129,"name":130,"title":130,"description":131,"hue":125,"aliases":132,"order":133},"architecture","Architecture","Learn about architecture and how a system is cut into parts people can own.",[],15,{"slug":135,"name":135,"title":135,"hue":136,"aliases":137,"order":138},"agile","neutral",[],9007199254740991,{"slug":140,"name":140,"title":140,"hue":136,"aliases":141,"order":138},"direction",[],{"slug":143,"name":143,"title":143,"hue":136,"aliases":144,"order":138},"fred-brooks",[],{"slug":146,"name":146,"title":146,"hue":136,"aliases":147,"order":138},"funding",[],{"slug":149,"name":149,"title":149,"hue":136,"aliases":150,"order":138},"method",[],{"slug":152,"name":152,"title":152,"hue":136,"aliases":153,"order":138},"principles",[],{"slug":155,"name":155,"title":155,"hue":136,"aliases":156,"order":138},"strategy",[],[158,315,686,834,920,1172,1299,1326,1373],{"id":159,"title":160,"author":161,"body":162,"children":19,"description":13,"draft":296,"extension":17,"lead":297,"listed":22,"meta":298,"navigation":22,"notion":13,"parent":19,"path":299,"published":300,"robots":19,"seo":301,"shortTitle":302,"sources":303,"stem":310,"tags":311,"updated":312,"__hash__":313,"entityType":314},"learn\u002Flearn\u002Fdirection.mdc","The importance of defining your vision before you define your mission, or start working on small deliveries","cb",{"type":10,"value":163,"toc":285},[164,168,173,177,180,184,187,190,193,201,204,212,217,220,230,233,237,240,243,246,252,256,259,267,270,273,277],[165,166],"img",{"src":167},"\u002Flearn\u002Fdirection.svg",[169,170,172],"h2",{"id":171},"introduction","Introduction",[174,175,176],"p",{},"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.",[174,178,179],{},"Shipping small things does not add up to a strategy. Iteration is not a substitute for a plan.",[169,181,183],{"id":182},"vision-the-destination-vision","Vision - the destination [[Vision]]",[174,185,186],{},"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.",[174,188,189],{},"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.",[174,191,192],{},"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.",[174,194,195,196,200],{},"If your vision statement contains your organizations name, you have not en",[197,198,199],"strong",{},"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.",[174,202,203],{},"This will tell you who your collaborative partners can be, which adjacent markets can be pivoted to, etc.",[174,205,206,207],{},"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 ",[208,209,211],"a",{"href":210},"\u002Flearn\u002Fpriority\u002Fcompeting-priorities","competing priorities",[213,214,216],"h3",{"id":215},"eu-topos-vs-ou-topos-utopia","Eu-topos vs Ou-topos [[Utopia]]",[174,218,219],{},"You need to distinguish between the two Greek definitions of utopia:",[221,222,223,227],"ol",{},[224,225,226],"li",{},"Eu-topos: The good place",[224,228,229],{},"Ou-topos: The place that cant exist",[174,231,232],{},"Do not define a vision of the world that cannot exist, sure it should feel out of reach, but not impossible.",[169,234,236],{"id":235},"mission-the-vehichle-mission","Mission - The vehichle [[Mission]]",[174,238,239],{},"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.",[174,241,242],{},"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.",[174,244,245],{},"A huge part of the mission is frankly to determine everything you are not going to be doing",[247,248,249],"blockquote",{},[174,250,251],{},"Planning is everyhting, the plan means nothing.\nChurchill",[213,253,255],{"id":254},"the-twin-sins","The twin sins",[174,257,258],{},"Be careful about the people that tell you aimless incrementalism through stakeholder driven prioritization or financialization of everything is the right direction for anything.",[221,260,261,264],{},[224,262,263],{},"Aimless agility",[224,265,266],{},"Financialization",[174,268,269],{},"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.",[174,271,272],{},"You cannot A\u002FB test your way to breakthroughs.",[169,274,276],{"id":275},"initatives","Initatives",[174,278,279,280,284],{},"Together with ",[208,281,283],{"href":282},"\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":13,"searchDepth":14,"depth":14,"links":286},[287,288,292,295],{"id":171,"depth":14,"text":172},{"id":182,"depth":14,"text":183,"children":289},[290],{"id":215,"depth":291,"text":216},3,{"id":235,"depth":14,"text":236,"children":293},[294],{"id":254,"depth":291,"text":255},{"id":275,"depth":14,"text":276},false,"Knowing why you are building what you are building, and where you want to go, is really important.",{},"\u002Flearn\u002Fdirection","2023-06-20",{"title":160,"description":13},"Direction",[304,307],{"title":305,"url":306},"Management by Objectives, Peter F. Drucker, 1954","\u002Fbook\u002Fmbo",{"title":308,"url":309},"Set the product direction, Linear Method,","https:\u002F\u002Flinear.app\u002Fmethod\u002Fproduct-direction","learn\u002Fdirection",[140,155,149],"2026-10-20","CQlyudBc_2ZVM0tADAVwRgBLrmYh3QS5aqZbrMHHTR8","learn",{"id":316,"title":317,"author":161,"body":318,"children":19,"description":13,"draft":296,"extension":17,"lead":669,"listed":22,"meta":670,"navigation":22,"notion":13,"parent":19,"path":671,"published":300,"robots":19,"seo":672,"shortTitle":673,"sources":674,"stem":682,"tags":683,"updated":684,"__hash__":685,"entityType":314},"learn\u002Flearn\u002Fmetrics.mdc","See how far you are from your objectives through real measures of success",{"type":10,"value":319,"toc":658},[320,324,327,330,333,336,339,346,350,353,356,362,365,370,427,431,434,437,445,448,453,464,477,481,484,487,512,515,518,521,525,530,533,536,540,543,546,549,552,555,558,561,565,568,572,575,578,655],[169,321,323],{"id":322},"introduction-intro","Introduction [[Intro]]",[174,325,326],{},"There is a dangerous comfort in measuring motion instead of progress. When organizations lose the discipline to judge work by actual systemic output, metrics become the ultimate refuge from accountability.",[174,328,329],{},"Most organizations do not use metrics to measure reality. They use them as administrative armor. When executives lack the conviction to inspect actual work, and middle managers lack the ability to produce it, metrics become the primary tool to simulate momentum. The entire layer of coordinators, managers, directors, and status reporters survives by converting real operational problems into clean, sanitized numbers that fit neatly onto a slide deck.",[174,331,332],{},"In most companies, executives and middle management have built entire careers out of confusing the two. Measuring actual progress is dangerous: it requires standing in front of real outcomes and taking ownership of the blast radius when things fail. Measuring motion is safe. You track tickets closed, processes followed, story points burned, and quarterly \"initiatives\" completed.",[174,334,335],{},"A metric is not a vanity mirror, nor is it a scorecard to justify someone’s headcount. It is diagnostic instrumentation. Its only function is to expose friction and systemic failure with complete, unemotional clarity so that people can make hard trade-offs before things break. The moment a metric exists to prove that leadership is doing a great job or to protect a comfortable middle manager from accountability, it ceases to be a measurement. It is just an expensive corporate cover story.",[174,337,338],{},"It is the best tool at your disposal to identify the bottlenecks in value creation, it is the only tool you can use to effectively prioritize where to put your best people at any time.",[174,340,341,342,345],{},"Measuring whether any of these activities contributed to any high priority ",[208,343,344],{"href":282},"objectives"," or not, is sadly a rare thing in mature organizations. This ruthless accountability is a dying art.",[213,347,349],{"id":348},"the-definition-of-useful-metrics-definition","The definition of useful metrics [[Definition]]",[174,351,352],{},"A metric is not an objective in itself. An objective is the destination, a goal with a clearly defined end state and a deadline. A metric is simply the instrument that measures how far you are along to the objective, and a way to measure whether you have actually achieved that objective or not.",[174,354,355],{},"It does not set strategy, it does not motivate teams, and it should never be treated as an end in itself. Its job is purely diagnostic, it should reflect the ground truth of the system as it runs, without narrative spin or managerial interpretation.",[174,357,358,361],{},[197,359,360],{},"Useful metrics over academic gymnastics","\nUseful metric is never an academic exercise in statistical gymnastics. If you need advanced math degrees or an explanation of polynomial regression to understand what a number means and how daily work impacts it, the metric is completely useless.",[174,363,364],{},"The best metrics are brutally simple, transparent, and immediately obvious to everyone looking at them. If you cannot explain the metric and what drives it in one plain-English sentence, throw it out.",[174,366,367],{},[197,368,369],{},"Determine a useful metric",[371,372,373,401],"columns",{},[374,375,377],"column",{"title":376},"Useless metric",[378,379,380,383,386,389,392,395,398],"ul",{},[224,381,382],{},"Story points burned in a two-week sprint.",[224,384,385],{},"Sprint commitment reliability tracked inside Jira.",[224,387,388],{},"Subjective \"Green\" status reports on a coordinator’s slide deck.",[224,390,391],{},"The number of architectural review meetings held or RFCs filed.",[224,393,394],{},"Internal \"stakeholder satisfaction\" survey scores.",[224,396,397],{},"98% test coverage testing trivial boilerplate code.",[224,399,400],{},"Total volume of tickets moved to \"Done\".",[374,402,404],{"title":403},"Useful metric",[378,405,406,409,412,415,418,421,424],{},[224,407,408],{},"Reducing database query latency that causes a 10% drop-off at checkout.",[224,410,411],{},"End-to-end cycle time: how long it takes for a committed change to reach production.",[224,413,414],{},"Zero unhandled production exceptions during peak operational hours.",[224,416,417],{},"Measurable reduction in cross-team dependencies stalling independent releases.",[224,419,420],{},"Net change in operating cost or hours shaved off a frontline workflow.",[224,422,423],{},"Mean time to detect and recover (MTTR) from an operational breakdown.",[224,425,426],{},"Elimination of manual workarounds required to process daily transactions.",[169,428,430],{"id":429},"proxy-metrics-risks-becoming-obfuscations-proxies","Proxy metrics risks becoming obfuscations [[Proxies]]",[174,432,433],{},"The moment middle managers and team leads realize that managing the score is easier than managing reality, proxy metrics take over.",[174,435,436],{},"A proxy metric is a synthetic measurement invented to simulate value without having to produce an actual business outcome. Real objectives carry real risk: they rely on operational performance, they face market reality, and when they fail, the blast radius is obvious. Proxy metrics, by contrast, offer total safety. A middle manager or coordinator can define them, track them, and report green status updates across every quarterly slide deck without ever solving an actual problem.",[174,438,439,440,444],{},"This is how an organization begins eating its own tail. Middle management starts inventing concepts like the ",[208,441,443],{"href":442},"\u002Ffeed\u002Finternal-customers","internal customers"," to insulate the organization from economic reality. Once teams only serve \"internal customers,\" the necessity of shipping real value vanishes. Engineering is measured by story points burned for Product; Product is measured by tickets delivered for Management; Coordinators are measured by sprint cadences maintained for Leadership.",[174,446,447],{},"The entire circus becomes a closed loop of fake productivity. A team can hit 100% of its internal proxy targets, win praise across the management chain, and celebrate another \"successful\" cycle while the core business output quietly degrades.",[174,449,450],{},[197,451,452],{},"Proxies will actively rot the system from within, by measuring movement instead of progress:",[221,454,455,458,461],{},[224,456,457],{},"They incentivize systematic gaming by chopping medium things into tiny things, to show ticket velocity instead of feature releases.",[224,459,460],{},"They reward motion over completion: A project coordinator can report an initiative as \"85% complete\" for three quarters in a row based on checklist proxies, even if zero functioning capability has reached reality.",[224,462,463],{},"They sever teams from reality: When the primary target is maintaining an internal score, nobody has an incentive to ask whether the system is actually holding up under real-world pressure.",[174,465,466,467,471,472,476],{},"Proxies are not harmless bureaucratic quirks. They are an active drain on organizational energy and focus. Every hour spent negotiating story points, calibrating motion, and sitting in sync meetings to defend synthetic numbers is an hour stolen from fixing ",[208,468,470],{"href":469},"\u002Flearn\u002Finitiatives\u002Fbottlenecks","real bottlenecks"," in the actual business or focusing on grabbing the ",[208,473,475],{"href":474},"\u002Flearn\u002Finitiatives\u002Fopportunities","real opportunities",".",[169,478,480],{"id":479},"metrics-needs-to-be-tamper-proof-tamper-proof","Metrics needs to be tamper proof [[Tamper proof]]",[174,482,483],{},"Middle managers and coordinators are rational actors. When their status, authority, or quarterly standing depends on a dashboard, human nature takes over and they will bend reality before they admit systemic failures.",[174,485,486],{},"Unless you enforce strict, objective governance over how numbers are gathered, metric tampering will run rampant across the organization:",[221,488,489,495,506],{},[224,490,491,494],{},[197,492,493],{},"Redefining terminology on the fly:"," When incident numbers spike, middle management simply reclassifies critical operational failures as problems instead of incidents to protect the uptime report.",[224,496,497,500,501,505],{},[197,498,499],{},"Filtering the dataset:"," Negative customer feedback, botched deliveries, or failed transactions are dismissed as ",[502,503,504],"em",{},"statistical outliers"," and quietly excluded from the monthly review.",[224,507,508,511],{},[197,509,510],{},"Grading their own homework:"," Coordinators determine the criteria for whether their own project hit its milestones, ensuring a 100% success rate on paper while the operational floor deals with the wreckage.",[174,513,514],{},"Measuring should never be done by the people being measured. If a metric requires human curation, manual entry, or managerial interpretation before it reaches leadership, it is not telemetry, it is public relations.",[174,516,517],{},"Useful metrics must be completely tamper-proof. They must be generated automatically by the systems doing the work: raw event logs, verified transaction drops, system latency, and uncurated frontline complaints. If they are qualitative in nature, there should be a seperate team doing the qualitative work.",[174,519,520],{},"If a middle manager has the administrative access to delete bad feedback or tweak the formula of a scorecard, they will to some degree and at some point in time do it. Protect the numbers from human interference, or stop pretending you care about the truth or is data driven. Then its better to just have power points with opinions rather than dashboards with fake truths.",[169,522,524],{"id":523},"metrics-are-not-objectives","Metrics are not objectives",[247,526,527],{},[174,528,529],{},"When a measure becomes a target, it ceases to be a good measure",[174,531,532],{},"It is important to build demand a culture where the metrics are not becoming",[174,534,535],{},"The moment a metric is tied to compensation, performance evaluations, or quarterly status reports, people stop managing the business and start managing the score.",[169,537,539],{"id":538},"quantitative-output-output","Quantitative output [[Output]]",[174,541,542],{},"Management literature has made a habit of sneering at output. We are told by consultants and framework peddlers that \"measuring output is an outdated industrial mindset\" and that \"mature organizations only measure outcomes.\"",[174,544,545],{},"This is complete nonsense. It is at its worst intellectually dishonest and at its best an excuse invented by people who produce nothing. A shield designed to excuse for not delivering something that is working on a deadline.",[174,547,548],{},"These metrics that measure financial increases or efficiency gains can be viewed as output oriented. They are in fact more valuable than the purely",[174,550,551],{},"These have recently been viewed as less valuable than outcome based ones. This is wrong, a business thrives on the quantiative metrics. Focusing solely and mainely on qualitative outcomes rather than output, turns an organization into a complicated academic excecices rather than a practical and pragmatic system.",[174,553,554],{},"Output is the baseline of operational vitality. It is what actually creates value and is the primus behind all other things in any organization.",[174,556,557],{},"Another alias of it is efficiency.",[174,559,560],{},"Do not apologize for measuring raw throughput. The goal is not to eliminate output metrics, but to ensure that the output you measure is real work rather than administrative motion.",[169,562,564],{"id":563},"qualtiative-outcomes-outcome","Qualtiative outcomes [[Outcome]]",[174,566,567],{},"Another alias of it is effectiveness.",[169,569,571],{"id":570},"paired-effects","Paired effects",[174,573,574],{},"Pairs of metrics should be used to balance the effect and counter-effect, that way we dont overreact to increases.",[174,576,577],{},"For instance releases increasing will also increase bugs in production. Needs to be paired with severity, length of bug, economic effect and release frequency.",[371,579,580,609,638],{},[374,581,583],{"title":582},"Primary metric (drive)",[378,584,585,591,597,603],{},[224,586,587,590],{},[197,588,589],{},"Release frequency:"," Increasing the number of deployments to production.",[224,592,593,596],{},[197,594,595],{},"Operational throughput:"," Total orders processed per shift.",[224,598,599,602],{},[197,600,601],{},"Cycle time:"," Speed from task initiation to completion.",[224,604,605,608],{},[197,606,607],{},"Infrastructure cost reduction:"," Slashing operational server and tool expenses.",[374,610,612],{"title":611},"Counter-weight metric (tension)",[378,613,614,620,626,632],{},[224,615,616,619],{},[197,617,618],{},"Defect severity and rollback rate:"," Mean time to recover, business cost of outages.",[224,621,622,625],{},[197,623,624],{},"Error and damage rate:"," The percentage of orders requiring manual intervention or returns.",[224,627,628,631],{},[197,629,630],{},"Rework percentage:"," Volume of work that has to be revisited due to missed edge cases.",[224,633,634,637],{},[197,635,636],{},"End-user latency and system degradation:"," Customer drop-off and request timeouts.",[374,639,641],{"title":640},"The distortion prevented",[378,642,643,646,649,652],{},[224,644,645],{},"Prevents teams from shipping broken, unverified changes just to inflate deployment counts.",[224,647,648],{},"Prevents hitting volume targets by cutting corners and passing defective work downstream.",[224,650,651],{},"Prevents rushing half-baked solutions that break within two weeks.",[224,653,654],{},"Prevents gutting necessary operational capacity under the guise of \"cost-saving drives.\"",[174,656,657],{},"Measuring screws used or stones cut instead of progress towards building",{"title":13,"searchDepth":14,"depth":14,"links":659},[660,663,664,665,666,667,668],{"id":322,"depth":14,"text":323,"children":661},[662],{"id":348,"depth":291,"text":349},{"id":429,"depth":14,"text":430},{"id":479,"depth":14,"text":480},{"id":523,"depth":14,"text":524},{"id":538,"depth":14,"text":539},{"id":563,"depth":14,"text":564},{"id":570,"depth":14,"text":571},"Most organizations use metrics not to measure progress, but to hide from accountability. They optimize proxies to create the illusion of momentum and velocity, while the actual foundation rots.",{},"\u002Flearn\u002Fmetrics",{"title":317,"description":13},"Metrics",[675,676,679],{"title":305,"url":306},{"title":677,"url":678},"Goodheart's Law","\u002F§goodhearts-law",{"title":680,"url":681},"High Output Management, Andrew S. Grove, 1983","\u002Fbook\u002Fhigh-output-management","learn\u002Fmetrics",[140,155,149],"2026-10-23","dw22BTzjq0bAEyStpVoXrZRDSWVfZsppx9A4KdKoA04",{"id":687,"title":688,"author":161,"body":689,"children":19,"description":13,"draft":296,"extension":17,"lead":822,"listed":22,"meta":823,"navigation":22,"notion":13,"parent":19,"path":282,"published":300,"robots":19,"seo":824,"shortTitle":825,"sources":826,"stem":831,"tags":832,"updated":684,"__hash__":833,"entityType":314},"learn\u002Flearn\u002Fobjectives.mdc","Clarity through objectives with deadlines create alignment",{"type":10,"value":690,"toc":815},[691,693,715,718,722,730,741,744,747,750,754,757,765,768,772,787,790,793,797,800,803,809,812],[169,692,172],{"id":171},[174,694,695,696,700,701,705,706,710,711,714],{},"They should have clear delivery dates, a clear scope of what is within and outisde. A clear ",[208,697,699],{"href":698},"\u002Flearn\u002Fpriority","priority"," and should be aligned with both your ",[208,702,704],{"href":703},"\u002Flearn\u002Fvision","vision"," and ",[208,707,709],{"href":708},"\u002Flearn\u002Fmission","mission",". They need to have measurable ",[208,712,713],{"href":671},"metrics"," for quantitative output and qualitative outcomes of completing the objective.",[174,716,717],{},"The purpose of an objective is to subordinate individual craftsmanship to systemic output.",[169,719,721],{"id":720},"parable","Parable",[174,723,724,725,729],{},"In The Practice of Management (1954), Peter Drucker illustrated the fundamental problem of organizational alignment through the parable of the three stonecutters",[726,727,728],"span",{},"cite: 3",". When asked what they were doing:",[221,731,732,735,738],{},[224,733,734],{},"The first said: \"I am making a living.\"",[224,736,737],{},"The second said: \"I am doing the best job of stonecutting in the entire country.\"",[224,739,740],{},"The third said: \"I am building a cathedral.\"",[174,742,743],{},"The second stonecutter is always the most dangerous person in an organization. He is an artisan who cares more about the elegance of his craft, whether that is clean code, beautiful mockups, or complex spreadsheets, than whether the cathedral ever gets built.\nWithout a clear, unifying objective, organizations naturally elevate the second stonecutter. Senior engineers will spend six weeks redesigning an internal build pipeline for marginal aesthetic pleasure; designers will obsess over micro-interactions for features that solve no real problem; managers will optimize their localized team headcount. Each person operates under the delusion that doing exceptional work in their narrow discipline automatically helps the business.",[174,745,746],{},"It does not. High craft in service of the wrong outcome is just expensive self-indulgence. An objective provides the single external standard that judges all internal effort: Does this specific technical or design trade-off get the cathedral built before the deadline, or is it just vanity stone-polishing?",[174,748,749],{},"With clearly defined objectives in your team, everyone can row in the same direction.",[169,751,753],{"id":752},"deadlines","Deadlines",[174,755,756],{},"In order to forcefully introduce momentum and velocity you need to always set deadlines, this operational constraint will introduce friction so teams are forced to make hard trade-offs.",[174,758,759,760,764],{},"The deadlines are not part of some rigid waterfall schedule, however we cannot let it be soft suggestions either, as the moment scope creeps or a hypothesis fails, the reflex of weak leadership is to move the deadline. While the disciplined response is to protect the deadline and ruthlessly ",[208,761,763],{"href":762},"\u002Flearn\u002Fscope","cut scope",". If moving a deadline carries zero friction, it will become the standard way of operating: huge initial scope, soft schedules, everything delayed.",[174,766,767],{},"Cutting scope should be within the authority of the team to make that decision, as they will be the owners of the problem space.",[169,769,771],{"id":770},"hysteric-focus-towards-fake-goals-hysteria","Hysteric focus towards fake goals [[Hysteria]]",[174,773,774,775,778,779,782,783,786],{},"Lacking a continuous, stable vector, leadership governs through rolling panic. One month an executive declares an ",[502,776,777],{},"costs drive"," to slash spending. That is immediately followed by a ",[502,780,781],{},"quality drive"," to get rid of bugs, which is followed by a ",[502,784,785],{},"speed drive"," to hit an arbitrary marketing release. Each campaign is launched with breathless urgency, derailing active engineering work to focus entirely on whatever symptom is currently screaming the loudest.",[174,788,789],{},"Management by drive is an admission of managerial debt and incompetence. It exhausts teams, induces cynicism, and teaches people to silently wait out every new corporate campaign, knowing that everything will collapse back into a broken status quo three weeks after the \"drive\" ends.",[174,791,792],{},"Objectives exist to eliminate the hysteria, by replacing unpredictable executive mood swings with the steady, unemotional discipline of building towards fixed constraints.",[169,794,796],{"id":795},"death-by-hierarchy","Death by hierarchy",[174,798,799],{},"The fastest way to destroy objective-based management is to cascade it into a bureaucratic hierarchy. This is what happened to agile and scrum, and once the bureaucracy catches up, it becomes yet another weapon by the laptop class to use to avoid work, accountability and focus.",[174,801,802],{},"When leadership forces every department and sub-team to invent its own bespoke layer of formal objectives, you create an administrative nightmare. Teams begin managing to proxies—metrics designed to simulate value without having to produce actual business outcomes. Engineering measures story points burned; QA measures test tickets closed; Product measures shipping frequency.   Proxies incentivize teams to game the system at the direct expense of the whole. A team can hit 100% of its internal proxy metrics while the actual product fails completely in the market.   Objectives cannot be an intellectual exercise in fractal tree-building. If an engineer on a pull request cannot draw a direct, unbroken line between their current technical task and the company’s primary objective without passing through three layers of corporate abstraction, the hierarchy is useless. Keep the objectives minimal, visible, and tied directly to real-world outcomes rather than internal activity.",[174,804,805,806,808],{},"Once each team start defining their own objectives and breaking them into, you risk them becoming too abstract and seize to be useful anymore. Just as the risk of ",[208,807,211],{"href":210}," we have the same for competing or different objectives that end up",[174,810,811],{},"That is why we think these abstractions\u002Fproxies of goals and metrics are not actually that useful in practice, beyond giving the teams a way to think about how they contribute.",[174,813,814],{},"But this should really just be something they think about always. How is the task im doing right now contributing to the organziations objectives?",{"title":13,"searchDepth":14,"depth":14,"links":816},[817,818,819,820,821],{"id":171,"depth":14,"text":172},{"id":720,"depth":14,"text":721},{"id":752,"depth":14,"text":753},{"id":770,"depth":14,"text":771},{"id":795,"depth":14,"text":796},"An Objective is a goal with a clearly defined end state. It has a measurable outcome and\u002For change in output. Without an objective, teams measure motion instead of progress.",{},{"title":688,"description":13},"Objectives",[827,830],{"title":828,"url":829},"The Practice of Management, Peter F. Drucker, 1954","\u002Fbook\u002Fthe-practice-of-management",{"title":305,"url":306},"learn\u002Fobjectives",[140,155,149],"mUcphsEPOXDkS7lXje181MPhIWuRSVHMeAc0PpAqPs0",{"id":835,"title":836,"author":161,"body":837,"children":19,"description":13,"draft":296,"extension":17,"lead":905,"listed":22,"meta":906,"navigation":22,"notion":13,"parent":19,"path":907,"published":300,"robots":19,"seo":908,"shortTitle":909,"sources":910,"stem":917,"tags":918,"updated":684,"__hash__":919,"entityType":314},"learn\u002Flearn\u002Fproblem-spaces.mdc","Accountable problem spaces",{"type":10,"value":838,"toc":898},[839,842,846,849,852,855,859,862,866,872,878,886,890,895],[165,840],{"src":841},"\u002Flearn\u002Fproblem-spaces.svg",[169,843,845],{"id":844},"intro","Intro",[174,847,848],{},"Splicing your business into clearly defined and accountable problem spaces is the best way to ensure you know who are responsible for exactly what.",[174,850,851],{},"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.",[174,853,854],{},"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",[213,856,858],{"id":857},"the-goal","The goal",[174,860,861],{},"The goal is to make the person setting the requirements, be the one responsible for the completion of it, make them accountable for it, and assign the consequences of it.",[169,863,865],{"id":864},"case-product-teams-product-teams","Case: Product teams [[Product teams]]",[174,867,868,871],{},[197,869,870],{},"Alias for problem space here:"," Product",[174,873,874,875,476],{},"Within a product team for instance, the product lead needs to take full accountability and ownership over the whole product, the ",[208,876,877],{"href":698},"prioritized features and improvements",[174,879,880,881,885],{},"The tech lead needs to take full responsibility for ",[208,882,884],{"href":883},"\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.",[169,887,889],{"id":888},"case-platfom-teams-platfom-teams","Case: Platfom teams [[Platfom teams]]",[174,891,892,894],{},[197,893,870],{}," Domain",[174,896,897],{},"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":13,"searchDepth":14,"depth":14,"links":899},[900,903,904],{"id":844,"depth":14,"text":845,"children":901},[902],{"id":857,"depth":291,"text":858},{"id":864,"depth":14,"text":865},{"id":888,"depth":14,"text":889},"One of the most important things you do is to define the problem spaces that others should occupy and solve.",{},"\u002Flearn\u002Fproblem-spaces",{"title":836,"description":13},"Problem spaces",[911,914],{"title":912,"url":913},"Team Topologies, Matthew Skelton and Manuel Pais, 2019","\u002Fbook\u002Fteam-topologies",{"title":915,"url":916},"Domain-Driven Design, Eric Evans, 2003","\u002Fbook\u002Fddd","learn\u002Fproblem-spaces",[115,122,102],"opMBSEv-vv_YbXhBmyztt4VAYm1zAOY5-m4l9FJvDeo",{"id":921,"title":922,"author":161,"body":923,"children":19,"description":13,"draft":296,"extension":17,"lead":1147,"listed":22,"meta":1148,"navigation":22,"notion":13,"parent":19,"path":883,"published":1149,"robots":19,"seo":1150,"shortTitle":1151,"sources":1152,"stem":1169,"tags":1170,"updated":19,"__hash__":1171,"entityType":314},"learn\u002Flearn\u002Ftech-debt.mdc","The magical solution to end all technical debt discussions and prolification",{"type":10,"value":924,"toc":1136},[925,928,932,949,952,956,970,981,984,1024,1028,1031,1041,1054,1058,1061,1066,1079,1082,1086,1089,1092,1107,1114,1122,1127,1130,1133],[165,926],{"src":927},"\u002Flearn\u002Ftech-debt.svg",[169,929,931],{"id":930},"the-landscape","The landscape",[174,933,934,935,939,940,939,944,948],{},"There are many types of debt ",[208,936,938],{"href":937},"\u002Flearn\u002Forg-debt","org debt",", ",[208,941,943],{"href":942},"\u002Flearn\u002Fprocess-debt","process debt",[208,945,947],{"href":946},"\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.",[174,950,951],{},"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.",[213,953,955],{"id":954},"tech-debt-is-changed-assumptions-that-can-turn-into-decay","Tech debt is changed assumptions, that can turn into decay",[174,957,958,959,705,962,965,966,969],{},"Defining tech debt is a hard excercise as the term has been misused so much. Just like other ubiquitous industry terms like ",[208,960,129],{"href":961},"\u002F%E2%8C%97architecture",[208,963,135],{"href":964},"\u002Flearn\u002Fagile",". The term ",[502,967,968],{},"technical debt"," has been so violently overused it has become so vague it has seized being useful.",[174,971,972,973,976,977,980],{},"Definition of technical debt: Since writing code requires making assumptions and assumptions about code changes over time, ",[197,974,975],{},"the delta between initial assumptions and current assumptions is technical debt",". Building on that definition, we can add that if those changed assumptions ",[197,978,979],{},"risk reducing velocity",", then that technical debt has an interest rate.",[174,982,983],{},"In order to use the term, we also need to definitively describe what tech debt is not, and what it is.",[371,985,986,1007],{},[374,987,989],{"title":988},"What is not technical debt",[378,990,991,998,1001,1004],{},[224,992,993,994,997],{},"Working code that looks ",[502,995,996],{},"ugly"," or uses an older programming style that a new hire dislikes.",[224,999,1000],{},"A framework that is one major version behind but receives security patches and performs reliably.",[224,1002,1003],{},"Features or scale the business might need two years from now (that is missing future-proofing, not debt).",[224,1005,1006],{},"Outright defects or bugs in active feature logic (those are defects, not architectural debt).",[374,1008,1010],{"title":1009},"What is technical debt",[378,1011,1012,1015,1018,1021],{},[224,1013,1014],{},"Core workflows that lack automated test coverage, turning every release into manual QA roulette.",[224,1016,1017],{},"Architectural coupling that forces three teams to coordinate deployments for a single button change.",[224,1019,1020],{},"Hardcoded business logic reflecting pricing models or constraints abandoned two years ago.",[224,1022,1023],{},"Brittle, slow build pipelines that waste 45 minutes of developer time per pull request.",[213,1025,1027],{"id":1026},"tech-debt-is-similar-to-real-debt","Tech debt is similar to real debt",[174,1029,1030],{},"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:",[174,1032,1033,1036,1037,1040],{},[197,1034,1035],{},"Low-interest debt"," ",[1038,1039],"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.",[174,1042,1043,1036,1046,1048,1049,1053],{},[197,1044,1045],{},"High-interest debt",[1038,1047],{}," Fast, tactical shortcuts—such as intentionally ",[208,1050,1052],{"href":1051},"\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.",[213,1055,1057],{"id":1056},"pay-the-debt-or-suffer-decay","Pay the debt, or suffer decay",[174,1059,1060],{},"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.",[174,1062,1063],{},[197,1064,1065],{},"We need to stop living in the two fantasies:",[221,1067,1068,1076],{},[224,1069,1070,1071,1075],{},"That we just need to ",[208,1072,1074],{"href":1073},"\u002Flearn\u002Fplanning-paradox","plan things better"," and build things perfectly the first time, and have it stary right forever.",[224,1077,1078],{},"That tech debt does not carry a compounding interest rate, and can be handled \"later\".",[174,1080,1081],{},"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.",[169,1083,1085],{"id":1084},"the-solution","The solution",[174,1087,1088],{},"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.",[174,1090,1091],{},"It solves three problems:",[221,1093,1094,1097,1100],{},[224,1095,1096],{},"Eliminates engineering using \"tech debt\" as a vague catch-all excuse for slow delivery.",[224,1098,1099],{},"Forces engineers to develop commercial discipline: once they own the budget, they have to decide what actually matters rather than demanding an unrealistic rewrite.",[224,1101,1102,1103,1106],{},"When the wrong debt is prioritized, the accountability for a systems failure and the ownership around that ",[208,1104,1105],{"href":907},"problem space"," is actually clear.",[174,1108,1109,1110,1113],{},"The allocation of 15% per sprint needs to have a strict ",[502,1111,1112],{},"use it or lose it"," expiration. This prevents capacity hoarding and guarantees product managers a stable, reliable cadence of feature delivery every cycle.",[213,1115,1117,1118,1121],{"id":1116},"consequence-of-prioritizing-the-wrong-debt","Consequence of ",[208,1119,1120],{"href":698},"prioritizing"," the wrong debt",[247,1123,1124],{},[174,1125,1126],{},"Autonomy without accountability is indulgence; accountability without autonomy is micromanagement.",[174,1128,1129],{},"Giving the tech lead full autonomy over this budget means that they own the operational outcome of their choice.",[174,1131,1132],{},"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.",[174,1134,1135],{},"True autonomy requires living with the blast radius of your decisions. Do not infantilize engineers by shielding them from that trade-off.",{"title":13,"searchDepth":14,"depth":14,"links":1137},[1138,1143],{"id":930,"depth":14,"text":931,"children":1139},[1140,1141,1142],{"id":954,"depth":291,"text":955},{"id":1026,"depth":291,"text":1027},{"id":1056,"depth":291,"text":1057},{"id":1084,"depth":14,"text":1085,"children":1144},[1145],{"id":1116,"depth":291,"text":1146},"Consequence of prioritizing the wrong debt","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.",{},"2023-04-13",{"title":922,"description":13},"Tech debt",[1153,1157,1161,1165],{"title":1154,"detail":1155,"url":1156},"How to Manage Technical Debt: A Practitioner's Guide","OpenHands, 2026","https:\u002F\u002Fwww.openhands.dev\u002Fblog\u002Ftechnical-debt-management",{"title":1158,"detail":1159,"url":1160},"Technical Debt","Martin Fowler, 2019","https:\u002F\u002Fmartinfowler.com\u002Fbliki\u002FTechnicalDebt.html",{"title":1162,"detail":1163,"url":1164},"Technical Debt Quadrant","Martin Fowler, 2009","https:\u002F\u002Fmartinfowler.com\u002Fbliki\u002FTechnicalDebtQuadrant.html",{"title":1166,"detail":1167,"url":1168},"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",[115,109],"VWc_6DU6b2H2cL1F3_2sdESaZ61i2wHItHhJSRnSiy8",{"id":1173,"title":1174,"author":161,"body":1175,"children":19,"description":13,"draft":296,"extension":17,"lead":1287,"listed":22,"meta":1288,"navigation":22,"notion":13,"parent":19,"path":762,"published":1289,"robots":19,"seo":1290,"shortTitle":1291,"sources":1292,"stem":1296,"tags":1297,"updated":684,"__hash__":1298,"entityType":314},"learn\u002Flearn\u002Fscope.mdc","Scoping down to ensure momentum and velocity",{"type":10,"value":1176,"toc":1280},[1177,1180,1182,1190,1193,1198,1206,1214,1218,1221,1228,1231,1234,1240,1243,1246,1250,1253,1256,1260,1263,1270,1274,1277],[165,1178],{"src":1179},"\u002Flearn\u002Fscope-down.svg",[169,1181,172],{"id":171},[174,1183,1184,1185,1189],{},"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 ",[208,1186,1188],{"href":1187},"\u002F%C2%A7brooks-law","late projects later"," and will decay product quality over time. Keep deliveries small enough to be completed within one to three weeks, with a clear outcome and as few dependencies as possible. Smaller scopes force everyone to think clearly about which features to actually prioritize. Instead of thinking or talking about doing something, you decide to do it or not to do it.",[174,1191,1192],{},"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.",[174,1194,1195],{},[197,1196,1197],{},"By scoping down you will:",[378,1199,1200,1203],{},[224,1201,1202],{},"Eliminate the need for release management",[224,1204,1205],{},"Reduce the need for test teams",[174,1207,1208,1209,1213],{},"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 ",[208,1210,1212],{"href":1211},"\u002Flearn\u002Fexecution-bias","execution bias"," and prioritize delivering value above all else.",[169,1215,1217],{"id":1216},"proof-of-concept-poc","Proof of concept [[POC]]",[174,1219,1220],{},"The proof of concept exists to validate technical and functional assumptions, and explore novelty, at an extremely low cost.",[174,1222,1223,1224,1227],{},"They should be viewed as ",[502,1225,1226],{},"minimal viable prototypes",", where we prototype and build exactly enough to validate whether or not a concept can technologically and directionally work, before spending months working based on flawed assumptions.",[174,1229,1230],{},"Most of the steps can be and in most cases should be manual. Copying database files, generating fake data, copy pasting e-mail addresses to an external solution, are all good practices and should happen in the proof of concept phase.",[174,1232,1233],{},"This will instill fear in a lot of developers, that have been getting used to pilots becoming the de facto production solution, not getting to the next phase etc. If you have this problem, it is a cultural one, where managers have not done their job in cleaning up after pilots and tests, and the tech leads should feel empowered by having the authority to prioritize cleaning up",[174,1235,1236],{},[208,1237,1239],{"href":1238},"\u002Flearn\u002Ftech-debt\u002Fthe-solution","learn about our elegant solution to all tech debt",[174,1241,1242],{},"The code in this part should not be reusable, it can turn out to be, but it's not a goal in this phase.",[174,1244,1245],{},"What is important is to split each concept you are trying to prove into their own smaller chunks that are easily verifiable on their own. That way you don't have to say \"it worked, but..\". Instead you can clearly state \"X and Y worked, but Z failed because of..\", knowing exactly which concept was the weak one.",[169,1247,1249],{"id":1248},"minimal-viable-product-mvp","Minimal viable product [[MVP]]",[174,1251,1252],{},"The key word here is product, it should be feature-poor, but not bug-rich. No admin dashboards, no perfect integrations, manual tasks are still ok, and the UI deoesn't have to be perfect.",[174,1254,1255],{},"The idea is to scope it down so hard, that it hurts to run it in production. You should still leave a lot to the next phase.",[169,1257,1259],{"id":1258},"commercially-viable-product-cvp","Commercially viable product [[CVP]]",[174,1261,1262],{},"it's greatest practical value is as a scoping weapon. The CVP exists inside the project as a designated bucket to catch stakeholder and developer panic.\nI borrowed this term from a banking friend that used to have a lot of B2B customers in the banking space. While MVP might be ok for internal testing in such environments, the CVP needs to be scalable. This phase isn't mandatory, but I find it to be useful just to get everyone on board with the MVP. It is more of a tool for scoping down than anything. It could be a part of iteration but it's cleaner to seperate it as a step before it can be prioritized under other things.",[174,1264,1265,1266,1269],{},"It is a bucket to catch stakeholder and developer panic, by pushing everything that people believe you ",[197,1267,1268],{},"have to include"," into the \"next phase\", you will end up eliminating a lot of it.",[169,1271,1273],{"id":1272},"iteration","Iteration",[174,1275,1276],{},"You test a few concepts, choose to move them into an MVP, push some things to the CVP, and the CVP should function as a combination of MVP iterations, the combination of the phases will be different. This does not mean you don't release continually. Releasing continually is important still.",[174,1278,1279],{},"The clue is to transition the feature into active continuous iteration instead of letting a \"project\" run indefinitely",{"title":13,"searchDepth":14,"depth":14,"links":1281},[1282,1283,1284,1285,1286],{"id":171,"depth":14,"text":172},{"id":1216,"depth":14,"text":1217},{"id":1248,"depth":14,"text":1249},{"id":1258,"depth":14,"text":1259},{"id":1272,"depth":14,"text":1273},"When work stalls, cut the scope before adding time or people. How small commitments and quick wins build an execution bias.",{},"2023-03-20",{"title":1174,"description":13},"Scope",[1293],{"title":1294,"url":1295},"Linear Method: Scope projects down","https:\u002F\u002Flinear.app\u002Fmethod\u002Fscope-projects","learn\u002Fscope",[115],"0DamD3unyTtGi9_0eJFSKTekfQqNLqfoqObXyZd5oSI",{"id":1300,"title":1301,"author":161,"body":1302,"children":19,"description":1306,"draft":296,"extension":17,"lead":1312,"listed":296,"meta":1313,"navigation":22,"notion":13,"parent":19,"path":1314,"published":1315,"robots":19,"seo":1316,"shortTitle":19,"sources":1317,"stem":1322,"tags":1323,"updated":19,"__hash__":1324,"entityType":1325},"principles\u002Fprinciples-and-practices\u002Fbrooks-law.mdc","Brook's law",{"type":10,"value":1303,"toc":1310},[1304,1307],[174,1305,1306],{},"Brooks's law is an observation about software project management that \"Adding manpower to a late software project makes it later.\".",[174,1308,1309],{},"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":13,"searchDepth":14,"depth":14,"links":1311},[],"An outrageous oversimplification that states \"Adding manpower to a late software project makes it later\"",{},"\u002Fprinciples-and-practices\u002Fbrooks-law","2023-07-20",{"title":1301,"description":1306},[1318,1321],{"title":1319,"url":1320},"The Mythical Man-Month, Fred Brooks, 1975","\u002Fbook\u002Fthe-mythical-man-month",{"title":912,"url":913},"principles-and-practices\u002Fbrooks-law",[115,143],"3sKM_zYAIkPGFEBZ3e2gPFsbRMsiB92K7-av6aD2CAY","principle-and-practice",{"id":1327,"title":1328,"author":161,"body":1329,"children":19,"description":1333,"draft":296,"extension":17,"lead":529,"listed":296,"meta":1357,"navigation":22,"notion":13,"parent":19,"path":1358,"published":1359,"robots":19,"seo":1360,"shortTitle":19,"sources":1361,"stem":1370,"tags":1371,"updated":19,"__hash__":1372,"entityType":1325},"principles\u002Fprinciples-and-practices\u002Fgoodhearts-law.mdc","Goodhart's law",{"type":10,"value":1330,"toc":1355},[1331,1334,1337,1348],[174,1332,1333],{},"Goodhart's law is an observation about organizational control that \"When a measure becomes a target, it ceases to be a good measure.\"",[174,1335,1336],{},"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.",[378,1338,1339,1342,1345],{},[224,1340,1341],{},"Tell developers they are measured by lines of code, and you get bloated, unmaintainable systems.",[224,1343,1344],{},"Measure QA by bugs closed, and trivial typos get logged while systemic architecture defects get ignored.",[224,1346,1347],{},"Measure sales reps by calls placed, and you get hundred-call days that convert zero real customers.",[174,1349,1350,1351,1354],{},"Measurement was originally designed by Drucker as an instrument of ",[197,1352,1353],{},"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":13,"searchDepth":14,"depth":14,"links":1356},[],{},"\u002Fprinciples-and-practices\u002Fgoodhearts-law","2026-10-18",{"title":1328,"description":1333},[1362,1365,1369],{"title":1363,"url":1364},"Problems of Monetary Management: The U.K. Experience","\u002Fresearch\u002Fproblems-of-monetary-management",{"title":1366,"detail":1367,"url":1368},"‘Improving ratings’: audit in the British University system","European Review","\u002Fresearch\u002Fimproving-ratings",{"title":305,"url":306},"principles-and-practices\u002Fgoodhearts-law",[115],"fetwjkYxxUa3EOdAdZV7HBx_-eDt2cKddusfeWfc8rM",{"id":1374,"title":1375,"author":161,"body":1376,"children":19,"description":13,"draft":296,"extension":17,"lead":13,"listed":296,"meta":1396,"navigation":22,"notion":13,"parent":19,"path":1397,"published":1315,"robots":19,"seo":1398,"shortTitle":19,"sources":1399,"stem":1402,"tags":1403,"updated":19,"__hash__":1404,"entityType":1325},"principles\u002Fprinciples-and-practices\u002Freverse-conway.mdc","Reverse Conway Manouver",{"type":10,"value":1377,"toc":1392},[1378,1382,1385,1389],[169,1379,1381],{"id":1380},"definition","Definition",[174,1383,1384],{},"The reverse conway manouver is a way to reverse engineer the orgnaizsational strucutre around the technological architecture.",[169,1386,1388],{"id":1387},"pincer","Pincer",[174,1390,1391],{},"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":13,"searchDepth":14,"depth":14,"links":1393},[1394,1395],{"id":1380,"depth":14,"text":1381},{"id":1387,"depth":14,"text":1388},{},"\u002Fprinciples-and-practices\u002Freverse-conway",{"title":1375,"description":13},[1400,1401],{"title":1319,"url":1320},{"title":912,"url":913},"principles-and-practices\u002Freverse-conway",[115,143],"RZlD-dtnyytVjzfJ3Pf6FxxrCNlr5yXsXZa4tKceCRo",1792745197972]