Stephen Moody
Dec 28, 2025 - Sep 3, 2026
13
Decisions
0
Active Todos
13
Patterns
Decisions (13)
Sensitive Decision
Hold the write-static-code guardrail at the 98 percent it actually buys - concede the escape case publicly and still refuse to mandate replacing third-party MCPs
At the 9/2 engineering all-hands Peter clarified the missive he had sent two weeks earlier about writing static code rather than pointing Claude at an MCP server. He gave the concrete failure it came from: someone stood up a Claude skill pointed straight at the HubSpot MCP server, and it deleted an org worth of data and 14 customers. The rule he wants: have the AI write Python or JavaScript, scope the token to exactly what that script needs, and let the skill know only that the script exists - not that the MCP server does. Jamin Collins pushed back hard and correctly - an over-helpful agent will eventually route around any tool that is not an actual guard, and once it learns it can, it will stop using the guard entirely. Peter conceded it in front of the whole org twice - he is right, he is completely right - and then held the line anyway: I do not think it is worth throwing out a pattern that works 98 percent of the time because of the 2 percent. If there is a better pattern you want to pitch, I am all for it. He named the tradeoff explicitly: the full fix is replacing each third-party MCP, which means an admin approval process per service, and I do not want to constrain our usage and our experimentation right now. Once we find that a certain set of tooling is really valuable, then it is worth investing in doing exactly that. He framed it as accepting a little bit of risk so that we can experiment as a team, and set the target as getting rid of the 100 percent failure case, not solving every edge case.
Force the stalled GB200 order to move the same day with time, not dollars, named as the governing constraint - and pre-absorb the over-utilisation complaint
On Aug 4 Peter pushed a stalled GB200 hardware order into motion in a group DM with Stephen Moody and Chris Wolford: did we get hardware ordered for the GB200s? If not, lets get something guaranteed moving today. Nvidia is asking for status and wants to see some output from their donation. As stated earlier, time is the important factor here, not dollars. It was reported unblocked two days later. The strategic frame behind it was one he had given the AI Committee four days earlier: NVIDIA is giving us hardware in their data center to use and asking us to light it up as much as we can with a promise that if we completely utilize that hardware, they will just keep giving us more, so my understanding is we have an unlimited check available with NVIDIA - we just have to prove that we will abuse the hardware. He paired that with an open-access instruction when Brady asked who to talk to about getting his hands on it: Nathan. Use it all you want. Just when Scott is responding because it is too utilized, shoot me a note, and I will get in front of Scott. Their commitment is they will give us more. We just have to prove we are going to use it.
Institute the inspectable-function rule for AI data access as company-wide hygiene - and refuse to make it either a shared library or retroactive
At the Friday AI Committee, Peter re-delivered the rule he had set once before and watched not land. He used Mini-Me as the worked example: AI helped create the capability, but AI is not part of the runtime function of accessing the repositories. Claude cannot get to Slack except through that function. It does not have the keys. He asked for exactly one thing - if you are pulling data in or out of a CIQ system, do it through a function that you write and could inspect - and explicitly declined two obvious extensions. He would not make it a shared implementation, because there is no value in building a library of these things and because forcing an MCP server would block people from experimenting with technology being stood up today. He would not apply it retroactively, because a year from now we are going to have 100 times as many tools running around the company, so he is way more worried about the giant tsunami of stuff that is coming. He named three reasons rather than one: inspectability, 100 percent repeatability, and teaching the company the right pattern, since Claude is going to make everybody at the company a developer and that is incredibly terrifying if we do not teach people to be better developers. He extended the bar to local models when asked, and licensed Michelle to publish the message with his name attached.
Purchase approvals below a managers own threshold must never route to the CTO - told Nathan to expense it anyway and took the fight to Finance rather than the person executing the policy
Nathan bought a roughly 100 dollar remote KVM for the NVIDIA DGX Spark so other engineers could access it, after asking Peter first and being told yes. Erin Fong flagged that company-funded equipment must be tracked through an IT ticket before purchase; Nathan said it was not worth the hassle and would pay out of pocket. Peter intervened in three places. In DM to Nathan: No. Tell them No and that the CTO said it was fine. I do not want stuff like this to continue - and, repeatedly, But I already just said you can just expense these things. In the group DM he took the diplomatic line publicly - Nathan asked me prior to purchasing if it was ok. I said yes. Did not know this policy existed. If a ticket can be created rapidly in a way that does not burden Nathan, great - and Stephen Moody opened IT-6605 to document the approval. Then he located the real owner: he asked Steve Wallace whether the policy came from him (it did not, it came from Finance via Erin), and stated the fight he intends to pick: you have a threshold you can approve up to, Nathan has a threshold, I have a threshold. If it is below your threshold and you approved it, I do not want it routing to me. I do not want to know about it. I do not want to think about it. I never want to see it. Separately he coached Nathan on target selection: ask yourself whether you are solving this for yourself, for CIQ, or trying to make Erin recognize the policy is stupid - Erin works for us a couple hours a week and her job is to click buttons on the policy, she does not own it, so there is nothing you can say that will change it.
Sensitive Decision
Approve GPU hardware spend and drive hours-not-days urgency for the Fuzzball/Arcee test cluster
Peter approved procuring and standing up GPU hardware for a Fuzzball test cluster - routing ~240K of GB200 cards he had in hand to the Reno office, approving a ~60K server plus InfiniBand switch (and more if needed), and greenlighting installing cards into the office servers Brady was using. He pushed hard on speed: hours matter, not days. The goal is to get a cluster online fast for Chris Wolford Arcee/Fuzzball work and the board/Nvidia demos.
Reject centralized AI governance and access-guardrails on internal AI tools - optimize adoption and transparency, accept eventual leakage
In the Brian/Brady sync Peter took a firm stance and described a past deliberation he had already resolved: he considered building protections so Mini-Me could not leak personnel and decision info, and decided NOT to. More broadly he rejected Brian Dawsons pull toward centralized applied enterprise AI coordination - teams should deploy their AI-built tools without approval (told Brady to just ship Cairn and expose the agent-to-agent endpoint without routing through Okta), and he would rather pay the eventual cost of a leak than slow adoption. He asked Brian to write down what he is afraid of so the fears can be weighed against each other.
Mariah escalates Stephen Moody project delays directly to Peter (bypass Wallace)
Mariah will notify Peter immediately when Steve Moody delays HR-relevant project work. Triggered by a 6-week unresponsiveness pattern on the Rippling/JIRA integration that Steve Wallace had not escalated. Direct-escalation bypasses the manager (Wallace) for HR-adjacent commitments while Peter assesses whether this is a Moody problem or a Wallace prioritization problem.
AI Governance Single-Track Pivot for ISO 42001
Pivoted AI governance from dual-track (internal vs products) to single rigorous model because CIQ products (RLCAI, Fuzzball, Werewolf) now directly integrate AI, changing the liability profile.
Require mandatory tagging of all fully AI-generated content
AI Committee established policy that all fully AI-generated content must be tagged to manage user expectations. Applies only to fully AI-generated content, not human-reviewed or AI-assisted work. Format and placement of tags is flexible.
AI Policy Governance Approach
Agreed to collaborative governance approach for AI policy: Peter, Nathan, and Max will present AI exploration findings to the AI committee weekly, ensuring engineering innovation feeds into policy development.
AI Bot Architecture Decision
Decided to build a web app to front the AI bot, allowing curated outputs to be shared with Sarah and others without granting direct data access to underlying Slack/email/Jira data.
Related Patterns (13)
Proactive Talent Pipeline Investment
Invest in building leadership bench and talent relationships before there is an urgent need. Use proven relationships from past experience to create optionality.
Accountability Follow-Through
When you issue a warning or mandate with stated consequences, you follow through. Warnings are not threats - they are commitments. The credibility of future accountability depends on following through now.
Executive Sponsorship for Strategic Partnerships
Strategic cross-company initiatives and major client partnerships require executive-level accountability to move at the right pace and ensure proper prioritization.
Small Circle for Sensitive Operations
When executing sensitive strategic operations, keep the circle of informed people as small as possible to prevent leaks that could accelerate hostile action or undermine the initiative.
Protect Engineering Capacity
When external demands threaten to overload engineering capacity, protect capacity by either requiring the demand to come with additional resources, or forcing hard prioritization choices upstream.
Lead by Example with New Tools
When championing new tools or processes, personally use them and share results rather than just advocating. Learning by doing and demonstrating value through example is more effective than mandates.
Protect Engineering Focus Through Process
When faced with requests that would disrupt engineering focus (from sales, governance, product, or other stakeholders), establish processes that protect engineering ability to innovate while still satisfying legitimate concerns. Prefer systematic solutions over ad-hoc responses.
Three-Lever Talent Management
When pursuing a velocity or performance mandate, simultaneously operate on all three talent levers — upgrade (hire better), retain (protect key people), and exit (remove blockers) — rather than sequentially. This creates compounding momentum: exits free capacity for upgrades, retention preserves institutional knowledge during transitions, and upgrades raise the performance bar that justifies further exits.
Purpose Is the Decision Procedure
When someone asks how a process, board, tool or artifact should handle their specific case, Peter refuses to answer on the askers terms. He re-derives the answer from what the artifact is for, states that purpose as the only decision procedure, and lets the answer fall out. Anything found to be serving a second purpose is deleted rather than debated. Tools and views are explicitly subordinate to definitions. He will accept that the askers real problem is simply not solved by this artifact rather than widen the artifact to cover it.
Demonstrate the Standard, Then Collect It
When a new leadership expectation has to land across multiple orgs, Peter does not write a spec. He runs a live exemplar in public with the strongest performer first, says openly that the ordering was deliberate, keeps the form of the deliverable open so the ask stays about the thinking rather than the artifact, lets the delta be self-evident to the people who will have to close it, and then collects the same from everyone else on a named rotation. He prefers showing imperfect work now over polished work later.
Redesign Conditions Over Policing Symptoms
When a direct report names a vulnerability and proposes surveillance-style verification mechanisms (breathalyzers, daily check-ins, monitoring rituals), Peter accepts the disclosure but pushes back on the surveillance model. Treats the verification proposal as a signal that the underlying environment needs redesign — and offers to change the conditions that produced the vulnerability rather than instrument the symptom. Costs Peter optionality (e.g., committing to broker work-hour expectations directly with the partner/spouse) — the asymmetry signals genuine retention vs transactional.
Constrain the Mechanism, Not the Access
When AI or automation raises a governance concern, Peter does not restrict who or what may reach the data. He constrains HOW the reach happens, so the pathway becomes auditable and deterministic. The failure mode he designs against is non-determinism, not leakage - a wrong filter in inspectable static code is a bug you fix once, while a model that sometimes pulls the wrong field is an unbounded, unauditable liability. He will therefore accept imperfect filtering and eventual leakage as the price of adoption speed, but will not accept a non-inspectable pathway.
Pragmatic Technical Middle Ground
When facing competing concerns (security vs innovation, access vs protection), find technical solutions that satisfy multiple stakeholders rather than debating policy or picking sides.