Octopus Deploy - How to InnerSource Your Platform ![rw-book-cover](https://d34adp677peecb.cloudfront.net/static/images/article1.be68295a7e40.png) 🔗 **Source:** [Octopus Deploy - How to InnerSource Your Platform](https://www.youtube.com/watch?v=DNnLYV6rvKA) > [!note]+ Document Notes > tags: [innersource, platform-engineering, ai-agents, contribution-governance, risk-management] > author: "LeadDev panel (Octopus Deploy speakers; names garbled in captions)" > source: LeadDev (YouTube) > reference: https://www.youtube.com/watch?v=DNnLYV6rvKA > date created: 2026-10-02 12:47 > > > [!info] Generated analysis — not the author's words. Sections below are machine-written > > from the captured source. Only text inside `> [!quote]` blocks is verbatim from the author. > > Do not quote or attribute any other line to the named author. > > # 🏷️ Title: Octopus Deploy - How to InnerSource your platform > <!-- deep-read:sections start --> ## 🧭 Table of contents - [📝 Summary](#-summary) - [📖 Main content](#-main-content) - [🗒️ Notes](#️-notes) - [📚 References](#-references) - [🗣️ Paraphrase](#️-paraphrase) - [📰 Newsletter](#-newsletter) - [✅ Action items](#-action-items) - [🧪 Hypotheses](#-hypotheses) - [📊 Methodology](#-methodology) - [❓ Questions](#-questions) - [🔮 Future research](#-future-research) - [💡 Implications](#-implications) - [🧠 Learning styles assessment](#-learning-styles-assessment) - [📊 Accessibility assessment](#-accessibility-assessment) - [🌍 DEIB assessment](#-deib-assessment) - [✅ Logical validity](#-logical-validity) - [🛡️ DARVO analysis](#️-darvo-analysis) - [🎯 Conclusion](#-conclusion) - [🔄 Refactor appendix](#-refactor-appendix--octopus-deploy---how-to-innersource-your-platform) ## 📝 Summary - **What happened.** LeadDev published a 48:44 online panel (uploaded 2026-09-30), "created in partnership with Octopus Deploy" per the moderator at 00:00:12. Lucy Adams (digital content producer, LeadDev) moderates three panelists: Patrick Debrah (spelling from the auto-captions), Cat Morris (head of product at Syntasso, which builds the Kratix platform framework), and Bob Walker (field CTO at Octopus Deploy). The video has no chapters and an empty description. - **The claim.** Opening a platform to contributions from other teams can keep compliance intact if the platform has automated tests for changes, written contribution guidelines, a clear line between high-scrutiny and low-scrutiny components, and trust built through community engagement. The panel treats AI agents as a force that makes this both more necessary (more requests, more generated code) and more workable (agents as design partners and reviewers). - **Why it matters.** Platform teams described at 00:03:47 as undersized (one anecdote: six people serving 10 to 15 engineering teams) either get ignored or get buried in tickets. InnerSource is offered as the way to scale capacity without giving up control. - **Key stakeholders.** Platform teams and their customers (internal engineering teams), leadership and finance who fund them, compliance and risk owners, and AI agents as a new class of contributor. Commercial interest: the panel is a partner production with Octopus Deploy, a deployment automation vendor, and Cat Morris works for another platform tooling vendor. Two of three panelists sell products in this space. - **Risks and tradeoffs.** The title promises "how to InnerSource", but the transcript never gives a defined InnerSource method or names an InnerSource framework. Most of the 48 minutes covers platform governance, AI-assisted review, and funding. Every number is an anecdote or a hypothetical (see Main content). Claims about Octopus Deploy's customers and open source work are the speaker's claims with no source in the video. - **Bottom line.** The strongest, most reusable advice is concrete: run the proposed change through an automated pipeline before merge (00:19:38), scale scrutiny to blast radius (00:18:11), and justify platform cost in time, risk and money tied to consuming teams (00:36:14, 00:40:32). The title's promise of an InnerSource how-to is only partly met. ## 📖 Main content **Format and framing.** This is a moderated panel, not a single talk. The moderator opens at 00:03:04 with a framing: opening a platform "can feel like trading control for chaos." A poll about attendees' InnerSource experience is launched, but the results are never read out in the transcript. Questions run in this order: platform team challenges (00:03:04), compliance and where governance becomes too much control (00:12:27), what a good contribution path looks like (00:19:38), what makes a contributor trustworthy (00:20:20), how to trust AI-generated contributions (00:25:22), how to handle risk in younger companies (00:30:28), funding when leadership pivots to revenue (00:34:03), and whether the platform should become a self-enforcing layer of judgment (00:44:08). **Terms.** InnerSource means applying open source contribution practices inside one organization: other teams can propose changes to a shared codebase, and the owning team reviews them. The panel uses the word loosely. Cat Morris says it "doesn't have to be a very strict inner sourcing model" (00:05:13). Other terms: platform as a product (treating internal developers as customers), guardrails (automated limits and checks), OPA policies (Open Policy Agent rules, named by Bob Walker at 00:18:11), and risk register (a list of accepted risks with owners, 00:38:22). **The two failure modes (00:03:47).** Cat Morris names two. First, low adoption: the platform team built it and nobody uses it. Second, overload: everybody wants it, and a small team can't keep up with the requests. At 00:04:30 Cat adds that AI agents worsen both: agents let other teams build side solutions without the guardrails, and agents act as extra engineer-like requesters, so ticket volume rises. Bob Walker (00:05:57) describes a pendulum: "you build it, you own it, you run it" gave autonomy but weak control and compliance, supply chain risk worries pushed organizations back to a central team, and that central team turned into a ticket queue, sometimes staffed by the most junior people. **Practices the panel names for opening a platform.** The panel gives no formal numbered sequence. The list below is this analysis's synthesis, ordered by where the practices appear, and each step cites the speaker's timestamp. 1. Find the niche first. Patrick Debrah (00:07:23, 00:08:06) says a platform finds a main direction, fences off tickets outside it ("you're on your own"), and offers self-service for the rest. Cat Morris (00:16:01) calls this a wedge that grows over time. 2. Define what a good contribution looks like before accepting pull requests. Cat Morris (00:16:44) warns that without stated strategy, target use cases and contribution criteria, a pull request triggers a half-hour standup debate about whether the platform wants the feature. 3. Write clear contribution guidelines and per-component goals. Bob Walker (00:19:38): what is expected, what must pass, which use cases are supported. 4. Run every proposed change through an automated pipeline. Bob Walker (00:19:38): a commit to a branch starts the pipeline, which runs policies and tests before merge. Manual testing misses steps, so the testing must be automated (00:14:35, 00:15:18). 5. Set a line of demarcation by blast radius. Bob Walker (00:18:11): OPA-governed compliance steps and anything used by everybody get higher scrutiny; niche, low-impact steps get less. 6. Make the right way the easy way. Patrick Debrah (00:17:27): reduce friction so developers don't skip the compliance step, and help people over the line instead of drawing one. 7. Provide documentation, tests and guardrails so teams can self-verify without the platform team (00:08:50). 8. Build trust through engagement, not seniority. Cat Morris (00:21:04): contribution frequency, community meetups, reading docs, filing issues first. Bob Walker (00:23:57): documentation contributions show a contributor understands the product. 9. Accept ideas where implementations are not accepted. Patrick Debrah (00:21:47, 00:22:30): some open source projects disable pull requests but keep issues, then iterate on the implementation with an agent against the maintainers' standards. 10. Keep a named human accountable for approval, and set agent approval limits per risk area. Patrick Debrah (00:25:22 to 00:27:36). 11. Categorize components by risk (ephemeral dev environment versus databases holding GDPR or PCI DSS data). Cat Morris (00:29:03, 00:29:46). 12. Give agents least-privilege tools, such as a delete tool that alerts above five rows. Patrick Debrah (00:32:35). 13. Tie platform funding to consuming teams and report time, risk and money. Cat Morris (00:36:14), Bob Walker (00:40:32). **Numbers and their status.** All are unsourced in the transcript. Team of six serving 10 to 15 teams (00:03:47) is Cat's experience. Bob Walker's "almost on 9 years" at Octopus Deploy and 15 years as an engineer (00:01:38, 00:02:22) are self-reported tenure. The "15% chance" of a "2 billion" fine and "6 million" in slowed development (00:39:50), and the "0.0001%" contrast (00:42:43), are illustrations, not data. "Five rows" (00:32:35) is a design example. The bank anecdote (a team "cut in half," three teams advocating, 00:34:47 to 00:35:30) has no named organization. **Speaker claims about vendors and products (unverified).** - Bob Walker (00:23:14): Octopus Deploy was "one of the primary contributors" to the Argo project, and many people enter Argo by contributing to docs. No source in the video. - Bob Walker (00:41:15): "a couple of our customers" dropped licensing costs by changing their approach. No customer or amount named. - Cat Morris (00:20:20): Syntasso's open source product received "a load of AI spam." Cat Morris (00:47:00): a customer used a Syntasso product to serve agents and skills to its team. Neither is documented in the video. - Patrick Debrah (00:26:08): an agentic tool the transcript renders "Open Hands" reversed a decision to let agents alone approve, and quality rose when humans became responsible again. No source. - Bob Walker (00:45:35): a colleague's article "AI agents are getting the onboarding that your developers never got." The author's name is garbled in captions ("Steve Hatton"); verify the name and URL on the Octopus Deploy blog. **Contested or thin.** The panel agrees on most points, so little is contested on screen. Cat Morris disagrees mildly with a smooth agentic future at 00:28:20 ("not many companies are there"). Nobody addresses InnerSource-specific problems such as discoverability catalogs, maintainer time budgets, or contribution credit. ## 🗒️ Notes #### ⏱️ [00:00:12](https://www.youtube.com/watch?v=DNnLYV6rvKA&t=12) Welcome, partnership disclosure, introductions - LeadDev online panel "created in partnership with Octopus Deploy" (moderator's words). Q&A moves to the LeadDev Slack afterward. - Patrick Debrah: DevOps background including "the first DevOps days," two recent years adding AI. The captions render the surname as "Debrah"; confirm the spelling before citing. - Cat Morris: head of product at Syntasso, about three years, builds Kratix; earlier consultant at ThoughtWorks on platform as a product. - Bob Walker: field CTO at Octopus Deploy, nearly 9 years; 15 years as an engineer doing 2 a.m. Saturday deployments. #### ⏱️ [00:03:04](https://www.youtube.com/watch?v=DNnLYV6rvKA&t=184) Platform team challenges today - Moderator frames the topic as trading control for chaos and launches a poll (results not read out). - Cat Morris: two sides, no adoption versus too much demand; AI agents worsen both by creating side solutions and extra requests. - InnerSource helps by making the platform visible (a marketing effect) and adding capacity the small team lacks. - Bob Walker: pendulum from "you build it, you own it" to a central ticket-queue team, sometimes staffed by juniors who lack the nuance to refuse requests. #### ⏱️ [00:07:23](https://www.youtube.com/watch?v=DNnLYV6rvKA&t=443) Scaling demand: niche, self-service, design partners, AI - Patrick Debrah: platforms find a niche; fence off tickets outside it; offer self-service with docs, tests and guardrails; keep risky components in-house. - "You build it, you own it" with AI means owning cost and maintenance; if unready, return to the mainstream platform. - Design-partner pattern: join a customer's budget and project, then generalize the result for the whole organization. - Giving AI the team's runbooks and way of working makes proposals better than "vibe coding," per the speaker. Counterpoint: "everybody hits you with the slop." #### ⏱️ [00:12:27](https://www.youtube.com/watch?v=DNnLYV6rvKA&t=747) Why compliance blocks direct contribution - Governance equals risk mitigation. Infrastructure lacks cheap test environments (proxies, data), so impact in production exceeds impact in test. - Bob Walker: a customer feared a compliance step would be skipped; developers disabled it for every single environment. Automated testing before merge is the main answer. Bob says one line of code once brought down a production SQL Server. - Cat Morris: direction risk matters too. Without strategy and contribution criteria, pull requests become standup debates. #### ⏱️ [00:17:27](https://www.youtube.com/watch?v=DNnLYV6rvKA&t=1047) Easy right way, demarcation, contribution path - Patrick Debrah: reduce friction so developers do the compliance step; pull the line less, help people over it. - Bob Walker: scrutiny scales with how many teams use a component; OPA policies get high scrutiny, niche steps low. A clear line cuts back-and-forth. - Good path (Bob, CI/CD view): commit to a branch triggers the proposed pipeline, which runs all policies; plus guidelines and stated goals per component. #### ⏱️ [00:20:20](https://www.youtube.com/watch?v=DNnLYV6rvKA&t=1220) What makes a contributor trustworthy - Cat Morris: inside an organization the originating source is known, unlike open source with AI spam; trust signals are contribution frequency and community engagement, not seniority. - Patrick Debrah: past good pull requests don't guarantee the next; rely on the harness and feedback. Some projects accept ideas but not implementations. - Bob Walker: docs contributions demonstrate understanding; deep conversations show a contributor grasps the problem even when the implementation is weak. #### ⏱️ [00:25:22](https://www.youtube.com/watch?v=DNnLYV6rvKA&t=1522) Trusting AI-generated contributions - Patrick Debrah: generation is cheap, so the bottleneck moves to review. AI can run an adversarial review loop, but a human should own the approval. - The tipping point: a human who only says yes becomes a rubber stamp. Mitigation: a human accepts a defined risk for agent approval in a defined area (a docs page versus payments or authentication). - Factories add after-the-fact risk analysis and code-owner style permissions; architecture limits blast radius (microservices versus databases). - Cat Morris (00:28:20): few companies categorize risk today, and AI raised risk aversion because teams don't know what generated code does. #### ⏱️ [00:30:28](https://www.youtube.com/watch?v=DNnLYV6rvKA&t=1828) Risk categories, startups, agent harnesses - Cat Morris: visualize risk so it feels less scary; separate GDPR or PCI DSS data from ephemeral dev environments. - Bob Walker: treat AI as a sparring partner, not an oracle. Startups still carry GDPR, OSFI (Canada) and US standards. - Patrick Debrah: give agents narrow tools with limits (alert beyond five deleted rows), apply least privilege, assume failure, and threat-model the architecture. #### ⏱️ [00:34:03](https://www.youtube.com/watch?v=DNnLYV6rvKA&t=2043) Funding guardrails when leadership wants revenue - Audience question: no funding or time for guardrails while teams pivot to growth projects. - Cat Morris: at a bank (unnamed), a team halved by cuts tied itself to three revenue teams that advocated for it, shared cost, and made guardrails a requirement for each market's regulation. Teams must justify cost through consumers' speed and lower cognitive load. - Patrick Debrah: value and cost savings sell; risk and tech debt are the hardest sell. Bring risks to management and have them accepted in the risk register. #### ⏱️ [00:39:07](https://www.youtube.com/watch?v=DNnLYV6rvKA&t=2347) Quantifying risk and showing team-level dashboards - Platform teams can't mitigate every risk; choose "enough bang for the buck" and let the rest be accepted. - Cat Morris: assign a financial value, for example probability times fine, to make risk comparable to savings. - Bob Walker: "time, risk, money"; compare the platform hour cost to hours saved, infrastructure savings, or licensing savings, and weigh likelihood in the risk register. - Patrick Debrah: a dashboard per team (backups, performance) shows which teams need help, and the PM picks items per sprint. #### ⏱️ [00:44:08](https://www.youtube.com/watch?v=DNnLYV6rvKA&t=2648) Closing: does the platform become a layer of judgment - Patrick Debrah: AI lets platform teams make recommendations self-serve and self-enforcing, and speeds their own customer feedback triage. - Bob Walker: agents need onboarding-grade context, which improves documentation that human developers also benefit from. - Cat Morris: good platforms always codified judgment; agents don't change that. A customer served agents and skills to its team (speaker's claim). - Patrick Debrah: developers now write tests and docs for the agent, which nagging never achieved. Moderator closes at 00:48:28 and points viewers to the panel Q&A channel in the LeadDev Slack. ## 📚 References The transcript itself contains no links; the following come from the video description or are primary sources for named entities. The description is empty, so every entry below is a primary-source pointer for an entity the speakers name, not a link the speakers gave. - [Octopus Deploy: LeadDev panel, "How to InnerSource your platform"](https://www.youtube.com/watch?v=DNnLYV6rvKA): the source video, 48:44, uploaded 2026-09-30. - [LeadDev](https://leaddev.com): publisher and host of the panel and its Slack Q&A. - [Octopus Deploy](https://octopus.com): panel partner; employer of Bob Walker. - [Syntasso](https://www.syntasso.io) and [Kratix](https://kratix.io): Cat Morris's employer and its platform framework, both named at 00:01:38. - [Argo Project](https://argoproj.github.io): named at 00:23:14 as a project Octopus Deploy contributed to (speaker's claim). - [Open Policy Agent](https://www.openpolicyagent.org): the OPA policies named at 00:18:11. - [InnerSource Commons](https://innersourcecommons.org): the community behind InnerSource practice. Not named in the transcript; included because the title's subject has no definition in the video. - [PCI Security Standards Council](https://www.pcisecuritystandards.org): source for PCI DSS, named at 00:29:46. - [OSFI](https://www.osfi-bsif.gc.ca): Canada's financial regulator, named at 00:31:52. - OpenHands (the transcript writes "Open Hands"): agentic tool cited at 00:26:08. No URL given; confirm the project's current official site before citing. - Article "AI agents are getting the onboarding that your developers never got": attributed at 00:45:35 to an Octopus Deploy colleague whose name is garbled ("Steve Hatton"). Not located; check the Octopus Deploy blog. ## 🗣️ Paraphrase The panel starts from a squeeze. Small platform teams either can't get adoption or can't keep up with demand, and AI agents add requests and side-built tools to both problems. Cat Morris argues that opening the platform to contributions fixes both: other teams add capability the platform team can't build, and the act of contributing spreads awareness. Bob Walker describes why that scares compliance owners: central teams became ticket queues, and when access opened, developers switched off the one step that mattered. Patrick Debrah adds that infrastructure changes are hard to test, so a one-line change can do more damage than an app change. The answers cluster around three moves. Automate the proof: every proposed change runs the full pipeline and its policies before merge. Scale scrutiny to blast radius: shared, high-impact components get more review than niche ones. Build trust from engagement: frequent participation, documentation work and real conversations count for more than job title. On AI-generated contributions, the panel says review replaces writing as the bottleneck, and a human should still own the approval, with agent approval limited to areas where someone has consciously accepted the risk. The last third covers money. Cat Morris tied a defunded bank platform team to three revenue teams that then advocated for it. Patrick Debrah and Bob Walker say platform teams win on value and cost savings, lose on abstract risk, and should express risk as probability times cost. The close frames a good platform as codified organizational judgment, and notes with some irony that developers now write documentation and tests because an agent needs them. ## 📰 Newsletter **Opening your platform without opening the floodgates.** LeadDev's panel, made in partnership with Octopus Deploy, spends 48 minutes on how platform teams can accept contributions without losing compliance. Three takeaways travel well to WordPress contributor workflows. First, run the checks automatically: Bob Walker's rule is that a commit to a branch triggers the full proposed pipeline, so no one relies on a reviewer remembering every step. Second, scale scrutiny to blast radius: the more teams use a component, the harder you review it. Third, trust engagement over seniority: Cat Morris names contribution frequency and community participation, and Bob Walker points to documentation contributions as the on-ramp. One caution for readers: the title promises an InnerSource how-to, but the panel never defines a method, and its numbers are anecdotes. Two of three panelists work for vendors in this space. Still, the "time, risk, money" funding frame at 00:40:32 is worth stealing for any community budget request. Links: [the panel](https://www.youtube.com/watch?v=DNnLYV6rvKA), [LeadDev](https://leaddev.com), [InnerSource Commons](https://innersourcecommons.org). ## ✅ Action items #### DevRel - Developer advocacy: turn the 13-practice list in Main content into a talk outline for "opening a platform to contributors," and replace the unsourced anecdotes with a case from your own organization. - Education: run an office-hours session on writing a contribution guideline that states target use cases, pass criteria and the escalation path, since Cat Morris at 00:16:44 ties unstated strategy to standup debates. - Developer experience: add an automated pre-merge pipeline run (lint, policy, integration test) to the contribution quickstart, following Bob Walker's branch-triggered pipeline at 00:19:38. - Developer marketing: when citing this panel, disclose the Octopus Deploy partnership and the Syntasso affiliation, and don't repeat the vendor customer claims without a source. - Community management: record contribution frequency and engagement as trust signals alongside seniority, per 00:21:04. - Internal/external/cross-project: ask the Octopus Deploy blog team for the colleague's article cited at 00:45:35 so the reference is verifiable. #### OSPO - Policy and governance: write a risk-tiered contribution policy that names which components need higher scrutiny and which agents may approve what, using Patrick Debrah's docs-page versus payments example (00:26:52). - License compliance: no direct action from this source; nearest relevance: contribution guidelines at 00:19:38 are where a license check belongs. - Security management: add least-privilege tool limits for agent contributors (Patrick Debrah's five-row delete alert, 00:32:35) and an after-the-fact risk analysis for agent merges (00:27:36). - Software inventory: classify components by data risk (ephemeral versus GDPR or PCI DSS data, 00:29:46) in the inventory so scrutiny levels have a source of truth. - Developer support: publish the demarcation line (OPA-governed compliance steps versus niche steps) so contributors know the review depth before they open a change. - Community engagement: no direct action from this source; nearest relevance: upstream docs contributions as the trust on-ramp at 00:23:14. - Strategic alignment: adopt "time, risk, money" (00:40:32) as the fields in every platform or tooling funding request, with the 15% times fine illustration replaced by real estimates. #### Community - Maintainers: adopt "ideas welcome, implementation by the maintainers' standards" as an option for AI-spam-prone repositories, as described at 00:22:30. - Contributors: define the docs-first path for newcomers: documentation contribution, then small code changes, per 00:23:57. - Sponsors: show sponsors a per-team dashboard of open improvement items, the pattern at 00:43:25, instead of a feature count. - Ecosystem: no direct action from this source; nearest relevance: a shared risk-tier vocabulary across projects would make cross-project review comparable. #### WordPress - Core: no direct action from this source; nearest relevance: scrutiny by blast radius matches how commit access differs by area. - Core Performance: no direct action from this source; nearest relevance: automated pre-merge tests at 00:19:38 match performance regression checks. - Core AI: draft a rule on where an agent may approve and where a human must, with the docs-versus-authentication contrast at 00:26:52 as the model. - **Core Program Team:** no direct action from this source; nearest relevance: the "time, risk, money" frame at 00:40:32 for cross-team dependency decisions. - Mobile: no direct action from this source. - Playground: no direct action from this source; nearest relevance: a disposable environment is the test bed the panel says infrastructure lacks (00:13:09). - Community: no direct action from this source; nearest relevance: contributor trust signals at 00:21:04. - Training: build a docs-contribution on-ramp lesson modeled on Bob Walker's Argo description at 00:23:14, marked as a speaker claim. - Marketing: no direct action from this source. - Support: no direct action from this source. - Design: no direct action from this source. - Documentation: treat documentation contributions as a trust signal for later code contribution (00:23:57), and add agent-ready context to the handbook as 00:45:35 suggests. - Photos: no direct action from this source. - TV: no direct action from this source. - Polyglots: no direct action from this source. - Accessibility: no direct action from this source; nearest relevance: automated checks in the pre-merge pipeline. - Meta: no direct action from this source; nearest relevance: an automated pipeline for .org tooling changes before merge. - CLI: no direct action from this source. - Hosting: no direct action from this source; nearest relevance: the difficulty of testing infrastructure changes (00:13:09). - Tide: no direct action from this source. - Openverse: no direct action from this source. - Themes: no direct action from this source; nearest relevance: automated checks at submission echo the branch-triggered pipeline. - Plugins: no direct action from this source; nearest relevance: tiering review depth by plugin reach, as at 00:18:53. #### The WPOCC - Programs: no direct action from this source; nearest relevance: a stipend request framed in time, risk and money (00:40:32). - Projects: no direct action from this source; nearest relevance: contribution guidelines with stated use cases (00:16:44) as a documentation sprint topic. - Funding experiments: require recipients to report time saved or cost avoided per funded item, mirroring the consumer-team advocacy test at 00:36:14. ### FAIR - Technical independence: no direct action from this source; nearest relevance: least-privilege limits for automated actors (00:32:35). - Policies and covenants: no direct action from this source; nearest relevance: a named human accepting the risk for agent approvals (00:26:52). - Productized governance artifacts: add a risk-tier and approval-limits row to operator scorecards, using the component categories at 00:29:46. ## 🧪 Hypotheses 1. Repositories with an automated pre-merge pipeline that runs policy checks accept outside contributions with fewer post-merge compliance exceptions than repositories relying on manual review (Bob Walker, 00:15:18). 2. A written contribution guideline that states target use cases cuts the share of outside pull requests closed as out of scope by at least a third (Cat Morris, 00:16:44). 3. Prior engagement (documentation edits, issues, meetup attendance) predicts first-pull-request acceptance better than job seniority (Cat Morris, 00:21:04; Bob Walker, 00:23:57). 4. Agent-approved merges restricted to low-risk components have a post-merge defect rate no higher than human-approved merges on the same components, and requiring a named human owner for high-risk components keeps quality from dropping (Patrick Debrah, 00:26:08 claim). 5. Platform funding requests that name consuming-team beneficiaries and quantify time, risk and money are approved more often than feature-list requests (Cat Morris, 00:36:14; Bob Walker, 00:40:32). 6. A per-team readiness dashboard raises the rate at which teams close their own gaps (backups, performance) compared with no dashboard (Patrick Debrah, 00:43:25). ## 📊 Methodology - **H1.** Pick 10 or more internal repositories with comparable change volume. Compare outside-contribution compliance exceptions per 100 merged changes before and after a pipeline gate is added, over two quarters, with the exception definition fixed in advance. - **H2.** Add a guideline file to half of a matched set of repositories and track the out-of-scope close rate and standup-time spent on scope debates (survey) for 90 days against the control half. - **H3.** Collect contributor histories for 200 or more first pull requests. Fit a logistic model of acceptance on prior engagement counts and seniority band, and compare the two predictors by area under the curve. - **H4.** On low-risk components, randomize agent versus human approval and record reverts and incidents at 30 and 90 days. Keep high-risk components human-owned in both arms and log reviewer override rates to detect rubber-stamping. - **H5.** Code 30 or more past funding requests for the presence of quantified time, risk and money fields and for named consumer teams, then compare outcomes. Treat this as observational and note selection effects. - **H6.** Introduce the dashboard in a staggered rollout across teams, measuring median days to close a listed gap against the not-yet-rolled-out teams. ## ❓ Questions - What is the panel's actual InnerSource method, if any, and why does the title promise more than the transcript delivers? - What did the opening poll show about attendee experience, and why are results absent from the video? - How does a team assign the "15%" style probabilities the panel recommends, and who audits them? - When does a human approver become a rubber stamp, and what measurable signal marks the tipping point Patrick Debrah describes at 00:26:08? - Does "ideas yes, implementations no" scale past projects with strong maintainers who can direct an agent? - What do the Octopus Deploy customers cited at 00:41:15 look like, and how typical are their licensing savings? - Which trust signals survive when contributors are agents instead of people? - How does a small platform team keep a contribution backlog from becoming the new ticket queue Bob Walker describes at 00:06:40? ## 🔮 Future research - **InnerSource-specific evidence.** The panel cites no study of InnerSource adoption, maintainer load, or contribution acceptance. Controlled comparisons of gated versus ungated internal contribution would fill the largest gap. - **Agent review quality.** The OpenHands anecdote at 00:26:08 is unsourced. A published comparison of human-owned versus agent-only approval would test it. - **Risk-tier schemes.** Cat Morris notes at 00:28:20 that most companies don't categorize risk. A shared, tested tiering scheme for platform components would help. - **Funding narratives.** The claim that platform teams survive only by tying to consumer teams (00:36:14) rests on one bank case. Multi-organization evidence would test it. - **Documentation as trust signal.** Whether docs contributions predict code quality (00:23:57) is testable with repository history. ## 💡 Implications - **Practice.** Pipelines that run policies and tests on every proposed change are the precondition for opening a platform, per 00:19:38. Teams without them should build them before inviting contributions. - **Policy.** Write down which components need higher scrutiny, who may approve what (including agents), and where a named human accepts residual risk (00:26:52). - **Security.** Give agents narrow tools with hard limits instead of broad API access (00:32:35). Treat agent-generated changes as higher volume, not lower risk. - **Education.** Documentation contributions double as training and as a trust signal (00:23:57). Writing agent-ready context also improves onboarding for people (00:45:35). - **Funding.** Express platform value as time, risk and money, with consumer teams as advocates (00:36:14, 00:40:32). Pure risk arguments are the hardest sell, per Patrick Debrah at 00:38:22. - **Source literacy.** A partner-produced panel mixes real advice with vendor-adjacent claims. Separate the transferable practices from the product anecdotes. ## 🧠 Learning styles assessment - **Reading level estimate.** Flesch-Kincaid Grade Level of the transcript computed with a script: about 8.9 (9,339 words, 439 sentences, 21.3 words per sentence, rough syllable counter). Flesch Reading Ease: about 69. Spoken, conversational English; the vocabulary (OPA, GDPR, PCI DSS, harness, blast radius) assumes platform engineering background. #### 👀 Visual learners - Present: a panel on screen with a poll launch at 00:03:04. The transcript can't confirm slides or diagrams, and none are referenced. - Improve: add a diagram of the contribution path (branch, pipeline, policy gate, review) and a risk-tier table. Cat Morris asks for a "visualization" of risk at 00:29:46 and the video doesn't supply one. #### 🔊 Aural learners - Present: the whole panel is spoken discussion with four distinct voices and a moderator who names speakers at the start. - Improve: add a 3-minute audio recap of the 13 practices. Speakers interrupt and trail off (00:45:35), so a summary helps. #### 🗣️ Verbal learners - Present: analogies carry the argument: the pendulum (00:05:57), the wedge (00:16:01), "sparring partner" (00:31:10), the salesperson who tells you to protect your house (00:39:07). - Improve: define OPA, risk register, GDPR, PCI DSS, OSFI and "harness" on first use. None is defined aloud. #### 🧩 Kinesthetic learners - Present: concrete scenarios such as the disabled compliance step (00:14:35) and the five-row delete alert (00:32:35). - Improve: no demo, repository or exercise is offered. A hands-on lab that adds a pipeline gate to a sample platform repository would convert the advice into practice. #### 🧠 Logical learners - Present: a clear risk framework (likelihood times cost, time-risk-money, 00:40:32 to 00:42:43) and a stated progression from risk to scrutiny level. - Improve: the 15%, 2 billion and 0.0001% figures are placeholders. A worked example with real inputs would let logical learners reuse the method. #### 🧑‍🤝‍🧑 Social learners - Present: panel discussion, a live audience question at 00:34:03, a poll, and a Slack Q&A channel after the session. - Improve: the Slack Q&A content isn't captured here. Publish the answers to the questions the panel ran out of time for. #### 🧘‍♀️ Solitary learners - Present: a self-contained recording that can be paused, with a clear question sequence. - Improve: add reflection prompts such as "Which of your components would you place in each risk tier?" #### 🌿 Naturalistic learners - Present: ecosystem analogies are implicit (open source communities, a niche for a product), not explicit. - Improve: tie platform sprawl and ephemeral environments to resource use. The ephemeral dev environment "spun up and killed every night" (00:29:46) is a natural hook for an environmental-cost discussion. ## 📊 Accessibility assessment #### Screen reader semantics - Present: YouTube supplies page landmarks and an auto-generated transcript. The speakers name themselves at 00:00:54 to 00:02:22. - Improve: speaker changes in the auto-transcript are marked only by ">>", and captions garble names ("Debrah," "Kat," "Cass," "Hatton"). Add speaker labels and a corrected transcript. WCAG 2.2 AA 1.2.1 and 1.1.1 apply to any visual material (poll, any slides) that narration doesn't describe. #### Keyboard navigation - Present: the YouTube player is keyboard operable by default. - Improve: no chapters exist on a 48-minute video, which forces scrubbing. Add chapters for the eight question blocks. Relevant criteria: 2.4.5 (Multiple Ways) and 2.4.6 (Headings and Labels) apply to the page, not the player. #### Contrast and readability - Present: unverifiable from the transcript. - Improve: if poll results or slides were shown, check text contrast against 1.4.3 (Contrast Minimum). No visuals are described in the transcript. #### Text resizing and reflow - Present: the player and captions scale on the platform. - Improve: burned-in text, if any, does not resize (1.4.4, 1.4.10). The transcript mentions none. #### Media and captions - Present: auto-captions exist, which is how this analysis was produced. - Improve: auto-captions garble proper nouns and product terms ("Open Hands," "Kat" and "Cass" for Cat, "Steve Hatton") and mix speakers, which fails the spirit of 1.2.2 (Captions, Prerecorded). A live Zoom event with no corrected captions is a missed 1.2.4 opportunity. Publish human-corrected captions and a speaker-labeled transcript. #### Forms and interactions - Present: audience questions via Zoom Q&A and a poll at 00:03:04. - Improve: the poll's results are never read aloud, which excludes viewers who can't see the screen (1.3.1, 3.3.2 for the poll form). State results aloud. #### Standards reference - Primary gaps against WCAG 2.2 AA: **1.2.2** (inaccurate captions), **1.2.5** (no audio description for any visual material), **1.3.1** (speaker identification and poll results not conveyed in text), **2.4.5** (no chapters or alternative navigation). The caption accuracy gap is the highest-impact and cheapest to fix. ## 🌍 DEIB assessment #### Cultural breadth - Present: the Canadian regulator OSFI (00:31:52), GDPR and US standards, and a bank serving multiple markets (00:35:30) appear. The transcript doesn't state where any speaker is based. - Improve: examples come from banking and enterprise software. Add non-enterprise cases such as public-sector or open source community platforms. #### Inclusive language - Present: plain second-person language, jargon mostly explained in context. Bob Walker notes junior engineers need support instead of dismissal (00:06:40). - Improve: idioms ("airy-fairy," "burning through fire," "freaking people out," "bang for the buck") are harder for non-native English speakers. The remark that junior staff don't grasp the nuance frames juniors as a liability; pair it with mentoring practices. #### Neurodiversity support - Present: the moderator announces the format and length up front and moves question by question, which gives a predictable structure. - Improve: no chapters, no on-screen question list, and several run-on answers with false starts (00:45:35). Chapters and a visible agenda would help. #### Representation - Present: four voices (a moderator and three panelists) with mixed seniority and employers. Pronouns are not stated for any speaker, and none are assumed here. - Improve: all speakers work in platform or DevOps vendor and enterprise roles. Add a contributor from a smaller team or a non-vendor practitioner to balance the vendor-adjacent view. #### Psychological safety - Present: respectful tone, mutual agreement, and open acknowledgment of difficulty ("it is really hard," 00:34:47). The moderator invites each panelist in turn. - Improve: the advice treats junior staff and startups as risks. Add explicit guidance on safe ways for newcomers to contribute (docs first, 00:23:57) and a path for raising concerns. ## ✅ Logical validity #### Strong reasoning - **Causal, 00:14:35.** A compliance step is disabled in every environment once developers get access, so a gate that can't be skipped (an automated pipeline) is needed. The mechanism is concrete and matches common practice. To clarify: say who owns the pipeline definition so contributors can't edit it away. - **Analogical and practical, 00:18:11 to 00:18:53.** Scrutiny should scale with how many teams use a component. The inference holds because impact scales with reach. - **Deductive, 00:25:22.** If generation is cheap, the bottleneck moves to review. The premise is plausible and the conclusion follows. - **Cost framing, 00:40:32 to 00:41:58.** Time, risk and money reduce to a comparison of platform hour cost against savings or avoided loss. The logic is sound when inputs are real. - **Self-limiting concession, 00:28:20.** Cat Morris notes that few companies reach the future Patrick Debrah describes, which keeps the panel from overstating adoption. #### Fallacies - **Anecdotal evidence, 00:34:47.** Cat Morris tells one story, about a single unnamed bank, as a personal best. One case supports the claim that platform teams survive only by tying to revenue teams (00:36:14, "the only way I've ever seen"). *Fix:* cite multiple cases or soften to "the way I've seen work." - **Unsupported number (bare assertion), 00:39:50.** The 15% chance, 2 billion fine and 6 million slowdown figures are illustrations, but they sound like estimates. *Fix:* label them hypothetical, which the speaker partly does. - **Appeal to a tool anecdote, 00:26:08.** An agentic tool allegedly reversed a no-human-approval rule and quality rose. No source, no measure of quality. *Fix:* cite the project's announcement and the metric. - **Possible conflict of interest, 00:23:14 and 00:41:15.** Bob Walker's vendor-employer claims (Argo contributions, customer licensing savings) support the vendor's credibility and are unverified. *Fix:* link sources or mark them as company claims. - **Title-content mismatch, whole video.** "How to InnerSource your platform" suggests a method the panel doesn't deliver; "InnerSource" is used loosely and defined only as "doesn't have to be a very strict inner sourcing model" (00:05:13). *Fix:* retitle or add a defined practice list. - **Hasty generalization, 00:21:04.** "Seniority" is dismissed as a trust signal using one hypothetical about a CTO. *Fix:* cite data that seniority is a weak predictor. #### Tone of voice - Conversational, collegial and practical, with first-person experience as the main evidence: "I've brought down an entire production SQL Server with one line of code" (Bob Walker, 00:15:18), the bank story told as a personal best (Cat Morris, 00:34:47). Patrick Debrah's answers run long and abstract, with metaphors (the salesperson, the house) at 00:39:07. The moderator's tone is polished and promotional ("really fantastic," "invigorating") consistent with a partner-produced event. Optimistic about AI overall, with Cat Morris as the measured voice. ## 🛡️ DARVO analysis Not applicable to this source. DARVO (Deny, Attack, Reverse Victim and Offender) describes a response to accusation or criticism, and this panel has no accuser, no accused and no conflict. For completeness across the three prongs: **Deny**: nothing is denied; panelists volunteer that few companies can categorize risk (00:28:20) and that AI worsens risk appetite (00:29:03). **Attack**: no individual, team or critic is attacked; juniors and non-compliant developers are described as a risk pattern, not blamed. **Reverse victim/offender**: no such move appears; platform teams are cast as sympathetic but not as victims of named parties. ## 🎯 Conclusion The panel's durable advice doesn't depend on any vendor: prove changes with automated pipelines before merge (00:19:38), scale scrutiny to blast radius (00:18:11), measure trust through engagement and understanding instead of job title (00:21:04, 00:23:57), keep a named human accountable for approvals (00:26:08), and fund the platform in time, risk and money tied to the teams it serves (00:36:14, 00:40:32). The weak spots are scope and sourcing. The title promises InnerSource and the transcript offers a loose version of it. All numbers are anecdotes or hypotheticals. Octopus Deploy partnered on the production, one panelist is an Octopus Deploy executive, and another works for a platform vendor, so product and customer claims are the speakers' own. **Next steps for readers:** pick one component, assign it a risk tier, and write its contribution guideline with the pass criteria and use cases. Add a branch-triggered pipeline gate before inviting outside changes. Then pilot the time-risk-money frame on one funding request with real figures. Confirm the garbled names (Patrick Debrah's surname, the colleague's article author) before citing anyone. ## 🔄 Refactor Appendix — Octopus Deploy - How to InnerSource your platform > Density: 2–5 Literature atoms (H3 pad), 0–3 Permanent candidates (H4 pad). > Emitted: 5 Literature, 2 Permanent. Resonance filter applied: vendor product anecdotes (Argo, customer licensing savings) were dropped as unevidenced. > > Konik claim-header rules: present tense, declarative, ≤10 words, searchable, unique. > > Atomicity: one declarative sentence per atom. "and"/"also" → split. > > Tag pool: #bmf · #addendum · #xref · #articleseed · #storystem · #share · #aphorisms ### 📚 Literature Split Pad #### [H1] Opening the platform doesn't require strict InnerSource > [!quote] [00:05:13] > opening up the platform to other contributions, it doesn't have to be a very strict inner sourcing model can can help with both of those **Context & use**: - 00:05:13, Cat Morris on the two platform failure modes, low adoption and overload. - Shows the panel's loose use of "InnerSource," which explains why the title promises more method than the video delivers. **Tags**: #xref #articleseed <!-- atomicity: 1 idea ✓ --> #### [H2] Reduced friction stops developers skipping compliance steps > [!quote] [00:17:27] > if you reduce the friction in a good way, that like they won't skip it, they will do it. **Context & use**: - 00:17:27, Patrick Debrah responding to Bob Walker's example of a disabled compliance step at 00:14:35. - Pairs a design principle (easy right way) with the automated-pipeline answer. **Tags**: #xref #aphorisms <!-- atomicity: 1 idea ✓ --> #### [H3] Documentation contributions demonstrate product understanding > [!quote] [00:23:57] > when you kind of demonstrate that yes, I I understand the product so much that I can write the documentation and approve the documentation **Context & use**: - 00:23:57, Bob Walker on how contributors earn trust, continuing the Argo-docs anecdote (a vendor-employee claim). - Usable as a contributor on-ramp pattern independent of the Argo claim. **Tags**: #xref #share <!-- atomicity: 1 idea ✓ --> #### [H4] Human accountability raised agent-merge quality > [!quote] [00:26:08] > the quality go up because of that sense of I I I want to be responsible for that. **Context & use**: - 00:26:08, Patrick Debrah on an agentic tool the captions call "Open Hands." Unsourced; treat as a hypothesis to test. - Connects to the rubber-stamp tipping point the same speaker names next. **Tags**: #xref #articleseed <!-- atomicity: 1 idea ✓ --> #### [H5] Platform teams survive by tying to consuming teams > [!quote] [00:36:14] > tie ourselves to other initiatives in the organization. That's kind of the only way I've ever seen platform teams survive and succeed **Context & use**: - 00:36:14, Cat Morris after the unnamed bank anecdote at 00:34:47. One case, so keep the scope narrow. - Funding frame reinforced by Bob Walker's "time, risk, money" at 00:40:32. **Tags**: #xref #share <!-- atomicity: 1 idea ✓ --> ### 🧠 Atomic Split Pad #### [P1] Automate the proof before you open the platform **Claim** (one sentence, Courtney's voice): A contribution workflow earns trust only when every proposed change runs the full policy and test pipeline before a human reviews it. **Evidence pointer**: [[#H2]] **Scope & conditions**: Holds when changes can be tested in an automated environment. Breaks for infrastructure that lacks realistic test environments or data (00:13:09), and when contributors can edit the pipeline itself. **Links**: - [[Contribution guidelines]] — because extends with stated pass criteria and use cases - [[Agent approval limits]] — because contrasts on who signs off after the pipeline passes - [[Platform engineering]] — because applies-in internal developer platforms <!-- atomicity: 1 idea ✓ --> #### [P2] Fund shared work by tying it to consuming teams **Claim** (one sentence, Courtney's voice): Shared tooling gets funded when consuming teams advocate for it and the request is stated in time, risk and money. **Evidence pointer**: [[#H5]] **Scope & conditions**: Holds where leadership prioritizes revenue and consumer teams have measurable benefits. Weak when the benefit is risk avoidance without a stated likelihood and cost, which the panel calls the hardest sell (00:38:22). **Links**: - [[Time risk money framing]] — because extends - [[Open source sustainability funding]] — because applies-in community budget requests - [[Vendor-partnered panels]] — because contrasts on evidence — the funding advice is anecdotal and one case comes from an unnamed bank <!-- atomicity: 1 idea ✓ --> ### ✏️ Fleeting Queue - [F1] Confirm Patrick Debrah's surname spelling and the colleague-article author ("Steve Hatton") against Octopus Deploy and LeadDev pages before citing: https://www.youtube.com/watch?v=DNnLYV6rvKA #fleeting #inbox - [F2] Find the source for the agentic tool that reversed agent-only approval (00:26:08, captions say "Open Hands") #fleeting #inbox - [F3] Open question: what did the 00:03:04 attendee poll show about InnerSource adoption? #fleeting #inbox - [F4] Article seed: "A panel titled how-to that never defines the method" as a source-literacy case #fleeting #inbox #articleseed - [F5] Try the docs-first contributor on-ramp (00:23:57) in a WordPress contributor workflow #fleeting #inbox ### → Things 3 (max 2 actions) - [ ] Verify panelist name spellings and the cited Octopus Deploy article before quoting this panel: research, 15 min #things - [ ] Draft a risk-tiered contribution guideline for one component using the 13 practices list: platform review #things <!-- deep-read:sections end --> 📄 **Full text:** [[Full Document Contents/Articles/Octopus Deploy - How to InnerSource Your Platform.md|Octopus Deploy - How to InnerSource Your Platform by LeadDev panel (Octopus Deploy speakers; names garbled in captions)]] ## Highlights - [00:04:30] cope? Um both of them are interesting with this topic because I think they both kind of get worse now that AI and agentic stuff is around, like because the in the first scenario, you've built some cool stuff, but now you've got a bunch of agents and other teams building things around the side. That typically is why there's no adoption cuz they've already got a way of doing it and it works which may not have those guardrails that you were mentioning before, Lucy. And then if there are lots more agents, they're kind of the same persona as an engineer would be, just making loads more requests to your platform. So, you're getting hit with even more tickets and even more requests that you've got to deal with. Um So, those challenge they're kind of the two two challenges that that I see and I think inner sourcing or a kind of [00:05:13] opening up the platform to other contributions, it doesn't have to be a very strict inner sourcing model can can help with both of those both by making what you've got more noticed across an organization, so you can use it as almost like a marketing technique to get people involved. Um and then also to provide that functionality that you as a smaller platform team can't provide yourself. So, making those capabilities able and out there for other teams to contribute to. Both both can be helped with inner sourcing in this uh when you've got a platform team that that is struggling to keep up with all the demands of the organization or struggling to find find the people who will be whose needs will be met by that platform. >> Absolutely. Bob, how does that fit with ([View Highlight](https://read.readwise.io/read/01m3yrfc6c48tma2tr6r6tf1e2)) - Note: [H1] Opening the platform doesn't require strict InnerSource - Tags: atom/literature/h1 - [00:17:27] >> Yeah. And I'd like to add to that, like you both talked about having a good process, and Bob talked about like developers skipping tests. There's that golden rule that says like make the right way easy way, or and the other way around, right? Because it it it is called if you reduce the friction in a good way, that like they won't skip it, they will do it. Like that is the thing that you're aiming for. And and the tendency is quite too often like, "Hey, we're we're we're pulling the line here, where it should be like, 'Hey, no, we're we're going to help you get over the line.'" That's a different mentality that you need to do. And that's customer-centric, offering a platform, not just the [00:18:11] infrastructure to your customers as well, so. >> I I also think that there needs to be in some cases a good line of demarcation of what you can allow people to change, and then what you cannot allow people to change. Uh so, for example, you know, it's like compliance policies. So, you might have some sort of OPA policies that you have, where it's going to have a higher degree of scrutiny for any sort of those changes versus, "Hey, this is a step that's called and it doesn't really do a whole lot." Probably has a lower degree of scrutiny uh in terms of the potential impacts, and making sure that you kind of set those appropriate guidelines. And again, as Kat was saying, having that discussion of, "Okay, do we really want to have this change?" If this is something that is ([View Highlight](https://read.readwise.io/read/01m3yrfehzan3mjny7kwffak6h)) - Note: [H2] Reduced friction stops developers skipping compliance steps - Tags: atom/literature/h2 - [00:23:14] things that they would never allowed to have touched before. But uh yeah, making that like a a process uh happening, so. >> Yeah. What's interesting is um so I fun fact may people may not know is that Octopus Deploy were one of the primary contributors to the Argo project, which is a pretty big open source project. And the way that a lot of people get into the Argo project initially, honestly, is contributing to the docs. And so when you start contributing to the docs, you're adding to the docs. And then not letting I would say and I think AI can be very beneficial here, but when you actually truly understand what's happening and you can explain it via the docs, I think it definitely offers a really good avenue to kind of learn the [00:23:57] product. And when you kind of demonstrate that yes, I I understand the product so much that I can write the documentation and approve the documentation cuz I see the the hey, there's a a hole here. There's a problem here. Then I think that kind of starts setting up that trust level of yeah, maybe they are good they could be a good contributor to the actual code base because they truly understand what they're doing. And that ultimately is always a big concern is cuz if you don't understand what's happening and you just submit something uh and you really don't again, you don't truly understand what's going on, it could be a big deal. It could be a big problem. Um but when if you really truly start understanding it, that's when you start trusting people more. When you have to have uh very meaningful conversations. May not even just be contributing to the docs. Could be like, hey, I've talked to the people. As Kat ([View Highlight](https://read.readwise.io/read/01m3yrfgswbk13mejn55p2vdav)) - Note: [H3] Documentation contributions demonstrate product understanding - Tags: atom/literature/h3 - [00:26:08] uh I think it was Open Hands, one of the AI agentic tools that um reverted the decision that agents are only on the approval. Uh and the reason is they saw when they put a human back being responsible, the quality go up because of that sense of I I I want to be responsible for that. Now, there is a tipping point after a while when you're a factory and your code is getting into a shape that you're like almost like the only thing I do is say, yes. There is an annoying face to this. Now, mitigating that risk of an agent saying, yes, then in your in your place is almost saying like well, me as a human, [00:26:52] I accept the risk for the agent to approve this type of things within that environment. But I actually have thought of what the risk is in that area. So, if I'm saying it's okay to I don't know, do something change a page in the documentation, right? That's a different risk than me changing the payment system or changing kind of the authentication system, right? So, what you see now in those agentic pipelines is that there is a review that's happening with like a lot more agent and it's almost like trying to prove what it what it did was a good thing. So, it's convincing you. And then ultimately, all the factories are having ([View Highlight](https://read.readwise.io/read/01m3yrfk6mhg73shf8my42xmtc)) - Note: [H4] Human accountability raised agent-merge quality - Tags: atom/literature/h3 - [00:36:14] to basically tie ourselves to other initiatives in the organization. That's kind of the only way I've ever seen platform teams survive and succeed by the way is like you have to constantly justify your cost and it has to be tied directly to those consumer or end customer teams that will be providing value and you have to show I've made that team go this much faster. They've told me that their cognitive load or their ability to deliver things is decreased like as sorry cognitive load decreased they can deliver more things they're not thinking about all of these other areas that they had to support before. They need to be your advocates just as much as any good external product will have end customers as their advocates through buying more of their services or [00:36:57] telling their friends and referring them like you have to it's you have to get that buying from from those people and have them advocate for you cuz you saying oh well um we've managed to deliver another capability isn't as compelling as six teams have told us that this is essential to their road map and that we've saved them 10 develop like the the time that it took us to do 10 other things so that is that's that's my advice there. >> I've um Yeah, it's it's a really tough thing. I I I usually break it down into four things like how do you provide value right like Kat says hey you know, we're doing this. We're helping the team and or we're helping find team five teams which is great. The other thing ([View Highlight](https://read.readwise.io/read/01m3yrfncknx9jb3gkqysfxx86)) - Note: [H5] Platform teams survive by tying to consuming teams - Tags: atom/literature/h3