Operational Decisions
50+ recent decisions
Collapse nineteen engineering titles into four groups - and put senior principal back only if a manager makes the morale case
Sep 7, 2026 · operational · low74% confidence
In the Nathan 1:1 Peter walked the leveling sheet and set the target explicitly: nineteen distinct titles across sixty people becomes four titling groups. He opened by declining the framing Nathan offered - this is not about correcting overinflated titles, it is about simplifying titling - and said his religion is the simplification, not any specific person. He asked Nathan to validate the mappings for his own people and to build planned promotions into the exercise rather than run them separately. On the senior principal tier, which the collapse removes, he did not decide unilaterally: he asked Nathan to probe Andrew Jorgensen and Jamie Maple on how much they actually care, and said if Nathan argues that senior principals are needed to manage morale on his team, Peter can get his head around engineer plus senior engineer and principal plus senior principal. He also told Wallace the same day that the leveling has cleared Greg and Mariah and that he will sit down per-org to make a plan, committing to Wallace next week after slipping the intent to do it this week.
People: Nathan Blackham, Steve Wallace
Put the NVIDIA Spark bootable-Rocky USB on Justins org - and size it to carry meeting materials
Sep 3, 2026 · operational · low61% confidence
On 9/2 Arthur Tyde asked whether CIQ could produce a Rocky-on-NVIDIA-Spark artifact for events. Peter confirmed the current Spark version of Rocky already is a bootable USB stick and called it super doable, then named the constraints and the owner. Constraint one: the image he holds is old, the current one sits with someone who is out, and he expects to have it in a couple of weeks. Constraint two: it only runs on an NVIDIA Spark - a Mac or other target would need different packaging and drivers, which is a separate ask. He then allocated the work outright: Justins org can build something. He also specified the form factor rather than leaving it open - small ones are fine, like a 128 gig would allow us to include additional meeting materials - turning a bare boot stick into a carrier for collateral.
People: Arthur Tyde, Justin Haynes
Deliver the AI-spend message myself at an engineering all-hands instead of letting the AI committee write a policy
Aug 28, 2026 · operational · medium77% confidence
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.
People: Ryan Smith, Chris Wolford, Steve Wallace, Steve Moody
Diagnose every AI overage case individually and apply the remedy that case calls for - without squashing AI usage
Aug 28, 2026 · operational · medium81% confidence
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.
People: Justin Haynes, Chris Wolford, Ryan Smith, Nathan Blackham, Steve Wallace
Shut down department-heads as an intake path for engineering work - I raised it to product, they will either ask for it or they will not
Aug 28, 2026 · operational · medium89% confidence
In a #department-heads thread about who owns and maintains the C3 RPMs and about hardware certification playbooks, Ryan Smith offered to tweak Gauntlet to run certification playbooks and asked for hardware to be sent to him. Peter cut it off directly: this channel is not how work gets in front of engineering. He restated the path he had actually used - he asked who maintains it, got back currently nobody, and took the follow-up question of whether it should be publicly visible to product, where Brady Dibble owns it. If product asks for it, it becomes a project and gets the right people and the right hardware support.
People: Ryan Smith, Nathan Blackham, Brady Dibble, Dave Dickerson, Greg Kurtzer
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
Aug 24, 2026 · operational · medium87% confidence
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.
People: Steve Wallace, Scott Moody, Ryan Smith, Bjorn Hovland, Chris Wolford
Extend abort-the-loop authority from the hiring manager down to every individual interviewer - anybody can pull the ripcord alone, without a debrief or consensus
Aug 21, 2026 · operational · medium70% confidence
At the close of the Friday roundtable the hiring manager mentioned that he already pulls candidates before they reach a debrief, so the panel will not see a roundtable for everyone they interview. Peter extended that authority downward rather than leaving it with the manager. He said he is a huge believer, we are a small team, everybody on this call is a super smart individual, and he is really comfortable with anybody just pulling the ripcord on an interview and saying this one is not moving on. He added that in past environments he was fine with someone standing up and walking a candidate out mid-loop on the grounds of not wasting anybody else time. He explicitly declined to impose it - the hiring manager might not be comfortable with it and Peter said he would leave that up to him. The hiring manager then agreed, saying at this stage in the game he was happy to do that. The exchange happened immediately after a debrief in which the panel had spent roughly twenty minutes on a candidate they all ended up rejecting, and after two of them had traded stories about aborted loops at a previous employer.
People: Nathan Blackham, Andrew Jorgensen, Jonathan Dieter
Move the metrics conversation with Nathan off the tooling and onto the why - which metrics, which were discarded, and how the team is told the reason
Aug 21, 2026 · operational · medium89% confidence
Peter closed the Nathan 1:1 by resetting what he wants from the metrics workstream. He stood it on the foundation that if you do not measure it, it does not change. He then said Max document was a fine first cut and he does not know whether Nathan wants to use it, but that is not the conversation - it is not about what Butler shows. Butler is just building a tool and it will not show me the whys, and it is the whys I want to talk about. He named the specific agenda for the next 1:1: why this metric, why this metric, which metrics you have discarded, and how you are communicating them to your team so they understand why you are tracking certain things. He connected it to his standing complaint that he is not seeing the change in pace he wants and that pounding that drum gets him nowhere - he wants to engage in the concrete bits of what Nathan is holding people to and why, acknowledging that Nathan knows how his own org will respond to a given metric better than Peter does. Nathan took it further himself, saying he should start adding the why to the dashboard, and Peter agreed with a second reason: it keeps people from making an incorrect assumption about why you care and gaming it through misinterpretation rather than intent.
People: Nathan Blackham, Steve Wallace, Max Spevack
Restate every RESF request as a request to CIQ rather than to Nathan - publish the secure-boot ask to all of Linux Engineering so someone else can raise a hand
Aug 21, 2026 · operational · medium88% confidence
Nathan reported that Dieter had asked him explicitly to help with a secure boot POC, and that he would demo it to Sharif, Scott and Dieter on Monday, building it on CIQ hardware because CIQ needs it too. Peter approved the substance and re-cut the framing: let me tweak things ever so slightly to the RESF has asked CIQ to do this, not Nathan. It may be Nathan who is doing it, but the ask should be published in Slack to all of Linux Engineering - the RESF has asked for help with secure boot, I know secure boot, so I am sitting down with them Monday, and if anybody else is interested in understanding how this works or how they can plug into that world, here is the opening. Peter said chances are it is nobody and everyone just pats Nathan on the back, but he wants to buy the chance that one person wakes up and goes that is interesting. He tied it to the wider problem: the RESF needs to stop being five or six people who think it is their clubhouse, and Nathan should be willing to say this contributor should get a structure and a title inside the RESF. In the Steve Wallace 1:1 the same day he committed to pressing Dieter on the same point next week - nobody at the RESF is asking CIQ for things directly, and both Nathan and Steve orgs have resources available.
People: Nathan Blackham, Steve Wallace, Jonathan Dieter, Gregory Kurtzer
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
Aug 19, 2026 · operational · medium80% confidence
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.
People: Lindsay Aamodt, Chris Wolford, Scott Shinn, Bjorn Hovland, Greg Kurtzer
The five-week leader presentations are baseline once, then deltas forever - show me what you changed to move the number, not the same dashboard
Aug 19, 2026 · operational · medium88% confidence
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.
People: Nathan Blackham, Steve Wallace, Chris Wolford, Ryan Smith, Justin Haynes, Max Spevack
Bake the confidence number on the scope in front of you today - and accept that a 90 percent can slip when scope changes
Aug 19, 2026 · operational · medium85% confidence
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.
People: Chris Wolford, Nathan Blackham
Refuse to act on the AI spend number until it is decomposed - one-time hardware out, recurring API in - then treat the remainder as usage discipline rather than a spend cap
Aug 19, 2026 · operational · medium90% confidence
Steve Wallace raised rising AI costs at the end of the Aug 18 Engineering Weekly Sync. Peter did not accept the number as presented. He said the AI costs finance is counting include one-time purchases like the giant chassis just bought from NVIDIA for the 200s, and: I do not want to get hung up on one-time costs. I care way more about the recurring cloud costs and making sure people are being smart there. He set a meeting with finance for Thursday in LA to decompose it, and named what the response will be once the number is clean: model-tier discipline (teaching people not to do every single thing with Fable and Opus - Sonnet is still there for a reason and still really good at some things), possibly monthly per-person budgets, and a quality bar on AI-assisted work. Nathan raised that copy-pasting a prompt in and the answer out adds no value; Peter closed it with: we should be holding each other accountable and not accepting work at that bar.
People: Steve Wallace, Nathan Blackham, Brady Dibble, Kelly Wall, Christopher Baek
Decline the DGX Spark allocation for now - a queue exists, Peter owns it, and the next batch is gated on CIQ showing Nvidia progress first
Aug 18, 2026 · operational · medium80% confidence
Sarah Almaraz relayed a request for a DGX Spark unit for Brian on 2026-08-15. Peter refused flatly and gave the conditions that would change the answer: You cannot. When Nvidia has more to give us I can put Brian on the list. But there are other people first. And we need to show some progress to Nvidia first. Realistically it is going to be a few more weeks before we might get more. He closed by taking the explanation upward himself - I will walk Bjorn through it though.
People: Sarah Almaraz, Brian Dawson, Bjorn Hovland
Require every five-week org review to show the delta against the prior review and what was done to move it - not a fresh static report
Aug 13, 2026 · operational · medium90% confidence
Peter gave Nathan and Steve the same instruction on Aug 13. The first round of five-week presentations is a level-set; from the second round onward he does not want to see the same presentation again. Each leader picks their own metrics - Max supplied a candidate list but Peter explicitly allowed rejecting any of them - and then must show how those numbers changed since the last review, what they did to change them, which metrics they dropped, which are new, and why. He named the intended side effect directly: so that you are feeling some pressure during the intervening five weeks to know that I am going to have to report against these metrics, what am I doing. Nathan is standing the metrics up as a self-service dashboard app rather than a slide, so the org can see them without him.
People: Nathan Blackham, Steve Wallace, Max Spevack
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
Aug 13, 2026 · operational · medium87% confidence
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.
People: Ryan Smith, Justin Haynes, Nathan Blackham, Chris Wolford, Steve Wallace
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
Aug 11, 2026 · operational · medium77% confidence
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.
People: Stephen Moody, Chris Wolford, Nathan Blackham, Brady Dibble
Ratify sales engineers owning first-pass demos as the permanent structure - reframing Chris Wolfords self-reported staffing error as having kickstarted the right thing
Aug 11, 2026 · operational · medium76% confidence
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.
People: Chris Wolford, Ramesh Srinivasan, Dave Horn, David Godlove
Declare Jira a system of record and not a venue for process debate - shut the product-prioritization thread and move it into a room
Aug 11, 2026 · operational · medium93% confidence
A process argument had been running in the #product-prioritization Jira-linked thread since Jul 29. Peter cut it off with a purpose statement rather than a position on the substance: I want to make one thing clear. Jira (and slack) are not conducive to good process debates. Jira is a great system of record. That is all. Lets just get the right people together in a room and talk - this should be a collaborative process on both sides. He tagged Bjorn to make sure it was seen, then closed the thread explicitly - then maybe we leave this thread alone until that meeting - and named the cost he was actually reacting to: the ripples this thing is creating across the company are substantial and unnecessary. All on the same team, all trying to get to the same place. Two days later he applied the same instrument to the adjacent board question in #department-heads-engineering: just remember the goals of the two boards, and that by definition it is not true that everything on Product Priorities has to move to the Eng board.
People: Bjorn Hovland, Brady Dibble, Justin Haynes, Nathan Blackham
Override your own teams stated intent to delete the RL 8.6 source tree, and apologize to Google directly rather than defend the position
Aug 11, 2026 · operational · high88% confidence
Tissa Senevirathne emailed Kelly Hall on Jul 30 saying CIQ had informed Google it wanted to delete the RL 8.6 OS and kernel source tree, and asked that it be preserved for contractual traceability and auditability. Peter replied to Tissa the next morning without consulting his team first: I do not know why my team informed you they wanted to delete that tree. I apologize. There is little cost associated with us keeping it live. I hope it was presented as a discussion, not as CIQ is doing this. I will dig in with them to understand what was motivating that, but your request is more than reasonable. In parallel he told Nathan in DM: we cannot shut this down right now, it does not cost us to leave it up except for a few dollars, and pressed for the reason - but why would we need to delete it? I do not want to do anything at all to rock the boat with them right now unless we need to. He named the underlying stake: I want to make sure we have the actual contracts completely signed in blood, and pushed back on the suspected motive - I do not want to do anything that they are nervous about right now, especially if the reason is that its existence makes our metrics look bad.
People: Tissa Senevirathne, Nathan Blackham, Kelly Hall
No engineering team owns C3 - the content is wrong and outdated, so manage it or kill it, and Peter explicitly does not care which
Jul 30, 2026 · operational · low76% confidence
Brady Dibble asked Peter directly at 8:40pm whether any team in Engineering owns C3 yet. Peter answered within two minutes: To my understanding the explicit answer is No. I raised it with Bjorn last week. The content is wrong/outdated. We need to either manage it or kill it in my opinion. (I do not care which). Brady acknowledged - thank you for confirming. Three things are established in one message: engineering has no owner, the artifact is in a bad state, and the acceptable resolutions are exactly two with no preference between them. The escalation had already been made to Bjorn a week earlier, so this is confirming and sharpening a position rather than forming a fresh one - what is new is the binary and the explicit indifference.
People: Brady Dibble, Bjorn Hovland
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
Jul 30, 2026 · operational · medium90% confidence
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.
People: Nathan Blackham, Steve Wallace, Chris Wolford
Deliver the code-driven-not-agent-driven rule personally at Fridays AI committee as a single top-down message, because the first attempt did not land
Jul 30, 2026 · operational · medium92% confidence
Ryan told Peter that data governance is a full-time job and needs a headcount, and that adoption will not happen until the mandate comes from the top: I think that is as simple as you coming to an AI committee meeting and make it a mandate. This stuff does not get fixed until it comes from the top. Peter agreed and committed to attend the Friday 1pm session. He named the exact message: I am betting that dashboard was agent-driven, not code-driven. I want us using AI to write code, but what data can get pulled into that dashboard is hard-coded in that function. The agent cannot just wake up on a Tuesday and do something different and pull some columns that we were not expecting it to pull. That is the single message I am going to deliver tomorrow. Because if we do that, now everything is inspectable and we can have clarity on exactly what data is going where. He explicitly acknowledged the rule already exists and did not stick: a few general rules that we all need to adhere to as we are pulling data in and out of systems, I am happy sitting down at this point and making that clear to the AI subcommittee. And I thought I had. But we will come back and redo it. Because the kind of thing that happened with Atlas should not be able to happen.
People: Ryan Smith, Tabatha Wilmot, Steve Wallace
Sensitive Decision
Purchase approvals below a managers own threshold must never route to the CTO - told Nathan to expense it anyway and took the fight to Finance rather than the person executing the policy
Jul 30, 2026 · operational · medium95% confidence
Nathan bought a roughly 100 dollar remote KVM for the NVIDIA DGX Spark so other engineers could access it, after asking Peter first and being told yes. Erin Fong flagged that company-funded equipment must be tracked through an IT ticket before purchase; Nathan said it was not worth the hassle and would pay out of pocket. Peter intervened in three places. In DM to Nathan: No. Tell them No and that the CTO said it was fine. I do not want stuff like this to continue - and, repeatedly, But I already just said you can just expense these things. In the group DM he took the diplomatic line publicly - Nathan asked me prior to purchasing if it was ok. I said yes. Did not know this policy existed. If a ticket can be created rapidly in a way that does not burden Nathan, great - and Stephen Moody opened IT-6605 to document the approval. Then he located the real owner: he asked Steve Wallace whether the policy came from him (it did not, it came from Finance via Erin), and stated the fight he intends to pick: you have a threshold you can approve up to, Nathan has a threshold, I have a threshold. If it is below your threshold and you approved it, I do not want it routing to me. I do not want to know about it. I do not want to think about it. I never want to see it. Separately he coached Nathan on target selection: ask yourself whether you are solving this for yourself, for CIQ, or trying to make Erin recognize the policy is stupid - Erin works for us a couple hours a week and her job is to click buttons on the policy, she does not own it, so there is nothing you can say that will change it.
People: Nathan Blackham, Erin Fong, Stephen Moody, Steve Wallace
The value-driver bottom row is the contract, not NGD - approved stripping target dates and confidence from product tickets and pointing them at NGD instead
Jul 30, 2026 · operational · high91% confidence
Nathan asked whether NGD is the communication mechanism to go-to-market, product and the rest of the company. Peter refused the framing: the reason I am using that language instead of NGD is because I do not care about NGD. The bottom of the value drivers list is purely for communication about our deliverables and their impact to go to market. What he cares about is that the bottom row holds confidence numbers and target delivery dates almost in real time - as long as that is true, what you use to back it, I do not care. And if the thing you use to back it serves a bunch of other goals, great, I do not care. But if NGD cannot serve that because it answers other masters, then something else has to get stood up, or a linkage or filter. Nathan then proposed ripping target dates and confidence numbers out of product tickets entirely, reporting them only from NGD, and having product tickets point at NGD tickets. Peter approved with one amendment: product tickets still want to hold products desired date.
People: Nathan Blackham, Brady Dibble
Confidence numbers stay human and per-leader - Brady translates them, Engineering does not remap to his scale
Jul 30, 2026 · operational · high96% confidence
Bjorn brought Brady Dibbles push for a uniform, consistent cross-team definition of the confidence column. Peter rejected it in a DM thread on 7/29 evening and repeated the same ruling to Nathan on 7/30. Confidence is a human thing. That is why we call the column that. It is not computed immutable expectation of delivery for a reason. Justin is risk averse, so he will not put a 99 when he can imagine millions of ways for something to go wrong. Another leader might. The team will learn over time what Justins 90 means. On Bradys ask: the real and only question is what does Brady want to do with these numbers that he cannot do - what is he going to do with a 95 different than a 90. If Brady wants to turn the numbers into high/medium/low or into ranges in his own process that is fine, but that is him translating, not asking Engineering to fit an arbitrary mapping. If he wants a structured definition of exactly what high/medium/low means, now he is losing the experience of engineering leadership and having a function fill out his numbers. Peter also rejected high/medium/low outright: the minute you have high/medium/low it is not functional enough and you end up with twelve gradations and the same problem. And he told Bjorn to test it empirically - ask Duane if he can work with the numbers Justin is providing, the answer will be yes.
People: Bjorn Hovland, Brady Dibble, Nathan Blackham, Justin Haynes, Duane
Show the half-migrated TPS report to the whole leadership room even though it was not perfect
Jul 29, 2026 · operational · low72% confidence
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.
People: Ryan Smith, Chris Baek
The NGD board never bends to serve the TPS report - the report changes, and pulls from two data sources if it has to
Jul 29, 2026 · operational · high81% confidence
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.
People: Chris Baek, Ryan Smith
Confidence must rise as the target date nears - slide the date early rather than carry a 60 percent to the wire
Jul 29, 2026 · operational · medium72% confidence
Reviewing Justin Haynes automated-repo-testing item on the NGD board, Peter ruled that a low confidence number a few days from a target date is itself the failure. His instruction: this close to the end of the week we need to be communicating to the company, through those two numbers, whether they are getting something - so a few days from the end I do not want to see a 60 percent confidence number, what I want to see a few days ago is that date sliding out now so that we are communicating a higher confidence number when we are this close to a target date. He grounded it in consumer value: the company cannot do anything with 60 percent confidence July 31st, they cannot take attention on that. Immediately afterwards, when Duane Carson acknowledged a cross-team miss on the 10-2 bits, Peter drew the complementary line - I do not mind misses as long as the team recognizes, hey, we have a miss here, and here is how we are going to get better.
People: Justin Haynes, Duane Carson, Brady Dibble
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
Jul 29, 2026 · operational · high94% confidence
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.
People: Chris Wolford, Nathan Blackham, Bjorn Hovland, Max Spevack, Justin Haynes, Ryan Smith, Steve Wallace, Sarah Almaraz
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
Jul 29, 2026 · operational · high88% confidence
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.
People: Chris Baek, Ryan Smith, Justin Haynes, Brady Dibble, Chris Wolford, Duane Carson
I dont know is the right answer - Support does not guess how Oracle does it, and LG questions are an Engineering/Product call not a Support call
Jul 29, 2026 · operational · high92% confidence
With Bjorn about to dig into the LG U+ escalation and likely to reach out directly to support engineers, Peter set an information-hygiene rule and had Ryan Smith push it to his team. The rule has three parts: if the team does not know how Oracle is doing it, the answer is we do not know - not they must be doing blah blah blah; answer his questions truthfully but do not lead the witness; and the LG question itself is an Engineering and Product call, not Support. Ryan confirmed his team had acked it and named Amr as the likely contact point, and Peter said he was doing the same thing with Howard. Peter closed with answer his questions. No guessing.
People: Ryan Smith, Bjorn Hovland, Howard, Amr Mumtaz
Team meetups are gated on a defined purpose and a purpose-derived attendee list, not on getting people together
Jul 28, 2026 · operational · low69% confidence
Joseph Tate flagged that Justin intends to ask Peter about a team meetup. Peter pre-decided his answer: supportive in principle, conditional on sitting down and writing out what the gathering is meant to accomplish before it is scheduled. He extended it to the attendee list - the right set of people falls out of the purpose, so it may be a subset rather than the whole team. He anchored the default against the companys remote choice: the company chose to be a remote company and we kind of got to live with that.
People: Joseph Tate, Justin Haynes
Let Brady raise the kernel-team cloud-resource block in Engineering Weekly, with the test being whether Justin agrees there is a problem
Jul 27, 2026 · operational · medium81% confidence
Brady Dibble DMed Peter saying he intended to surface in the Engineering Weekly a flag from Maple that the kernel team is blocked on cloud resources and is being redirected to Outfitter instead of getting the access it needs. Brady noted he had checked with Justin first, was raising it early because every day is precious for the kernel team, and explicitly offered to drop it if Peter preferred to handle it internally to Engineering. Peter replied: you can raise it, the only question I am going to ask is whether Justin agrees there is a problem.
People: Brady Dibble, Justin Haynes, Maple
Make metric design the single biggest ask of Max - 10 auto-reported metrics spanning Justin and Nathan, delivered by Thursday
Jul 27, 2026 · operational · high84% confidence
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.
People: Max Spevack, Nathan Blackham, Justin Haynes, Chris Wolford
Grant Max standing permission to publish public Spark/Nemotron benchmarks with no pre-approval
Jul 27, 2026 · operational · low81% confidence
Max asked whether he had permission to submit a state-of-the-art single-unit Nemotron benchmark on DGX Spark to a public benchmark site under his own name, fixing bugs in the currently submitted benchmarks. Peter said do it, and when Max offered to write an internal doc first for Peter and Lindsay to review before publishing, Peter overrode that and told him to publish first and write the addendum after. Peter generalised it: whenever you do it, just do it, you do not need permission to make us look good. Max is to share the finished public artifact with Peter and Bjorn afterwards.
People: Max Spevack, Bjorn Hovland
Codify how engineering answers sales - bugs get fixed, out-of-scope features get a no, and the only next step is Product not re-escalation
Jul 27, 2026 · operational · high94% confidence
Coming out of the LG episode Peter laid down the operating rule in writing in the temp-lg channel: Engineering will respond to sales requesting a fix for a bug and will deliver that bug fix without product involvement. Engineering response to a sales request for a new feature that falls outside currently supported builds or plans is no. The step after that is for Product to get involved. In the meeting he attached three companion rules: re-escalation after an answer has to stop, engineering should stop saying you can try it and it might work in favour of that is not supported, and CIQ must present a unified front so no internal voice tells a customer something is a bug after engineering has ruled it is not. He also drew the line between discussion time and decision time - internal deliberation should not be shown to sales as if it were still open.
People: Ryan Smith, Justin Haynes, Bjorn Hovland, Brady Dibble, Melissa Kivisto
Approve a single-seat ChatGPT CVE-model trial for Sultan, narrowing Steves small-group ask to one named person
Jul 24, 2026 · operational · low83% confidence
In the 7/23 Steve Wallace 1:1 Steve relayed Sultans request to trial a ChatGPT model he believes will help with CVEs and may outperform Anthropics tooling against them. Steve recommended approval on a small basis and flagged the exposure himself - AI spend is running 60 to 80 thousand a month, and opening the floodgates likely means people run tools in parallel rather than switching, compounding cost. Peter narrowed the grant to exactly one seat: I am happy to have one person test it out, I would not open it up to the entire company, giving it to Sultan is fine, totally fine. Moody will handle the program application and setup.
People: Steve Wallace, Sultan, Moody
Approve the Tim Pepper consulting proposal, then push back on the absence of a standard contracting process rather than hand-roll the SOW
Jul 24, 2026 · operational · low81% confidence
Greg forwarded Tim Peppers consulting proposal to Peter on 7/21 with apologies for the latency, and Peter approved it flatly the same afternoon - I am good with this - without asking cost, scope, or management in the thread. He forwarded it to Sarah on 7/23 to get it moving. On 7/24 when Sarah relayed that Gregs next step was for Peter to follow through with the contract, Peter declined to hand-roll it and asked where the standard process was. Sarahs answer confirmed there is not a reliable one - CIQ has done things fast and not by the book with other people, case by case - and she took an action to check with HR.
People: Gregory Kurtzer, Tim Pepper, Sarah Almaraz, Mariah Rippee
Block the AI-cost workstream on complete per-individual measurement before any optimization - so each persons correct plan can be determined
Jul 24, 2026 · operational · medium81% confidence
In the 7/23 Steve Wallace 1:1 Steve reported several threads coming out of Mondays AI meeting: efficiency coaching for heavy users, model-switching guidance, and usage reporting to department heads. Peter cut across all of it and set a sequencing requirement - first get a dashboard that shows every individual in the company, including himself. His evidence was his own absence from it: he shows as zero on every cost dashboard despite Claude running 8 to 10 hours a day, with CIQ apparently paying around 200 dollars a month for him. He rejected the manager-level rollup as a starting point and rejected pushing justification down to department heads. All of the costs, not just some of them.
People: Steve Wallace, Michelle Novicio, Ryan Smith, Gregory Kurtzer
Hand mainline TPS report ownership to Ryan pointed at the NGD board; abandon Peters private fork and deprioritize the Linux software-delivery lifecycle doc
Jul 24, 2026 · operational · medium85% confidence
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.
People: Ryan Smith, Max Spevack, Chris Wolford
Narrow the NGD board to cross-company coordination only - not a deliverables tracker and not a complete decomposition of product acceptance criteria
Jul 24, 2026 · operational · high87% confidence
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.
People: Brian Dawson, Brady Dibble, Chris Baek, Justin Haynes, Bjorn Hovland
Institute a rotating per-team deep dive at the Tuesday staff meeting, anchored on empirically measurable metrics co-designed in the room
Jul 24, 2026 · operational · high93% confidence
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.
People: Chris Wolford, Steve Wallace, Nathan Blackham, Sarah Almaraz
Codify the Product-Engineering operating model: value drivers are context, product demands date+confidence and owns prioritization
Jul 21, 2026 · operational · high80% confidence
In the Peter/Brady/Brian session Peter laid down the operating contract between Product and Engineering. (1) Value drivers are context/metadata, period - not prioritized and not a vehicle to smuggle in scope. (2) Product superpower is to demand a date plus confidence number from engineering and own prioritization, while staying on its own side of the fence - not telling engineering how or who, not chasing the whys. (3) Escalation: first confirm alignment on priorities; if not aligned, mutually escalate to Peter and Bjorn immediately. (4) Engineering runs a sustainable pace; early low-confidence estimates will slide, but a re-baselined date is made intentionally with test harness and context, and must then be hit.
People: Peter Nelson, Brady Dibble, Brian Dawson, Bjorn Hovland
Rule the Toyota kernel patch a feature not a bug; no automatic queue jump, escalate through normal priority
Jul 10, 2026 · operational · medium78% confidence
Nathan flagged a Toyota/Yoshi request (relayed via Art/sales) framed as a bug fix. Peter ruled it is a feature, not a bug, so it does not automatically jump the engineering queue on the bug argument. Support may still be offered, but the bug framing is off the table. If the business wants it prioritized it must go through normal escalation and trade-off (Peter + Bjorn), not a backdoor via mislabeling severity. Reinforced later the same day in the Ryan 1:1 (Peter rebuked Art for taking the bug-vs-feature fight to engineering).
People: Nathan Blackham, Art Tyde, Bjorn Hovland
Willing to pull C3 into engineering, gated on Product confirming it is a priority
Jul 9, 2026 · operational · medium61% confidence
In his 1:1 with Art Tyde, Peter said he is willing to pull C3 into his engineering org, conditional on Product (Bjorn) actually confirming it is a priority. C3 ownership is currently ambiguous (Peter was told Greg owns it, which he called a terrible answer, and nobody under Peter owns it), it is degraded (reported ~50 percent down, Fathom-approximate), and it is blocking a Huawei evaluation. Peter made a note to figure out who is responsible for keeping it up and how to fix that.
People: Peter Nelson, Bjorn Hovland, Greg Kurtzer, Arthur Tyde
Restructure the Tuesday staff meeting to org-by-org TPS ownership and un-fork the TPS report to one shared source
Jul 7, 2026 · operational · medium69% confidence
Peter is firmly changing how he runs his Tuesday staff meeting: instead of Peter walking the team through the TPS report, each org owner presents their own section and owns that part of the meeting. He also committed to un-fork his drifted TPS report back to a single shared report, visible to everyone three days ahead.
People: Peter Nelson, Max Spevack
Mandate Snyk vulnerability-remediation SLA compliance across all engineering teams
Jun 30, 2026 · operational · medium52% confidence
In his 1:1 with Steve Wallace, Peter committed to mandate Snyk vulnerability-remediation SLA compliance across all engineering teams, not just Steves. Snyk SLAs are being breached, putting the fall ISO 27001 audit (broader scope than SOC 2) at risk, and the breaches span other teams repos including the PIC team and Ryans customer-service app. Steve will draft a high-level doc of the required compliance behavior, and Peter will push it out across engineering with CTO authority behind it. The mandate is decided; issuance is pending Steves doc.
People: Steve Wallace
Engineering owns defining the ask, success criteria, and documentation; CS responds to specific asks
Jun 30, 2026 · operational · medium63% confidence
In a DM with Nathan about friction with Ryan, Peter drew the Engineering-CS interface boundary: core engineering owns defining the ask and the success criteria and owns ensuring documentation exists; it is not Customer Support job to dig out engineering details. CS cannot follow everything and is expected to respond to specific, well-defined asks. AI can do much of the doing, but engineering still owns defining the ask and what success looks like.
People: Nathan Blackham, Ryan Smith