Chris
Dec 19, 2025 - Sep 7, 2026
130
Decisions
1
Active Todos
16
Patterns
Decisions (130)
Let the dual-loop candidate pick her team - then stop the other loop rather than finish it
Kristin Cox was interviewing for open roles in both Justin Haynes org and Chris Wolford org. Bree wanted her steered toward Wolford req on the grounds that it had been harder to find strong candidates for. Peter overrode that without debating it. His instruction: have Bree ask the candidate directly which role she is most interested in; if she picks Justin, stop the Wolford process immediately and get an offer out as fast as possible; if she picks Wolford, let that loop finish. He told Justin to be selfish about it and said he would write to Bree himself. He also stated plainly that all else equal his thumb is on Justin side of the scale, because he is far more worried about delivery on the Linux side of the house than on the Fuzzball side.
Extend Karl Lowenbjer under Wallace and land Atlas and Motherbrain in Engineering
After spending the prior week reading the Motherbrain and Atlas code Karl Lowenbjer built under Tabatha, Peter concluded it was quite good - really well architected and thought through. Chris Baek did not want to keep Karl on the Operations side. In the Thursday 1:1 Peter pitched Wallace directly on taking both the contractor and the applications, telling him he is pretty sure Wallace ends up being the one asked to maintain things like Motherbrain and Atlas anyway. Wallace agreed the same call, having independently run a compliance and security read of the code and landed in the same place. On Saturday Peter DMed Karl himself, told him his contract ends in about a week and a half, and asked whether he wanted to let it end or extend it under Peter - then asked Sarah for 30 minutes with Karl on Tuesday or Wednesday to work it out.
Judge the Atlas code on its engineering merits alone - keep it, port it off the laptop, and stop building skills with direct data access
After a deep dive through the revops-motherbrain repo and a walkthrough with Karl Lowenbjer, Tabatha Wilmot and Chris Baek, Peter delivered a written verdict on 8/31. He opened by refusing the question he was not asked: I am making ZERO statements about whether what this code was written to do is something we need at CIQ - that is a discussion for others. On the code itself: keep the bulk of it. API, frontend, warehouse and agents are independently separable with no cross dependencies. Data access is SQL direct rather than through hallucination-prone skill paths, read-only is enforced at the right layers, the MCP server sits above those layers, test-to-code ratio is roughly 2:3 and the documentation has not drifted. Fixes named: pull the business logic out of the code into a human-readable rule set (he called it the most valuable part of the project), delete the dead Trust Anchor, remove a write token that should be read-only, de-duplicate the mql LLM screen defined in two codebases. The real problem is what runs on the contractor laptop - Claude skills against the claude.ai MCP connector with direct HubSpot write scope, running without asking permission, bypassing the pipeline-approval and closed-edit rules HubSpot enforces on humans. Verdict on the open PRs: approve the move to a consolidated server, do NOT proceed with the interim laptop-resident lead router, fix it properly instead. And a standing instruction: the process of building out skills with direct access to data should stop immediately. In the 8/31 sync with Bjorn and Chris Baek he also confirmed he could pick up and make good use of the code if the contractor who wrote it did not stay - separating the keep-the-code question from the keep-the-person question.
Attack the live-patching gap through Google co-development as a paid deliverable while keeping the req open - buy the timeline, do not just wait for the hire
In the 2026-08-25 Exec Product Prioritization session Peter named kernel live patching as his single biggest capability gap, and said he does not need more heads beyond the requisitions already open to deliver the top of the board - with live patching the exception. Rather than waiting on that hire, he took a 5:15pm sync with Tissa Senevirathne at Google the same day, scoped specifically to whether Google can accelerate the live-patching timeline and whether it can be added as another paid deliverable to the existing engagement. He described the approach to Chris Baek and Bjorn Hovland as throwing co-development options at the wall to see what sticks. The Rex requisition stays open, so this is an additional path rather than a substitute for the hire.
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.
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.
Scope the Atlas review to how it works, not whether it is worth it - and restate the rule that Claude must call a script, never an MCP directly
In the Motherbrain / Atlas sync with Tabatha Wilmot, Karl Lowenbjer and Chris Baek, Peter set the terms of his own code review. He told them outright that he would not wade into whether Atlas is valuable - that is a Tabatha-and-sales question - and that what he wants to answer is how it works, how it is architected, how it stores and persists data, how it does security protections, what should run on a laptop versus centralized, and what the scheduler should be. He asked for the scripts and skills that still live only on Tabatha laptop to be pushed into the repo first so he can read both ends of the system, asked for half-sentence direct answers to Marlon open questions rather than more narrative, and committed to a four-to-five-hour deep dive by Saturday evening with a follow-up the middle of next week. When Tabatha described reps closing deals wrongly through the HubSpot MCP, Peter named the cause - Claude writing code at runtime against a system of record - and restated the standing rule that Claude should never call an MCP directly, it should call a script that structurally cannot do that.
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.
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.
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.
Sensitive Decision
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.
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
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.
Sensitive Decision
Show the half-migrated TPS report to the whole leadership room even though it was not perfect
On the morning of the 7/28 Engineering Weekly, Peter asked in #department-heads-engineering for the repointed TPS report to be shown on that days call in its current state rather than held until it was clean - can you show the current state of the report briefly on todays call, even if not perfect. Ryan presented it in the meeting, flagged that there were 33 items and that the report pulled from the Engineering Deliverables board now diverged from the product-priorities view, and that segment is what opened the 17-minute re-ruling of both board purposes in front of the full room.
Sensitive Decision
Run a Monday state-of-the-Linux storytelling session on pipeline, and have Baek carry the same rah-rah into the all-hands
Acting on a morale signal that surfaced in Gregs round of one-on-ones, Peter committed to sitting down with the Linux org on Monday to walk them through what he is seeing in the Middle East and with Google. He framed it explicitly as storytelling and cheerleader rah-rah about why he feels so bullish, not as a status update, and asked Chris Baek to sprinkle a little bit of the same into the upcoming company all-hands. He gave the diagnosis comparatively - the Linux org is meh on our future while Fuzzball is gangbusters and Ryans org is gangbusters, and there is no reason for Linux to be less positive about our future than everybody else - and bounded the response with it is not a risk right now. Sarah had already blocked Monday for the session.
The NGD board never bends to serve the TPS report - the report changes, and pulls from two data sources if it has to
In the 7/29 Baek 1:1, Baek surfaced the live consequence of repointing the TPS report at the Engineering Deliverables (NGD) board: most of Ryan Smiths work does not belong on NGD under the cross-functional-coordination definition, so Ryans work no longer appears in the report. Baek offered the ruling - under no circumstances should the NGD board change to accommodate it - and Peter took it, then extended it with the remedy: if the TPS report is not showing Ryans work, then the TPS report needs to change and maybe pull from two data sources or whatever, but the NGD board stays the same. Peter also named the recurring pattern he is fighting: almost daily somebody is using these boards for something different than what he said they were for.
Sensitive Decision
Google ELTS: pay or I stop the work - and CIQ eats the disputed 150k out of the existing discount to remove the excuse
In the 7/28 CIQ ELTS payment discussion with Google (Madhu, Alyssa, Arun, Katur and Kelly Hall), Peter went in deliberately hot and said so. Madhu was trying to hold Kelly to account for who made a technical decision back in February, with the implication that if CIQ made it Google would not pay for work since then. Peter refused the premise - these are technical decisions, they get made by the team, they get recorded by your people as the decisions of the consolidated team, and then we move forward - and then removed the money as an obstacle by offering to absorb it against an existing concession: I gave you a 250,000 dollar discount over here, so you are bitching about 150,000. I will shake your hand right now that that is on us. That 250,000 discount just turned into a 100,000 discount. With the excuse gone he put the actual question: are we getting paid or are we not getting paid, and if we are not getting paid I am taking my toys and going home. Madhus boss and others stopped the meeting and committed to closing it out by the next day. The call also ended abruptly, which Peter read as someone telling Madhu to stand down.
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.
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.
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.
Sensitive Decision
Bring Ryan to SKO (Aug 19-21, LA) - make the ask on his behalf and let him choose his own duration
In the 7/23 Ryan 1:1 Peter learned nobody had asked Ryan about the sales kickoff. He decided support should be represented, said he would take it to Chris Baek himself, and explicitly refused to dictate how long Ryan should attend - I am going to turn it around, I am going to support whatever you want. He called Baek the same evening and confirmed back to Ryan an hour later that Baek was on board. Peter himself attends only Thursday the 20th.
Require all agent/LLM access to systems of record to go through inspectable static code, never direct LLM access
Peter opened the 7/24 Jira Automation call with Karl Lowenbjer by setting a condition before taking Karls agenda. The rule: no LLM gets direct access to a system of record. In every instance the LLM writes code that accesses the system, and that code is inspectable by a human or by another LLM. He stated he wants this true for everything Karls team builds, and that as long as it is true he is comfortable. He explicitly accepted that the filters themselves may be wrong - we might make a mistake in terms of what we pull in and out and that is fine, I do not mind mistakes - but the mechanism is non-negotiable. Karl confirmed Atlas already works this way. Peter then closed the topic without further discussion.
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.
Slow-roll Googles request for kernel-build documentation until the contract is signed
On 7/23 Google asked CIQ for documentation on how it builds its kernels. Peter decided to slow-roll any response until after the contract is signed, and said so in both a group DM and directly to Justin Haynes - correct, at least until contract is signed, after that I am fine. He read the motive out loud: they are asking so they can build their own.
Narrow the NGD board to cross-company coordination only - not a deliverables tracker and not a complete decomposition of product acceptance criteria
In the 7/24 Brian Dawson / Brady Dibble sync Peter ruled against the working assumption that the NGD board is the comprehensive ordered list of engineering deliverables. His ruling: the boards only purpose is coordination across the company for things that drive value. It is not for tracking deliverables, not for holding engineering accountable to delivery dates, and does not need to be a complete decomposition of the acceptance criteria in a product ticket. Anything that should not link to a value driver is a component and belongs in Jira, which Peter will never look at. Engineering may blend several product-priority items into one NGD ticket or ship one top-level ticket, as long as the board forms a palette that overlays the product priority and engineering can say when these are done, this product priority is complete. Separately he fixed the product priorities list as strategic priorities full stop - no delivery dates, plus an engineering order-of-operations column and nothing more.
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.
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.
Sensitive Decision
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.
TPM charter + one-owner-per-release accountability mandate (problem/solution/owner grid)
In the TPM sync with Chris Baek, Peter locked an accountability framework: TPMs solve problems and coordinate but do not own engineering processes (engineering owns its own processes and its coordination with Product); every new process must be defined on a 3-column grid of Problem, Solution, and a single named Owner; and every release gets one clear accountable owner (one throat to choke) empowered to make the go/no-go call. The incomplete NGD board is the named blocker, with engineering managers (Nathan, Justin) accountable for completing it so it feeds dates and confidence into the Value Drivers Board bottom swim lane.
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.
Hold the margin line - willing to walk from bad-economics deals (currently applied to Rakuten)
In his 1:1 with Baek, Peter articulated a generalized stance and named its current target: stop playing the tell-the-customer-yes-to-anything game, and hold a hard line even if it means losing the deal. He will not spend 2M to capture 400K. He confirmed this is a generalized principle that at this moment absolutely applies to Rakuten as those negotiations finalize.
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.
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.
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.
Value Drivers Board becomes source of truth for engineering dates and confidence; JPD dates become computed
In the 6/03 working session that Peter recorded (Peter + Nathan + Justin + Chris Baek, during the in-person engineering F2F), Peter locked the architecture that distinguishes the JPD from the Value Drivers Board. JPD stays purely for product strategy and prioritization (not work tracking). The Value Drivers Board is the Engineering-to-GTM coordination instrument that captures context (the why) and dependencies. The concrete decision: engineering target dates and confidence numbers live on the Value Drivers Board engineering lane as the source of truth, kept current on a tight cadence (always right on a Friday), and JPD dates and confidence become computed properties pulled from the Value Drivers Board rather than manually entered.
Take on Value Drivers Board restructure as the next coordination lever after JPD doctrine
In the 6/01 Leadership Roundtable, Peter committed to bring a formal proposal to restructure the Value Drivers Board, explicitly sequenced as the next move now that the product-priorities board (the JPD-doctrine work, closed 5/29) is aligned where he wanted it. Took the Fathom action item to draft the proposal and share with Chris Baek and the group within a couple of days. Triggered by Lindsay surfacing marketing/product misalignment (premature RLC+AMD announcement before AMD validation; Fuzzball multicloud date churn May 28 to June 4).
Sensitive Decision
JPD board scope locked to ordered priority list — Peter drew the line in writing to Nathan
In a long Slack DM thread on 5/27 (~25 Peter messages, 09:15–09:41 AM PDT), Peter rejected Nathan's draft framing for JPD scope and replaced it with an absolute definition: JPD is an ordered list of product's priorities used to drive company strategy, and nothing else. Not project planning, not marketing coordination, not a control surface for engineering order-of-operations. Tickets should be as large as possible and only split when product strategically cares about sub-priority. Value Drivers carry GTM linkage and dates. Every time someone tries to widen JPD scope, Nathan is instructed to push back. Reinforced same day in Baek 1:1 (Peter-recorded Fathom) and surfaces in the RLC cross-functional standup where Nathan is tasked with drafting the formal product-board structure proposal.
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.
Engineering hiring forecast: 2-3 engineers every 6 months, Linux Security next, Bay Area preference
Peter committed to a 12-month engineering hiring cadence of 2-3 net new engineers every 6 months. Next 6 months: Linux Security Engineer (target hire 4-6 months out), plus potentially one more for Nathans team contingent on bug volume. Hiring location preference: Bay Area. Mariah updates the shared headcount/salary forecast spreadsheet to reflect this for Bjorn.
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.
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.
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.
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.
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.
No bugs, only change requests — structural reframe for product/engineering interaction
Peter coached Brady (with Brian Dawson present) to eliminate the bug terminology in JPD/Jira entirely and replace it with change-request framing — borrowed from a CRM system Peter used at a smaller company earlier in his career, where the bug-tracking system had no bugs category type to eliminate the QA-vs-engineering-vs-product debate. Code works this way at this moment, I want to change it. Whether it's a bug or a new request — not material. Brady committed on the spot to roll out the change with Chris and Jamie and through Nathan's team. Brian aligned. Goal: remove the psychological/defensive trigger that makes prideful engineers slow to ship.
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.
CVE response strategy — three-pillar overhaul (process + tooling + strategic kernel review)
In Engineering Weekly Sync, Peter operationalized the 5/11 Leadership Roundtable vuln-handling commitment into three concrete pillars: (1) Chris Baek to restructure the embargo/CVE comms doc with Jamie, separating process from tooling/templates; (2) tooling strategy — Peter commits to email Greg requesting Claude Opus 4.7 whitelist for CIQ accounts AND to set up unbridled internal LLM models on Fuzzball for vuln investigations; (3) schedule strategic kernel philosophy review for early June, with Nathan and Justin to provide a list of downstream automation efforts to prioritize.
Commit engineering to vuln-handling infra/automation at Leadership Roundtable
At the 5/11 Leadership Roundtable, Peter accepted an explicit action item to prioritize vulnerability-response infrastructure and automation work in engineering, and to update Chris Baek as the interim process owner. The commitment converts the 5/8 internal-to-engineering commitment (build/test infra to eliminate reactive interrupts) into a cross-functional commitment with Bjorn, Greg, Chris, and Lindsay in the room.
Peter delivers Reno QBR C-suite intro Thursday — covering Bjorn late arrival
Peter will deliver the C-suite intro at Reno QBR Thursday morning, since Bjorn arrives Thursday afternoon. Peter arrives 8:45 AM Thursday. Greg travels to Houston with Adam for a 1 PM Thursday sales meeting.
Documentation process — Product defines exit criteria in Jira, Engineering delivers
Formalize documentation ownership: Product defines documentation requirements in Jira ticket exit criteria (e.g., docs suitable for blog post). Engineering delivers content meeting those criteria. Product or Marketing (Lindsay) refines technical content into user-friendly format.
Engineering veto required on custom deals and new lines of business
Peter is implementing a formal process where Engineering has review-and-veto authority on custom deals and new lines of business. Engineering must be consulted to assess cost and feasibility before any deal is finalized. Discussed in Peter <> Chris 5/1 and applied immediately to the Everfox proposal restructuring on 5/4.
Sensitive Decision
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.
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.
Sensitive Decision
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.
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.
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.
Agreed to Uber Value Drivers Framework for Strategic Clarity
Agreed with Bjorn and Chris Baek to restructure value drivers into a two-tier system: 'Uber Value Drivers' (Theme/Epic level) that group related granular drivers. This resolves the tension between strategic clarity (too many granular items fail to communicate corporate strategy) and operational granularity (engineering/marketing need precise items to sync on).
Reinforced Product Owns Exit Criteria — Engineering Cannot Unilaterally Remove Requirements
Directed Brady and Brian that Product defines the 'what' and the 'when' while Engineering owns the 'how'. Engineering cannot unilaterally remove requirements from exit criteria. The correct response when a requirement is challenged is 'When can you deliver it?' not to debate or remove it. Forwarded the meeting recording to Bjorn and Chris Baek to align them on this prod/eng interface vision.
Reinforced Product Ownership of Exit Criteria
Engineering unilaterally removed the NVIDIA CUDA toolkit requirement from RLC Pro 9.6 LTS exit criteria, citing lack of automation. Peter clarified in the Brian/Brady sync that Product owns exit criteria and prioritization, Engineering owns the solution and date. When a requirement is challenged, Product asks When can you deliver it - not whether to include it.
Value Driver Consolidation from ~50 to ~3 Core Drivers
Peter demanded that the current list of ~50 'value drivers' be reduced to ~3 core, company-wide drivers that articulate CIQ's mission and differentiation. Called the current list a 'shotgun approach' and 'pile of stuff' that prevents focus. Test: if a product's value pillars cannot be tied to these core drivers, its strategic value to CIQ should be re-evaluated. Also requested a 1-year product vision for RLCAI/RLCH from Brian Dawson.
Set April Engineering Delivery Miss Target at 3-6 Items
Set a specific target of missing 3-6 items out of ~50 April engineering deliverables at Leadership Roundtable. The list contained mis-categorized items, granular sub-tasks, and placeholder dates. Follow-up: Chris Baek and Bjorn to prune the list tomorrow, engineering leads must update Jira with realistic dates by 9am.
RESF JIRA Date Reset for Realistic Expectations
Peter directed Nathan and Justin to adjust April/May JIRA items with low confidence due to RESF resource drain. Move them out now to give marketing a high-confidence scope for 4-6 weeks.
AI/Data Security Audit Commitment to Greg
When Greg raised concerns about CIQ leaking data through AI agents/bots/services, Peter committed to getting Michelle's oversight team to do an assessment/audit of what's running and with what access.
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.
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.
RESF Operational Framework — CIQ Resources Work Under RESF Direction
Established and communicated to entire engineering org that all CIQ work for RESF must be done 100% at RESF direction, with every request flagged for Peter's visibility. Reinforced individually with Ryan (get accounting of in-flight work, ensure RESF person directing), Nathan (hold then green-light Taylor contact with specific messaging), and Mustafa (offer resources under RESF direction, recommend MatterMost for coordination).
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.
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.
Sensitive Decision
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.
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.
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.
Directed March engineering priorities to come from Bjorn (Product)
When Chris Baek asked Peter to present engineering deliverables for March at the Leadership Roundtable, Peter redirected: the top priorities for March should come from Bjorn (Product), not from Engineering. Peter offered to go over them but insisted the framing should come from Product.
Approved retention check-in strategy for must-keep employee list
Approved the must-keep employee list prepared by Mariah and Chris. Committed to personally leading retention check-ins with must-keep engineering employees. Bjorn leads check-ins for his org. Mariah and Chris excluded their own teams (already monitored closely).
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.
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.
Directed AMD inclusion in Project Odin approach document
Peter reviewed Adam Jackson's first draft of the Project Odin approach document and approved it with one specific direction: slides 6/7 should include AMD. Otherwise approved as a great first draft.
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.
Enforced Product-owns-prioritization process with Greg
Pushed back directly on Greg when he tried to route engineering work outside the established prioritization process. Insisted Product owns the priority list and work requests must flow through the proper channel. Simultaneously reminded Chris Baek that his team owns signoff authority and should use it rather than escalating through Greg.
Committed to Anduril attendance with Max
Committed that Peter and Max will attend Anduril events and meetings that are valuable.
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.
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.
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.
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.
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.
Instituted ARR and CVE gap metrics visibility at weekly meetings
Decided to communicate both current ARR (as determined by finance) and CVE gap metrics at weekly meetings. Proactively communicated this to Bjorn and Greg, anticipating potential concerns but proceeding anyway.
Value Drivers document cannot be automated from Jira - fills a gap Jira lacks
Clarified that the Value Drivers Release Plan document cannot be automated from Jira. The document was created specifically to fill a gap in Jira - linking engineering deliverables to GTM deliverables around WHY certain work is being done. Since Jira does not contain this linkage data, automating from Jira would just reproduce the gap.
Engineering dates commitment by Friday - reprioritize for revenue impact
Committed to publishing updated engineering dates/milestones by Friday for Monday group review. Acknowledged January deliverables are unrealistic - many items were newly added and cannot complete in remaining ~10 days. Will reprioritize toward revenue-impacting items first. Tomorrow all-day session with Chris Baek to rework H1 plan into aggressive but achievable targets.
Estimation philosophy: move dates early, hold them late
Project dates should be moved when new information is learned, rather than just dropping confidence when dates pass. Early SWAG dates should be updated once actual scoping begins. Red patterns in dashboards reflect engineers being trained not to move goalposts - this needs to change.
All-Hands messaging: acknowledge Q4 miss, pivot to pipeline optimism
Aligned with leadership on All-Hands messaging strategy: directly acknowledge Q4 revenue miss, then pivot to optimistic outlook highlighting $22M H1 pipeline and unified GTM plan. Peter to present tech updates (service endpoints, Nerf) and guide Mural board walkthrough. No naming specific deals to avoid premature expectations.
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.
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.
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.
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.
H1 Planning Framework - 3-Lane Model
Pushed for the team to focus on ICPs, goals, and milestones rather than getting lost in metrics and mid-level tactics. Established a 3-lane framework (GTM, Value Drivers, Engineering) to align all work.
OSPO Restructure - New Mandate and Leadership
OSPO moved under Customer Engineering (Ryan Smith). Chris Short removed as head. New leadership: Brian Clemons (VP, RESF) and Lee Hennig (former RESF MD). New mandate: govern ALL open source CIQ touches, not just RESF. Top priority: eliminate extinction event risks. RESF board resolution target by H1 2026. Self-sufficiency goal: enable CIQ to internally reproduce Rocky Linux.
ICP Consolidation - RLCH and RLCAI into Fuzzball
Consolidated RLCH (Rocky Linux Confidential Hardened) and RLCAI ICPs with Fuzzball ICPs to simplify GTM. RLCH targets regulated industries, government, power distribution. RLCAI targets AI-inferencing and compute-heavy industries. Rocky Pro kept separate for mid-market RHEL/SUSE/Oracle replacement motion.
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.
Google Scope Change - Hold the Line on Commercial Terms
Google is pushing scope changes that bundle 8 versions into a 5-version contract, omit EOL dates, and include undefined dev streams. This creates scope creep risk and jeopardizes the Extended LTS revenue stream (~$300k/year per product). Decision to personally attend the Monday meeting with Tissa (with Max) to hold the line. Greg will NOT attend to preserve escalation path.
Trinity Quirk & Chris Short Terminations Executed
Terminated Trinity Quirk for failing to progress NARF/CVE automation integration despite clear expectations. Terminated Chris Short for failing to deliver on critical RESF-related goals. Sent transparent communication to all of engineering explaining the WHY behind these decisions.
Friday Layoff List Finalized
Finalized the layoff list for Friday Jan 9: Eli, Derek, Chris Short, Craig, and Trinity. Jason deferred due to ISO certification needs.
NARF Performance Accountability - Public Termination
Decided to execute a public termination within Nathan's org on Monday if NARF deliverables are not met. This is specifically intended as organizational signaling to drive accountability and force motion across the team. A second termination (Chris) may be required for legal reasons.
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.
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.
Chris Short Performance Review Ratings
Finalized yearly review ratings for Chris Short: 2s in Optimism and Efficiency, 3s in other categories. Offered to deliver the review personally.
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.
Championing AI Butler Internal Adoption
Hosted and recorded the AI Dashboard/Butler setup session to drive internal adoption of Claude-based personal productivity tools across CIQ. Shared personal use case of creating meeting prep notes from Slack/email/docs.
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.
Related Patterns (16)
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.
Reclassify to Route - Decide Who Owns It, Then Give a Criterion Not a Verdict
When a question arrives at Peter framed in one domain, he often does not answer it in that framing. He reclassifies it into the domain that actually governs the outcome, which relocates ownership to whoever owns that lane, and then hands down a decision criterion rather than a verdict. The reclassification IS the decision - it determines who decides. He does this rather than adjudicating on the merits himself, even when he was explicitly cc-ed and even when a direct report challenges him on the substance.
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.
Route Non-Differentiating FTE Classes to Partners
When CIQ would otherwise need to staff a function whose work does not differentiate the company — compliance bureaucracy, audit/cert paperwork, ongoing regulatory attestation, etc. — Peter routes the load to a partner who already owns adjacent capability rather than adding the FTE class internally. Org-shape decision dressed as a partnership decision.
Decide on the Precedent, Not the Case
When a request arrives framed as a one-off, Peter does not evaluate the one-off. He evaluates the rule that granting it would write, and answers that instead. Peter generalized this himself on 2026-08-11: it is always about understanding precedent - whether it is a comp change or anything that structurally affects the company. It is therefore NOT a compensation pattern; the domain of the presenting request is incidental. The tell that this pattern is live is that the stated reason for the answer refers to future cases rather than to the merits of the present one.
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.
Metrics Must Follow Strategy
When shifting team priorities or strategic direction, the communication alone will not drive behavior change. Engineers may acknowledge the new direction but continue existing behavior patterns without clear, explicit metrics holding them accountable.
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.