[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"sanity-cMTxWOw-_yQ_VPWSlUoRGryOjoTBexRLaO010V32zD4":3,"sanity-nV_U_8ow46sAryunTIi_uL8zKNycyIiPvlwuEbI6knU":875},{"data":4,"sourceMap":-1},{"latestPodcast":5,"latestReleases":14,"post":39,"recent":850},[6],{"_id":7,"publishedAt":8,"slug":9,"sponsored":12,"title":13},"50f4509c-4f55-4f11-8adc-5556e821ea77","2026-06-30T07:40:00.000Z",{"_type":10,"current":11},"slug","why-intent-prediction-needs-more-than-an-llm",null,"Why intent prediction needs more than an LLM",[15,21,27,33],{"_id":16,"publishedAt":17,"slug":18,"title":20},"eb5b66eb-9410-4329-83bb-22bbff39402a","2026-04-28T13:00:00.000Z",{"_type":10,"current":19},"turn-scattered-knowledge-into-trusted-intelligence","Turning scattered knowledge into trusted intelligence: Stack Internal 2026.3",{"_id":22,"publishedAt":23,"slug":24,"title":26},"369c2401-b62e-4a37-8ff8-bf603023ecad","2026-03-02T15:03:00.988Z",{"_type":10,"current":25},"what-s-new-at-stack-overflow-march-2026","What’s new at Stack Overflow: March 2026",{"_id":28,"publishedAt":29,"slug":30,"title":32},"5e9053a4-07ea-447c-91ea-29e0b6228537","2026-02-02T15:00:00.000Z",{"_type":10,"current":31},"what-s-new-at-stack-overflow-february-2026","What’s new at Stack Overflow: February 2026",{"_id":34,"publishedAt":35,"slug":36,"title":38},"a1b538eb-a8a6-46d0-80a1-ac70ec9bb935","2026-01-05T10:00:00.000-05:00",{"_type":10,"current":37},"what-s-new-at-stack-overflow-january-2026","What’s new at Stack Overflow: January 2026",{"_createdAt":40,"_id":41,"_rev":42,"_system":43,"_type":46,"_updatedAt":47,"author":48,"body":65,"comments":801,"dateUrl":802,"excerpt":803,"image":804,"legacyBody":807,"product":12,"publishedAt":810,"slug":811,"sponsored":12,"tags":813,"title":849,"visible":801},"2023-05-24T12:28:25Z","wp-post-21885","nvZcks16ldBXxsacAEgUzM",{"base":44},{"id":41,"rev":45},"0aYkJXBENQTxI4C1z7NQYh","blogPost","2026-05-11T18:30:31Z",[49],{"_createdAt":50,"_id":51,"_rev":52,"_type":53,"_updatedAt":54,"avatar":55,"bio":60,"employee":61,"name":62,"slug":63},"2023-05-23T16:27:18Z","wp-author-cap-18115","07ZbrKPSUrjrV4wQ6fDpaa","blogAuthor","2023-06-20T15:05:10Z",{"_type":56,"asset":57},"image",{"_ref":58,"_type":59},"image-8cf69a05d6ef9dfd6db2ac2da2518a7d5e4b90d1-386x426-png","reference","Daniel Orner is a Staff Software Engineer at Flipp and has previously worked at IBM. You can find his articles, ranging from musings on event-driven microservices to what Ruby can learn from Go, at his GitHub profile. He lives in Toronto with a wife and four small people who alternate between enriching and enraging him.","none","Daniel Orner",{"current":64},"daniel-orner",[66,78,98,117,125,133,141,150,175,184,192,201,211,219,227,235,243,251,259,267,275,283,291,299,307,315,323,331,338,346,354,362,370,377,385,393,401,409,436,444,452,492,508,516,524,532,540,548,556,564,572,580,596,612,636,652,668,676,698,706,714,722,738,753,761,769,777,785,793],{"_key":67,"_type":68,"children":69,"markDefs":76,"style":77},"5ff30551c598","block",[70],{"_key":71,"_type":72,"marks":73,"text":75},"5ff30551c5980","span",[74],"em","Thanks to David Meyers, Principal Engineer at Flipp, for introducing me to this concept, normalizing it, and implementing it flawlessly.",[],"normal",{"_key":79,"_type":68,"children":80,"markDefs":94,"style":77},"b73dd618c89f",[81,85,90],{"_key":82,"_type":72,"marks":83,"text":84},"b73dd618c89f0",[],"Raw startups are often chaotic and scattered. \"Move fast and break things!\" was repeated in the standups of hundreds of startup engineering orgs. Typically, startups tend to build monolithic systems to reduce friction in creating and changing features. As time goes on, the monolithic architecture begins to show strain, and ",{"_key":86,"_type":72,"marks":87,"text":89},"b73dd618c89f1",[88],"c77e75161848","almost",{"_key":91,"_type":72,"marks":92,"text":93},"b73dd618c89f2",[]," inevitably begins to be broken up.",[95],{"_key":88,"_type":96,"href":97,"reference":12},"link","https://m.signalvnoise.com/the-majestic-monolith/",{"_key":99,"_type":68,"children":100,"markDefs":114,"style":77},"2474a2e5a76f",[101,105,110],{"_key":102,"_type":72,"marks":103,"text":104},"2474a2e5a76f0",[],"Teams begin to take ownership of the new services, usually adhering to ",{"_key":106,"_type":72,"marks":107,"text":109},"2474a2e5a76f1",[108],"ca3b1da24c2e","Conway's Law",{"_key":111,"_type":72,"marks":112,"text":113},"2474a2e5a76f2",[],". Since each service is only owned by a single team (or should be), questions inevitably arise related to the technologies used for each of them.",[115],{"_key":108,"_type":96,"href":116,"reference":12},"https://en.wikipedia.org/wiki/Conway%27s_law",{"_key":118,"_type":68,"children":119,"markDefs":124,"style":77},"b21002c73c2c",[120],{"_key":121,"_type":72,"marks":122,"text":123},"b21002c73c2c0",[],"Should the backend administrative system, used by a dozen internal employees, be written using the same frameworks and stack as the tight, performance-critical end-user system? Should batch processors have the same technical footprint as stream processors? Should analytics databases use the same solution as the one used for ad-hoc queries?",[],{"_key":126,"_type":68,"children":127,"markDefs":132,"style":77},"232c45defe01",[128],{"_key":129,"_type":72,"marks":130,"text":131},"232c45defe010",[],"Some engineers love to experiment with new, bleeding-edge technologies. Others warn of the perils and demand adherence to the tried-and-true. As the company grows ever bigger, the same sorts of problems emerge over and over again to be solved. Do you solve those problems the same way you did earlier because it's already done? Or do you go with a new approach that offers more benefits?",[],{"_key":134,"_type":68,"children":135,"markDefs":140,"style":77},"5d9881348726",[136],{"_key":137,"_type":72,"marks":138,"text":139},"5d98813487260",[],"How these problems get solved becomes more critical as a startup transitions to a medium-sized company.",[],{"_key":142,"_type":68,"children":143,"markDefs":148,"style":149},"4006625778ec",[144],{"_key":145,"_type":72,"marks":146,"text":147},"4006625778ec0",[],"Terminology",[],"h1",{"_key":151,"_type":68,"children":152,"markDefs":174,"style":77},"e6ed6518b27e",[153,157,161,165,170],{"_key":154,"_type":72,"marks":155,"text":156},"e6ed6518b27e0",[],"This article discusses all kinds of ",{"_key":158,"_type":72,"marks":159,"text":160},"e6ed6518b27e1",[74],"technology",{"_key":162,"_type":72,"marks":163,"text":164},"e6ed6518b27e2",[]," from a software engineering perspective. This can include programming languages, frameworks, database systems, ways to store and transfer files, schema definition systems, etc. I will use the word ",{"_key":166,"_type":72,"marks":167,"text":169},"e6ed6518b27e3",[168],"strong","tech",{"_key":171,"_type":72,"marks":172,"text":173},"e6ed6518b27e4",[]," as a shortcut to describe this list of solutions, systems, and projects.",[],{"_key":176,"_type":68,"children":177,"markDefs":182,"style":183},"c2ac49133d08",[178],{"_key":179,"_type":72,"marks":180,"text":181},"c2ac49133d080",[],"Option 1: The Wild West",[],"h2",{"_key":185,"_type":68,"children":186,"markDefs":191,"style":77},"ca8ea9688b02",[187],{"_key":188,"_type":72,"marks":189,"text":190},"ca8ea9688b020",[],"At one extreme, we could simply allow every team to choose whatever tech they wanted to use with full autonomy. There's no oversight committee, no red tape, and no blockers to doing what they want how they want.",[],{"_key":193,"_type":68,"children":194,"markDefs":199,"style":200},"a0b67deb07d0",[195],{"_key":196,"_type":72,"marks":197,"text":198},"a0b67deb07d00",[],"The benefits",[],"h3",{"_key":202,"_type":68,"children":203,"level":208,"listItem":209,"markDefs":210,"style":77},"3e44564ee91e",[204],{"_key":205,"_type":72,"marks":206,"text":207},"3e44564ee91e0",[],"Teams are empowered to make their own technology decisions based on the information they have.",1,"bullet",[],{"_key":212,"_type":68,"children":213,"level":208,"listItem":209,"markDefs":218,"style":77},"527a160526a0",[214],{"_key":215,"_type":72,"marks":216,"text":217},"527a160526a00",[],"The \"best\" tech for the problem being solved can be used.",[],{"_key":220,"_type":68,"children":221,"level":208,"listItem":209,"markDefs":226,"style":77},"58e2202e527f",[222],{"_key":223,"_type":72,"marks":224,"text":225},"58e2202e527f0",[],"Teams are not tied down by previous technical decisions made either by themselves or other teams.",[],{"_key":228,"_type":68,"children":229,"level":208,"listItem":209,"markDefs":234,"style":77},"1c9d9abd3bf7",[230],{"_key":231,"_type":72,"marks":232,"text":233},"1c9d9abd3bf70",[],"Morale is high since engineers get to use new, fun tech rather than being stuck with old or out-of-style choices.",[],{"_key":236,"_type":68,"children":237,"level":208,"listItem":209,"markDefs":242,"style":77},"a4aa8cb5ffb6",[238],{"_key":239,"_type":72,"marks":240,"text":241},"a4aa8cb5ffb60",[],"Engineers feel that their voices matter in technology decisions.",[],{"_key":244,"_type":68,"children":245,"markDefs":250,"style":200},"76f313e7ed11",[246],{"_key":247,"_type":72,"marks":248,"text":249},"76f313e7ed110",[],"The downsides",[],{"_key":252,"_type":68,"children":253,"level":208,"listItem":209,"markDefs":258,"style":77},"ec18e45feb2f",[254],{"_key":255,"_type":72,"marks":256,"text":257},"ec18e45feb2f0",[],"It is more difficult to reuse previous solutions written in other languages or frameworks.",[],{"_key":260,"_type":68,"children":261,"level":208,"listItem":209,"markDefs":266,"style":77},"689a6c6bad3a",[262],{"_key":263,"_type":72,"marks":264,"text":265},"689a6c6bad3a0",[],"It is harder to generalize solutions across similar problems since reuse is harder.",[],{"_key":268,"_type":68,"children":269,"level":208,"listItem":209,"markDefs":274,"style":77},"f7d1b60daaa2",[270],{"_key":271,"_type":72,"marks":272,"text":273},"f7d1b60daaa20",[],"There is risk of \"technology sprawl\": a single engineer has to know multiple technologies in order to succeed at their job.",[],{"_key":276,"_type":68,"children":277,"level":208,"listItem":209,"markDefs":282,"style":77},"cfa064accda9",[278],{"_key":279,"_type":72,"marks":280,"text":281},"cfa064accda90",[],"This can result in superficial broad knowledge of languages or systems rather than deep knowledge of one tech, which can affect the ability to debug problems or make more advanced changes.",[],{"_key":284,"_type":68,"children":285,"level":208,"listItem":209,"markDefs":290,"style":77},"c6c4f51fb70a",[286],{"_key":287,"_type":72,"marks":288,"text":289},"c6c4f51fb70a0",[],"Hiring and internal training becomes more onerous. Either the company has to hire engineers who already know the full set of tech or spend more time training them once they are hired.",[],{"_key":292,"_type":68,"children":293,"level":208,"listItem":209,"markDefs":298,"style":77},"1d9982bf692e",[294],{"_key":295,"_type":72,"marks":296,"text":297},"1d9982bf692e0",[],"Internal support becomes more fractured since there will be fewer experts in any one tech to help less experienced developers.",[],{"_key":300,"_type":68,"children":301,"level":208,"listItem":209,"markDefs":306,"style":77},"c1afc93e3768",[302],{"_key":303,"_type":72,"marks":304,"text":305},"c1afc93e37680",[],"Building internal tools may become more difficult since it has to work with all the tech that the team (or company) supports.",[],{"_key":308,"_type":68,"children":309,"markDefs":314,"style":183},"2adf2e4ddf84",[310],{"_key":311,"_type":72,"marks":312,"text":313},"2adf2e4ddf840",[],"Option 2: Lock it down",[],{"_key":316,"_type":68,"children":317,"markDefs":322,"style":77},"082bb16b8a20",[318],{"_key":319,"_type":72,"marks":320,"text":321},"082bb16b8a200",[],"At the other extreme, whatever choice was made at the company's inception becomes the one and only solution that must be used. If the first application was made using Python and Postgres, then every service must use only Python and Postgres.",[],{"_key":324,"_type":68,"children":325,"markDefs":330,"style":77},"63fa70bb264c",[326],{"_key":327,"_type":72,"marks":328,"text":329},"63fa70bb264c0",[],"The advantages and disadvantages are swapped here.",[],{"_key":332,"_type":68,"children":333,"markDefs":337,"style":200},"44fc90cefc69",[334],{"_key":335,"_type":72,"marks":336,"text":198},"44fc90cefc690",[],[],{"_key":339,"_type":68,"children":340,"level":208,"listItem":209,"markDefs":345,"style":77},"810621dd0e11",[341],{"_key":342,"_type":72,"marks":343,"text":344},"810621dd0e110",[],"Reusing previous solutions and generalizing them becomes much easier since you are guaranteed to use the same tech stack.",[],{"_key":347,"_type":68,"children":348,"level":208,"listItem":209,"markDefs":353,"style":77},"1ca76bf97001",[349],{"_key":350,"_type":72,"marks":351,"text":352},"1ca76bf970010",[],"Each engineer can be trained on a single stack and can more easily learn deep knowledge about it, and therefore help support other engineers.",[],{"_key":355,"_type":68,"children":356,"level":208,"listItem":209,"markDefs":361,"style":77},"49c3bdca906e",[357],{"_key":358,"_type":72,"marks":359,"text":360},"49c3bdca906e0",[],"Hiring is easier since only one set of skills is necessary.",[],{"_key":363,"_type":68,"children":364,"level":208,"listItem":209,"markDefs":369,"style":77},"a133b3576c27",[365],{"_key":366,"_type":72,"marks":367,"text":368},"a133b3576c270",[],"Internal tools are simpler since they only have to deal with one set of tech.",[],{"_key":371,"_type":68,"children":372,"markDefs":376,"style":200},"469c1cf0293c",[373],{"_key":374,"_type":72,"marks":375,"text":249},"469c1cf0293c0",[],[],{"_key":378,"_type":68,"children":379,"level":208,"listItem":209,"markDefs":384,"style":77},"642a2df7c046",[380],{"_key":381,"_type":72,"marks":382,"text":383},"642a2df7c0460",[],"Engineers become demoralized since they feel stuck with old tech that may not be well suited to the problem at hand.",[],{"_key":386,"_type":68,"children":387,"level":208,"listItem":209,"markDefs":392,"style":77},"ff25fb92df9c",[388],{"_key":389,"_type":72,"marks":390,"text":391},"ff25fb92df9c0",[],"Trying to squeeze a tech into solving a problem it isn't designed for can result in increasingly hacky and costly kludges.",[],{"_key":394,"_type":68,"children":395,"level":208,"listItem":209,"markDefs":400,"style":77},"f77beba40fda",[396],{"_key":397,"_type":72,"marks":398,"text":399},"f77beba40fda0",[],"Engineers do not feel empowered since they have no agency to make technological decisions.",[],{"_key":402,"_type":68,"children":403,"markDefs":408,"style":183},"6e77a09eb036",[404],{"_key":405,"_type":72,"marks":406,"text":407},"6e77a09eb0360",[],"The golden mean",[],{"_key":410,"_type":68,"children":411,"markDefs":433,"style":77},"bdea87d9953c",[412,416,421,425,429],{"_key":413,"_type":72,"marks":414,"text":415},"bdea87d9953c0",[],"As you can guess, the \"right path\" is somewhere in the middle of these extremes. At ",{"_key":417,"_type":72,"marks":418,"text":420},"bdea87d9953c1",[419],"684974b0639a","Flipp",{"_key":422,"_type":72,"marks":423,"text":424},"bdea87d9953c2",[],", the term used is the ",{"_key":426,"_type":72,"marks":427,"text":428},"bdea87d9953c3",[74],"Tech Toolbox",{"_key":430,"_type":72,"marks":431,"text":432},"bdea87d9953c4",[],", and it works like this.",[434],{"_key":419,"_type":96,"href":435,"reference":12},"http://corp.flipp.com/",{"_key":437,"_type":68,"children":438,"level":208,"listItem":209,"markDefs":443,"style":77},"006de73e6ad6",[439],{"_key":440,"_type":72,"marks":441,"text":442},"006de73e6ad60",[],"The team or company curates a list of approved tech. This list should be very small.",[],{"_key":445,"_type":68,"children":446,"level":208,"listItem":209,"markDefs":451,"style":77},"5a7c88fa102f",[447],{"_key":448,"_type":72,"marks":449,"text":450},"5a7c88fa102f0",[],"The contents of the list should start with whatever the company is using at the moment.",[],{"_key":453,"_type":68,"children":454,"level":208,"listItem":209,"markDefs":491,"style":77},"28e5e0fff4ff",[455,459,463,467,471,475,479,483,487],{"_key":456,"_type":72,"marks":457,"text":458},"28e5e0fff4ff0",[],"Each tech on the list should be given an overall status of ",{"_key":460,"_type":72,"marks":461,"text":462},"28e5e0fff4ff1",[168],"approved",{"_key":464,"_type":72,"marks":465,"text":466},"28e5e0fff4ff2",[],", ",{"_key":468,"_type":72,"marks":469,"text":470},"28e5e0fff4ff3",[168],"pending approval",{"_key":472,"_type":72,"marks":473,"text":474},"28e5e0fff4ff4",[],",",{"_key":476,"_type":72,"marks":477,"text":478},"28e5e0fff4ff5",[168]," discouraged",{"_key":480,"_type":72,"marks":481,"text":482},"28e5e0fff4ff6",[],", or ",{"_key":484,"_type":72,"marks":485,"text":486},"28e5e0fff4ff7",[168],"not allowed",{"_key":488,"_type":72,"marks":489,"text":490},"28e5e0fff4ff8",[],".",[],{"_key":493,"_type":68,"children":494,"level":208,"listItem":209,"markDefs":507,"style":77},"ea9b35eb3cdc",[495,499,503],{"_key":496,"_type":72,"marks":497,"text":498},"ea9b35eb3cdc0",[],"Further, each tech should be specific as to ",{"_key":500,"_type":72,"marks":501,"text":502},"ea9b35eb3cdc1",[168],"what use cases ",{"_key":504,"_type":72,"marks":505,"text":506},"ea9b35eb3cdc2",[],"it is approved for. For example, Postgres might be approved for ad-hoc queries and internal tools, while MongoDB might be used for more performance-critical uses where the queries are well-known.",[],{"_key":509,"_type":68,"children":510,"level":208,"listItem":209,"markDefs":515,"style":77},"734833ac255b",[511],{"_key":512,"_type":72,"marks":513,"text":514},"734833ac255b0",[],"All new projects must by default use tech on this list, and all other tech is not allowed.",[],{"_key":517,"_type":68,"children":518,"level":208,"listItem":209,"markDefs":523,"style":77},"97533a671be7",[519],{"_key":520,"_type":72,"marks":521,"text":522},"97533a671be70",[],"Approved tech are given official support by internal tools and our engineering guilds. All other tech is not supported.",[],{"_key":525,"_type":68,"children":526,"markDefs":531,"style":77},"a6cb8bea61b0",[527],{"_key":528,"_type":72,"marks":529,"text":530},"a6cb8bea61b00",[],"Crucial to the success of this framework is that it should have three processes:",[],{"_key":533,"_type":68,"children":534,"level":208,"listItem":209,"markDefs":539,"style":77},"3238723f5954",[535],{"_key":536,"_type":72,"marks":537,"text":538},"3238723f59540",[],"Adding a tech to the toolbox",[],{"_key":541,"_type":68,"children":542,"level":208,"listItem":209,"markDefs":547,"style":77},"def0b3beece7",[543],{"_key":544,"_type":72,"marks":545,"text":546},"def0b3beece70",[],"Auditing and removing tech from the toolbox",[],{"_key":549,"_type":68,"children":550,"level":208,"listItem":209,"markDefs":555,"style":77},"d1b2ccf6dc34",[551],{"_key":552,"_type":72,"marks":553,"text":554},"d1b2ccf6dc340",[],"Allowing one-off exceptions to the policy",[],{"_key":557,"_type":68,"children":558,"markDefs":563,"style":77},"fa12f990905e",[559],{"_key":560,"_type":72,"marks":561,"text":562},"fa12f990905e0",[],"There should be a committee of senior, staff, or principal engineers who manage these processes. This sounds heavy-handed, but in reality, once the toolbox is set and disseminated properly, these processes happen very rarely.",[],{"_key":565,"_type":68,"children":566,"markDefs":571,"style":200},"6ade2c032f11",[567],{"_key":568,"_type":72,"marks":569,"text":570},"6ade2c032f110",[],"Adding a new tech",[],{"_key":573,"_type":68,"children":574,"markDefs":579,"style":77},"ef037f87861d",[575],{"_key":576,"_type":72,"marks":577,"text":578},"ef037f87861d0",[],"If a team feels that none of the tech in the toolbox currently solve its problem set and that a new tech could be broadly useful across the team or company, it can petition the committee to add it to the toolbox.",[],{"_key":581,"_type":68,"children":582,"markDefs":595,"style":77},"964cb9b211b4",[583,587,591],{"_key":584,"_type":72,"marks":585,"text":586},"964cb9b211b40",[],"This petition needs to be presented as a ",{"_key":588,"_type":72,"marks":589,"text":590},"964cb9b211b41",[168],"business case",{"_key":592,"_type":72,"marks":593,"text":594},"964cb9b211b42",[],". This doesn't mean that the team needs to do research with actual dollars attached to it. They need to be able to argue one or more of the following:",[],{"_key":597,"_type":68,"children":598,"level":208,"listItem":209,"markDefs":611,"style":77},"422b27c2eccc",[599,603,607],{"_key":600,"_type":72,"marks":601,"text":602},"422b27c2eccc0",[],"The tech allows us to significantly reduce ",{"_key":604,"_type":72,"marks":605,"text":606},"422b27c2eccc1",[168],"infrastructure cost",{"_key":608,"_type":72,"marks":609,"text":610},"422b27c2eccc2",[]," by being more performant.",[],{"_key":613,"_type":68,"children":614,"level":208,"listItem":209,"markDefs":635,"style":77},"32887e0a9400",[615,619,623,627,631],{"_key":616,"_type":72,"marks":617,"text":618},"32887e0a94000",[],"The tech allows us to reduce ",{"_key":620,"_type":72,"marks":621,"text":622},"32887e0a94001",[168],"engineering costs",{"_key":624,"_type":72,"marks":625,"text":626},"32887e0a94002",[]," and ",{"_key":628,"_type":72,"marks":629,"text":630},"32887e0a94003",[168],"go to market faster ",{"_key":632,"_type":72,"marks":633,"text":634},"32887e0a94004",[],"by making it significantly faster to develop with.",[],{"_key":637,"_type":68,"children":638,"level":208,"listItem":209,"markDefs":651,"style":77},"9348af24b44c",[639,643,647],{"_key":640,"_type":72,"marks":641,"text":642},"9348af24b44c0",[],"The tech saves on ",{"_key":644,"_type":72,"marks":645,"text":646},"9348af24b44c1",[168],"testing and quality costs",{"_key":648,"_type":72,"marks":649,"text":650},"9348af24b44c2",[]," by reducing errors.",[],{"_key":653,"_type":68,"children":654,"level":208,"listItem":209,"markDefs":667,"style":77},"a9a62761aec2",[655,659,663],{"_key":656,"_type":72,"marks":657,"text":658},"a9a62761aec20",[],"The tech ",{"_key":660,"_type":72,"marks":661,"text":662},"a9a62761aec21",[168],"increases morale",{"_key":664,"_type":72,"marks":665,"text":666},"a9a62761aec22",[]," by providing a less stressful development environment. (This could be a broad category).",[],{"_key":669,"_type":68,"children":670,"markDefs":675,"style":77},"5437232d649d",[671],{"_key":672,"_type":72,"marks":673,"text":674},"5437232d649d0",[],"Generally, there should be some kind of data attached to this. In the latter point, it might simply be surveys of the engineers on the team.",[],{"_key":677,"_type":68,"children":678,"markDefs":697,"style":77},"aa5633225410",[679,683,686,690,693],{"_key":680,"_type":72,"marks":681,"text":682},"aa56332254100",[],"Once the committee is satisfied, the tech is considered ",{"_key":684,"_type":72,"marks":685,"text":470},"aa56332254101",[168],{"_key":687,"_type":72,"marks":688,"text":689},"aa56332254102",[],". The requesting team should proceed with a proof-of-concept implementation of the new tech so that any kinks or surprises can be ironed out. Once this is deemed a success, the tech can be ",{"_key":691,"_type":72,"marks":692,"text":462},"aa56332254103",[168],{"_key":694,"_type":72,"marks":695,"text":696},"aa56332254104",[]," in the toolbox.",[],{"_key":699,"_type":68,"children":700,"markDefs":705,"style":77},"21f480302bca",[701],{"_key":702,"_type":72,"marks":703,"text":704},"21f480302bca0",[],"If the tech fails the process, that doesn't mean the proposal is dead in the water! Proposals can always be revisited if there is new information or use cases. And the proposing team always has the option of using it for one-offs (see below).",[],{"_key":707,"_type":68,"children":708,"markDefs":713,"style":200},"e9039f201552",[709],{"_key":710,"_type":72,"marks":711,"text":712},"e9039f2015520",[],"Auditing and removing tech",[],{"_key":715,"_type":68,"children":716,"markDefs":721,"style":77},"710a33886411",[717],{"_key":718,"_type":72,"marks":719,"text":720},"710a338864110",[],"Periodically, the committee should speak to the engineers who manage the systems they own and see if a particular tech has fallen out of favor, and if so, why. Sometimes a new tech entirely supplants an older one and is deemed unwise to use since the new one is better in most respects for the use case in question.",[],{"_key":723,"_type":68,"children":724,"markDefs":737,"style":77},"3b2c85491004",[725,729,733],{"_key":726,"_type":72,"marks":727,"text":728},"3b2c854910040",[],"If the committee and engineers agree, the tech in question then becomes demoted to ",{"_key":730,"_type":72,"marks":731,"text":732},"3b2c854910041",[168],"discouraged",{"_key":734,"_type":72,"marks":735,"text":736},"3b2c854910042",[],". This means that no new projects should be built with it, and all existing projects using it should have some kind of plan to move off of it if possible.",[],{"_key":739,"_type":68,"children":740,"markDefs":752,"style":77},"54a6c9205b66",[741,745,748],{"_key":742,"_type":72,"marks":743,"text":744},"54a6c9205b660",[],"Once as many services as possible have moved off it, the tech can be moved to ",{"_key":746,"_type":72,"marks":747,"text":486},"54a6c9205b661",[168],{"_key":749,"_type":72,"marks":750,"text":751},"54a6c9205b662",[],". There can be legacy systems using the old tech that are grandfathered in and allowed to stay, but these are \"special cases\" and don't affect the overall status of the tech in the toolbox.",[],{"_key":754,"_type":68,"children":755,"markDefs":760,"style":200},"3f992bb18221",[756],{"_key":757,"_type":72,"marks":758,"text":759},"3f992bb182210",[],"One-off exceptions",[],{"_key":762,"_type":68,"children":763,"markDefs":768,"style":77},"974588380ba1",[764],{"_key":765,"_type":72,"marks":766,"text":767},"974588380ba10",[],"No one likes working for tyrants, and the tech leadership committee is no different. There are always cases where a tech that didn't make the cut or is marked as discouraged still needs to be used.",[],{"_key":770,"_type":68,"children":771,"markDefs":776,"style":77},"a32147e429ed",[772],{"_key":773,"_type":72,"marks":774,"text":775},"a32147e429ed0",[],"At Flipp, we moved Node.js from approved to discouraged for our end user-facing systems, and effectively replaced it with Go. However, we identified that there are some cases that Go is not well suited for—data munging arbitrary JSON files, for example, or using third-party SDKs that often are better maintained in JavaScript. These projects were able to argue their case and got a pass, with the caveat that these teams were on their own for support and tooling.",[],{"_key":778,"_type":68,"children":779,"markDefs":784,"style":183},"6990d1707d80",[780],{"_key":781,"_type":72,"marks":782,"text":783},"6990d1707d800",[],"The result",[],{"_key":786,"_type":68,"children":787,"markDefs":792,"style":77},"060a2859ace3",[788],{"_key":789,"_type":72,"marks":790,"text":791},"060a2859ace30",[],"With a tech toolbox, we have a single central document we can point to explaining what we use at Flipp and why. We have a \"paved road\" to make it easier to create projects using this technology, such as an app generator, shared libraries, deployment support, and more. We have guilds that meet regularly and take on projects to improve the usage and documentation for how we use that tech within the company. And we have an explicit process to make changes to this list so engineers don't feel disenfranchised.",[],{"_key":794,"_type":68,"children":795,"markDefs":800,"style":77},"c0d29b06cfbc",[796],{"_key":797,"_type":72,"marks":798,"text":799},"c0d29b06cfbc0",[],"As your company grows, technology decisions become more costly. Having a framework like this in place will provide a defined path forward.",[],true,"2023/03/23","Do you solve new problems the same way because it's already done? Or do you go with a new approach that offers more benefits?",{"_type":56,"asset":805},{"_ref":806,"_type":59},"image-e73d1d45977f5166f08c446fe4dfc7e9811732fb-2560x1344-jpg",{"code":808,"language":809},"\u003C!-- wp:paragraph -->\n\u003Cp>\u003Cem>Thanks to David Meyers, Principal Engineer at Flipp, for introducing me to this concept, normalizing it, and implementing it flawlessly.\u003C/em>\u003C/p>\n\u003C!-- /wp:paragraph -->\n\n\u003C!-- wp:paragraph -->\n\u003Cp>Raw startups are often chaotic and scattered. \"Move fast and break things!\" was repeated in the standups of hundreds of startup engineering orgs. Typically, startups tend to build monolithic systems to reduce friction in creating and changing features. As time goes on, the monolithic architecture begins to show strain, and \u003Ca href=\"https://m.signalvnoise.com/the-majestic-monolith/\">almost\u003C/a> inevitably begins to be broken up. \u003C/p>\n\u003C!-- /wp:paragraph -->\n\n\u003C!-- wp:paragraph -->\n\u003Cp>Teams begin to take ownership of the new services, usually adhering to \u003Ca href=\"https://en.wikipedia.org/wiki/Conway%27s_law\">Conway's Law\u003C/a>. Since each service is only owned by a single team (or should be), questions inevitably arise related to the technologies used for each of them.\u003C/p>\n\u003C!-- /wp:paragraph -->\n\n\u003C!-- wp:paragraph -->\n\u003Cp>Should the backend administrative system, used by a dozen internal employees, be written using the same frameworks and stack as the tight, performance-critical end-user system? Should batch processors have the same technical footprint as stream processors? Should analytics databases use the same solution as the one used for ad-hoc queries?\u003C/p>\n\u003C!-- /wp:paragraph -->\n\n\u003C!-- wp:paragraph -->\n\u003Cp>Some engineers love to experiment with new, bleeding-edge technologies. Others warn of the perils and demand adherence to the tried-and-true. As the company grows ever bigger, the same sorts of problems emerge over and over again to be solved. Do you solve those problems the same way you did earlier because it's already done? Or do you go with a new approach that offers more benefits?\u003C/p>\n\u003C!-- /wp:paragraph -->\n\n\u003C!-- wp:paragraph -->\n\u003Cp>How these problems get solved becomes more critical as a startup transitions to a medium-sized company.\u003C/p>\n\u003C!-- /wp:paragraph -->\n\n\u003C!-- wp:heading {\"level\":1} -->\n\u003Ch1 id=\"h-terminology\">Terminology\u003C/h1>\n\u003C!-- /wp:heading -->\n\n\u003C!-- wp:paragraph -->\n\u003Cp>This article discusses all kinds of \u003Cem>technology\u003C/em> from a software engineering perspective. This can include programming languages, frameworks, database systems, ways to store and transfer files, schema definition systems, etc. I will use the word \u003Cstrong>tech\u003C/strong> as a shortcut to describe this list of solutions, systems, and projects.\u003C/p>\n\u003C!-- /wp:paragraph -->\n\n\u003C!-- wp:heading -->\n\u003Ch2 id=\"h-option-1-the-wild-west\">Option 1: The Wild West\u003C/h2>\n\u003C!-- /wp:heading -->\n\n\u003C!-- wp:paragraph -->\n\u003Cp>At one extreme, we could simply allow every team to choose whatever tech they wanted to use with full autonomy. There's no oversight committee, no red tape, and no blockers to doing what they want how they want.\u003C/p>\n\u003C!-- /wp:paragraph -->\n\n\u003C!-- wp:heading {\"level\":3} -->\n\u003Ch3 id=\"h-the-benefits\">The benefits\u003C/h3>\n\u003C!-- /wp:heading -->\n\n\u003C!-- wp:list -->\n\u003Cul>\u003C!-- wp:list-item -->\n\u003Cli>Teams are empowered to make their own technology decisions based on the information they have.\u003C/li>\n\u003C!-- /wp:list-item -->\n\n\u003C!-- wp:list-item -->\n\u003Cli>The \"best\" tech for the problem being solved can be used.\u003C/li>\n\u003C!-- /wp:list-item -->\n\n\u003C!-- wp:list-item -->\n\u003Cli>Teams are not tied down by previous technical decisions made either by themselves or other teams.\u003C/li>\n\u003C!-- /wp:list-item -->\n\n\u003C!-- wp:list-item -->\n\u003Cli>Morale is high since engineers get to use new, fun tech rather than being stuck with old or out-of-style choices.\u003C/li>\n\u003C!-- /wp:list-item -->\n\n\u003C!-- wp:list-item -->\n\u003Cli>Engineers feel that their voices matter in technology decisions.\u003C/li>\n\u003C!-- /wp:list-item -->\u003C/ul>\n\u003C!-- /wp:list -->\n\n\u003C!-- wp:heading {\"level\":3} -->\n\u003Ch3 id=\"h-the-downsides\">The downsides\u003C/h3>\n\u003C!-- /wp:heading -->\n\n\u003C!-- wp:list -->\n\u003Cul>\u003C!-- wp:list-item -->\n\u003Cli>It is more difficult to reuse previous solutions written in other languages or frameworks.\u003C/li>\n\u003C!-- /wp:list-item -->\n\n\u003C!-- wp:list-item -->\n\u003Cli>It is harder to generalize solutions across similar problems since reuse is harder.\u003C/li>\n\u003C!-- /wp:list-item -->\n\n\u003C!-- wp:list-item -->\n\u003Cli>There is risk of \"technology sprawl\": a single engineer has to know multiple technologies in order to succeed at their job.\u003C/li>\n\u003C!-- /wp:list-item -->\n\n\u003C!-- wp:list-item -->\n\u003Cli>This can result in superficial broad knowledge of languages or systems rather than deep knowledge of one tech, which can affect the ability to debug problems or make more advanced changes.\u003C/li>\n\u003C!-- /wp:list-item -->\n\n\u003C!-- wp:list-item -->\n\u003Cli>Hiring and internal training becomes more onerous. Either the company has to hire engineers who already know the full set of tech or spend more time training them once they are hired.\u003C/li>\n\u003C!-- /wp:list-item -->\n\n\u003C!-- wp:list-item -->\n\u003Cli>Internal support becomes more fractured since there will be fewer experts in any one tech to help less experienced developers.\u003C/li>\n\u003C!-- /wp:list-item -->\n\n\u003C!-- wp:list-item -->\n\u003Cli>Building internal tools may become more difficult since it has to work with all the tech that the team (or company) supports.\u003C/li>\n\u003C!-- /wp:list-item -->\u003C/ul>\n\u003C!-- /wp:list -->\n\n\u003C!-- wp:heading -->\n\u003Ch2 id=\"h-option-2-lock-it-down\">Option 2: Lock it down\u003C/h2>\n\u003C!-- /wp:heading -->\n\n\u003C!-- wp:paragraph -->\n\u003Cp>At the other extreme, whatever choice was made at the company's inception becomes the one and only solution that must be used. If the first application was made using Python and Postgres, then every service must use only Python and Postgres.\u003C/p>\n\u003C!-- /wp:paragraph -->\n\n\u003C!-- wp:paragraph -->\n\u003Cp>The advantages and disadvantages are swapped here.\u003C/p>\n\u003C!-- /wp:paragraph -->\n\n\u003C!-- wp:heading {\"level\":3} -->\n\u003Ch3 id=\"h-the-benefits-1\">The benefits\u003C/h3>\n\u003C!-- /wp:heading -->\n\n\u003C!-- wp:list -->\n\u003Cul>\u003C!-- wp:list-item -->\n\u003Cli>Reusing previous solutions and generalizing them becomes much easier since you are guaranteed to use the same tech stack.\u003C/li>\n\u003C!-- /wp:list-item -->\n\n\u003C!-- wp:list-item -->\n\u003Cli>Each engineer can be trained on a single stack and can more easily learn deep knowledge about it, and therefore help support other engineers.\u003C/li>\n\u003C!-- /wp:list-item -->\n\n\u003C!-- wp:list-item -->\n\u003Cli>Hiring is easier since only one set of skills is necessary.\u003C/li>\n\u003C!-- /wp:list-item -->\n\n\u003C!-- wp:list-item -->\n\u003Cli>Internal tools are simpler since they only have to deal with one set of tech.\u003C/li>\n\u003C!-- /wp:list-item -->\u003C/ul>\n\u003C!-- /wp:list -->\n\n\u003C!-- wp:heading {\"level\":3} -->\n\u003Ch3 id=\"h-the-downsides-1\">The downsides\u003C/h3>\n\u003C!-- /wp:heading -->\n\n\u003C!-- wp:list -->\n\u003Cul>\u003C!-- wp:list-item -->\n\u003Cli>Engineers become demoralized since they feel stuck with old tech that may not be well suited to the problem at hand.\u003C/li>\n\u003C!-- /wp:list-item -->\n\n\u003C!-- wp:list-item -->\n\u003Cli>Trying to squeeze a tech into solving a problem it isn't designed for can result in increasingly hacky and costly kludges.\u003C/li>\n\u003C!-- /wp:list-item -->\n\n\u003C!-- wp:list-item -->\n\u003Cli>Engineers do not feel empowered since they have no agency to make technological decisions.\u003C/li>\n\u003C!-- /wp:list-item -->\u003C/ul>\n\u003C!-- /wp:list -->\n\n\u003C!-- wp:heading -->\n\u003Ch2 id=\"h-the-golden-mean\">The golden mean\u003C/h2>\n\u003C!-- /wp:heading -->\n\n\u003C!-- wp:paragraph -->\n\u003Cp>As you can guess, the \"right path\" is somewhere in the middle of these extremes. At \u003Ca href=\"http://corp.flipp.com/\">Flipp\u003C/a>, the term used is the \u003Cem>Tech Toolbox\u003C/em>, and it works like this.\u003C/p>\n\u003C!-- /wp:paragraph -->\n\n\u003C!-- wp:list -->\n\u003Cul>\u003C!-- wp:list-item -->\n\u003Cli>The team or company curates a list of approved tech. This list should be very small.\u003C/li>\n\u003C!-- /wp:list-item -->\n\n\u003C!-- wp:list-item -->\n\u003Cli>The contents of the list should start with whatever the company is using at the moment.\u003C/li>\n\u003C!-- /wp:list-item -->\n\n\u003C!-- wp:list-item -->\n\u003Cli>Each tech on the list should be given an overall status of \u003Cstrong>approved\u003C/strong>, \u003Cstrong>pending approval\u003C/strong>,\u003Cstrong> discouraged\u003C/strong>, or \u003Cstrong>not allowed\u003C/strong>.\u003C/li>\n\u003C!-- /wp:list-item -->\n\n\u003C!-- wp:list-item -->\n\u003Cli>Further, each tech should be specific as to \u003Cstrong>what use cases \u003C/strong>it is approved for. For example, Postgres might be approved for ad-hoc queries and internal tools, while MongoDB might be used for more performance-critical uses where the queries are well-known.\u003C/li>\n\u003C!-- /wp:list-item -->\n\n\u003C!-- wp:list-item -->\n\u003Cli>All new projects must by default use tech on this list, and all other tech is not allowed.\u003C/li>\n\u003C!-- /wp:list-item -->\n\n\u003C!-- wp:list-item -->\n\u003Cli>Approved tech are given official support by internal tools and our engineering guilds. All other tech is not supported.\u003C/li>\n\u003C!-- /wp:list-item -->\u003C/ul>\n\u003C!-- /wp:list -->\n\n\u003C!-- wp:paragraph -->\n\u003Cp>Crucial to the success of this framework is that it should have three processes:\u003C/p>\n\u003C!-- /wp:paragraph -->\n\n\u003C!-- wp:list -->\n\u003Cul>\u003C!-- wp:list-item -->\n\u003Cli>Adding a tech to the toolbox\u003C/li>\n\u003C!-- /wp:list-item -->\n\n\u003C!-- wp:list-item -->\n\u003Cli>Auditing and removing tech from the toolbox\u003C/li>\n\u003C!-- /wp:list-item -->\n\n\u003C!-- wp:list-item -->\n\u003Cli>Allowing one-off exceptions to the policy\u003C/li>\n\u003C!-- /wp:list-item -->\u003C/ul>\n\u003C!-- /wp:list -->\n\n\u003C!-- wp:paragraph -->\n\u003Cp>There should be a committee of senior, staff, or principal engineers who manage these processes. This sounds heavy-handed, but in reality, once the toolbox is set and disseminated properly, these processes happen very rarely.\u003C/p>\n\u003C!-- /wp:paragraph -->\n\n\u003C!-- wp:heading {\"level\":3} -->\n\u003Ch3 id=\"h-adding-a-new-tech\">Adding a new tech\u003C/h3>\n\u003C!-- /wp:heading -->\n\n\u003C!-- wp:paragraph -->\n\u003Cp>If a team feels that none of the tech in the toolbox currently solve its problem set and that a new tech could be broadly useful across the team or company, it can petition the committee to add it to the toolbox.\u003C/p>\n\u003C!-- /wp:paragraph -->\n\n\u003C!-- wp:paragraph -->\n\u003Cp>This petition needs to be presented as a \u003Cstrong>business case\u003C/strong>. This doesn't mean that the team needs to do research with actual dollars attached to it. They need to be able to argue one or more of the following:\u003C/p>\n\u003C!-- /wp:paragraph -->\n\n\u003C!-- wp:list -->\n\u003Cul>\u003C!-- wp:list-item -->\n\u003Cli>The tech allows us to significantly reduce \u003Cstrong>infrastructure cost\u003C/strong> by being more performant.\u003C/li>\n\u003C!-- /wp:list-item -->\n\n\u003C!-- wp:list-item -->\n\u003Cli>The tech allows us to reduce \u003Cstrong>engineering costs\u003C/strong> and \u003Cstrong>go to market faster \u003C/strong>by making it significantly faster to develop with.\u003C/li>\n\u003C!-- /wp:list-item -->\n\n\u003C!-- wp:list-item -->\n\u003Cli>The tech saves on \u003Cstrong>testing and quality costs\u003C/strong> by reducing errors.\u003C/li>\n\u003C!-- /wp:list-item -->\n\n\u003C!-- wp:list-item -->\n\u003Cli>The tech \u003Cstrong>increases morale\u003C/strong> by providing a less stressful development environment. (This could be a broad category).\u003C/li>\n\u003C!-- /wp:list-item -->\u003C/ul>\n\u003C!-- /wp:list -->\n\n\u003C!-- wp:paragraph -->\n\u003Cp>Generally, there should be some kind of data attached to this. In the latter point, it might simply be surveys of the engineers on the team.\u003C/p>\n\u003C!-- /wp:paragraph -->\n\n\u003C!-- wp:paragraph -->\n\u003Cp>Once the committee is satisfied, the tech is considered \u003Cstrong>pending approval\u003C/strong>. The requesting team should proceed with a proof-of-concept implementation of the new tech so that any kinks or surprises can be ironed out. Once this is deemed a success, the tech can be \u003Cstrong>approved\u003C/strong> in the toolbox.\u003C/p>\n\u003C!-- /wp:paragraph -->\n\n\u003C!-- wp:paragraph -->\n\u003Cp>If the tech fails the process, that doesn't mean the proposal is dead in the water! Proposals can always be revisited if there is new information or use cases. And the proposing team always has the option of using it for one-offs (see below).\u003C/p>\n\u003C!-- /wp:paragraph -->\n\n\u003C!-- wp:heading {\"level\":3} -->\n\u003Ch3 id=\"h-auditing-and-removing-tech\">Auditing and removing tech\u003C/h3>\n\u003C!-- /wp:heading -->\n\n\u003C!-- wp:paragraph -->\n\u003Cp>Periodically, the committee should speak to the engineers who manage the systems they own and see if a particular tech has fallen out of favor, and if so, why. Sometimes a new tech entirely supplants an older one and is deemed unwise to use since the new one is better in most respects for the use case in question.\u003C/p>\n\u003C!-- /wp:paragraph -->\n\n\u003C!-- wp:paragraph -->\n\u003Cp>If the committee and engineers agree, the tech in question then becomes demoted to \u003Cstrong>discouraged\u003C/strong>. This means that no new projects should be built with it, and all existing projects using it should have some kind of plan to move off of it if possible.\u003C/p>\n\u003C!-- /wp:paragraph -->\n\n\u003C!-- wp:paragraph -->\n\u003Cp>Once as many services as possible have moved off it, the tech can be moved to \u003Cstrong>not allowed\u003C/strong>. There can be legacy systems using the old tech that are grandfathered in and allowed to stay, but these are \"special cases\" and don't affect the overall status of the tech in the toolbox.\u003C/p>\n\u003C!-- /wp:paragraph -->\n\n\u003C!-- wp:heading {\"level\":3} -->\n\u003Ch3 id=\"h-one-off-exceptions\">One-off exceptions\u003C/h3>\n\u003C!-- /wp:heading -->\n\n\u003C!-- wp:paragraph -->\n\u003Cp>No one likes working for tyrants, and the tech leadership committee is no different. There are always cases where a tech that didn't make the cut or is marked as discouraged still needs to be used.\u003C/p>\n\u003C!-- /wp:paragraph -->\n\n\u003C!-- wp:paragraph -->\n\u003Cp>At Flipp, we moved Node.js from approved to discouraged for our end user-facing systems, and effectively replaced it with Go. However, we identified that there are some cases that Go is not well suited for—data munging arbitrary JSON files, for example, or using third-party SDKs that  often are better maintained in JavaScript. These projects were able to argue their case and got a pass, with the caveat that these teams were on their own for support and tooling.\u003C/p>\n\u003C!-- /wp:paragraph -->\n\n\u003C!-- wp:heading -->\n\u003Ch2 id=\"h-the-result\">The result\u003C/h2>\n\u003C!-- /wp:heading -->\n\n\u003C!-- wp:paragraph -->\n\u003Cp>With a tech toolbox, we have a single central document we can point to explaining what we use at Flipp and why. We have a \"paved road\" to make it easier to create projects using this technology, such as an app generator, shared libraries, deployment support, and more. We have guilds that meet regularly and take on projects to improve the usage and documentation for how we use that tech within the company. And we have an explicit process to make changes to this list so engineers don't feel disenfranchised.\u003C/p>\n\u003C!-- /wp:paragraph -->\n\n\u003C!-- wp:paragraph -->\n\u003Cp>As your company grows, technology decisions become more costly. Having a framework like this in place will provide a defined path forward.\u003C/p>\n\u003C!-- /wp:paragraph -->","html","2023-03-23T14:00:00.000Z",{"current":812},"your-tech-toolbox-the-middle-ground-between-tech-chaos-and-rigidity",[814,822,827,832],{"_createdAt":815,"_id":816,"_rev":817,"_type":818,"_updatedAt":815,"slug":819,"title":821},"2023-05-23T16:43:21Z","wp-tagcat-code-for-a-living","9HpbCsT2tq0xwozQfkc4ih","blogTag",{"current":820},"code-for-a-living","Code for a Living",{"_createdAt":815,"_id":823,"_rev":817,"_type":818,"_updatedAt":815,"slug":824,"title":826},"wp-tagcat-software-development",{"current":825},"software-development","software development",{"_createdAt":815,"_id":828,"_rev":817,"_type":818,"_updatedAt":815,"slug":829,"title":831},"wp-tagcat-tech-stack",{"current":830},"tech-stack","tech stack",{"_createdAt":833,"_id":834,"_rev":835,"_type":818,"_updatedAt":836,"description":837,"slug":846,"title":848},"2024-09-12T10:47:51Z","1dc92c86-0099-46d4-ba5b-41e5697d43c0","6PK1Gm0YEnAcvtXN32g6bL","2024-09-17T14:27:36Z",[838],{"_key":839,"_type":68,"children":840,"markDefs":845,"style":77},"1ddad854068f",[841],{"_key":842,"_type":72,"marks":843,"text":844},"312bffce4f510",[],"Articles on business, SaaS, and the software that powers organizations.",[],{"_type":10,"current":847},"business","Business Hub","Your tech toolbox: The middle ground between tech chaos and rigidity",[851,857,863,869],{"_id":852,"publishedAt":853,"slug":854,"sponsored":12,"title":856},"28e560af-f0aa-4d46-bd90-f435ad604aa7","2026-06-26T14:00:27.102Z",{"_type":10,"current":855},"paging-charity-how-can-engineering-leaders-avoid-becoming-bond-villains","Paging Charity! How can engineering leaders avoid becoming Bond villains?",{"_id":858,"publishedAt":859,"slug":860,"sponsored":12,"title":862},"4b22c2a3-3779-4966-93eb-5230391dbdce","2026-06-23T14:08:58.595Z",{"_type":10,"current":861},"your-ai-shipped-a-backend-that-boots-that-is-the-whole-problem","Your AI shipped a backend that boots. That is the whole problem.",{"_id":864,"publishedAt":865,"slug":866,"sponsored":12,"title":868},"5cf362e1-fe7b-45af-b69c-914731c6a052","2026-06-23T14:00:00.000Z",{"_type":10,"current":867},"the-2026-developer-survey-is-now-open-for-human-developers-only","The 2026 Developer Survey is now open (for human developers only)!",{"_id":870,"publishedAt":871,"slug":872,"sponsored":12,"title":874},"30b995f7-7cb9-4dd8-bf71-d0685940a32b","2026-06-19T14:00:00.000Z",{"_type":10,"current":873},"dispatches-from-o-reilly-from-capabilities-to-responsibilities","Dispatches from O'Reilly: From capabilities to responsibilities",{"data":876,"sourceMap":-1},{"count":877,"lastTimestamp":878},5,"2024-01-18T17:02:57Z"]