Chris Wolford

Deliver the AI-spend message myself at an engineering all-hands instead of letting the AI committee write a policy

In the 2026-08-27 Ryan Smith 1:1, Ryan argued that the next AI committee meeting should produce a company-wide best practice on AI spend - consensus around spend, do not use Fable for everything, be self-aware of usage. Peter declined the policy framing but conceded the underlying point: the conversation has to happen and has to be delivered directly to engineering rather than routed through a committee or left to individual managers. He committed to an engineering all-hands the following week and flagged it verbally for capture in the moment. He scoped it explicitly to engineering, excluding Ryan own organization.

Aug 28

Diagnose every AI overage case individually and apply the remedy that case calls for - without squashing AI usage

Facing an AI token run rate heading toward roughly 3 million dollars a year, with the top ten spenders accounting for about 95 percent of it, Peter refused both a spend cap and a single blanket fix. He directed each manager to work out why the overage is occurring for their own people, case by case, and to do whatever is appropriate for that specific cause - with the standing constraint that the answer must never be to suppress AI usage. He gave different answers for the cases he had already looked at himself: one engineer at roughly 60k a month is justified and was told to keep going; two others at roughly 100k a month between them are low-return and their manager was already digging in; Zorina team burned 12k in August purely because they were hitting the Claude API directly rather than the enterprise plan, so Justin Haynes action is a plan switch. Peter also declined Ryan Smith push to have the AI committee issue a company-wide best-practice policy on spend.

Aug 28

Accept Bjorn conclusion on the Stratum name while refusing his reason - dont make a decision now that you dont have to make

Naming the new CIQ Kubernetes product. On Aug 23 in the executive group DM, Bjorn Hovland put up five candidates - CIQ Lattice, CIQ Stratum, CIQ Formation, CIQ Maestro, CIQ Marshal. Peter opened against the field with his own pick: my vote is Lattice, Marshal does not fit. Bjorn raised an SEO conflict, that an HR platform already owns Lattice, and Peter switched in one message - Stratum for the win, shrug. Chris Wolford independently backed Stratum and noted Lattice is also Quantum object storage system. Chris Baek started the trademark search. In the Aug 24 Kubernetes sync Bjorn laid out his actual reasoning - that over time he expects to combine the back ends into one and simply route a workload to Kubernetes or Fuzzball, but that is not the world today, so calling it the Fuzzball Kubernetes engine would muddy the waters too early and he needs to run keywords against Kubernetes as a discrete product. Peter agreed with the destination and rejected the route: he gets to the same place for totally different reasons, does not believe Bjorn story about the way the world ends up, and points out that if you do not believe it then you want the thing to have its own referenceable name anyway. Peter also asked that the final form match the naming convention used elsewhere.

Aug 24

Fuzzball Substrate can be an option for the Kubernetes engine, never the only runtime - ship on existing rails or nobody buys the train

In the Aug 24 Kubernetes Weekly Sync, Jonathon Anderson raised whether the new CIQ Kubernetes engine should use Fuzzball Substrate as its default or its only container runtime, framing it as the question that would drive whether Substrate gets open-sourced - a Substrate-by-default engine would put Substrate in far more places and let CIQ target the same worker nodes with both Fuzzball Orchestrate and the Kubernetes engine. Bjorn Hovland split it immediately: default yes, only no, on the grounds that forcing one runtime reduces the usefulness of Kubernetes and CIQ products should be independently viable with value-add tie-ins. Peter argued against both halves from the buyer side, taking the position of a hyperscaler already running Kubernetes and evaluating a switch to CIQ: either CIQ sits on the same Kubernetes they already sit on, which is an easy sale to reason about, or CIQ hands them a pile of validation hoops to clear before a contract can be signed. He compressed it to a rule - it has to include existing rail widths, otherwise nobody is going to buy our trains - and then kept the door open rather than closing it, noting defaults can change over time as Fuzzball starts getting traction. Jonathon withdrew the framing as overstated. Chris Wolford then supplied the decisive fact, that Substrate cannot be the Kubernetes default because the engine would fail Kubernetes conformance testing and lose certification, and proposed it as a user-selectable option in the Pro tier instead. Jonathon concluded the open-source question is therefore deferred, since it only mattered if Substrate were the shipping default.

Aug 24

Govern AI spend by notification and trust rather than a cap - alert at a thousand over, and if the person knows what they are doing get out of their way

Peter met with Steve Wallace and Scott Moody on AI and cloud costs Aug 24 at 11am, then recounted the outcome to Ryan and Bjorn an hour later. What he asked for is visibility plus a Slack notification when someone goes a thousand dollars over their limit, followed by a second one. The rule attached to the notification is not a stop - it is: if you do not know you are doing that, stop what you are doing and figure it out, and if you do know what you are doing and it is right and you are a smart person and it is right, I do not want to get in your way. He explicitly declined a single best-practice standard, differentiating by workload: Sultan costs are fine because he is dealing with a CVE swarm and the right behaviour is solve it as fast as you possibly can, whereas Jason Rodriguez spinning up 13 Opus or Fable agents makes no sense - but Peter attributed that to missing visibility rather than to judgment. He named his own next step as a person-by-person conversation with each leader over what he can now see. Separately on cloud costs he closed the question rather than opening it: the split is 100 percent Fuzzball, and he told Bjorn and Ryan they just need to get used to that being the new normal, while committing to sit with Wolford to slice it up.

Aug 24

Sensitive Decision

Sensitive

Approve the NVIDIA-supported Fuzzball hackathon at SC - with a Wolford engineer on site a day early and a month of hardware notice from NVIDIA

In the L/P Quick Sync on 2026-08-18, Lindsay Aamodt brought the NVIDIA hackathon she has been building - in person in Chicago, Friday November 13 kickoff, build Saturday and Sunday, judging Monday, winner presented in the booth Tuesday as SC opens - and asked Peter to name the risks that would make it a flop in person. Peter approved it and attached conditions: someone who works for Chris Wolford goes on site a day ahead to stand the clusters up, explicitly not Lindsay; and NVIDIA must confirm exactly what hardware they are providing a month in advance so the networking is handled beforehand. He committed himself as a judge alongside Bjorn, Greg and Scott, and Wolford as mentor staying through Saturday.

The five-week leader presentations are baseline once, then deltas forever - show me what you changed to move the number, not the same dashboard

Closing the Engineering Weekly Sync on 2026-08-18, Peter defined what the recurring per-report presentations are for now that nearly every direct report has completed one iteration. He said he is deliberately giving little feedback on the first round because its only job is to set a baseline for each team. From the second round on he wants the conversation to be about what changes the leader is making to drive improvement in the metrics they report, what they are changing when those changes do not produce the expected movement, and whether the metrics themselves should still be the metrics. He explicitly said he does not expect the org to be tracking the same metrics a year from now and that this is fine.

Bake the confidence number on the scope in front of you today - and accept that a 90 percent can slip when scope changes

In the Engineering Weekly Sync on 2026-08-18, Chris Wolford said he could not settle a confidence figure on the Toyota/RC item because he did not know whether the customer would ask for more after their heavier testing had surfaced bugs. He offered to either bump the number or push the date. Peter supplied the method instead: bake the confidence on the scope you have in front of you today, and let the number or the date move if scope changes. He extended it past the item in hand - Wolford answered that he would apply the same to both Toyotas, and Peter said it was for everybody.

Value delivering things over doing work - ship three items all the way out the door and nothing elsewhere, rather than move nineteen forward

Closing the Aug 18 Engineering Weekly Sync, Peter gave the whole engineering leadership group a standing priority instruction: I really want everybody here to value delivering things over doing work. He put it concretely - I would much rather see you do fewer things all the way to completion and get stuff shipped to customers than be reporting status of, look, I am moving the ball forward on 19 different items. And not across the finish line on any of them, but forward on 19 items. I would way rather see us ship three items and do nothing anywhere else. He grounded it in the prior half: we delivered just enough in a bunch of areas to squeak across the finish line. And we built up a bunch of tech debt. He then closed the obvious loophole - I do not want to do less just to do less - and converted the instruction into standing permission to re-allocate: if pulling people off one project and putting them on another is going to allow us to get that second one out the door, let us have a conversation and advocate for that, make that change. The engineering order of operations is the named venue for making that argument.

Refuse to start the incident-response conversation from the premise that an on-call system is needed - require an SLA first, and put accepting overnight downtime on the table as a real option

Ryan brought Peter a plan: after the Portal outage he had asked Justin and Nathan whether engineering had an on-call rotation, got a no, and wanted to build one at the Tuesday Aug 18 meeting. Peter agreed to the meeting, added Chris Wolford to the invite, and then inverted the agenda. His first question would be do we need this - not dismissively, but because he wanted both branches evaluated: accept that some systems are down overnight and publish a status page the way Apple does, or commit to short SLAs and staff an on-call rotation to meet them. He named the decision rule: define the SLA for each class of thing first, and if any SLA is under 12 hours, that implies on-call; if none is, it does not.

Aug 13

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.

Ratify sales engineers owning first-pass demos as the permanent structure - reframing Chris Wolfords self-reported staffing error as having kickstarted the right thing

Chris flagged as a back-of-mind item that he had made the tactical error of letting Godlove and Wolfgang take vacation the same week, and described the workaround he had arranged with Ramesh, Godlove and Horn: sales engineers run first-pass demos, Jonathan supports them, and Chris himself only takes deep dives. Peter converted the workaround into the standing structure on the spot: that is what it should be anyway, so I agree - I am with you on the tactical error, but it sounds like you might have kickstarted the right structure anyway. Sales should be doing that. When Chris characterised it as knee jerk with the plan already in the back of his head, Peter closed the reframe: I know, the pieces were all there. Just forced me to do it.

Sensitive Decision

Sensitive

Give the Fuzzball engineering team the Arcee credit ahead of Bjorn, in writing, in their own channel - then cross-post it to department heads so the framing is on the record

Arcee closed on Aug 6 - the first major Fuzzball deal, to an AI lab that will run a model training run on the product. On Aug 7 Peter posted a note to #fuzzball that opened by naming and then subordinating the commercial credit: Bjorn pounds his chest about getting the deal across the line (and he earned that - he was hounding them daily). But you are the reason there was a deal to close. They did not buy a pitch. They bought Fuzzball. Everyone here understands that, and I want to make sure you hear it from me directly. He acknowledged the cost - I know about the long nights and weekends that went into making that happen. Thank you. It is not lost on me - and then added three forward statements: the standard is now understood so this gets easier from here, Arcee is the first of these and it is the worst Fuzzball deployment that is ever going to happen, a reference customer changes the conversations we get to have with the next AI lab and with investors, and this team has changed gears and is holding the pace, which is the hard part. He then reposted the whole message into #department-heads with the framing just so you all have visibility into what I am telling the Fuzzball engineering org. He had told Chris Wolford in their 1:1 that morning that Bjorn will pat himself on the back for getting the deal across the line, and yeah, he was hounding them daily, but your team did the work - and tagged Mini-Me in the same breath to remind him to send it that evening.

Treat prototypes crossing from Product into Engineering as a feature rather than a burden - the code is worth two days, the market learning is the payload, and every one arrives with headcount

Justin raised Elm - a prototype somebody had been building for about three weeks and which was apparently launching the following week - and assumed it would eventually become his problem without the bandwidth to carry it. Nathan had objected in stronger terms that we cannot launch things without engineering being deep into it. Peter sided against both of them and with Bjorn, and gave the reasoning in two parts. On the code: it is a prototype, nothing more than a prototype, the amount of code there is not more valuable than two days, it would take two days to recreate it from nothing, so when it does come over to our side of the fence it is not like we are burdened with a pile of architecture that is terrible and horrible to manage. On what actually transfers: all we are burdened with is what we have learned in the market about what people want from it, which is an awesome thing to be burdened with - because now we are burdened with these two customers wanted to do these things, instead of Brady woke up one day and had a brain fart and decided that this is what a product should do. He then removed the capacity objection three separate times: it will come with headcount. Two, and you are seeing Ascender come your way with headcount, period. Everfox desktop with headcount, Kubernetes with headcount. So it will come with headcount, period. He named the contrast with their shared past - it is a very different model than anything we would have done at Amazon - and pushed the logic further with Bjorn, suggesting Satellite be announced with a go-to-market and a feature list without actually making the software available, to see who rings our front doorbell. He also accepted Justins counter-constraint on feature bloat and added his own: we can cut features too, I do not mind us removing features and seeing if nobody ever notices.

The 1:1 tracking spreadsheet becomes Nathans choice - suggest, do not mandate - but whatever replaces it must be measurable and must never go to HR

Nathan asked whether Peter still wants his direct reports using the individual 1:1 tracking spreadsheets, noting he is not leveraging them much right now. Peter released the mechanism and held the outcome: Look, I find them useful. I am confident at this point that I have spent enough time going over them with you. I am happy transitioning more to you decide if they are useful. My answer is I suggest yes, but I do not mandate yes. And if you have a better way, that is super fine. Two constraints attached. First, if Nathan builds a different method, that method is what he presents at the Tuesday engineering sessions - this is how I am managing my team - with Wolfords different approach as the contrast case. Second, the hard requirement: I just want to make sure there is something there that is measurable, that is driving conversations about whether people are doing what you want, and that there is some sort of a record produced as part of it that does not go to HR so that it is open and honest and unpolluted. Peter also said he will keep pulling them out from time to time and is moving his own cadence with Nathan from monthly to roughly quarterly. He gave Steve Wallace the same latitude the same day: what I care is that there is something documented between you and employees that you can point to, whether it is the spreadsheets or not is not the important point for me.

Jul 30

Sensitive Decision

Sensitive

Sensitive Decision

Sensitive

Every org owes its own delivery-performance metric system, and Wolfords dashboard is the deliberate exemplar - used to train the Linux side of the house

Peter restructured the 7/28 Engineering Weekly into a fast breadth-first TPS pass followed by a single-org deep dive, and made Wolford go first on purpose. After Wolford walked through his PIC tooling - PR review latency, time-to-merge, bug-vs-feature ratio, commit distribution, release cadence, internal and external documentation coverage, plus a per-quarter epic assignment board - Peter named the ask explicitly: I dont care whether there is a dashboard or just a system that reports a set of metrics, but this is the kind of thing I am going to be looking for from every org. It is not an accident that Wolfords going first here. He then propagated the exemplar three ways: forwarded the Fathom recap to Bjorn saying he was using it to help train the Linux side of the house, told Nathan to watch the recording because there are critical things in there that will impact your teams and that I want to be able to talk through in terms of team management, and told Wolford directly that the presentation was exactly what I wanted/needed to kick that all off - while warning him you will not be impressed when Linux and the other portions of eng deliver theirs. Sarah set the rotation: Wolford, then Nathan, then Steve, Ryan and Justin.

Jul 29

Re-ruled the two boards from first principles in the room - prioritization vs dates-and-confidence - and told the org to delete any column serving a third purpose

Seventeen minutes of the 7/28 Engineering Weekly went to re-landing the board doctrine after Ryan reported that Chris Baek had told him all work must move to the Engineering Deliverables (NGD) board. Peter said flatly he is wrong, then re-derived both boards from purpose. Product Priorities board: prioritization only - not work tracking, not delivery dates, not confidence numbers - and engineering continues to own the engineering-order-of-operations column that has existed for nine months. NGD board: only work that must be visible to the company because it is tied through value drivers to go-to-market, with exactly two required fields kept current in real time, a confidence number and an engineering target delivery date, and no statement about whether items are epics, stories or tasks. He also ruled that Wolford does not get to choose whether his work appears in NGD, that internal-quality-only work should not be on NGD at all, and that where duplicate order-of-operations columns exist the answer is derivable from purpose - if there are columns there to serve any other purpose, they are wrong, remove them.

Jul 29

Make metric design the single biggest ask of Max - 10 auto-reported metrics spanning Justin and Nathan, delivered by Thursday

In the Max 1:1 Peter redirected Max away from personally fixing NARF reporting bugs and toward crafting the metrics that Nathan and Justin will present against at the engineering all-hands and the Tuesday meeting. Peter framed it as if I have a single biggest ask of you, it is help craft that. Max committed to writing a list of the ten most interesting metrics he would want reported automatically in a dashboard anyone can look at any time, spanning both Justin and Nathan, by their Thursday 1:1. Peter stated he will work Nathan on the people-management side but wants to do it through the lens of achieving those metrics.

Jul 27

Sensitive Decision

Sensitive

Hand mainline TPS report ownership to Ryan pointed at the NGD board; abandon Peters private fork and deprioritize the Linux software-delivery lifecycle doc

In the 7/23 Ryan 1:1 Peter made three linked calls on his own reporting stack. First, Ryan takes ownership of getting the mainline TPS report pointed at the right source - now that the NGD board sits as a layer below value drivers, the report should point at that. Second, Peter drops his own private branch of the TPS report and will consume the mainline one instead. Third, he explicitly deprioritized the Document Lifecycle for how we deliver software in Linux item that carries both Ryan and Max names - if you see that in MiniMe, that is not my highest priority - and said he will push Max on it separately. He also declined Ryan offer to deliver by tomorrow: I do not need it tomorrow.

Jul 24

Institute a rotating per-team deep dive at the Tuesday staff meeting, anchored on empirically measurable metrics co-designed in the room

Peter gave the same instruction independently to Chris Wolford and Steve Wallace on 7/23. Each org lead will take roughly 45 minutes of the Tuesday staff meeting on a five-week rotation. Three parts: a functional overview or demo of what the team delivered in the last month and is working on next; a project-plan view with milestones, tracking, who is on what, and how team time is being spent; and a set of empirically measurable metrics. The metrics do not have to be right the first time - the explicit purpose of doing it in front of peers is to argue out which metrics are the correct ones for each org. Metrics differ by domain: on the Linux side Peter wants automation measures such as the percentage of PRs auto-approved by Nerf versus human-approved; on PIC Chris proposed PR volume and the rate at which releases require bug fixes over time. Chris Wolford presents first, Tuesday.

Jul 24

Sensitive Decision

Sensitive

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.

Jul 21

Sensitive Decision

Sensitive

Champion Kubernetes-by-CIQ as an H2 engineering deliverable (build on the standard)

Peter is actively pushing for a CIQ-branded Kubernetes offering, built on the standard rather than reinvented, to be an H2 engineering deliverable that eliminates a recurring objection in sales conversations. He green-lit Chris Wolford putting Kubernetes by CIQ on his H2 doc. It fits the broader turnkey/easy-button vision (single installable image combining Rocky Hardened plus Fuzzball substrate). Peter acknowledges final product prioritization authority sits with Bjorn/Product; his action here is advocacy and engineering-roadmap steering, not a prioritization decree.

Jun 30

Repair the mis-framed Engineering All-Hands - hold a PIC/Fuzzball follow-up and proactively notify the slighted PIC team

After Jonathan Anderson and others read the recent State of Linux session as the Engineering All-Hands - leaving the PIC team feeling ignored - Peter diagnosed it as a framing/naming failure (Linux-only, Wolford not on it, no Fuzzball content) and directed the fix: a PIC/Fuzzball-focused follow-up session in the next few weeks, Baek to own the Fuzzball angle, and the PIC team to be told now that it is coming because yesterday was bad for them - they felt completely ignored.

Jun 18

Mandate 24-hour Sev-1 outage auto-escalation to estaff and AE

After the Fyr Fuzzball outage ran roughly 5 days without surfacing to leadership and the customer had to ping Horn directly to force escalation, Peter directed that any Sev-1 or customer outage open past 24 hours must automatically notify estaff and the account AE, built into tooling so it does not depend on a human judgment call. Ryan operationalized it as Zendesk automation plus CCing named-account AEs at ticket creation.

Jun 17

Gate NVIDIA/Spark announcement on engineering supportability — eng-only until then, then hand to GTM

With NVIDIA engagement happening at very high levels over the next week, Peter decided to say nothing publicly and not pre-announce anything until CIQ has something it can support — something it would actually ship and point a customer at the support org for. Until then the Spark/Rocky-on-Spark work stays purely engineering (get it on Nathan, Wolford, Westley, and Peter own Sparks; validate it works), explicitly not a Bjorn/GTM item. Once it is supportable, GTM is unleashed.

Jun 12

Greenlight Chris Wolford on continuous recruiting — always be fishing, no open req required

Peter granted Chris Wolford standing latitude to recruit continuously: fill his two current open reqs, but also keep feeding recruiter Bree candidate profiles and interviewing strong people even with no open req. Extends Chris a trust-gated operating model to build a faster-paced bench rather than hiring only against approved headcount.

Jun 5

Peter Computex condition: product must be production-ready, not a POC

For the proposed early-June Computex Fuzzball-on-DGX-Spark announcement, Peter set one engineering-side condition: the product must be production-ready (not just a POC). Bjorn separately set the GTM-cadence gates (max 6-week lag between announcement and delivery; sufficient PR-runway for Lindsay and Cathay). Peter held the engineering line cleanly and let Bjorn hold the product-marketing line.

May 27

Kyle move conditions: permanent (no return) and gated on RLC completion

If/when Kyle moves to Gregs research team, the move is permanent with no path back to Wolfords org. The gate is Kyle completing his current RLC commitments first, not just Wolford filling the backfill rec. Greg owns the conversation and setting expectations with Kyle on self-management and performance; Greg will update Peter and Bjorn on Kyles decision.

May 27

Cedric placed full-time on Gregs research team; Kyle still pending Gregs conversation

After the C-Suite Sync surfaced the Kyle/Cedric risk asymmetry (Kyle = low performer needing hard deadlines, Cedric = high-output engineer well-suited for rapid POCs), the research-team assignment from yesterday flipped: Cedric is now the firm full-time mover to Gregs research org, while Kyles move is still open and gated on Greg-owned conversation + Kyle finishing his RLC commitments first. The Wolford backfill rec opens regardless of which one moves.

May 27

Refuse holiday-weekend pressure on people — Mariah review deadline AND Ryan reviews

Two paired actions on 5/24. (1) When Mariah pushed Peter Sunday evening that mid-year reviews were 50% complete on the day-of deadline, Peter held the line — no pushing direct reports who are on a 3-day holiday weekend. Drew distinction between the people who plan ahead (will finish on time) and those who do not (will finish Tuesday night either way). Committed to thinking about better engagement separately. (2) Same evening Peter DMed Ryan: I am not going to read your reviews today or tomorrow — you should take a break. Same posture applied to a direct report Peter could see was burning out from a hard week.

Firewall Greg AI prototyping team — company makes no plans against their output

Peter explicitly framed Gregs AI prototyping work as a separate research division that the rest of the company cannot bet on. No items show on the value drivers board for this work; nothing is committed to customers; deliverables are not on engineering plans. If they emerge with a usable nugget, fine — Wolfords or Nathans team will productize it. Until then, planning treats the team as if it does not exist.

Kyle conditional move to Greg AI role gated by filling Wolfords rec first; Cedric written off the Fuzzball team

Kyle reached out to Greg directly about the AI role reporting into Greg. Peter aligned with Greg and Chris Wolford on the following: (a) Kyle stays in Wolfords org through end of June while the new tickets land; (b) Wolford receives Gregs open rec immediately and starts hiring; (c) Kyle does not move until that rec is filled; (d) Kyle is told this is a job change, not a trial — if it does not work in Gregs world he is out, same as any other role mismatch; (e) Peter will tell Greg that Cedric is NOT meaningfully delivering on Fuzzball today (he is a part-time advisor at best while building for Greg), and Wolford will plan as if Cedric does not exist on the team going forward.

Slip Fuzzball V4 date now and drop confidence rather than fight to hit it

In the Chris Wolford 1:1, Peter coached Chris to take the V4 target date (end of May, 80% confidence) out by ~2 weeks immediately, drop the confidence number now if his gut said 50-50, and tell the team explicitly: we are sliding so we hit. Frame the new date as a high-confidence communication contract with Go-to-Market (Lindsay) rather than a hope.

Jira confidence-as-contract doctrine codified across engineering directs

Codified explicitly in Justin 1:1 5/21 and same-day endorsed via Chris W DM: Jiras confidence number is a communication contract between engineering and GTM. Rules: (1) drop confidence immediately when a date is at risk (e.g., 80%→50%), (2) slide the date by a calculated intentional amount, (3) once confidence is high (95%), the date is a firm commit and must be hit even at extra cost, (4) treat ALL work as change-requests (no bug-vs-scope debate), (5) any change in understanding triggers immediate date/confidence updates. Engineering Order of Operations vs JPD prioritization formally separated: engineering owns operational/health priority (e.g., image build pipeline rework), JPD = product-value priority. Significant misalignment triggers a conversation. Same doctrine to be rolled out to Nathan and Max next.

May 21

Kyle AI transfer approved with hard conditions; Gregs AI team codified as research firewall

Approved Kyles move from Wolfords Fuzzball team to Gregs AI team. Conditions: (1) Kyle stays on Fuzzball through end of June to finish RC tickets, (2) Chris receives Gregs open AI rec immediately to start backfill hiring, (3) transfer only happens after replacement rec is filled, (4) move is permanent — not a trial; failure to perform in AI role = out (not back to Fuzzball). Same turn with Wolford codified the broader doctrine: Gregs AI team operates as a research division firewall — the company plans nothing based on its work until a proven nugget of gold is delivered, and Cedric is now assumed unavailable for Fuzzball planning.

May 21

Ascender Pro Dev JD scope finalized — application engineer to de-risk Jimmy, pulls Ascender dev into Peter org

Joint Peter/Bjorn/Jimmy/Brianne meeting 5/14: title is application engineer (intentionally NOT Ascender-engineer — allows cross-project use), $180k mid-senior, 6-8 years experience, React + Python primary (50/50 front-end/back-end), Go a plus, go-getter required (must keep pace with Larry and Jimmy who are both super-fast). Interview panel: Brianne, Jimmy, Larry, Chris Wolford. Peter optional final (Bjorn pushed Peter onto panel: I trust Peter's interviewing). Brianne posts JD by weekend / Monday. Will report into Peter's org, location-within-org TBD. Bjorn's framing: pull all Ascender development under [Peter's org] form.

May 19

Engineering QBR format — collaborative discussion with three topics, not a presentation

Peter directed that the 5/22 Engineering QBR will be a collaborative working session rather than a formal presentation, organized around three questions: what is working well, what needs improvement, and how to streamline communication and increase work visibility. Chris Baek owns the shared prep doc that will collect bullet-point inputs from engineering leads ahead of the session.

May 13

Sensitive Decision

Sensitive

Manage Wesley via Greg; set boat-anchor trigger with Chris (preserve optionality)

In the Chris W 1:1, Peter decided to manage Wesley's performance situation through his Greg relationship rather than moving Wesley onto a PIP or active weekly-1:1 performance track like Cole and Thomas Chin. Assessment: Wesley is capable but slow, requires handholding, won't operate at senior/principal level, but is not a net negative. Chris asked to proactively flag if Wesley becomes a boat anchor on team productivity — that is the threshold for escalation.

Apr 18

Delivered Jira Hygiene Mandate to Engineering

In Engineering Weekly Sync, mandated immediate improvement in Jira hygiene after presenting 3.5 months of data showing >50% of tickets updated after their due date (most slips 2-4 weeks). Prioritized communication over speed — proactive updates required, aggressive initial targets (20-30% confidence) acceptable. Directed Chris Baek to add a 'blocked reason' field to Jira for stakeholder visibility.

Apr 17

Sensitive Decision

Sensitive

Delivered Jira Hygiene Mandate to Engineering

Apr 15

Delayed HR action pending Chris feedback in upcoming 1:1

When Mariah proposed proceeding with an HR-related action, Peter declined, saying he wants to get feedback first from Chris about how it's going in his 1:1 with Chris this week. Mariah acknowledged and asked to be kept posted.

Apr 14

Committed to engineering date hygiene confrontation with directs

Peter publicly committed in Leadership Roundtable to holding a tough conversation with his directs about deliverable date hygiene. Requested date-slip magnitude data from Chris Baek (days vs weeks) to focus on significant delays rather than minor variance.

Apr 14

Established Fuzzball AI validation process

Committed to validating Greg's Fuzzball AI marketing claims before they go external. New process: Greg/Jonathan provides desired story, Peter documents engineering tests required, engineering validates and gives thumbs-up/down. HumanX conference in 2 weeks is the forcing function.

Mar 25

Fuzzball SaaS Prepaid Token Billing Model with Unified Portal Backend

Drove adoption of prepaid token ('CIQ Tokens') billing model for Fuzzball SaaS MVP, with unified Portal backend as single source of truth for all user accounts and token balances. Free tier deferred to fast-follow. MVP requires account + credit card to run workflows.

Mar 21

RESF Impact — Consolidated Marketing Alignment Meeting

Decided to schedule a single, consolidated meeting with Chris Wolford and Marketing to align on a new delivery schedule once the full RESF impact is known, rather than piecemeal schedule updates.

Mar 11

Westley Transition — 70% Fuzzball, Maintain Depot Support

Westley will start transitioning to Fuzzball at 70% allocation while maintaining depot support work for Justin team until fit is confirmed.

Mar 6

Toyota POC — No Hotfix, Demo MPI and PBS Separately

Decided NOT to rush a hotfix for Toyota's urgent out-of-scope MPI-via-PBS request before their Thursday director meeting. Team will demo MPI and PBS as separate working components, explain the integration bug is known, and commit to fix in ~1 week by the March 17 Reno meeting.

Mar 5

Team Building Mandate — 6-Month Priority Over Features

Directed all engineering managers to prioritize team building over feature delivery for the next six months. Includes permission to swap out low performers, with Peter providing air cover for the risks involved.

Mar 4

Escalated Ian Kaneshiro retention to CEO level

After learning Ian Kaneshiro (PIC team, reports to Chris Wolford) resigned to join an AI startup, Peter immediately directed a retention escalation: told Mariah to get Greg talking to Ian, told Greg to do anything to keep him. After learning Ian had already accepted and wouldn't go back on it, shifted to ensuring the door stays open for a future return.

Feb 24

Directed Fuzzball team to improve logging and error observability

After AMD MI300 troubleshooting meeting, directed Fuzzball team (Jonathon Anderson, David Horn) that the product needs better logging and error visibility. Customers should be able to self-diagnose issues via log files instead of requiring live troubleshooting meetings with CIQ engineers.

Feb 20

Coached David Godlove on sales-focused approach for AMD Fuzzball presentation

During the AMD Fuzzball overview meeting, coached David Godlove via DM to maintain a sales mindset rather than defaulting to engineering transparency about product limitations. Emphasized that the goal was to make AMD want to recommend Fuzzball, not to give a technical peer review.

Feb 6

Committed to Anduril attendance with Max

Committed that Peter and Max will attend Anduril events and meetings that are valuable.

Feb 2

Recommend partial bounty payout for Fuzzball single-binary work

Recommended paying out half of the originally established bounty to the team members who completed the Fuzzball single-binary work. Want to use bounties as a repeatable, low-friction model across engineering and ensure all of engineering knows about the payout.

Jan 31

Directed output-based management approach for underperforming engineers

Directed Chris Wolford to shift from activity-based to output-based management for engineers Kyle, Thomas, and Cole. Set ambitious goals (2x output), measure only results, give underperformers a short window (2 weeks) to meet targets, and replace them if they miss. Guaranteed headcount back for every open chair for the next 6 months.

Jan 30

Advocated for PIC team progress to Greg

Reported to Greg (CEO) about satisfaction with Chris Wolford team improvement and transparency. Thanked Greg for going into PIC Demos meeting with open mind despite having strong opinions. Highlighted Ian Kaneshiro as fantastic.

Jan 28

Approved Greg-Cedric engagement starting Monday

Approved Greg beginning conversations with Cedric on Monday to provide context on upcoming PIC work. Cedric will continue participating in epic scoping sessions to stay connected to the tactical work.

Jan 23

Conference Travel Approval - David Godlove HBCSF

Approved David Godlove travel to speak on Apptainer at HBCSF conference in Chicago in late March (~$2,200 cost). Required Chris Wolford to coordinate with Lindsay (Marketing) and Chris Baek (Finance) as part of the approval.

Jan 16

Product Roadmap Overload - Challenge Product on Prioritization

Directed Chris Wolford to push back on Product for a clear separation of critical path vs nice-to-have items in the H1 roadmap. Current roadmap is overloaded and risks critical path items.

Jan 16

Strategic Map Framework - Value Drivers vs Internal Efficiency Separation

Established new H1 strategic planning framework that separates customer-facing Value Drivers from Internal Efficiency Drivers. Framework uses three lanes: middle lane for Value Drivers (the WHY), top lane for GTM activities, bottom lane for engineering deliverables. Also established phased estimation process: low-confidence ballpark dates first, then engineering-only session to raise confidence.

Jan 15

Work intake must flow through managers, not directly to engineers

Established new process where small customer requests go to Engineering Managers (Justin, Chris W.) for approval. EMs will attend bi-weekly CECA board review to ensure they are in the loop on incoming work.

Jan 14

H1 Planning Framework - 3-Lane Model

Introduced a new 3-lane planning model to address GTM and Engineering misalignment. Top Lane (GTM): marketing campaigns, messaging. Middle Lane (Value Drivers): the why - market state change, ICP, business significance. Bottom Lane (Engineering): deliverables driven by Value Drivers.

Jan 12

H1 Planning Strategy - Aggressive Goals with Staggered Milestones

Articulated H1 strategy: shift from hope to concrete plan with aggressive audacious goals. Achieve goals differently not just faster. Staggered milestones every 4-6 weeks for course correction. Missed milestones trigger retrospectives for process or personnel changes. Clear prioritization at Reno eliminating everything is P0 problem.

Dec 31

Fuzzball SaaS - Defer Pending Technical Alignment

Rather than making a call on Fuzzball SaaS viability concerns raised by Chris Wolford, directed Chris to align with Jonathan (who has pitched cloud-native ideas) to form a unified stance. If they reach opposing conclusions, escalate to Peter. H1 planning docs to proceed with caveat that SaaS initiative is pending alignment.

Dec 29

Talent Introduction for Fuzzball Org

Introduced Meena Rajvaidya to Chris Wolford via email, recommending her as a senior leader for the Fuzzball org with deep experience in monitoring/visibility.

Dec 19

Talent Introduction for Fuzzball Org

Introduced Meena Rajvaidya to Chris Wolford, recommending her as a senior leader candidate for the Fuzzball org, noting her deep experience in monitoring/visibility from when she previously worked for Peter.

Dec 19