Decisions
43+ 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
An ambiguous interview verdict is a no - hold the bar rather than adding interviewers
Sep 7, 2026 · people · low73% confidence
Steve Wallace reported on the security engineer req that he had interviewed Jared, a contact of Greg, and had told Brianne and Greg that he was not a yes but not a no. Wallace proposed pushing the candidate on to CeeLo or TJ to gather more input. Peter closed it on the spot: not a clear yes and not a clear no means no, leave it as a no. He framed the rule rather than the case - he would rather hold a high bar, and if a candidate is not a giant yes, move on.
People: Steve Wallace, Greg Kurtzer
Sensitive Decision
Sensitive Decision
Take the KT 9.8 one-year bridge - engineering will figure it out as long as the million dollars comes with headcount
Sep 7, 2026 · strategy · high90% confidence
Korea Telecom needs 9.8 rather than the 9.6 discussed the day before, ahead of a regulatory approval process. Bjorn proposed installing 9.8 now with CIQ supporting it for a year - including CVE remediation, which CIQ does not normally do outside LTS versions - against a commitment that KT migrates to 9.10 a year out, for a million dollars. Peter shook Bjorn hand on it and then told Nathan in their 1:1. Nathan pushed back that he does not like doing CVEs on a non-LTS 9.8. Peter did not argue the technical objection: he answered that it is not just a million dollars, it comes with people, that it will not cost more than one or two headcount, and that once those hires are indoctrinated into Nathan system he can redeploy them elsewhere.
People: Bjorn Hovland, Nathan Blackham
Extend Karl Lowenbjer under Wallace and land Atlas and Motherbrain in Engineering
Sep 7, 2026 · people · medium85% confidence
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.
People: Steve Wallace, Karl Lowenbjer, Chris Baek
Refuse an SDLC release-cadence contract that would bind engineering - prioritization authority stays with Product
Sep 7, 2026 · strategy · high94% confidence
In the weekly sync with Brian Dawson and Brady Dibble, Brian proposed defining an SDLC/release process and release SLOs, framing recurring commitments (cloud image drops, driver updates, benchmark work) as an implied contract engineering should honor without being re-prioritized each time. Peter refused the framing outright and repeatedly: engineering will ignore any such document, and the only thing engineering will not ignore is Product. He told them the document has no teeth for engineering, that Product may absolutely write one and shove it down engineering throat in the moment, but the moment it becomes a thing engineering must uphold independently, Product has handed its authority away. He used the NVIDIA driver ask from the CEO the night before as the live example: rather than absorbing it as recurring work, he turned it into a ticket in front of Product so they could rank it. He also drew the boundary for what Product should write - tickets that are changes, not tickets that restate steady-state, so a one-time automation ticket replaces a recurring one.
People: Brian Dawson, Brady Dibble
Refuse to green-light the HPE indemnity escalation - this is a Bjorn call, not an Engineering call
Sep 3, 2026 · strategy · medium80% confidence
HPE was blocking the Core42 Stargate deal on the grounds that Rocky is not a certified OS on the GB300s, against a contract where HPE has guaranteed 99.999 percent uptime with penalties. On 9/1 Adam Jackson proposed that CIQ absorb HPEs support penalties for the first cluster and contract the risk out to an insurer, laid out a six-step plan starting with an immediate call to HPEs Russ Fromkin, and asked Peter and Bjorn for permission to make that call. Six minutes later Peter answered with one sentence: This is a Bjorn call, not an Engineering call. Adam stood down - I will not reach out to Russ unless I am given the green light - and Bjorn took ownership, slowing the solutioning until the actual contract terms were known. Dave Dickerson pressed the same way, asking repeatedly to see the contract. The exposure being discussed turned out to be roughly an 8 million dollar guarantee against roughly a 10 million dollar future deployment stream.
People: Adam Jackson, Bjorn Hovland, Dave Dickerson
Sensitive Decision
Sensitive Decision
Hold the write-static-code guardrail at the 98 percent it actually buys - concede the escape case publicly and still refuse to mandate replacing third-party MCPs
Sep 2, 2026 · technical · high94% confidence
At the 9/2 engineering all-hands Peter clarified the missive he had sent two weeks earlier about writing static code rather than pointing Claude at an MCP server. He gave the concrete failure it came from: someone stood up a Claude skill pointed straight at the HubSpot MCP server, and it deleted an org worth of data and 14 customers. The rule he wants: have the AI write Python or JavaScript, scope the token to exactly what that script needs, and let the skill know only that the script exists - not that the MCP server does. Jamin Collins pushed back hard and correctly - an over-helpful agent will eventually route around any tool that is not an actual guard, and once it learns it can, it will stop using the guard entirely. Peter conceded it in front of the whole org twice - he is right, he is completely right - and then held the line anyway: I do not think it is worth throwing out a pattern that works 98 percent of the time because of the 2 percent. If there is a better pattern you want to pitch, I am all for it. He named the tradeoff explicitly: the full fix is replacing each third-party MCP, which means an admin approval process per service, and I do not want to constrain our usage and our experimentation right now. Once we find that a certain set of tooling is really valuable, then it is worth investing in doing exactly that. He framed it as accepting a little bit of risk so that we can experiment as a team, and set the target as getting rid of the 100 percent failure case, not solving every edge case.
People: Jamin Collins, Andrew Jorgensen, Stephen Moody, Nathan Blackham
Refuse the 9.10-as-of-today letter for KT - give them 9.6 LTS now with its real support window and a required migration, and correct the numbers publicly when they turn out to be wrong
Sep 2, 2026 · strategy · high94% confidence
Arthur Tyde pulled Peter and Ramesh Srinivasan into an early-morning call on 9/2 over a roughly 1.x million dollar KT deal. The Korea AE had drafted a letter, largely AI-written, committing CIQ to deliver RLC 9.10 LTS as of today. RLC 9.10 does not exist - it is a November-December release - and KT cannot move to 10 because their ISV and telco software is certified on 9. Peter refused the letter shape and reframed the question first: why do they want early access, what do they want to do with it, what are they trying to accomplish. He then constructed the alternative himself - ship 9.6, which is the actual LTS build (9.8 is not), now, and extend support on 9.6 toward the 9.10 LTS window - and committed to verify feasibility with Nathan Blackham before anyone signed. He noted CIQ has done nothing on 9.10 builds yet, so early access to 9.10 does not exist to give. Later the same day in the group DM with Arthur, the Korea AE and Ramesh, Peter worked the actual support windows: 9.6 support is 4 years, 9.10 is not 10 years but 8, so the gap cannot be bridged - we can give them 9.6 now but they would need to migrate to 9.10 within 4 years. He posted the correction against himself unprompted: And I was wrong - 9.10 is 8 years, not 10. But still the same overall problem.
People: Arthur Tyde, Ramesh Srinivasan, Nathan Blackham
Judge the Atlas code on its engineering merits alone - keep it, port it off the laptop, and stop building skills with direct data access
Sep 2, 2026 · technical · high94% confidence
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.
People: Karl Lowenbjer, Chris Baek, Bjorn Hovland, Tabatha Wilmot
Put the Core42 deployment on Ryan org to resource - Nathan stays advisor and the unfilled Forward Deployed Engineer goes on the contract list
Aug 31, 2026 · strategy · medium84% confidence
While assembling the supported-contacts list for the Core42 contract, Nathan Blackham asked Peter whether he knew who from Ryan Smith team he wanted on it or whether Nathan should reach out to Ryan himself. Peter answered by pointing at the unfilled role first: He is hiring a new guy specifically to do work like this. So we definitely put down an entry for the Forward Deployed Engineer TBH. And then anyone else you want from Ryan world is fine - you have the pick of the litter. Nathan then reminded him of an earlier commitment - And remember when you told me that the deployment management was not going to be on my list.... - and asked whether Ryan himself should get access or only engineers. Peter drew the boundary explicitly: Definitely add Ryan. He will be tasked with the bulk of this work is the plan. You will be there as advisor. But I do not want you getting sucked into managing this. So do not pack the list with your folks either. LEt ryan spend resources as much as possible.
People: Nathan Blackham, Ryan Smith
Hold the Core42 commitment at five weeks, signal two-to-three as likely, and trade the compression for topology data
Aug 31, 2026 · strategy · high96% confidence
Core42 sent an overnight message via Anand asking CIQ to pull in the deployment timeline because HPE is running double shifts and the delay is causing them problems. Bjorn Hovland called an impromptu Zoom with Nathan Blackham and Peter, said he wanted to pull the previously quoted five weeks into two to three, and asked Nathan to confirm his notes that two to three weeks was reasonable for a bare greenfield deployment with none of the Scott Shinn extras. Nathan agreed it was reasonable if Ansible scripts and prep work started now. Peter then set the terms of what could actually be said to the customer, in three parts. One - the estimate is fine but the commitment is not: I think two or three weeks is reasonable and possible. I would be really careful about committing to it when it is the first time we have done this with these resources. One thing goes wrong and that timeline is blown. Two - keep the contracted number and frame the gap honestly: I am really comfortable with you telling them five weeks was our padded... so it covers something goes wrong. But we think it is likely to land in the two to three week range. I am fine with that. I just would not commit to two or three weeks. Three - convert the customer urgency into an input: I would leverage it a little bit with them and say, yeah, we can probably bring it into two or three weeks. By the way, guys, the more you can give us about your topology, the more information then that you can feed us now, the way more likely we are to hit two or three weeks. Later that morning in DM he restated it: I would be VERY careful about how we word commitment around something tightly timed like this. I do not think we CAN hit this timeline, and when Bjorn said Nathan had originally said two weeks, Peter corrected the provenance of the number - No he did not. He answered a question about how fast it MIGHT go if everything went perfectly. he gave a range. the minimum side of that range was 3 weeks... There is a reason under promise and over deliver is a phrase.
People: Bjorn Hovland, Nathan Blackham
Sensitive Decision
Hire Jori Koolstra now - go into the interview intending to sell, then compress the loop to days
Aug 31, 2026 · people · high94% confidence
Peter had a 10:00 interview with Jori Koolstra for the Linux Kernel Development Engineer role on Aug 30 (a Sunday). Beforehand he asked Nathan Blackham directly whether the slot was an interview or a sell, and said his own plan was already sell: I hope it is sell because that is my plan. I also really hope I like this guy because I LOVE his resume. Immediately after the call he told Nathan Hire him now. That is my take, and in the group DM with Nathan and Brianne Clasen he wrote We should hire Jori. Like... today. In #distinguished-leaders, replying to Bjorn Hovland asking whether anything ever happened with Tim Pepper and saying We need to be better at evangelizing Rocky and We just do not have an active community leader over there, Peter volunteered the same candidate: I also interviewed a kernel engineer candidate that I LOVED today (background in math) who wants to spend a lot of time evangelizing Rocky upstream and building a community. Bjorn replied Get him. Nathan confirmed the next morning that it was a sell, said he would get the roundtable scheduled for today or tomorrow, and added that he might be trying to get him out earlier.
People: Nathan Blackham, Brianne Clasen, Bjorn Hovland, Jori Koolstra
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
Aug 28, 2026 · strategy · medium79% confidence
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.
People: Tissa Senevirathne, Bjorn Hovland, Chris Baek, Kelly Hall
Answer the Gauntlet adoption fight as a cross-team communication problem and take it to the managers meeting as a case study rather than mandating the tool
Aug 28, 2026 · people · medium67% confidence
Ryan Smith team reads core engineering non-adoption of the Gauntlet test framework as a not-invented-here rejection. Justin Haynes team has an existing test harness that already meets their needs, so Gauntlet does not solve a critical pain point for them and the switching cost and risk are high. In the 2026-08-28 Justin 1:1 Peter diagnosed the friction as a communication breakdown rather than a technical one, and declined both available shortcuts - he did not mandate adoption and he did not arbitrate the tool. Instead he took it as the concrete case study on cross-team dynamics for the next managers meeting, with an action item on himself to add Gauntlet and cross-team communications to the Tuesday Horde agenda and to ask Justin to remind him.
People: Justin Haynes, Ryan Smith
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
Sensitive Decision
Broken-in-production is an automatic fast path - small thing with embarrassing impact jumps the queue regardless of the size of the epic around it
Aug 28, 2026 · strategy · medium84% confidence
In the 2026-08-25 Exec Product Prioritization session the errata CPE-to-product mapping item had drifted to number 30 on the board. The specific defect was that CIQ was shipping images identified as Rocky Linux when they should have been identified as RLC Pro. Peter moved it into the top ten on the spot. Brian Dawson stopped and asked what criterion drove the move, and Peter generalised it: something broken that we are shipping is an automatic fast path. He bounded it in the same breath - the broader errata epic is genuinely large and stays where it is; only the shipping-the-wrong-identifiers piece jumps, because fixing that piece is not dramatic at all. In the same meeting he pushed the reciprocal direction, arguing that some net-new items should be prioritized above keep-the-lights-on work because a two-month effort sitting at number 34 becomes a six-month effort.
People: Bjorn Hovland, Brian Dawson, Brady Dibble, Greg Kurtzer, Jonathon Anderson
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
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
Aug 28, 2026 · technical · medium90% confidence
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.
People: Tabatha Wilmot, Karl Lowenbjer, Chris Baek
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
Sensitive Decision
Sensitive Decision
Accept Bjorn conclusion on the Stratum name while refusing his reason - dont make a decision now that you dont have to make
Aug 24, 2026 · strategy · low58% confidence
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.
People: Bjorn Hovland, Chris Wolford, Chris Baek, Greg Kurtzer, Brian Dawson
Keep the reference requirement because the failure to produce one is the signal - not because the reference itself is worth reading
Aug 24, 2026 · people · low66% confidence
On Aug 22, in the hiring group DM, Brianne Clasen asked whether a kernel candidate should still submit references after Nathan Blackham had objected that the ones offered were not from the relevant period of the person work history. Peter kept the requirement and separated it from its stated purpose: he would like to get one, not so much because he cares about the reference itself, but because if someone cannot find one, there is something going on. Brianne confirmed she had read it the same way. Nathan then offered to supply names of people from the relevant team the candidate could approach, which makes the negative result meaningful rather than an artefact of the candidate not knowing who to ask.
People: Brianne Clasen, Nathan Blackham
Sensitive Decision
Fuzzball Substrate can be an option for the Kubernetes engine, never the only runtime - ship on existing rails or nobody buys the train
Aug 24, 2026 · technical · medium73% confidence
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.
People: Jonathon Anderson, Bjorn Hovland, Chris Wolford, Brian Dawson
Call the Core42 SOW1 won mid-call and forbid reopening anything that does not need reopening
Aug 24, 2026 · strategy · medium88% confidence
During the Aug 24 Core42 and CIQ call, the customer side kept probing why the SOW does not cover the broader logical control set, and the CIQ team started engaging on where work splits under partials. Peter intervened twice in four minutes in the internal channel running alongside the call. First he reframed the confusion: I think we have lost track of the fact that ultimately there will be 2 SOWs. Then, once Alex Trafton had asked whether they could sign, he closed it: this is won, we should be careful not to re-open ANYTHING that does not need to be reopened. When Adam Jackson asked whether he could stop screen-sharing the HLD, Peter answered yes please stop sharing. The team changed behaviour inside the same minute - Bjorn said I will wrap, Brian Dawson said he would refrain from additional comment and let Bjorn and Adam land it, and Adam stopped sharing. The SOW1 final package went out to Core42 by email that afternoon.
People: Bjorn Hovland, Brian Dawson, Adam Jackson, Michael Shinn, Alex Trafton
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
Define the forward-deployed deployment hire as a spearhead and work-distributor whose job is to work themselves out of a job - and reject the all-remote premise outright
Aug 24, 2026 · people · high90% confidence
In the Aug 24 Ryan/Peter/Bjorn session on the forward-deployed engineering org, Bjorn framed the headcount - one head for deployment, sitting under Ryan, Core42 as the prototype, jack of all trades, paid real money rather than the slightly junior mold-them profile Ryan usually favours. Peter locked onto Bjorn word spearhead and redefined the role around it: it is great if this person can do a pile of the work and they should be able to sanity check it, but the core capability is getting to know the rest of Ryan org, knowing the capabilities, and being able to tap a shoulder and say I need Arsalan for 14 hours here, I need somebody in Nathan org for 14 hours here. They do not need to do it all themselves, they need to be a distributor of work. He added the geographic requirement - willing to be anywhere in the world - and rejected the stated Core42 premise flatly: the plan with Core42 is that it is all remote setup, 100 percent, my confidence that that is true is zero, absolutely zero. On the long-term shape he split from Bjorn deliberately: Bjorn does not want the person plugged in long-term, Peter said he expects they will be, and that he is not arguing, he wants them acting as if their job is to not be there later. He named why he likes it as a support role - the person stands up repeatable, stampable systems so that most customer issues funnel into Ryan down-the-middle support funnels rather than back to the deployment person. Ryan took the JD first draft and named a candidate, Chris Wolford former number two based in Florida.
People: Ryan Smith, Bjorn Hovland
Trade a company-wide VP definition to get Greg to ratify the engineering ladder - structure first, names later
Aug 24, 2026 · people · high93% confidence
In the Aug 24 1:1, Peter walked Greg through the engineering leveling spreadsheet. He deliberately separated ratifying the STRUCTURE from mapping the PEOPLE, saying he wanted Greg bought into the structure and cared much less about the mapping for now. The ladder collapses roughly 27 levels to four IC levels - Engineer, Senior, Principal, Distinguished - plus Technical Fellow retained as a title outside the ladder rather than a level, and leadership reporting to Peter as either VP or Director with no Senior anythings. Greg objected to VP on optics grounds. Peter did not defend the word, he defended the need: I wanted a senior leader and a junior leader title, what we call them I am far less interested in. The two then jointly settled a company-wide convention: VP spans organizations and reports to a C-suite, SVP means junior C-suite where no CXO title is being given, Directors can report to either. Peter committed unilaterally: you will never see me arguing for a VP that does not report to me. Greg accepted, and asked that the ladder not be built in a vacuum but be made cross-applicable and run as an org-wide initiative with Mariah. Peter agreed and took the write-up. They ended at Peter stating they were 85 percent aligned.
People: Greg Kurtzer, Mariah Rippee
Sensitive Decision
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
Sensitive Decision
Sensitive Decision
Re-anchor the no-more-Amazon-blood rule on the deficit it was actually naming - what the org is short of is people who have had a startup collapse under them, not people with different opinions about Linux
Aug 21, 2026 · people · medium74% confidence
Across the Friday roundtable and the Nathan 1:1 Peter restated a hiring rule he had previously given as no more Amazon blood. In the roundtable he opened on the first candidate by saying he almost wanted to disqualify him purely on years of Amazon experience, that it has become absolutely critical to get a broader set of blood into the organization, and conceded that since stating the rule he has let two more people in and gets why. He then corrected Nathan reading of it - it is not about bad Amazon, it is that there is so much Amazon that there is not enough discussion about how we solve problems. In the 1:1 he specified it precisely: the thing he is pushing on is how you internalize the risk of not moving quickly. At Amazon the cost of slowness is somebody misses a promotion or a bonus; at CIQ the company goes under. He said Nathan is not less aggressive because of ability but because he has not had a startup collapse underneath him, and that what it boils down to is a few more people in your org that just have experience at startups. He closed by saying explicitly he is not shooting for differences in how people think about Linux - it is differences in work experience.
People: Nathan Blackham, Andrew Jorgensen, Jonathan Dieter, Justin Haynes
Sensitive Decision
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