## Sources

1. [TBM 417: Before You Fire All Your Glue People Because of AI](https://cutlefish.substack.com/p/tbm-417-before-you-fire-all-your)
2. [We're in 1905: Why Electricity (Not Dot-Com) Is the Right AI Analogy](https://joereis.substack.com/p/were-in-1905-why-electricity-not)
3. [The data reliability question you're avoiding](https://andrewrjones.substack.com/p/the-data-reliability-question-youre)
4. [TBM 416: Investment Stewardship (As Habit)](https://cutlefish.substack.com/p/tbm-416-investment-stewardship-as)
5. [AI Is Here, But The Hard Parts Haven't Changed](https://joereis.substack.com/p/ai-is-here-but-the-hard-parts-havent)
6. [What does it mean to take responsibility?](https://andrewrjones.substack.com/p/what-does-it-mean-to-take-responsibility)

---

### "AI Is Here, But The Hard Parts Haven't Changed" by Joe Reis

*   **Main Argument:** While AI adoption in data engineering has become nearly universal, the technology has not solved the fundamental, difficult challenges of the discipline, such as data modeling, semantics, and architectural patterns [1-3].
*   **Key Takeaways on AI Adoption and Impact:** 
    *   AI tools are now a standard part of the daily toolkit, with 82% of respondents in a larger survey reporting daily or more frequent use, and only one respondent in the pulse survey reporting no use at all [1, 4].
    *   Claude is overwhelmingly the most popular tool, used by 49% of respondents, followed by GitHub Copilot (16%) and ChatGPT/OpenAI (15%) [5].
    *   Over half of the respondents (57%) state that AI significantly increases the speed at which they write code [4]. 
*   **The Risks of Increased Velocity:** 
    *   The rapid speed of AI-assisted delivery threatens to create quality issues, with one respondent warning that production environments could become a "cesspool" because foundational knowledge is no longer being evaluated [5].
    *   A new form of technical debt is emerging: AI-generated code that appears correct and passes tests, but which human engineers have not read or fully understood [6].
*   **The "1 = 10 Dilemma":**
    *   There is a growing belief that a single engineer utilizing AI can perform the work previously done by a team of four to ten people [7].
    *   However, leadership's expectation of smaller teams achieving higher velocity without a drop in quality may backfire, as engineers capable of this feat are rare [7].
*   **The Enduring Importance of Fundamentals:**
    *   Nearly 50% of survey respondents identify data modeling and semantic layers as the most critical focus areas moving forward, indicating that AI surfaces the need to get "boring" concepts like context, governance, and cost right [8].
    *   AI can understand the rules of data modeling, but it cannot currently understand the specific meaning of an organization's data or capture tacit knowledge, especially when employees fear job replacement [9].
    *   Skipping fundamentals leads to "firefighting," with over 25% of teams spending significant time just fixing issues [7]. Organizations utilizing ad-hoc modeling fight fires at double the rate (38%) of those utilizing canonical or semantic models (19%) [10].
*   **Career Outlook:** Despite industry fears of AI-driven job losses, practitioners remain highly optimistic (71%), viewing AI as an effectiveness tool rather than a replacement, and 42% even expect their data teams to grow in 2026 [11].

### "TBM 416: Investment Stewardship (As Habit)" by John Cutler

*   **Main Argument:** Measuring the return on investment (ROI) for engineering teams cannot be solved through a single metric, benchmark, or retroactive calculation; instead, it is an ongoing behavioral practice of stewardship, care, and continuous evaluation [12-14].
*   **The Pitfalls of ROI Calculations:**
    *   Companies typically attempt to measure engineering value only after something has gone wrong, such as over-hiring, toxic leadership, or a revenue pinch [15].
    *   Leaders often rely on flawed proxies, such as comparing "revenue per engineer" against companies with entirely different business models, tracking time allocation on the cost side while ignoring the value side, or using flow metrics to celebrate shipping speed rather than value [12, 16].
    *   Adding more personnel to an initiative rarely fixes a dysfunctional team and instead obscures the root problems [17]. 
*   **The Private Equity (PE) Contrast:** 
    *   When PE firms acquire companies, they bring explicit, reductive models that show exactly how every dollar spent is expected to contribute to the EBITDA target [18].
    *   While many leaders disagree with the bluntness of PE models, they admit it brings a level of honest clarity that should have existed long before the acquisition occurred [18].
*   **Stewardship as a Habit:** 
    *   Successful evaluation of ROI stems from a team consistently asking itself if it is working on the highest-leverage tasks, solving the right problems, and attempting to achieve outcomes with less complexity before resorting to hiring [19].
    *   Teams that dedicate time to "gardening" their codebase to fend off entropy create a compounding effect that keeps them highly productive years later [20].
*   **Actionable Steps for Stewardship:** Cutler outlines five concrete behaviors for organizations to practice [21]:
    1.  Identify leading indicators of success before lagging financial metrics appear.
    2.  Build a "useful" (not perfect) model linking product levers to revenue, retention, and costs.
    3.  Regularly assess those indicators every quarter to update confidence levels.
    4.  Apply strict discipline to hiring by first exhausting all existing avenues for efficiency.
    5.  Have honest conversations with finance to establish a reasonable model that accepts product outcomes lag and require specific funding modes.

### "TBM 417: Before You Fire All Your Glue People Because of AI" by John Cutler

*   **Main Argument:** While AI is highly effective at reducing physical friction for well-understood tasks, it cannot replicate the nuanced social infrastructure, judgment, and political navigation provided by organizational "glue people" [22-24]. 
*   **The Heuristic for AI Implementation:**
    *   Organizations should follow the instinct to use AI for things they know they *should* do but fail to do because of time and friction—such as drafting tailored release notes or updating project status documents [25-27].
    *   AI succeeds here because it significantly lowers the effort cost of tasks that are already understood, mandated, and valued by the organization [23, 28].
*   **When the AI Heuristic Fails:** The belief that AI can effortlessly replace human output breaks down when the true barrier to a task isn't just a lack of time [29]:
    *   **Capability gaps:** If an organization lacks a shared definition of what an aspirational goal (like "closing the loop on outcomes") actually looks like, AI will generate a performative artifact that nobody trusts or understands [30, 31].
    *   **Social opportunity and incentives:** If an organization claims to value an output (like risk logs) but only rewards shipping speed, making AI generate the log for free won't make the organization consume or value it [32].
    *   **Systemic barriers:** Sometimes behaviors don't happen because power dynamics make it unsafe; an AI flagging misalignment does not have the social capital to do so safely [33, 34].
*   **The "Iceberg" of Glue People:**
    *   Glue people often step into gaps between job descriptions to align teams and keep information flowing smoothly [35, 36].
    *   Organizations mistakenly believe AI can replace glue people because they only see the visible 20% of their output (documents, summaries, meetings) [24, 37].
    *   The invisible 80% of a glue person's role involves reading weak signals, navigating legitimacy, building shared language across disparate departments, running informal feedback loops, and possessing the political judgment to know when and how to surface problems [24, 38, 39].
*   **The Downstream Risk:** 
    *   Replacing a glue person with AI maintains the superficial artifacts but destroys the adaptive capacity and social permission required to make those artifacts actionable [40]. 
    *   Because the glue person's goal was to prevent problems from becoming visible, the structural damage of their removal often takes months to surface, long after the AI has taken over [40].

### "The data reliability question you're avoiding" by Andrew Jones

*   **Main Argument:** Data engineers frequently prioritize the speed of delivery over data reliability, a trade-off that is highly problematic if consumers require trustworthy data for critical applications [41, 42].
*   **Key Takeaways:**
    *   Engineers default to moving fast by relying on quick, permanent ETL fixes, skipping investments in reliability tooling, and shipping pipelines without proper monitoring, hoping they "fail loudly" instead [42].
    *   This speed-over-reliability trade-off is only acceptable if data users share the same expectations [42].
    *   If users expect reliable data to drive key business processes or revenue-generating ML features, data engineers are making the wrong trade-off and failing to set proper expectations [42, 43].

### "We're in 1905: Why Electricity (Not Dot-Com) Is the Right AI Analogy" by Joe Reis

*   **Main Argument:** The current AI revolution is analogous to the electrification of factories in 1905, meaning true productivity gains will not occur until companies entirely redesign their organizational architecture and workflows, rather than merely bolting AI onto legacy systems [44, 45].
*   **The Electrification Analogy:** 
    *   In the 1880s, factory owners replaced steam engines with electric motors but kept the same restrictive, multi-story belt-and-pulley factory layouts, resulting in no meaningful productivity gains [44, 45].
    *   Productivity only surged in the 1920s when factories were torn down and rebuilt into single-story layouts utilizing "unit drive" (individual motors per machine), allowing workflows to dictate the layout [44, 45].
*   **The Data Industry's History of "Swapping Motors":**
    *   The data industry has repeatedly upgraded its technology without changing its underlying architecture, such as lifting-and-shifting on-premise warehouses to the cloud with the exact same batch ETL and data models [46].
    *   The Modern Data Stack swapped monoliths for modular systems, but retained the identical organizational reality of centralized teams, centralized pipelines, and centralized consumption [47].
*   **The Current AI Trap:**
    *   Presently, organizations are simply bolting AI onto existing structures—such as adding Copilot to SharePoint or a chatbot to a data warehouse—which fails to alter the actual architecture or organizational design [48].
    *   Using AI to accelerate code migrations (like COBOL to Java) feels like progress, but it essentially automates the reconstruction of an outdated architecture faster [49].
*   **Rethinking the "Factory":**
    *   Centralized BI operates like the old central power shaft, bottlenecking downstream consumers [50].
    *   To succeed with AI, companies must emulate the "unit drive" shift: embed AI into business processes, move decision-making to where data is generated, and eliminate the analytics request queue [51].
*   **Timeline and Winners:**
    *   Replatforming and changing organizational incentive structures, workforce skills, and institutional inertia will likely take 10 to 20 years of real transformation [52, 53].
    *   Incumbents are unlikely to survive this shift; instead, they will be replaced by new entrants who build AI-native "single-story factories" from scratch, understanding that ways of working matter more than the technology itself [54].

### "What does it mean to take responsibility? - Andrew Jones"

*   **Main Argument:** Data producers must take explicit responsibility for the change management of their data to prevent breaking downstream data applications [55, 56].
*   **Key Takeaways:**
    *   Schema changes lacking effective change management are a primary cause of system breakages, accounting for 37% of all data incidents [56].
    *   Organizations must clearly define and explicitly state what data producers are responsible for and why it matters [55, 56].
    *   When introducing breaking changes to data or schemas, producers should follow established change management processes, which may include drafting RFCs for review, backfilling historical data, and concurrently populating both old and new schema versions to allow consumers to migrate without downtime [56, 57].
    *   The producer is responsible for determining the specific timeline and execution of these tasks based on the dataset's criticality; minor datasets may require a transition of days, while critical ones might require months [57].