## Sources 1. [TBM 419: Stop Being So Negative! Stop Being So Naive!](https://cutlefish.substack.com/p/tbm-419-stop-being-so-negative-stop) 2. [WTF is a Software Moat in 2026?](https://joereis.substack.com/p/wtf-is-a-software-moat-in-2026) 3. [The quality of a data product is its data and its code](https://andrewrjones.substack.com/p/the-quality-of-a-data-product-is) 4. [A Two-Week Sprint for Knowledge](https://jessicatalisman.substack.com/p/a-two-week-sprint-for-knowledge) 5. [TBM 418: Campfires, Trails, and Quests](https://cutlefish.substack.com/p/tbm-418-campfires-trails-and-quests) 6. [I’m at SFO waiting for my flight - Ask me anything](https://joereis.substack.com/p/im-at-sfo-waiting-for-my-flight-ask) --- ### A Two-Week Sprint for Knowledge - by Jessica Talisman, MLS * **Agile Methodology vs. Knowledge Work:** The author argues that **Agile and Scrum methodologies are ill-suited for knowledge work, semantic systems, and AI** [1]. Scrum was built for manufacturing and software engineering with discrete, additive parts (the Third Industrial Revolution), while modern knowledge problems (the Fourth Industrial Revolution) are messy and recursive [2-5]. * **Knowledge Organization as a "Wicked Problem":** Building semantic architectures, like taxonomies and ontologies, involves "wicked problems" where the requirements constantly change as the work is done, lacking definitive formulations or stopping rules [6, 7]. You cannot "ship half a taxonomy" because it requires complete logical coherence and precise vocabulary control to function [3, 8]. * **The Faux-Agile Illusion:** Organizations often force knowledge workers to use Agile rituals, leading to "faux-agile" environments [9]. This results in fractured ontologies, orphan classes, and hallucinating AI systems, even as burndown charts look falsely perfect [10-12]. * **Design Thinking as the Solution:** **Design thinking is proposed as the proper framework for knowledge work** because it embraces ambiguity, iteration, and continuous problem discovery [13, 14]. It operates in what Donald Schön called the "swampy lowland," focusing on reflection-in-action rather than rigid, two-week sprint deadlines [15]. * **AI Needs a Semantic Layer to Become a Knowledge Tool:** Large Language Models (LLMs) are merely information-processing tools that stitch together linguistic patterns without understanding meaning [16]. **For AI to become a true knowledge tool, it must be grounded in a semantic layer** (controlled vocabularies, taxonomies, ontologies) that provides provenance and descriptive logic [17, 18]. ### I'm at SFO waiting for my flight - Ask me anything - by Joe Reis * **Spontaneous Airport AMA:** This source is a transcript of a live, spontaneous "Ask Me Anything" video hosted by Joe Reis while waiting on the tarmac at San Francisco International Airport [19]. * **Data Engineering Community Events:** Reis mentions he was in San Francisco for "Confluent's Undercurrent," an intimate data engineering event he worked on alongside Confluent [20]. * **Notable Industry Figures:** He highlights that the event featured prominent industry figures, including Maxime Beauchemin, the creator of Apache Airflow and Preset/Superset [20]. * **Future Content Planning:** During the stream, Reis notes that he plans to work on his upcoming "Freestyle Friday" podcast topic while on his flight [20]. ### TBM 418: Campfires, Trails, and Quests - by John Cutler * **Multiplayer vs. Single-Player AI:** Cutler contrasts collaborative ("multiplayer") AI usage with isolated ("single-player") AI [21, 22]. **Multiplayer AI leads to evolving context and shared understanding**, whereas single-player AI curates a narrow, isolated context that lacks diverse perspectives [21, 22]. * **The 4Es of Cognitive Science:** Effective AI collaboration is explained using the 4Es: **Embedded** (reasoning within a shared environment), **Enacted** (understanding through active doing and reshaping), **Extended** (knowledge held in the environment), and **Embodied** (the back-and-forth iteration of different perspectives) [22, 23]. * **The Power of Stigmergy:** The concept of "stigmergy" is highlighted, which involves leaving knowledge traces for others to build upon asynchronously, much like Wikipedia editors [24]. AI can help create these rich traces [25]. * **Campfires, Trails, and Quests:** Cutler uses a powerful metaphor for teamwork: **Trails** are the traces left behind (context pointers, docs), **Quests** are purposeful work done between meetings, and **Campfires** are the moments teams convene to reshape beliefs and collaborate [26, 27]. * **AI as a Collaboration Enhancer:** Instead of replacing human interaction, **AI should be woven into every phase of collaboration to make individual preparation sharper, documentation richer, and team meetings higher-leverage** [25, 28]. ### TBM 419: Stop Being So Negative! Stop Being So Naive! - by John Cutler * **Two Kinds of Optimism:** Cutler identifies a fundamental tension in teams between **"Outcome optimism"** (the belief that "we'll get there," which protects morale) and **"Capability optimism"** (the belief that "we can figure this out," which protects the quality of the plan by stress-testing risks) [29]. * **Systemic Punishment of Capability Optimism:** Workplaces and organizations structurally reward outcome optimism but often unfairly brand capability optimism as "negativity," "naysaying," or doubt [30, 31]. This branding can also be exacerbated by gender dynamics, where women asking hard questions are disproportionately perceived as negative [32]. * **Base-Camp Mode vs. Climbing Mode:** To resolve this tension, **teams must explicitly sequence their modes of work** [33]. "Base-camp mode" is the time for rigorous debate, naming risks, and challenging assumptions, while "climbing mode" is reserved for commitment, execution, and moving forward [34]. * **The Danger of Weaponized Conflict:** Both forms of optimism can be weaponized. Critical thinkers might use skepticism to avoid committing to a plan or to perform rigor without offering solutions [35, 36]. Conversely, outcome optimists might use positivity to advocate for their own agenda and avoid facing reality [37]. * **Earned Confidence:** True competence requires linking the identification of a problem to a constructive response [36]. **Professionals must seek earned confidence by honestly looking at reality before committing to a path**, ensuring their critique serves the team rather than their ego [38]. ### The quality of a data product is its data and its code - by Andrew Jones * **Redefining Data Product Quality:** Jones argues that tracking a data product's quality solely through traditional data metrics (like accuracy, completeness, and validity) or operational SLOs is insufficient because those metrics are merely reactive [39, 40]. * **Monitoring Code Quality:** **To ensure true reliability, organizations must also actively monitor the code quality behind their data products** (e.g., dbt pipelines, Spark jobs, and Python workflows) [40, 41]. * **Preventing Issues Proactively:** By tracking code quality, teams can detect technical debt, security vulnerabilities, and maintainability flaws *before* they cause production failures or data corruption [42]. * **Utilizing Service Catalogs:** Borrowing from software engineering practices, Jones recommends **using service catalogs to track the software health of data repositories** [41, 42]. This includes checking for updated dependencies, correctly configured CI jobs, and thorough documentation [41]. * **Industry Insights:** The newsletter also curates industry insights, noting that building effective LLM platforms requires leveraging existing robust platform capabilities, and emphasizing that data professionals are ultimately building "decision systems" rather than just data systems [43, 44]. ### WTF is a Software Moat in 2026? - Joe Reis * **The Death of Traditional Software Moats:** Historical competitive advantages—like massive engineering teams, fast feature velocity, and great UX—are no longer moats because **AI coding agents have dropped the cost and barrier of shipping code to near-zero** [45, 46]. * **Thin Wrappers are Not Defensible:** Building a UI "duct-taped" around a public foundation model (like Claude or GPT) provides no longevity [47]. These products act as unpaid R&D for large AI companies, whose next update will simply absorb the startup's specific workflow [47]. * **Systems of Record as Moats:** **Defensibility now exists where there is high friction, such as deeply embedded infrastructure and systems of record** [46, 48]. Technologies like Postgres, DuckDB, SAP, or Oracle are incredibly sticky because businesses struggle immensely to migrate away from them [48]. * **Proprietary Data as a Moat:** Having unique, clean telemetry and private data that hyperscalers lack is a major competitive advantage [49]. Because LLMs will "query garbage" if data architecture is poor, **fixing data models is a fundamental business survival tactic** [49]. * **Deep Expertise and Brand as Moats:** AI can aggregate knowledge, but it cannot invent net-new frameworks from lived experience [50]. Therefore, **personal reputation, deep expertise, trust, and brand distribution remain highly defensible moats** [50].