Nathan Blackham
Dec 19, 2025 - Sep 7, 2026
246
Decisions
0
Active Todos
17
Patterns
Decisions (246)
Collapse nineteen engineering titles into four groups - and put senior principal back only if a manager makes the morale case
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.
Take the KT 9.8 one-year bridge - engineering will figure it out as long as the million dollars comes with headcount
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.
Stay current on NVIDIA drivers - build the automation, and do not ship RLC-AI again without the latest drivers
Greg flagged in #distinguished-leaders that the NVIDIA contract obliges CIQ to distribute the latest drivers within 30 days of release, and that CIQ has drifted. Peter took it to Nathan Blackham and Justin Haynes in their group DM the next morning, told both that he had not had the 30-day obligation in his head either, and asked them to put some sort of process in place to stay current. Nathan opened ENGD-839 for the automation; Peter told him to slot it right around where the next RLC-AI drop lands. Separately he told Product the gate plainly: it makes no sense to put out RLC-AI again without updating to the latest drivers at the very least.
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
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.
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
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.
Put the Core42 deployment on Ryan org to resource - Nathan stays advisor and the unfilled Forward Deployed Engineer goes on the contract list
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.
Hold the Core42 commitment at five weeks, signal two-to-three as likely, and trade the compression for topology data
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.
Sensitive Decision
Hire Jori Koolstra now - go into the interview intending to sell, then compress the loop to days
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.
Diagnose every AI overage case individually and apply the remedy that case calls for - without squashing AI usage
Facing an AI token run rate heading toward roughly 3 million dollars a year, with the top ten spenders accounting for about 95 percent of it, Peter refused both a spend cap and a single blanket fix. He directed each manager to work out why the overage is occurring for their own people, case by case, and to do whatever is appropriate for that specific cause - with the standing constraint that the answer must never be to suppress AI usage. He gave different answers for the cases he had already looked at himself: one engineer at roughly 60k a month is justified and was told to keep going; two others at roughly 100k a month between them are low-return and their manager was already digging in; Zorina team burned 12k in August purely because they were hitting the Claude API directly rather than the enterprise plan, so Justin Haynes action is a plan switch. Peter also declined Ryan Smith push to have the AI committee issue a company-wide best-practice policy on spend.
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
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.
Sensitive Decision
Keep the reference requirement because the failure to produce one is the signal - not because the reference itself is worth reading
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.
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
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.
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
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.
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
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.
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
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.
Claim the Core42 Dubai build-out for engineering outright - there is no sales engineering function, so if it gets built it gets built by engineering, and every scope increase still arrives with headcount
In a DM with Nathan on 8/20, Nathan was worrying about the scale of what Core42 is asking CIQ to stand up. Peter walked the argument to its end rather than reassuring him. He said CIQ does not have a sales engineering function, maybe one day it will, but today if something is going to get built at this company it will be handled by engineering - and that does not mean the people who work here today. He then named the pattern: we have seen over and over for the last year that requests for additional scope have come with a demand for headcount, and me and Bjorn be aligned on that. He asked Nathan directly whether Jimmy, Larry or Patrick were going to build out a datacenter of that scale, and if not, whether Nathan wanted Bjorn managing it or Peter. He closed by absorbing it: all the resources I listed will report to me, so it is not a Nathan problem, it is 100 percent a Peter problem - and asked how do we get you to a place where you never spend another brain cell worrying about that kind of thing. The staffing shape he named was consult where needed, heavy lifting from the Shin brothers plus one or two from Ryan world, then see if another contractor or two is needed.
Say yes to the Nikola Kolev hire only against a handshake that it starts a timer on Jason Rodriguez - and reject the three-or-four-more-people gate outright
Mariah reported that Nathan had told her he needs three or four more people in before anything moves on Jason Rodriguez, and would not be ready to start until October. Peter told Mariah flatly that is not going to be true, then took it to Nathan in their 1:1 the same afternoon. He drew the line precisely: he will shake hands on you can hire a Jason Rodriguez replacement before we do anything about Jason, but not on we filled every role that we could possibly fill before we are doing something. He then made Nikola conditional - if you want to move forward on Nick because you think it will allow you to remove Jason, then I will say yes, but I would like it to come with a handshake that you are getting super aggressive then with Jason. Nathan agreed to the handshake. In the roundtable an hour earlier Peter had held the same question open in front of the panel, saying the manager conversation had to happen separately.
The five-week leader presentations are baseline once, then deltas forever - show me what you changed to move the number, not the same dashboard
Closing the Engineering Weekly Sync on 2026-08-18, Peter defined what the recurring per-report presentations are for now that nearly every direct report has completed one iteration. He said he is deliberately giving little feedback on the first round because its only job is to set a baseline for each team. From the second round on he wants the conversation to be about what changes the leader is making to drive improvement in the metrics they report, what they are changing when those changes do not produce the expected movement, and whether the metrics themselves should still be the metrics. He explicitly said he does not expect the org to be tracking the same metrics a year from now and that this is fine.
Bake the confidence number on the scope in front of you today - and accept that a 90 percent can slip when scope changes
In the Engineering Weekly Sync on 2026-08-18, Chris Wolford said he could not settle a confidence figure on the Toyota/RC item because he did not know whether the customer would ask for more after their heavier testing had surfaced bugs. He offered to either bump the number or push the date. Peter supplied the method instead: bake the confidence on the scope you have in front of you today, and let the number or the date move if scope changes. He extended it past the item in hand - Wolford answered that he would apply the same to both Toyotas, and Peter said it was for everybody.
Value delivering things over doing work - ship three items all the way out the door and nothing elsewhere, rather than move nineteen forward
Closing the Aug 18 Engineering Weekly Sync, Peter gave the whole engineering leadership group a standing priority instruction: I really want everybody here to value delivering things over doing work. He put it concretely - I would much rather see you do fewer things all the way to completion and get stuff shipped to customers than be reporting status of, look, I am moving the ball forward on 19 different items. And not across the finish line on any of them, but forward on 19 items. I would way rather see us ship three items and do nothing anywhere else. He grounded it in the prior half: we delivered just enough in a bunch of areas to squeak across the finish line. And we built up a bunch of tech debt. He then closed the obvious loophole - I do not want to do less just to do less - and converted the instruction into standing permission to re-allocate: if pulling people off one project and putting them on another is going to allow us to get that second one out the door, let us have a conversation and advocate for that, make that change. The engineering order of operations is the named venue for making that argument.
Refuse to 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
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.
Fork the Core42 engagement into two SOWs and let nothing delay the first - land the GB300 paper now, put the expanded security architecture in a separate SOW
On the Aug 19 CIQ-C42 Gap Analysis Part 2 call, Alex Trafton (Core42 CISO, roughly 10 weeks into the role) opened a scope far wider than the existing SOW - PAM consolidation across 4-plus tools, continuous vulnerability management, AI-specific security, physical and OT telemetry correlation, and future AMD MI350X deployments. The room read it as a much larger opportunity. Peter, facilitating, held the immediate GB300 deployment SOW as a closeable unit on its own and pushed the expanded scope into a separate second SOW. In the debrief immediately after the call he put it to Adam Jackson directly: But you agree, Adam, that for the next couple of days, it is just about getting that first SOW across. Adam: Yeah, 100 percent, Peter, 100 percent. Peter: I just do not want to put anything in the way of that. The same instinct had been set the night before in the pre-call, where the agreed play was to propose a second SOW or a simple addendum rather than expand the current paper.
Sensitive Decision
Sensitive Decision
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
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.
Compress the Leandro Dorileo hire into a single week and run his final interview as a sell call rather than an evaluation - on the strength of Nathan like-mind endorsement alone
Nathan told Peter that Leandro (Leo) is one of a very small set of people - alongside Andrew and Dieter - with whom he can sit down and know they understand the in and out of OS engineering, and that he would have offered on the spot. Peter asked what he should cover; Nathan answered sell call. Peter accepted that framing without pushing back, immediately compressed the timeline (I would love to get it handled before the end of the week), asked Brianne to schedule a decision call for Friday morning, and told Nathan to chase Dieter and Jeff for scorecards - proceeding to his own 2pm interview before those scorecards existed. Two hours after the 1:1 he confirmed in Slack: I think I sold him. I am a yes. Lets move.
Hire Hailey Mothershead without reservation, and take John Paul as a qualified yes with a standing instruction not to chase him if he declines
At the Aug 12 kernel round table Peter gave two very different verdicts. On Hailey he was unreserved - I would hire her today, I thought she was smart, I thought she was inquisitive, I think she will work incredibly well with the team - and said that at a smaller company he would have called Brianne right after the interview and not let her leave the building without papers in front of her. He named his one real concern, a complete lack of C experience, and dismissed it as learnable, and flagged that she will find CIQ feedback culture blunt. On John Paul he deferred entirely to the technical panel, said he did not enjoy the interactions, did not believe JP is interested in what CIQ is doing, agreed with Shreeya read that they are getting roughly a year, and said he would not block a consensus yes. He then added the operative instruction: if we make an offer to him and he does not accept, let us not kill ourselves to make it work out. He closed the meeting with I know this team has felt pressured. I do not want this pressure to bring in the wrong person.
Refuse to start the incident-response conversation from the premise that an on-call system is needed - require an SLA first, and put accepting overnight downtime on the table as a real option
Ryan brought Peter a plan: after the Portal outage he had asked Justin and Nathan whether engineering had an on-call rotation, got a no, and wanted to build one at the Tuesday Aug 18 meeting. Peter agreed to the meeting, added Chris Wolford to the invite, and then inverted the agenda. His first question would be do we need this - not dismissively, but because he wanted both branches evaluated: accept that some systems are down overnight and publish a status page the way Apple does, or commit to short SLAs and staff an on-call rotation to meet them. He named the decision rule: define the SLA for each class of thing first, and if any SLA is under 12 hours, that implies on-call; if none is, it does not.
Redirect the entire Core42 solution-review effort away from the people on the call and toward whoever watches the recording afterward - and make every answer technical, never personal
Peter reframed the Core42 engagement in his Nathan 1:1 and again in the group prep. His read: the Core42 security team is married to a Red Hat solution and is using the calls to collect disqualifying gaps, so there is no answer that converts the room. He therefore instructed the team to assume the people on the call are antagonistic, to stop optimizing answers for them, and to tailor everything to the decision-makers who will review the recording. Concretely: stay calm, concise and confident; give less detail rather than more; say yes we can do that repeatedly; and convert every rebuttal from a personal challenge into a technical statement - the FreeIPA docs confirm session recording is possible, not why are you saying it cannot. He also killed Bjorn framing that the win depends on having the best prepared answers.
Take the engineering re-leveling from principle to a concrete ladder - 13 levels down to 4 (open to a 5th), leadership down to Director and VP - and commit that no mapping ships without the direct report in the room
Across three 1:1s on Aug 13 (Nathan, Steve, Ryan) Peter walked each direct report through a spreadsheet he had shown nobody, collapsing roughly 13 engineering levels into Engineer / Senior / Principal / Distinguished, and collapsing his own leadership layer from directors, senior directors and head-of titles down to Director and VP. Nathan argued for a fifth level (Staff) to separate Jeremy from Sultan; Peter took it as reasonable without committing. Ryan was placed in the VP bucket and told so directly. Peter named two hard constraints: nobody gets a pay cut, and existing option grants cannot legally be reduced. Timeline given to Ryan: weeks, not months. Sequence: get Mariah bought into the framework first, then walk each org through its own mapping.
Sensitive Decision
Force the stalled GB200 order to move the same day with time, not dollars, named as the governing constraint - and pre-absorb the over-utilisation complaint
On Aug 4 Peter pushed a stalled GB200 hardware order into motion in a group DM with Stephen Moody and Chris Wolford: did we get hardware ordered for the GB200s? If not, lets get something guaranteed moving today. Nvidia is asking for status and wants to see some output from their donation. As stated earlier, time is the important factor here, not dollars. It was reported unblocked two days later. The strategic frame behind it was one he had given the AI Committee four days earlier: NVIDIA is giving us hardware in their data center to use and asking us to light it up as much as we can with a promise that if we completely utilize that hardware, they will just keep giving us more, so my understanding is we have an unlimited check available with NVIDIA - we just have to prove that we will abuse the hardware. He paired that with an open-access instruction when Brady asked who to talk to about getting his hands on it: Nathan. Use it all you want. Just when Scott is responding because it is too utilized, shoot me a note, and I will get in front of Scott. Their commitment is they will give us more. We just have to prove we are going to use it.
Sensitive Decision
Declare Jira a system of record and not a venue for process debate - shut the product-prioritization thread and move it into a room
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.
Treat prototypes crossing from Product into Engineering as a feature rather than a burden - the code is worth two days, the market learning is the payload, and every one arrives with headcount
Justin raised Elm - a prototype somebody had been building for about three weeks and which was apparently launching the following week - and assumed it would eventually become his problem without the bandwidth to carry it. Nathan had objected in stronger terms that we cannot launch things without engineering being deep into it. Peter sided against both of them and with Bjorn, and gave the reasoning in two parts. On the code: it is a prototype, nothing more than a prototype, the amount of code there is not more valuable than two days, it would take two days to recreate it from nothing, so when it does come over to our side of the fence it is not like we are burdened with a pile of architecture that is terrible and horrible to manage. On what actually transfers: all we are burdened with is what we have learned in the market about what people want from it, which is an awesome thing to be burdened with - because now we are burdened with these two customers wanted to do these things, instead of Brady woke up one day and had a brain fart and decided that this is what a product should do. He then removed the capacity objection three separate times: it will come with headcount. Two, and you are seeing Ascender come your way with headcount, period. Everfox desktop with headcount, Kubernetes with headcount. So it will come with headcount, period. He named the contrast with their shared past - it is a very different model than anything we would have done at Amazon - and pushed the logic further with Bjorn, suggesting Satellite be announced with a go-to-market and a feature list without actually making the software available, to see who rings our front doorbell. He also accepted Justins counter-constraint on feature bloat and added his own: we can cut features too, I do not mind us removing features and seeing if nobody ever notices.
Crown Andrew owner of NARF with real authority and an explicit cannot-wait instruction - accepting the recommendation while rejecting its stated rationale out loud
The programs previous steward produced an assessment of why NARF had not moved forward during his absence, with recommendations. Peter read it and took the main one - hey, Crown Andrew is king of NARF, I am fine with that - but named his objection to the logic in the same breath: the one problem I have with it is it is Crown Andrew is king of NARF, in part because Andrew has not moved NARF forward. I have trouble with that linkage. But whatever, I can get over it. He then converted the recommendation into a delegation instruction for Justin with three distinct components: You need to tell Andrew he has to own this thing. And run it like he owns it. He has got the authority to do what he wants with it. He cannot wait on the previous steward. The last clause was the operative one - it pre-emptively removes the dependency that had produced the stall, rather than waiting to see whether it recurs. He linked it explicitly to the stewards impending step-back from day-to-day delivery. Three days later the org-wide announcement named the handover of NARF stewardship to Andrew and Nathan as a fact.
Price the Google live-kernel-patching ask at 2 HC for 3.5 months plus 1 ongoing, and take the honest slower timeline back to Tissa rather than fit their October date
Tissa asked for a quote on live kernel patching as paid work in addition to the existing monthly full-kernel contract: evaluate whether an incoming CVE patch can be delivered as a live patch, deliver it that way when it can, and still roll it into the next monthly drop. Volume unpredictable - might be 70 percent of a months patches, might be zero. Google wants something working by October so they can test before a January go-live. Peter opened the request to Nathan and Justin with a pre-commitment that removes the usual objection - assume we get headcount to cover this work - then interrogated the shape rather than the number: 2 engineers for 3-4 months and less ongoing, or 2 forever? He landed on 2 HC for 3.5 months and 1 ongoing after that. He then did the arithmetic out loud against Googles date - lets assume a month to hire, and 4 after that to have something, as the reasonable case - concluded I think that gets it to them too late and they will say no, and chose to go back with it anyway: but lemme go back to tissa with that and see where it lands. He closed with lets go fishing and see what we can catch. He also flagged that Tissa appeared unaware of internal discussion on the topic - Tissa seemed in the dark - and asked whether that discussion had ever reached Google.
Proceed with the Patrick Culp offer as US-only and say absolutely nothing about the future - if we lose him, we lose him
Nathan raised that Patrick Culp intends to relocate to Japan with no firm date, and Brie asked whether to proceed and how to shape the offer. Nathan proposed telling him relocation is not something we would be open to in the short term and would have to be re-evaluated. Peter judged that about 80 percent correct and cut the remaining 20 percent hard: I would not make any future looking statements, even something - I would not make any future looking statements, period. We just do not know what is going to happen. Even in the short term, we do not know what is going to happen. What he authorized instead was a statement of present fact framed against Patricks own Amazon background: unlike Amazon, unlike Apple, unlike Google, we do not have a Japan entity right now, so there is no Japan CIQ to move you to. It is true that we have people working in Japan right now - they do not actually work for CIQ. And I would leave it at that. No more than that. He gave one reason for today - today I would not support moving an engineer to Japan because they do not work for CIQ and because the hiring policies make it prohibitively difficult - and then stopped. He accepted the cost out loud: and if we lose him, we lose him. But also, as long as he is willing to hear this is what is true today, and he is willing to sign on to it, I am happy backing it. Nathan and Brie agreed to have the conversation before writing the offer, with the US number known internally but not presented.
Override your own teams stated intent to delete the RL 8.6 source tree, and apologize to Google directly rather than defend the position
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.
Mondays session with the Linux org is universally positive - period, full stop - and any fix-things conversation goes to a separate meeting
Gregs company-wide 1:1s surfaced that the Linux organization - Nathans and Justins teams together - is measurably less optimistic about the future of the company than the rest of CIQ. Not massively unoptimistic, but a clear differential. Peter checked the instrument before trusting it: he watched a couple of recordings of Gregs 1:1s just to make sure that he was not leading the witness and asking the question the same way in all of them, and judged he was doing a pretty good job of it. His response is a Monday session with Nathans team, and he set a hard constraint on its contents. Content: state the finding transparently to the team, then walk them through what he is seeing in the Middle East from his second trip and from the Axiom Space meetings - we are seeing a massive uptick in our ability to do business - then walk them through what dealing with Google over the last week and a half has been like, explicitly attributing his own ability to do it to their groundwork: I got to do that because of the work that your team has done, laying the groundwork, and I want them to hear that, understand it, I want to thank them for it. Constraint: It should be just a universally positive meeting with your team on Monday. Period. Full stop. And I really want it to stay focused on being a universally positive meeting. If there are places where we want to talk about fixing things or tweaking things, that can be another meeting. But I do not want to muddy the message at all. He also gave Nathan the entire rationale in advance rather than staging it - I will say all of this to them, super transparently.
The engineering re-leveling lands as a conversation with each direct report, not a directive - and Wallaces org is over-titled but not over-paid
Peter settled how the engineering leveling and compensation review will be delivered. The artifact is a spreadsheet comparing each orgs leveling and compensation against all of engineering, and he will walk it through individually with each direct report next week. He pre-emptively stripped it of authority in both 1:1s where it came up. To Ryan: it is going to be the spreadsheet I am putting together is the beginning of a conversation with each of my direct reports to say, here is how your org is structured from a leveling perspective, here is how all of engineering is structured, here is how your org is compensated, here is how all of engineering is compensated. I am not going to shove it down your throat. To Steve, twice: it is not something I am going to force down your throat or anybody else throat, it is the beginning of a conversation, that is all it is - and I will get it in front of you sometime next week, but it is for a conversation, not for this is what I am doing to your team exercise. He also delivered the specific diagnosis for Wallaces org directly to Steve: your team has titles that are far above the rest of the organization, so there is going to be some leveling reset that ends up impacting your team - but from a comp perspective your team is not overly compensated, in fact they may be low in some places, so I think you are going to have a fine story to tell. To Ryan he was blunter about the same finding: the number of directors we have across Wallaces org is just stupid, and it does not fit what I am doing everywhere else in engineering. He deliberately left the remedy open - we could change it by making more people VPs, we could strip away VP titles, we could do a lot of different things to level it - and named Mariah as involved with probably Bjorn a bit. He deferred the Steve walkthrough to Monday because he was slammed both days.
Sensitive Decision
Core 42 delivery will not land on Nathans org - it needs a purpose-built deployment team, likely based in the Middle East, under Bjorns forward-deployed structure
Nathan called an impromptu Zoom to make sure the Core 42 work was not silently assigned to him. His read: the work is a data-center build-out, a white-glove deployment similar to how Fuzzball is delivered, requiring a standard-operations deployment skill set he does not hire for - and CIQ has no equivalent of Wolfgang doing Rocky deployments. Peter agreed and made the routing call: if we get across the line on this, we need to be making clear to the account team we are going to need to put together a team to go do this, and it is not the people currently in Nathans org - they may be able to help. He accepted that some of the work will land on Nathans team as guidance, architecture and planning, but not execution. Then he named the likely shape and geography: there is a good chance the small team that does this wants to be located in the Middle East - a team in Qatar flying to the UAE, to Saudi, doing these deployments across the region. Nathan twice offered to own that team and Peter twice declined on his behalf: I think this is going to fit in with Bjorns forward-deployed engineering structure that he is trying to set up, and I do not think you want to own that. I get that you are happy to, but I do not think it fits properly there. Peter added his expectation that it ends up under sales eventually.
The 1:1 tracking spreadsheet becomes Nathans choice - suggest, do not mandate - but whatever replaces it must be measurable and must never go to HR
Nathan asked whether Peter still wants his direct reports using the individual 1:1 tracking spreadsheets, noting he is not leveraging them much right now. Peter released the mechanism and held the outcome: Look, I find them useful. I am confident at this point that I have spent enough time going over them with you. I am happy transitioning more to you decide if they are useful. My answer is I suggest yes, but I do not mandate yes. And if you have a better way, that is super fine. Two constraints attached. First, if Nathan builds a different method, that method is what he presents at the Tuesday engineering sessions - this is how I am managing my team - with Wolfords different approach as the contrast case. Second, the hard requirement: I just want to make sure there is something there that is measurable, that is driving conversations about whether people are doing what you want, and that there is some sort of a record produced as part of it that does not go to HR so that it is open and honest and unpolluted. Peter also said he will keep pulling them out from time to time and is moving his own cadence with Nathan from monthly to roughly quarterly. He gave Steve Wallace the same latitude the same day: what I care is that there is something documented between you and employees that you can point to, whether it is the spreadsheets or not is not the important point for me.
Nathans user-space recs are the highest-priority reqs in the company - told him to ask Brie directly whether they are her top priority and escalate to a three-way if the answer is no
Nathan said his biggest focus is hiring, that Brie had not moved anything on the Linux user-space side while he was away for two weeks, and that he would push her hard and dedicate his own time to it. Peter escalated the framing rather than the complaint: You should also be really comfortable asking Brie, hey, are my recs your highest priority? I am really curious what she would say. I hope she says yes. If she says no, it is probably worth a conversation with you, me, Brie, and whoever else rec she thinks is a higher priority. Then, unprompted: Because I think your recs are the highest priority in the company right now. Nathan has five open recs - three user space, two kernel. Nathan also floated an October/November Linux offsite for his team and Justins, and Peter tied its value to how much of the hiring is done by then.
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
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.
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
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.
Confidence numbers stay human and per-leader - Brady translates them, Engineering does not remap to his scale
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.
Run a Monday state-of-the-Linux storytelling session on pipeline, and have Baek carry the same rah-rah into the all-hands
Acting on a morale signal that surfaced in Gregs round of one-on-ones, Peter committed to sitting down with the Linux org on Monday to walk them through what he is seeing in the Middle East and with Google. He framed it explicitly as storytelling and cheerleader rah-rah about why he feels so bullish, not as a status update, and asked Chris Baek to sprinkle a little bit of the same into the upcoming company all-hands. He gave the diagnosis comparatively - the Linux org is meh on our future while Fuzzball is gangbusters and Ryans org is gangbusters, and there is no reason for Linux to be less positive about our future than everybody else - and bounded the response with it is not a risk right now. Sarah had already blocked Monday for the session.
Google ELTS: pay or I stop the work - and CIQ eats the disputed 150k out of the existing discount to remove the excuse
In the 7/28 CIQ ELTS payment discussion with Google (Madhu, Alyssa, Arun, Katur and Kelly Hall), Peter went in deliberately hot and said so. Madhu was trying to hold Kelly to account for who made a technical decision back in February, with the implication that if CIQ made it Google would not pay for work since then. Peter refused the premise - these are technical decisions, they get made by the team, they get recorded by your people as the decisions of the consolidated team, and then we move forward - and then removed the money as an obstacle by offering to absorb it against an existing concession: I gave you a 250,000 dollar discount over here, so you are bitching about 150,000. I will shake your hand right now that that is on us. That 250,000 discount just turned into a 100,000 discount. With the excuse gone he put the actual question: are we getting paid or are we not getting paid, and if we are not getting paid I am taking my toys and going home. Madhus boss and others stopped the meeting and committed to closing it out by the next day. The call also ended abruptly, which Peter read as someone telling Madhu to stand down.
Every org owes its own delivery-performance metric system, and Wolfords dashboard is the deliberate exemplar - used to train the Linux side of the house
Peter restructured the 7/28 Engineering Weekly into a fast breadth-first TPS pass followed by a single-org deep dive, and made Wolford go first on purpose. After Wolford walked through his PIC tooling - PR review latency, time-to-merge, bug-vs-feature ratio, commit distribution, release cadence, internal and external documentation coverage, plus a per-quarter epic assignment board - Peter named the ask explicitly: I dont care whether there is a dashboard or just a system that reports a set of metrics, but this is the kind of thing I am going to be looking for from every org. It is not an accident that Wolfords going first here. He then propagated the exemplar three ways: forwarded the Fathom recap to Bjorn saying he was using it to help train the Linux side of the house, told Nathan to watch the recording because there are critical things in there that will impact your teams and that I want to be able to talk through in terms of team management, and told Wolford directly that the presentation was exactly what I wanted/needed to kick that all off - while warning him you will not be impressed when Linux and the other portions of eng deliver theirs. Sarah set the rotation: Wolford, then Nathan, then Steve, Ryan and Justin.
Endura scope for CIQs own pipelines - include Fuzzball, Warewulf, Ascender and Depot; exclude Apptainer
Eric Sheridan of Infrared Security updated Peter on the Endura proposal for securing CIQ build pipelines, noting Nathan and Justin had reviewed the Koji integration strategy positively and that Bjorn was excited about using Endura to protect Rocky core packages. Eric asked whether scope should extend beyond Rocky to Fuzzball, Warewulf, Apptainer and Ascender. Peter replied to include Fuzzball, Warewulf and Ascender, said Apptainer should not be necessary, and added a product Eric had not asked about - Depot - on the grounds that projects which serve CIQ products to customers should be included as well. Pricing follows this scope, and a call with Greg and Bjorn was set for Wednesday.
Everfox desktop - CIQ is an integrator, not a builder of novel desktop technology; convert the ambiguity into integrator-shaped requirements
Max raised that the Everfox desktop requirement had reached him third-hand through Nathan as something about launching multiple GUI programs with some running in a special memory-protected mode. Max said CIQ can be great as an integrator pulling patches together and writing tests, but cannot build brand new security-critical technology into Linux. Peter agreed - not with the tiny team that we have - and made that the operating constraint. He tasked Max, with Bjorn and possibly Brady, to convert whatever Everfox is actually asking for into a series of requirements that fit an integrator posture, and stated he does not want CIQ designing a new desktop. He offered the shape he hopes the answer takes: which desktop are we shipping, which variant, and is there a set of a few applications we ensure run.
Yes to anointing Andrew NARF tech lead - but Max confers it, so it does not set a precedent that the CTO blesses tech leads
Max proposed formally naming Andrew tech leader for NARF with full review and merge authority. Peter interrogated why Andrew could not simply claim it, and Max explained Andrew is afraid of stepping on Maxs toes and needs to be told it is his ballgame. Peter approved - we will say yes to this - while stating plainly that he does not personally believe in the anointed tech lead model. He then separated the approval from the ritual: on learning Max could confer the title himself, Peter routed the naming to Max specifically so the org would not learn that authority flows from a CTO blessing. Max will speak to Andrew before their Thursday 1:1.
Make metric design the single biggest ask of Max - 10 auto-reported metrics spanning Justin and Nathan, delivered by Thursday
In the Max 1:1 Peter redirected Max away from personally fixing NARF reporting bugs and toward crafting the metrics that Nathan and Justin will present against at the engineering all-hands and the Tuesday meeting. Peter framed it as if I have a single biggest ask of you, it is help craft that. Max committed to writing a list of the ten most interesting metrics he would want reported automatically in a dashboard anyone can look at any time, spanning both Justin and Nathan, by their Thursday 1:1. Peter stated he will work Nathan on the people-management side but wants to do it through the lens of achieving those metrics.
Institute a rotating per-team deep dive at the Tuesday staff meeting, anchored on empirically measurable metrics co-designed in the room
Peter gave the same instruction independently to Chris Wolford and Steve Wallace on 7/23. Each org lead will take roughly 45 minutes of the Tuesday staff meeting on a five-week rotation. Three parts: a functional overview or demo of what the team delivered in the last month and is working on next; a project-plan view with milestones, tracking, who is on what, and how team time is being spent; and a set of empirically measurable metrics. The metrics do not have to be right the first time - the explicit purpose of doing it in front of peers is to argue out which metrics are the correct ones for each org. Metrics differ by domain: on the Linux side Peter wants automation measures such as the percentage of PRs auto-approved by Nerf versus human-approved; on PIC Chris proposed PR volume and the rate at which releases require bug fixes over time. Chris Wolford presents first, Tuesday.
Hold the Google 6.18 image as contract leverage - nothing ships to Google without Peter say-so
Both 6.18 kernels (default and minimal) were built and validated by 7/17, but Peter instituted a delivery-control gate: no kernels go to Google without his explicit say-so, and delivery-timing questions route to Kelly Hall. The build is done; the only remaining gate is contractual, so CIQ holds the finished image as leverage until GDC signs and resolves the outstanding payment. The ultimate release decision Peter deferred to Bjorn and Kelly.
Rule the Toyota kernel patch a feature not a bug; no automatic queue jump, escalate through normal priority
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).
Pass on Patrick Culp for now (no black mark), re-engage in 3-6 months
In the Round Table hiring debrief for candidates Ben Howard and Patrick Culp, Peter decided to pass on Patrick Culp for now - explicitly not a hard rejection - with intent to re-engage him in three to six months. Stated reason: he wants breadth of past experience coming into Nathan org right now. Peter committed to co-drafting the decline and re-engage message with Bree Clasen.
Support Nathan CVE-first prioritization over the Google minimal-kernel delivery; own the customer comms
Nathan flagged that in-flight critical local-privilege-escalation CVEs collided with the committed 6.18 minimal-kernel delivery to Google and called for CVE remediation to come first. Peter backed that call rather than making it: agreed to a bounded slip (no more than a week, not three), was comfortable asking the team to work a weekend to verify already-built patches, and took personal ownership of communicating the slip to Google - framed as value-add (surface only the CVEs Google benefits from), not an apology. Peter wrote and sent the explanatory email to Tissa and the Google team the same day.
Reinforce that an automated Linux CI/CD pipeline is one of the top-3 H2 company objectives
Peter had already set an automated Linux CI/CD pipeline as one of CIQ three top company objectives for H2 (base decision not previously captured). In the Max 1:1 and Engineering Weekly he reinforced to people that it is there and that it is critical to Linux delivery - a company objective, not just a Nathan-team objective. Logged as reinforcement.
Sensitive Decision
Reverse the No on one non-Amazon-only Linux candidate and open Roxana backfill req immediately
After learning Roxana (a Linux contractor under Nathan) is leaving - the second Linux departure after Gomez - Peter reversed his 7/6 stance of declining both Amazon-background candidates. He will remove his No on the one candidate with breadth beyond Amazon, get him in now, and open a replacement req for Roxana immediately, while still holding the general ideally-not-Amazon preference.
Gate Rakuten 8.6 / RT-kernel support work on a signed 1.6 to 1.8M expansion that funds dedicated headcount
Decided that the risky, currently unsupportable Rakuten 8.6 / RT-kernel support work will either not be done at all or only be delivered tied to a signed contract expansion in the 1.6 to 1.8M range that funds dedicated Rakuten headcount on CIQ side. The bar is enough to cover roughly two dedicated engineers, not an arbitrary large number. Peter forwarded the engineering teams infrastructure objections to Bjorn to arm the customer conversation.
Sensitive Decision
Everfox desktop-OS: require explicitly scoped and funded eng-investment before supporting the deal
On the Everfox desktop-OS deal, Peter framed it as a fundamentally different business (be like Ubuntu while also being like RedHat, not add desktop support to Rocky) and insisted the unknowns around hardware enablement / driver support and a dedicated lab be made explicit. His engineering-side conditions: the MSA must fix the hardware scope with out-of-scope hardware priced separately, and CIQ should proceed only with an explicit commitment to fund the engineering regardless of revenue. He tasked Max to assess technical feasibility with Nathan before committing. Relates to the prior logged Everfox decision d1ea8ed9; this is the engineering-stewardship condition layer.
Engineering owns defining the ask, success criteria, and documentation; CS responds to specific asks
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.
TPM charter + one-owner-per-release accountability mandate (problem/solution/owner grid)
In the TPM sync with Chris Baek, Peter locked an accountability framework: TPMs solve problems and coordinate but do not own engineering processes (engineering owns its own processes and its coordination with Product); every new process must be defined on a 3-column grid of Problem, Solution, and a single named Owner; and every release gets one clear accountable owner (one throat to choke) empowered to make the go/no-go call. The incomplete NGD board is the named blocker, with engineering managers (Nathan, Justin) accountable for completing it so it feeds dates and confidence into the Value Drivers Board bottom swim lane.
Sensitive Decision
Hiring direction to Nathan - prioritize background diversity, broaden beyond Amazon blood
In Nathans 1:1, as Nathan described two engineers entering his pipeline (both Amazon backgrounds), Peter directed him to prioritize diversity of background - people who have been at multiple companies, not more Amazon hires, because CIQ has more Amazon blood than Peter wants for its size. He framed it as part of deciding who we want to be as we grow to this next stage. Not a veto on Amazon backgrounds (I do not mind Amazon, but make sure they have been other places too).
Veeam CVE-escalation response: tell the honest intentional-tradeoff story, diagnose via Dickerson first
Ahead of a 5 AM Monday call with Veeam on a roughly 1M deal Bjorn flagged as at-risk, Peter set the response strategy. Tell Veeam the honest story: CIQ made an intentional trade-off (criticals 9-plus, known-exploit CVEs, and high-8s are handled; behind on some low-7s) because it is investing in CVE automation to handle the coming flood, and this is NOT a reaction to being caught. Step one is to reach out to Dickerson first to learn Veeams actual expectations and what specifically unblocks their signature. Nathan owns the technical scanner-nuance explanation (stack-protection downgrades, scanners scoring off non-Red-Hat CVEs).
Fix performance-review confirm-receipt acknowledgment — hand-deliver packets now, push HR for global wording change
When Andrew Jorgensen objected that Ripplings mid-year review flow forces employees to click confirm receipt before they actually have the packet, Peter sided with him. In his lane he directed an interim fix: managers download and hand-deliver packets directly so employees physically have them before acknowledging (told Nathan to send Andrew his packet; floated telling all his managers to email packets to everyone this round). As advocacy in HRs lane, he asked Mariah to change the button globally to access your packet and remove the receipt-confirmation sentence. Final wording decision deferred to the 6/16 C-Suite.
Sensitive Decision
Sensitive Decision
Sensitive Decision
Re-institute and enforce monthly performance conversations across engineering managers
Peter decided to re-institute and enforce lightweight monthly 1:1 performance conversations (a few minutes each, using the shared spreadsheet) as the real accountability mechanism for managers and their directs — and to restart doing them himself with his own directs, having admitted he had fallen off. The point is catching misalignment on goals and deficiencies early rather than letting it fester for months.
Gate NVIDIA/Spark announcement on engineering supportability — eng-only until then, then hand to GTM
With NVIDIA engagement happening at very high levels over the next week, Peter decided to say nothing publicly and not pre-announce anything until CIQ has something it can support — something it would actually ship and point a customer at the support org for. Until then the Spark/Rocky-on-Spark work stays purely engineering (get it on Nathan, Wolford, Westley, and Peter own Sparks; validate it works), explicitly not a Bjorn/GTM item. Once it is supportable, GTM is unleashed.
Sensitive Decision
Prioritize RLC 10.2 to the top, drop AI+H work — and validate the JPD deprioritization as correct
After a Citadel-driven escalation (10.2 needed for a ~$200k contract + expansion), Peter pulled Nathan, Justin and Max into a 5-minute call, made 10.2 priority-one for Linux eng above RLC AI and H work (only 3 critical CVEs rank higher), and was willing to drop other work if needed. He then posted an actionable timeline range to #department-heads (inner bound Fri 6/19, outside June 30, gated by CVEs). Crucially, he endorsed that the team had correctly deprioritized 10.2 per the JPD board and framed the whole episode as a communication failure (Bjorn got a single June-30 date without the range/assumptions), NOT an execution failure.
Kill follow-on Icicle patents — finalize the single Icicle filing only
Peter decided not to pursue the secondary/follow-on patent filings around Icicle (Know Your Workload / Kernel Control Authority family) and to have Ani Fox finalize only the one Icicle patent already in flight, before the issuance/filing window closes. Closes a months-long open question on whether to use the remaining window to add follow-on patents.
Mandate CIQ build/test pipeline converge with the RESFs — one unified project, Nathan accountable, coordination over speed
Peter laid down a mandate that CIQs Linux build/test pipeline will become functionally identical to the RESFs over time — a single consolidated project rather than parallel tooling. Nathan drives and is held accountable for closing the CIQ-to-RESF gaps (hardware parity, cut over to Koji, mirrored build infrastructure, a full validation framework that runs PR-specific tests). Justins build world must sign on and use it everywhere. Ryans gauntlet/outfitter tooling and Leighs RESF-side work are welcome only if they plug into the one project rather than forking. Peter explicitly chose coordination over speed even though it slows Ryans faster build-it-now instinct.
Value Drivers Board becomes source of truth for engineering dates and confidence; JPD dates become computed
In the 6/03 working session that Peter recorded (Peter + Nathan + Justin + Chris Baek, during the in-person engineering F2F), Peter locked the architecture that distinguishes the JPD from the Value Drivers Board. JPD stays purely for product strategy and prioritization (not work tracking). The Value Drivers Board is the Engineering-to-GTM coordination instrument that captures context (the why) and dependencies. The concrete decision: engineering target dates and confidence numbers live on the Value Drivers Board engineering lane as the source of truth, kept current on a tight cadence (always right on a Friday), and JPD dates and confidence become computed properties pulled from the Value Drivers Board rather than manually entered.
Take on Value Drivers Board restructure as the next coordination lever after JPD doctrine
In the 6/01 Leadership Roundtable, Peter committed to bring a formal proposal to restructure the Value Drivers Board, explicitly sequenced as the next move now that the product-priorities board (the JPD-doctrine work, closed 5/29) is aligned where he wanted it. Took the Fathom action item to draft the proposal and share with Chris Baek and the group within a couple of days. Triggered by Lindsay surfacing marketing/product misalignment (premature RLC+AMD announcement before AMD validation; Fuzzball multicloud date churn May 28 to June 4).
Icicle wind-down — stop tracking; preserve patent + Fuzzball-side optionality
In the 5/28 Nathan 1:1, Peter formally took Icicle off his active tracking list. Nathan concluded that Icicle is not going to make money for CIQ; Peter agreed and said I am checking it off my list. I am done watching it. The wind-down is not a kill — patent prosecution continues (CIQ filed a day before Dell/Google filed similar patents), and Icicle survives as a possible Fuzzball-side opportunistic checkbox feature for hobbyist or small-deployment workloads. What was cut is Peter attention as a recurring tracked item.
Sensitive Decision
JPD board scope locked to ordered priority list — Peter drew the line in writing to Nathan
In a long Slack DM thread on 5/27 (~25 Peter messages, 09:15–09:41 AM PDT), Peter rejected Nathan's draft framing for JPD scope and replaced it with an absolute definition: JPD is an ordered list of product's priorities used to drive company strategy, and nothing else. Not project planning, not marketing coordination, not a control surface for engineering order-of-operations. Tickets should be as large as possible and only split when product strategically cares about sub-priority. Value Drivers carry GTM linkage and dates. Every time someone tries to widen JPD scope, Nathan is instructed to push back. Reinforced same day in Baek 1:1 (Peter-recorded Fathom) and surfaces in the RLC cross-functional standup where Nathan is tasked with drafting the formal product-board structure proposal.
Hire dedicated cloud-security engineer — Steve drafts JD, Peter champions, dovetail with Nathan STIG/FIPS gap
In Steve 1:1 5/21, TJ flagged CIQ is doing the bare minimum on infrastructure security across 4-5 clouds. Peter asked Steve to have TJ (or Steve) draft a quickie JD describing what the role does and is responsible for — explicitly NOT urgent, but needed as a champion artifact so Peter can take it to Bjorn/Greg with a concrete ask. Steve flagged that the same hire could dovetail with Nathans STIG/FIPS expertise need on the technical side; Peter agreed ("Awesome"). QBR 5/22 made it official as a Steve-owned area requiring formal assessment and potentially a new headcount.
Dieter Middle East trip proceeds; Peter shifts to off-loading other stress vectors
After the Nathan 1:1 5/21 raised the Middle East trip as a stress concern, Peter and Bjorn aligned: the trip business value holds, Dieter ships. The landed decision is upstream — Peter recalibrates his support for Dieter to be much more sensitive to overload signals and actively off-loads other stress vectors (release pressure framing, recognition, vacation enforcement post-release, board-proposal ghostwriting timing) so the Middle East trip is the one stressor, not stacked on top of others.
Hardware lab: paint the full picture and buy the whole complement upfront
When Nathan proposed buying one server per quarter to build out the engineering hardware lab, Peter pushed back: do it backwards. Define what we want the lab to be, then buy the full complement, not slice by quarter. Only chunk it if there is a real reason (cooling, ops bandwidth) — not for budget reasons. Tied to: NVIDIA H100/GB300/B200, AMD parity, and figuring out where to put it (Reno closet vs Texas DC).
Engineering owns docs content; Customer Engineering or Marketing owns customer-ready packaging
In Ryan 1:1, Peter split docs into two layers and assigned ownership cleanly: (1) the technical content, details, and accuracy IS engineering responsibility — same as QA. If Ryans org helps fine, but not held to it. (2) Making docs customer-ready/pretty is NOT engineerings responsibility — that lives with Ryan or Lindsay; they decide between themselves where it lives, Peter does not care which.
Ascender ownership moves to Nathan org with possible Zarina-led sister team
Peter decided Ascender does not stay parked between Jimmy and Larry as a half-supported side-project — it needs a real owner. Not adding a direct report to Peter; not adding to Justin who is at his limit. Lands in Nathans org. Possible structure: a sister group under Nathan (parallel to Justins org) for customer-facing delivery — would hold externally-facing Depot AND Ascender, led by Zarina, with one new engineer hired in for Ascender work. Decision contingent on Zarinas current Depot-Sodor commitment and the Wesley situation resolving.
Dieter wellness three-layer intervention — trip offer + Mattermost kudos + RESF governance reform
Triggered by Nathan flagging Dieters stress (release delays + planned Middle East trip), Peter committed to a three-part response: (1) Trip cancellation offer — confirm trip status with Bjorn first, then directly ask Dieter if cancelling helps reduce his stress. (2) Community recognition — post in RESF Mattermost thanking community for 9.2/10.8 release efforts, coordinated with Nathan via #hey-pete-look. (3) RESF governance reform — Nathan to draft governance proposals (term-based board and team-lead seats, monthly status reports from team leads to board) for Dieter to present. Also reframed how Dieters performance gets evaluated: from absolute targets to pre-Dieter vs post-Dieter comparison. Stack to take ownership of release sign-off so Dieter does not carry that burden.
Dedicated cloud security engineer role to be championed — dual-purpose JD covering cloud + STIG/FIPS
Committed in Steve 1:1 5/21 to champion a new dedicated cloud security engineer role. Steve will work with TJ to draft the JD; Peter will champion it to budget owners (Bjorn/Greg). Triggered by TJ flagging current cloud security as bare minimum and the proactive supply-chain projects (TJ on GitHub workflow SHA pinning, CeeLo on NPM package securing) needing a dedicated owner. Dual-purpose JD: also serves Nathans STIG/FIPS security expertise needs — one hire, two demand surfaces.
Lab hardware acquisition shift — buy all 8-10 servers at once, Texas DC over Reno, NVIDIA+AMD outreach
Committed in Nathan 1:1 5/21 to a hardware acquisition strategy shift: buy all needed lab hardware at once (8-10 servers) instead of one-per-quarter. Cost is not the barrier; speed of development is. Reno office ruled out (1Gbps shared, no after-hours support, 5-6 server power/cooling cap). Texas DC preferred — to be re-evaluated against Reno after Nathan defines the full hardware list. Peter to email Scott at NVIDIA (H100/B200/B300) and discuss strategy with Steve directly. Nathan to email AMD for equivalent GPU hardware. Hardware sits inside the broader CI/CD acceleration goal — shift to Koji for automated signed kernel builds in a secure enclave to handle frequent builds and zero-day vulnerabilities. Hardware-acquisition shift is what unblocks the Koji shift.
Engineering owns all QA — Nathan accountable; tests required for Done; Ryans team builds tooling not rescue
Non-negotiable directive issued to Ryan: engineering is responsible for its own QA, Nathan is named accountable for quality, and a ticket is not Done until it has documented executed tests. Ryans role is re-shaped: build QA automation tooling (Gauntlet CLI, Outfitter, CIQCTL) that empowers engineers, NOT take over QA responsibility from engineering. Documentation also clarified: engineering provides all technical content; the customer-ready presentation layer is a Ryan-and-Lindsay conversation. Ryan to define a Definition-of-Done lifecycle visual for H2 to standardize across the org. Peter committed to email Nathan and Justin directly to reassert.
Jira confidence-as-contract doctrine codified across engineering directs
Codified explicitly in Justin 1:1 5/21 and same-day endorsed via Chris W DM: Jiras confidence number is a communication contract between engineering and GTM. Rules: (1) drop confidence immediately when a date is at risk (e.g., 80%→50%), (2) slide the date by a calculated intentional amount, (3) once confidence is high (95%), the date is a firm commit and must be hit even at extra cost, (4) treat ALL work as change-requests (no bug-vs-scope debate), (5) any change in understanding triggers immediate date/confidence updates. Engineering Order of Operations vs JPD prioritization formally separated: engineering owns operational/health priority (e.g., image build pipeline rework), JPD = product-value priority. Significant misalignment triggers a conversation. Same doctrine to be rolled out to Nathan and Max next.
Ascender consolidates under Nathan; opened customer-facing-delivery org reorg as a future possibility
The new Ascender application engineer hire (JD finalized 5/14, panel kickoff 5/20) will report to Nathan, not Justin. Reasoning: Nathans team has the necessary ecosystem breadth (OS + Depot + Ledger); Justins team is at capacity with narrower focus. Beyond the immediate staffing call, Peter opened a much larger structural question with Nathan: whether the engineering org should split along a new axis — a customer-facing-delivery group containing Ascender today, future external Depot, and other delivered-products — potentially led by Zarina. Wesleys uncertain future at CIQ surfaces as a blocker to firing that lever.
OPA precedent — three-in-a-row water-carrier tap, not single-event hero pay
In 5/14 Nathan 1:1, with Nathan in middle of CVE response (third consecutive: dirty frag → copy-fail → current embargo), Peter declined to set the precedent of OPA/bonus payouts for single-event heroics. Maple — who carried water across all three events via consistent handoffs and status updates — is THE OPA candidate. David (took over secure-boot kernel build during Tate's absence) is growing into the role you'd want him to grow into normally → no OPA. Sultan (great dirty-frag work, up-late nights) → no OPA this round despite the effort. Nathan retained decision authority (Peter: I'm going to support whatever you decide. But, be cautious.) but the framework was set explicitly.
No bugs, only change requests — structural reframe for product/engineering interaction
Peter coached Brady (with Brian Dawson present) to eliminate the bug terminology in JPD/Jira entirely and replace it with change-request framing — borrowed from a CRM system Peter used at a smaller company earlier in his career, where the bug-tracking system had no bugs category type to eliminate the QA-vs-engineering-vs-product debate. Code works this way at this moment, I want to change it. Whether it's a bug or a new request — not material. Brady committed on the spot to roll out the change with Chris and Jamie and through Nathan's team. Brian aligned. Goal: remove the psychological/defensive trigger that makes prideful engineers slow to ship.
Rakuten RFQ prioritized over Board prep + vulnerability response — scope-discipline enforced at line-item level
After conferring with Bjorn 5/15 afternoon, Peter reordered the week to put Rakuten RFQ response above both Tuesday 5/19 board prep and continued kernel vulnerability work. Held the boundary against scope creep in the submission itself: stripped runc nohz_full / ACC100 commits (Reqs 19, 37, 10, 38), scrubbed AI-generated CIQ Rapid Security Patch SLO Framework (48h/72h/14d commitments), softened Validated-for-[hardware] to Supported-on, kept RT kernel position to vmcore-dump-analysis-plus-recommendations only — no hands-on-keyboard custom patches. Deal size is $2M/year per Ramesh — different business with Rakuten than the existing engagement.
Engineering QBR format — collaborative discussion with three topics, not a presentation
Peter directed that the 5/22 Engineering QBR will be a collaborative working session rather than a formal presentation, organized around three questions: what is working well, what needs improvement, and how to streamline communication and increase work visibility. Chris Baek owns the shared prep doc that will collect bullet-point inputs from engineering leads ahead of the session.
CVE response strategy — three-pillar overhaul (process + tooling + strategic kernel review)
In Engineering Weekly Sync, Peter operationalized the 5/11 Leadership Roundtable vuln-handling commitment into three concrete pillars: (1) Chris Baek to restructure the embargo/CVE comms doc with Jamie, separating process from tooling/templates; (2) tooling strategy — Peter commits to email Greg requesting Claude Opus 4.7 whitelist for CIQ accounts AND to set up unbridled internal LLM models on Fuzzball for vuln investigations; (3) schedule strategic kernel philosophy review for early June, with Nathan and Justin to provide a list of downstream automation efforts to prioritize.
Open strategic review of RLC/RLK identity + upstream binding (Dirty Frag triggered)
Saturday 5/9 in #department-heads, in immediate response to Justin's Dirty Frag status table and Nathan's note about CIQ patches being shared with the RESF, Peter announced he wants the leadership team to take up a strategic question next week: what recurring vulnerabilities imply about CIQ's kernel posture, how tightly to bind to upstream, how to work with the RESF, and what it means going forward to be RLC and RLK. Aimed at framing input for the mid-to-late June LA in-person product-strategy session with Bjorn and Greg.
Reject open-ended LGU+ RHEL/OEL support commitments — best effort only
Nathan surfaced (via Justin) a CIQ <> LGU+ contract proposal requiring CIQ to provide workarounds and answer customer SR tickets for RHEL 6 (already EOL), RHEL 7/8/9, and OEL 6/7. Peter intervened in the same-day group DM with Bjorn, Art, and Ramesh to draw the line at best effort only — no commitments to deliver workarounds or answers. Asked Nathan if it is not yet in force so he can get in front of it before signing.
Prioritize build/test infrastructure to eliminate reactive engineering interrupts
After Dirty Frag CVE took Linux engineering offline for 24 hours, Peter committed to prioritize building robust build/test infrastructure as the proactive response. Told Brady/Brian this requires Product leadership to de-prioritize other work to make room. Surfaced publicly in #department-heads thread asking how to structure infra for the new normal of AI-assisted exploit cadence.
Senior leadership candidate engagement: open to talk, not under pressure, will not give away the kingdom
On the senior leadership candidate Greg/Bjorn surfaced (described by Bjorn as a bit all over the place and by Greg as starting like she is that much of a gift to us), Peter took a disciplined position: happy to talk, would like another senior person, but not feeling pressure right now and will not concede equity/scope/title to land her. Also flagged: expects steady-state of senior candidate flow for a while.
Icicle viability gate: AI inference benchmark on H100 decides go/no-go
Set a clear decision gate for the Icicle project: viability is determined by performance on a real-world AI inference workload, not synthetic benchmarks. Omer to run the RLC Pro AI benchmark on an H100 GPU. 2-3x synthetic CPU/memory degradation is acceptable IF power savings are significant for AI inference; otherwise project gets punted.
Reassign Owen to Maxs AI tooling for definitive performance evaluation
In Ryan 1:1, decided to assign Owen to Maxs AI tooling projects when Max returns from leave (~3 weeks). Defines the project with Nate beforehand so it is ready to deploy day one. Resolves conflicting feedback: Ryan sees senior Golang engineer underutilized; Bjorn questions value; Max and Nathan have called recent work AI slop.
Approve Veeam-related kernel engineering headcount; run Sergei + Jamin referral in parallel
In Nathan 1:1, approved the Veeam-related kernel engineering headcount. Nathan to continue engaging Sergei despite initial salary concerns and to evaluate a new referral (former Twitter/EC2 database engineer with strong automation skills) as a parallel track.
Assign Owen to Max AI tooling for definitive performance evaluation
Decision in Ryan 1:1 (Wed 5/6 12:30 PM) to assign Owen Wood to Max Spevack AI tooling projects on Max return from leave (~3 weeks). Definitive evaluation to resolve conflicting team feedback — Ryan sees senior Golang underutilized; Bjorn questions value; Max and Nathan have called recent work AI slop. Peter confirmed in DM with Ryan: We will get it rolling.
Three-tier board hierarchy formalized — Strategic EPICs / Value Drivers / Tactical Jira
Aligned with Bjorn on a 3-tier hierarchy: Strategic Board (EPICs requiring CEO-level prioritization), Value Drivers Board (GTM stories), and Tactical Boards (Jira execution). The current PPL board converts to the Strategic Board. Top ~50 only; anything below is wasted prioritization that will need redoing by the time it is worked on. Greg agreed to disagree-and-commit once Peter+Bjorn document the rules and walk him through.
Three-tier Rakuten kernel proposal — 8.10 preferred, 8.6 sustaining, $800k-$1M PS for full 8.6
Push Rakuten to migrate RLC 8.6 to 8.10. Three-tier proposal: (1) preferred — full support on 8.10 with CIQ vendor coordination to accelerate hardware recertification; (2) alternative — sustaining support on 8.6 with no new patches/backports (security risk on Rakuten); (3) PS engagement — $800k-$1M/year to fund two dedicated kernel engineers for full 8.6 support, framed explicitly as Professional Services cost not mainline engineering. June renewal is the forcing function. The original handshake-pricing deal with Tarek is void.
Everfox: require ~$2M front-loaded year-one payment, reject back-loaded $600k structure
Peter is requiring a large upfront payment ($2M floor with the proposal team; $4-6M float with Greg) for the new Everfox custom work (legacy CPU support, custom desktop) and rejecting the back-loaded $600k year-one structure. The $20M/10-year deal will be restructured to front-load payments, potentially by reducing total contract value if needed. CIQ will not absorb non-reusable engineering work without immediate funding.
Ship CIQ kernel patch with extra fix; contribute upstream; race to be first/best on CVE response
Linux kernel CVE response: CIQ shipping 10 fixes vs CentOS Stream's 9 (CIQ found and is fixing an extra issue related to the CVE). Extra commit submitted upstream to centos-stream and acknowledged for inclusion. CIQ pushing to be first EL distro to release, with primary goal of customer reassurance and secondary goal of public proof point that CIQ contributes to security and is large enough to serve big customers. Also pushing patches to RLC kernels as fallback in case RH doesn't move quickly.
Empower Nathan to defer Hassan secure-boot working session if engineering not ready
Apr 28 morning, Nathan flagged in #google-partnership-governance that he was not prepared for the Hassan working session that afternoon. Peter (at IAG, unable to attend) DMed Nathan: Youll be the senior guy in the room. If we arent ready for it tell Kelly we arent ready and to push it back. Brady and Kelly both signaled flexibility; the team coordinated and chose to proceed with a working-meeting framing. Peter closed the channel thread with Thank you all.
Assign Justin (not Nathan) ownership of Binarly engineering relationship
When Brady asked via DM whether Nathan or Justin should own the Binarly engineering relationship from CIQ side, Peter answered More Justin.
Introduce Serge Hallyn to Nathan for senior Linux engineering hire
Activated the dormant Serge Hallyn introduction (originally made by Meena Rajvaidya in January 2026, on hold while Serge had Q1 commitments) by emailing Serge Apr 27 to introduce him to Nathan Blackham, who runs Linux Development, to evaluate a potential CIQ join.
Expand Atomicorp partnership scope to absorb compliance load CIQ will not staff
Peter directed deeper integration with Atomicorp specifically to avoid investing in internal HR/headcount around compliance. Atomicorp will carry as much of the compliance load (STIG, FIPS, audit, certification, ongoing attestation work) as they are willing to absorb, freeing CIQ from staffing a dedicated compliance function.
Defer ARM64 Pro Hardened build until Core42 commits — group decision Peter endorsed
In Apr 26 Sovereign AI response review meetings, the team — with Peter participating — decided the response language to Core42 will acknowledge that Pro Hardened on ARM64 (and FIPS-143 ARM certification) is contingent on a client commitment, not unilateral CIQ investment. ARM64 build estimated weeks not months once committed; FIPS-143 ARM is ~$200k / 4-6 months and gates on a deal commitment. Peter explicitly told the room: "We are going to need Nathan to say when. I am not going to be able to say on this call."
Open Ascender hiring req — start the process now, hire after close
Peter approved opening the Ascender engineer requisition and running the recruiting process immediately, while noting actual hiring against the req cannot happen until the role formally closes. Operational handoff to Nathan to drive.
Manage Max situation — protect privacy, halt org outreach, decline his calendar
Peter is actively shielding Max Spevack from organizational pressure during a personal/private situation. Directed Sarah to access Max's calendar and decline all his meetings for the week, told Ryan to stand down ("No reaching out"), told Nathan to stand down ("worst thing Ryan can do is involve himself"), declined Mariah's offer to use Max's emergency contact ("let's give it a little more time"). Committed to talk with Max himself early this week.
Core42: pivot from Fuzzball sale to full-stack compliance partnership
After the Core42 Tech Dive Part 2 surfaced Core42 wants a single OS vendor for their full UAE compliance stack (NIST 800-53, BIS, IDAM, physical security) across three EOY-2026 GPU clusters, Peter immediately convened an internal Impromptu Zoom to reposition the opportunity. CIQ will propose a comprehensive partnership framing CIQ as the only group that can provide all requirements, with RLC Pro Hardened + Fuzzball + Ascender as the core stack and partners filling the remaining ~20%. Consultative play: CIQ will advise Core42 on which requirements in Eric Grundstrom's doc would cause unacceptable performance degradation vs. which can be met. Nathan to draft the proposal doc by EOD Saturday so CIQ can deliver an answer by Monday.
Escalated Dieter/RASF urgency to Greg publicly — secured EOW commitment
Publicly escalated Dieters stress and lack of RESF authority in #distinguished-leaders (When are we actioning Dieter? Hes super stressed and feeling unsupported), forcing Greg to commit End of week is my target on finalizing the RASF.
Reframe Azure relationship — CIQ supports RLC, not all of RESF
Directed Justin to align with Kelly on Azure messaging, clarifying that CIQ supports its own RLC offering (not the entire RESF ecosystem). Protects Nathans team from unbounded support burden while preserving the January 2027 contract renewal opportunity.
Committed CVE categorization + kpatch estimates to Google by Monday
After Tissa agreed no one can answer Madhus blanket questions, committed CIQ to deliver a CVE-type classification table with kpatch coverage estimates by Monday. Reshaping an unanswerable request into a structured, defensible answer by category.
Delivered Jira Hygiene Mandate to Engineering
In Engineering Weekly Sync, mandated immediate improvement in Jira hygiene after presenting 3.5 months of data showing >50% of tickets updated after their due date (most slips 2-4 weeks). Prioritized communication over speed — proactive updates required, aggressive initial targets (20-30% confidence) acceptable. Directed Chris Baek to add a 'blocked reason' field to Jira for stakeholder visibility.
Committed CIQ Engineering Resources to Unblock RESF
Committed CIQ engineering resources (specifically Max Spevack) to unblock RESF, positioning RESF health as critical to CIQ success. Committed to asking Nathan to prioritize providing new AWS contacts for Leigh to bypass stalled Duncan access. Directed Chris to lock down internal-rasf Slack channel for Leigh's weekly write-ups. Clarified Max's role as Chief Architect for Everything Linux focused on upstream health and AI-automated CVE remediation. Agreed Brian's value is limited to admin tasks — Leigh will communicate this assessment to Greg.
Delivered Jira Hygiene Mandate to Engineering
In Engineering Weekly Sync, mandated immediate improvement in Jira hygiene after presenting 3.5 months of data showing >50% of tickets updated after their due date (most slips 2-4 weeks). Prioritized communication over speed — proactive updates required, aggressive initial targets (20-30% confidence) acceptable. Directed Chris Baek to add a 'blocked reason' field to Jira for stakeholder visibility.
Escalated Google/NVIDIA Rocky messaging discrepancy to Bjorn
Peter flagged in Leadership Roundtable that Google is giving NVIDIA conflicting information about Rocky Linux usage. One Google contingent confirmed usage to Peter/Bjorn/NVIDIA last week, while a separate contingent is now telling NVIDIA Rocky is not being used. Peter escalated to Bjorn for same-day resolution.
Committed to engineering date hygiene confrontation with directs
Peter publicly committed in Leadership Roundtable to holding a tough conversation with his directs about deliverable date hygiene. Requested date-slip magnitude data from Chris Baek (days vs weeks) to focus on significant delays rather than minor variance.
Google NEXT - Value-First Attendance Framework for Nathan
When Kelly asked if Nathan should attend Google NEXT (April 21-24), set a value-first framework: Nathan goes only if there's a concrete business objective. Pushed Kelly to define the business case rather than defaulting to sending people.
NVIDIA Partnership - Resource Commitment for Grace Vera Patch Support
Committed to assessing headcount needs for NVIDIA Grace Vera patch support — both for the first 6 months and then ongoing. Forwarded NVIDIA patch list to Nathan for SWAG assessment. Nathan estimated 3-6 months for RLC, faster for CLK 6.18. Communicated requirements to Scott Hara: hardware access, test suites, functional and performance targets.
Google Meeting Communication Coaching for Brady/Nathan
Directed Brady and Nathan on exactly how to communicate during the Google GDC follow-up call — present CIQ as calm, capable, and dedicated; don't volunteer unnecessary details; distinguish technical infeasibility from resource constraints. Personally bookended the engineering meeting with success criteria. Chose to keep GDC post-mortem attribution under Peter's name rather than crediting others.
FIPS 6.18 Option 2 Engineering Kickoff
After Manu at Google did not respond to the relationship reset email sent Sunday, Peter escalated the FIPS proposal to Tissa via Kelly. Tissa authorized CIQ to proceed. Peter then directed Nathan to begin engineering work on Option 2 (faster timing path) while awaiting the Atsec contract. Engineering was held in reserve until external confirmations landed to avoid thrashing.
Committed to Improve Team Bandwidth Visibility in Monday Meeting
Committed to discuss with Nathan how to improve visibility in the Monday meeting on team bandwidth and impact, after Andrew raised he lacks visibility into other teams' work and hesitates to ask for help for fear of disrupting higher-priority work.
Google GDC Relationship Reset via CTO Email to Manu
Drafted and sent strategic email directly to Manu at Google Engineering, acknowledging communication disconnect, offering FIPS 6.18 acceleration at certification cost only (~$180k, CIQ absorbs NRE), directing shared git repo setup for co-development transparency, and requesting Google revenue ramp projections. Reviewed draft with Bjorn before sending; forwarded final to Max crediting his input.
RESF JIRA Date Reset for Realistic Expectations
Peter directed Nathan and Justin to adjust April/May JIRA items with low confidence due to RESF resource drain. Move them out now to give marketing a high-confidence scope for 4-6 weeks.
Google FIPS 618 as Commercial Leverage
Peter decided to use FIPS 618 kernel as leverage to push Google toward a paid contract before committing CIQ to significant new engineering work like live patching.
Empower Dieter as RESF Infrastructure Lead + Stock Grant
Peter decided to push Greg to give Dieter formal authority as RESF technical infrastructure lead, and approved a stock grant for Dieter with Bjorn's support to tie him more closely to CIQ.
Google Contract Engineering Justification
Directed Nathan Blackham to provide engineering cost breakdown for GDC work, and Kelly Hall to provide revenue numbers, building justification for higher pricing in Google contract renewal/expansion. Nathan confirmed ~$800K/yr cost for 1-2 engineers on GDC with zero profit, and CIQ actually spends more on GDC than GCE.
Accepted CLK 6.18 delay to March 31
Approved Jonathan Maple's request to slip CLK 6.18 from March 27 to March 31, due to kernel source-git conversion process. Positively reinforced Maple's proactive escalation.
Sensitive Decision
RESF — Committed CIQ resources (Dieter/Nathan) and proposed tech lead structure
Committed Dieter and Nathan to near-full-time RESF work. Proposed Dieter as RESF tech lead reporting to Peter for ~1 year. Told Leigh both are available immediately (Dieter now, Nathan when back from vacation). Scheduled Tuesday alignment meeting with Greg/Bjorn/Max to formalize structure and authority. Briefed Max on strategy: unified front with Bjorn, carrots and sticks approach for Greg meeting.
Personally Invest in Retaining Mustafa at RESF
Proactively reached out to Mustafa, scheduled a 1:1 for Monday March 23 at 9:30am PST. Shared outreach in #distinguished-leaders and declared 'I will invest HARD in the good ones.' Providing executive-level support to counter harassment from Taylor and Sharif.
Sensitive Decision
Shared Mini-Me Source Code to Internal Org
Shared Mini-Me source code by creating repo at ctrliq/min-me in CIQ GitHub org, after Ryan, Nathan, and Michelle independently asked for it. Proactively noted never having seen the code, setting quality expectations. Requested internal-only repo visibility.
Sensitive Decision
Google Deal — Engineering Owns Resource Projection
Directed that engineering (not finance/biz dev) should own projecting what the Google deal requires in terms of team size and capacity. Participated in Google Deal review meeting where consolidated $6M/yr development fee proposal was developed, including engineering guardrails (live patching scope limits, early renewal trigger). Deal structure: $6M dev fee for 5-7 senior engineers, uncapped variable usage fees (removing $1M cap), 15-25% margin on premium listings + MDF, early renewal trigger if scope exceeds funded team capacity.
RESF Operational Framework — CIQ Resources Work Under RESF Direction
Established and communicated to entire engineering org that all CIQ work for RESF must be done 100% at RESF direction, with every request flagged for Peter's visibility. Reinforced individually with Ryan (get accounting of in-flight work, ensure RESF person directing), Nathan (hold then green-light Taylor contact with specific messaging), and Mustafa (offer resources under RESF direction, recommend MatterMost for coordination).
Post-RESF Consolidated Deliverable Reset
Decided to deliver a single consolidated update to Lindsay on revised March deliverables after RESF work stabilizes, rather than incremental delay announcements. Nathan will reset all project dates at once.
RESF Internal Comms — Slack Post Not AMA
Decided to announce RESF engineering support via a Slack post (not company-wide AMA) to control narrative without signaling alarm. Nathan follows up with team Q&A for project impacts.
RESF Monday Cutover — Finalized 3 PM PT Execution Plan
Finalized the RESF infrastructure cutover plan for Monday March 16 at 3 PM PT, including DNS NS record flip, AWS VPC firewalling, account disabling (Lewis, Neal), and security audit — accepting up to 24 hours of DNS-related downtime.
Coordinated Google Post-Mortem Alignment Between Nathan and Bjorn
Ensured Nathan's Google post-mortem document was reviewed by Bjorn before sending to Google, because Bjorn has a Thursday call about contract changes and the doc could undermine his asks.
Sensitive Decision
RESF Operational Security — Compartmentalize Until Board Action
Directed that Brian must not be told anything until after the RESF board notification. Emphasized extreme caution about leaks to Lewis. Approved Joseph being read into the initiative but warned about leak risk. Sequenced information flow: board action first, then notifications, then credential recovery.
Sensitive Decision
Sensitive Decision
Custom Engineering Scoping Process — Nathan as Gate
Established formal process for unplanned custom engineering requests from sales: Nathan provides quick effort estimate (days/weeks/months), enabling formal prioritization. Nathan can say no, escalation goes to Peter.
Team Building Mandate — 6-Month Priority Over Features
Directed all engineering managers to prioritize team building over feature delivery for the next six months. Includes permission to swap out low performers, with Peter providing air cover for the risks involved.
Set maximum urgency on LTS 9.6 i686 package crisis
Nathan escalated that i686 multilib packages were never built for LTS 9.6 — the S3 bucket and Peridot config were never created. Every LTS 9.6 package with i686 variants is missing them. Brady flagged Siemens as a customer that specifically cares about i686. Peter acknowledged the escalation and set maximum urgency expectation.
Committed to RESF day-of execution planning meeting next week
Committed in #internal-resf-escalation to organizing a meeting next week to build an execution plan for the RESF day-of lockdown. Directed Sarah to invite Nathan, Max, Justin, and Dieter. Bjorn is finishing messaging drafts this weekend, so technical execution planning must be ready to match the communication track.
Committed to aggressive NVIDIA GPU Operator self-certification timeline for GTC
Led GPU Operator Self Certification meeting with NVIDIA. Committed CIQ to building pre-compiled GPU driver containers for Rocky Linux (mirroring Ubuntu model) and pursuing self-certification targeting preliminary completion by end of next week to support a GTC announcement.
Rocky project contingency war room - infrastructure security planning
Committed to scheduling a war room meeting to create a detailed, step-by-step contingency plan for securing Rocky infrastructure (AWS, FreeIPA) against potential hostile action by former members. Plan assumes an outage will be necessary to revoke access. Technical cutover to be planned before legal letters are sent.
Risk tolerance recalibration - push and be wrong for low-risk releases
Established new release philosophy: 'push and be wrong' for low-risk changes, prioritizing speed over perfection. Directed Nathan to ship two approved CVE fixes for unused packages immediately as a precedent-setting test case, bypassing the usual review process.
Release artifact ownership assignment - Nathan RPMs, Justin images
Assigned clear ownership of release artifacts: Nathan is the final approver for RPMs, Justin for images. Each owner defines their own validation process and has autonomy to improve it without seeking permission. Creates a 'throat to choke' accountability model for release quality.
Personnel action plan from effort/impact matrix review
Conducted comprehensive effort vs. impact performance review of ~20 engineers across kernel and platform teams, resulting in specific personnel actions: underperformers on short improvement timelines or face replacement, one engineer to be replaced with a high-impact hire, one engineer requires direct performance conversation about ownership and visibility, one to be reassigned to simple packaging tasks.
Mandated Engineering double delivery pace in 6 months
Directed Justin Haynes and Nathan Blackham to double their teams' delivery pace within 6 months. Method: hire new talent to build a team capable of that pace; some current members may not be a fit. In-person planning session in San Jose on Feb 25 with Justin, Nathan, Max, Peter.
Assign Max as RLC-AI benchmarking plan owner with RHEL comparisons
Assigned Max Spevack as owner of the RLC-AI benchmarking plan in response to Greg's question about ownership. Directed that RHEL comparisons be added to exit criteria. Bjorn owns product definition (what to benchmark), Max owns technical execution (how to benchmark accurately). Max will create a one-page methodology document for the Humane pitch.
Approve Jason Rodriguez performance exit path
Approved Nathan's plan to tell Jason Rodriguez he's 'not meeting expectations' and create an exit path. A 1-month exit plan is acceptable if Jason agrees. Performance gaps include missed deadlines (shim review for Rocky 9 late, Rocky 7 review pending) and unshippable code (large PR unlikely to pass review).
Override hiring freeze to hire Ben and Jamin for Linux engineering
Decided to bypass the company hiring freeze to bring on two key candidates: Ben (priority hire, competing with Anthropic offer) and Jamin (from Oracle, expensive but high-performing with strong ownership). Committed to sync with Mariah to clear headcount for both.
Sensitive Decision
Set Google GDC meeting strategy: build direct relationship and manage attendee roles
Peter decided to attend the Google GDC executive meeting himself (without Greg), bringing Max, Brady, and Nathan. Will personally manage Nathan's participation to protect Brady's roadmap presentation. Kelly directed to tell Google 'Peter has this covered.'
Directed Nathan to surface eng-product communication gaps
After Department Heads meeting, spent 30 minutes coaching Nathan 1:1. Praised his handling of the meeting despite frustration. Directed Nathan and Justin to be proactively transparent with product, and specifically to surface instances where engineering communicates clearly but product claims ignorance.
Mandated accelerated cadence with coordination accountability
In Department Heads meeting, mandated announcements every 2-4 weeks as non-negotiable. Drew accountability line: engineering protected for speed mistakes but NOT for coordination failures (status updates, product priorities, public channel decisions). Framed as make-or-break period driven by $30B revenue goal and Middle East partnership success.
Mobilized team for Saudi meeting prep and escalated NVIDIA DOCA blocker
Peter personally intervened to prepare team for critical Saudi Arabia partner meeting on RLC-AI. Posted in #product-rlc-ai asking about CUDA/DOCA availability, discovered NVIDIA written approval for DOCA OFED still pending. Emailed Scott Hara (NVIDIA) directly to advance the approval. Tagged Nathan, Justin, Jeff Uphoff, and Damen Knight demanding they answer Max's detailed technical questions within 24 hours. Set hard deadline: '24 hours from now.' Bjorn committed to calling Scott to reaffirm DOCA modification rights.
Sensitive Decision
AMD RLC Plus Strategy: Speed-to-Market with Minimal Scope
Decided to prioritize speed-to-market for the RLC Plus AMD co-marketing launch. The initial build will use upstream AMD packages (pre-built ROCm), the kernel driver (not upstream DKMS), and enable EPEL. Deferring the more robust in-house rebuild until market traction is proven. Justin Haynes to draft proposal and decision matrix.
Rocky Security Updates Urgency - Competitive Gap
Flagged to Max, Justin, and Nathan that Rocky security update tagging is a critical competitive gap needing urgent attention. Shared community post recommending Alma over Rocky because Alma correctly tags security updates and has timelier updates.
New Engineering Mandate - 2x Velocity in 6 Months
Set new mandate for Justin and Nathan: top priority is building a team that can deliver twice as fast in six months. This is a shift from the previous coaching model to a performance-driven one - setting ambitious targets, holding people accountable, and replacing underperformers.
Created #hey-pete-look channel for engineering visibility and recognition
Created a Slack channel #hey-pete-look for engineering managers to share wins and significant accomplishments. Two purposes: (1) provide Peter visibility to enable recognition when things go well, (2) create cross-team visibility of accomplishments. Committed to look at everything shared, but not necessarily comment on everything.
Time-based releases concept - trains leave on schedule
Consider moving to time-based releases where engineering ships whats ready on a fixed cadence (e.g., monthly or bi-weekly). Product must scope features to fit the timeline rather than engineering stretching to fit scope. The train leaves whether youre ready or not.
RESF crisis comms - single source of truth
In a RESF crisis, publish one official blog post as the central source of truth. All responses on social media (Hacker News, LWN, HPC forums) link back to that post. Do not engage in real-time debates. Own the traditional news cycle, not social media.
Project Shackleton - RESF contingency infrastructure
Build a parallel mirror of all RESF infrastructure in AWS (Git repos, Koji, vault/pub, Mattermost history) with goal of restoring Rocky Linux builds within two weeks if Lewis triggers his kill switch. Everything built with CDK and Ansible for repeatable deployment.
Servant leadership requires clear targets
Servant leadership and mentoring are fine, but must be paired with clear targets. Without clear targets, you cannot train the system. The AND between servant leadership and clear targets is mandatory - you cannot have one without the other.
Quality investment must serve velocity
Quality and automation investments are acceptable if the thesis is this will massively increase velocity in 3 months. Quality for its own sake is not the priority. Every quality investment should have a velocity payoff hypothesis attached.
Find the ceiling approach to velocity
Rather than incrementally improving 5% at a time safely, push until something breaks, then figure out if the breakage is fixable or a real ceiling. Air cover provided for aggressive experiments. Nobody gets fired for trying to go fast and breaking things.
Trustless processes over building trust
Focus on building contracts and processes that work without trust, not on building relationships. Good fences make good neighbors. Trust becomes a bonus, not a requirement. Contracts are what matter - relationships are nice to have.
PR standards in AI era - own the test suite, not the code
In an AI-enabled world, engineers should own the test suite and exit criteria, not necessarily every line of code. Quality comes from tests passing, not from reading every line. Engineer accountability shifts from I wrote this code to I own that this code passes these tests.
PRD contract process - stop teaching product
Stop trying to teach product how to write PRDs. Define acceptance criteria for PRDs, respond within 24-48 hours, rearrange and cut scope ourselves, and hand back a contract. They can accept or negotiate, but no endless back-and-forth. Engineering restructures the work and presents how we will deliver.
Team building over individual protection - Machiavellian approach
Stop protecting individuals at the expense of team success. The body being taken care of is the team, not individual engineers. Every day spent betting on someone who wont make it hurts the team. You already know who youre going to fire - just convince yourself youve done due diligence.
Trinity backfill for RLCAI/RLCH work, not maintenance
Use Trinitys backfill headcount to hire for RLCAI and RLCH work, not maintenance. Look for someone who can hold their own technically with Maple but will push AI adoption aggressively. Jamin identified as strong candidate - automation-first thinker, delivers and iterates, QA mindset.
Sensitive Decision
Aggressive goal-setting philosophy - undercut estimates, force innovation
Set targets that seem impossible (e.g., 2 months instead of historical 6 months) and let the team figure out how. Success is not just hitting the target - its learning and attempting new approaches. The managers job used to be to pad estimates; now its to undercut them.
AI ownership standard - own everything you submit
Engineers must fully own everything in documents and code they submit, regardless of whether AI generated it. Using AI is expected and assumed. Submitting AI output you dont understand or endorse is not acceptable. Quality and accountability matter, not authorship.
Nathan job redefined - build a team, not deliver outputs
Nathan deliverable is a team that can adapt and learn, not technical outputs. Focus shifts from figure out how to deliver X with current team to build a team that can deliver what CIQ needs. This is fundamentally different from traditional engineering management.
WBR restructuring to outcome-based commitments
Restructure the Weekly Business Review (WBR) to be outcome-based. At the end of the meeting, everyone has publicly committed to what they will deliver by Friday. The meeting should create social accountability through public commitment.
Focus CVE automation on top 5 priority packages first
Stack-rank the CVE priority package list and start automation with just the top 5 packages. Drive open CVE count for those 5 as close to zero as possible before expanding scope. Report closed-by-automation separately from will-not-do.
LTS roll-forward policy - small stable core, roll everything else
Define a small core set of packages (~5) that stay stable in LTS releases (kernel, glibc, gcc, and a few others). Everything else can be rolled forward aggressively. Customer-specific additions can be negotiated as needed.
CVE automation architecture - simple state machine, 1 CVE per commit
CVE automation should be built as a simple state machine with clear exit criteria at each step. Each commit addresses exactly one CVE. The orchestrator should be stupid-simple - just moving between states. Steps: Research -> Rebase -> Build -> Test -> MR -> Final Build -> Integration Test -> Promote to Beta -> Integration Test -> Production.
Redefine wins to only celebrate step-function improvements
Reset the definition of wins across engineering teams to only celebrate step-function improvements and exceptional contributions, not completing expected work. Use recognition strategically as a management lever to train teams toward higher performance.
Leadership meeting cadence - need-based, not scheduled
Leadership meetings will happen every 4-6 weeks based on need, not a fixed schedule. Buy refundable tickets ahead of time and cancel if there is not a full agenda worth discussing.
Everfox partnership requires ARR-target-level contract to proceed
Participated in technical scoping meeting with Everfox to understand feasibility of supporting their RHEL 8 to RHEL 10 migration for 100k+ hardened thin client units. Meeting was exploratory - no commitment made.
Addressed Nathan tendency to shield his people from criticism
Identified and communicated to Max that Nathan pattern of shielding his people from criticism is counterproductive and puts them at risk rather than protecting them. Aligned with Max to give same message to Nathan that we dont have time for this.
Committed to ensuring Greg technical direction reaches Justin
Committed to redirecting Justin to follow Greg architectural guidance on object storage/depot, and to be the conduit ensuring Greg technical direction reaches engineering clearly. Greg flagged that depot work was not in line with past directives.
Established escalation protocol for Product blockers
When Product (specifically Dawson) does not respond to meeting requests blocking engineering work, Nathan should explicitly request the meeting, then escalate to Peter and Bjorn via Slack if no response within 1-2 days. This creates a documented pattern of Product blocking Engineering.
Engineering dates commitment by Friday - reprioritize for revenue impact
Committed to publishing updated engineering dates/milestones by Friday for Monday group review. Acknowledged January deliverables are unrealistic - many items were newly added and cannot complete in remaining ~10 days. Will reprioritize toward revenue-impacting items first. Tomorrow all-day session with Chris Baek to rework H1 plan into aggressive but achievable targets.
Mandate big leaps risk approach for H1
Directed Justin to take big leaps and calculated risks to meet H1 goals, especially with AI. Speed and learning prioritized over avoiding potential issues. Example: a vibe-coded Portal in one day is preferable to a 1.5-month architected build - worst case is a day lost, best case is massive time-to-market advantage.
Strategic Map Framework - Value Drivers vs Internal Efficiency Separation
Established new H1 strategic planning framework that separates customer-facing Value Drivers from Internal Efficiency Drivers. Framework uses three lanes: middle lane for Value Drivers (the WHY), top lane for GTM activities, bottom lane for engineering deliverables. Also established phased estimation process: low-confidence ballpark dates first, then engineering-only session to raise confidence.
Accelerate Koji build system as RESF contingency
Emphasized urgency of having CIQ own build system mirroring RESF capabilities. Currently half of Nathan and Dieters time, targeting end of month. Requested visibility into milestones for board meeting prep.
Commit to increased visibility with engineering org
In response to employee feedback about low visibility creating a trust gap and fear-based culture perception, committed to: bi-weekly positive Slack updates, more 1-on-1s with key individuals, frequent positive feedback in public channels, weekly summary of focus areas, and an SF meeting with Nathan/Justin/Max.
Work intake must flow through managers, not directly to engineers
Established new process where small customer requests go to Engineering Managers (Justin, Chris W.) for approval. EMs will attend bi-weekly CECA board review to ensure they are in the loop on incoming work.
Koji Build System Priority - RESF Risk Mitigation
Directed Nathan to prioritize Koji cluster standup with Dieter. Goal is to have independent build infrastructure in place so CIQ is not dependent on RESF. Asked for timeline if this became top priority, and indicated Dieter should reprioritize accordingly.
Termination Messaging Strategy - Organizational Signal
Discussed with Max the organizational messaging around Trinity termination. The termination is not about introducing fear but correcting a losing posture that existed before. Nathan was coached to communicate clearly that Trinity was not meeting the bar, and that leadership alignment is expected.
Max Spevack Role Expansion - Formalized Authority
Announced to engineering that Max takes a dedicated leadership role spanning Linux Engineering and RAT, reporting directly to Peter. Max acts with Peters authority in meetings, serves as quality gate for major decisions, shapes engineering culture, and is an escalation point outside the management chain.
ICP Consolidation - RLCH and RLCAI into Fuzzball
Consolidated RLCH (Rocky Linux Confidential Hardened) and RLCAI ICPs with Fuzzball ICPs to simplify GTM. RLCH targets regulated industries, government, power distribution. RLCAI targets AI-inferencing and compute-heavy industries. Rocky Pro kept separate for mid-market RHEL/SUSE/Oracle replacement motion.
H1 Planning Framework - 3-Lane Model
Introduced a new 3-lane planning model to address GTM and Engineering misalignment. Top Lane (GTM): marketing campaigns, messaging. Middle Lane (Value Drivers): the why - market state change, ICP, business significance. Bottom Lane (Engineering): deliverables driven by Value Drivers.
Ownership Definition Clarification Commitment
Committed to working with direct reports to create a clear, shared definition of Ownership and distribute it to all of engineering within a couple of days.
Trinity Quirk & Chris Short Terminations Executed
Terminated Trinity Quirk for failing to progress NARF/CVE automation integration despite clear expectations. Terminated Chris Short for failing to deliver on critical RESF-related goals. Sent transparent communication to all of engineering explaining the WHY behind these decisions.
CVE Automation Prioritized Over EUS Daily Numbers
Decision to push the EUS catch-up deadline to prioritize automating CVE work. Automation is a higher priority than hitting daily EUS numbers manually.
Leadership 1:1s with Maple, Dieter, Andrew
Decision to begin regular 1-on-1s with Maple, Dieter, and Andrew (when onboarded) to build trust and ensure unified messaging.
NARF Performance Accountability - Public Termination
Decided to execute a public termination within Nathan's org on Monday if NARF deliverables are not met. This is specifically intended as organizational signaling to drive accountability and force motion across the team. A second termination (Chris) may be required for legal reasons.
Ali Contract Termination
Decided to end Ali's contract after he missed another check-in meeting and failed to demonstrate proactive delivery necessary for a remote contractor. Reached out to Mariah to understand the process steps.
Andrew Jorgensen Level Flexibility Confirmed
Clarified with Brianne that Andrew does not need to come in as Maxs peer. Happy to slot him into either the more senior or less senior position based on his comfort. Want him coming in feeling happy and excited about what hes signing up for.
H1 Planning Strategy - Aggressive Goals with Staggered Milestones
Articulated H1 strategy: shift from hope to concrete plan with aggressive audacious goals. Achieve goals differently not just faster. Staggered milestones every 4-6 weeks for course correction. Missed milestones trigger retrospectives for process or personnel changes. Clear prioritization at Reno eliminating everything is P0 problem.
Ali Contract Termination Warning
Alis contract will be terminated immediately if tomorrows progress review is unsatisfactory. This sets a clear performance standard and signals that when work is deemed important, there is no time to wait for progress - it must be executed efficiently and quickly.
CVE Remediation Mandate with Termination Consequence
Mandated CVE remediation as top priority and made clear that Trinity or Jeff will have their employment terminated due to lack of progress on adopting automation tools. This termination is intended to signal to the rest of the team the grave importance of improving how this work is done.
Build Environment Contingency Prioritized
Aligned with Nathan that his top priority is secretly building a full build environment (Koji, Pungie) to create a concrete recovery plan in response to potential RESF sabotage threat.
Andrew Jorgensen Hiring Approved
Approved hiring Andrew Jorgensen for an IC role reporting to Nathan Blackham. Offered flexibility on level - he can come in at senior or less senior position based on his comfort.
NARF Launch as Forcing Function
Decided to use NARF automation launch as a forcing function to drive adoption. Max will launch NARF for simple backports by Friday, generating MRs for human approval. Nathan team required to review all generated MRs by end of next week. Peter to meet with Nathan tomorrow to mandate CVE remediation as top priority.
CVE Strategy - Eventually Consistent Model
Aligned with Max on new approach to CVE patching: adopt an eventually consistent model that prioritizes rapid patching over perfect upfront testing. Accept a small error rate (e.g., 5%) as a necessary trade-off for speed, with fixes handled by COE.
AI Policy Governance Approach
Agreed to collaborative governance approach for AI policy: Peter, Nathan, and Max will present AI exploration findings to the AI committee weekly, ensuring engineering innovation feeds into policy development.
CVE Remediation - Direct Intervention Required
Identified unacceptable lack of urgency from Nathan team on NARF-created CVEs. Will take direct action to address performance issues next week.
Andrew Jorgensen Hiring - Deferred to Role Clarity
After CTO interview for Sr. Linux System Engineer, did not fill in final hire/dont recommendation. Deferred to Max/Nathan to clarify what they want him doing and culture fit concerns.
RESF Infrastructure Independence - Technical Execution
Directed Nathan to mirror all RESF repositories and initiated build environment duplication. Created #internal-resf-escalation channel with strict confidentiality rules. Keeping technical circle small (Nathan, Max, Justin, Dieter) while moving quickly.
RESF Crisis Response - Infrastructure Independence
After learning of hostile plans by RESF board members (Louis, Neil, Brian Clemens) to publicly attack CIQ, dismantle Rocky Linux infrastructure, and damage the project, initiated emergency response to replicate RESF infrastructure for Rocky 8, 9, 10 with minimal team awareness.
RLC 9.7 Launch Path Decision
Participated in RLC 9.7 Launch planning meeting to decide path forward on release and rework priorities.
Championing AI Butler Adoption Internally
Shared detailed Slack MCP setup instructions with team members. Hosted/recorded AI Dashboard session demonstrating Butler setup. Personally using and advocating for meeting prep automation.
Championing AI Butler Internal Adoption
Hosted and recorded the AI Dashboard/Butler setup session to drive internal adoption of Claude-based personal productivity tools across CIQ. Shared personal use case of creating meeting prep notes from Slack/email/docs.
Related Patterns (17)
Proactive Talent Pipeline Investment
Invest in building leadership bench and talent relationships before there is an urgent need. Use proven relationships from past experience to create optionality.
Accountability Follow-Through
When you issue a warning or mandate with stated consequences, you follow through. Warnings are not threats - they are commitments. The credibility of future accountability depends on following through now.
Executive Sponsorship for Strategic Partnerships
Strategic cross-company initiatives and major client partnerships require executive-level accountability to move at the right pace and ensure proper prioritization.
Small Circle for Sensitive Operations
When executing sensitive strategic operations, keep the circle of informed people as small as possible to prevent leaks that could accelerate hostile action or undermine the initiative.
Protect Engineering Capacity
When external demands threaten to overload engineering capacity, protect capacity by either requiring the demand to come with additional resources, or forcing hard prioritization choices upstream.
Lead by Example with New Tools
When championing new tools or processes, personally use them and share results rather than just advocating. Learning by doing and demonstrating value through example is more effective than mandates.
Protect Engineering Focus Through Process
When faced with requests that would disrupt engineering focus (from sales, governance, product, or other stakeholders), establish processes that protect engineering ability to innovate while still satisfying legitimate concerns. Prefer systematic solutions over ad-hoc responses.
Three-Lever Talent Management
When pursuing a velocity or performance mandate, simultaneously operate on all three talent levers — upgrade (hire better), retain (protect key people), and exit (remove blockers) — rather than sequentially. This creates compounding momentum: exits free capacity for upgrades, retention preserves institutional knowledge during transitions, and upgrades raise the performance bar that justifies further exits.
Reclassify to Route - Decide Who Owns It, Then Give a Criterion Not a Verdict
When a question arrives at Peter framed in one domain, he often does not answer it in that framing. He reclassifies it into the domain that actually governs the outcome, which relocates ownership to whoever owns that lane, and then hands down a decision criterion rather than a verdict. The reclassification IS the decision - it determines who decides. He does this rather than adjudicating on the merits himself, even when he was explicitly cc-ed and even when a direct report challenges him on the substance.
Purpose Is the Decision Procedure
When someone asks how a process, board, tool or artifact should handle their specific case, Peter refuses to answer on the askers terms. He re-derives the answer from what the artifact is for, states that purpose as the only decision procedure, and lets the answer fall out. Anything found to be serving a second purpose is deleted rather than debated. Tools and views are explicitly subordinate to definitions. He will accept that the askers real problem is simply not solved by this artifact rather than widen the artifact to cover it.
Demonstrate the Standard, Then Collect It
When a new leadership expectation has to land across multiple orgs, Peter does not write a spec. He runs a live exemplar in public with the strongest performer first, says openly that the ordering was deliberate, keeps the form of the deliverable open so the ask stays about the thinking rather than the artifact, lets the delta be self-evident to the people who will have to close it, and then collects the same from everyone else on a named rotation. He prefers showing imperfect work now over polished work later.
Route Non-Differentiating FTE Classes to Partners
When CIQ would otherwise need to staff a function whose work does not differentiate the company — compliance bureaucracy, audit/cert paperwork, ongoing regulatory attestation, etc. — Peter routes the load to a partner who already owns adjacent capability rather than adding the FTE class internally. Org-shape decision dressed as a partnership decision.
Decide on the Precedent, Not the Case
When a request arrives framed as a one-off, Peter does not evaluate the one-off. He evaluates the rule that granting it would write, and answers that instead. Peter generalized this himself on 2026-08-11: it is always about understanding precedent - whether it is a comp change or anything that structurally affects the company. It is therefore NOT a compensation pattern; the domain of the presenting request is incidental. The tell that this pattern is live is that the stated reason for the answer refers to future cases rather than to the merits of the present one.
Redesign Conditions Over Policing Symptoms
When a direct report names a vulnerability and proposes surveillance-style verification mechanisms (breathalyzers, daily check-ins, monitoring rituals), Peter accepts the disclosure but pushes back on the surveillance model. Treats the verification proposal as a signal that the underlying environment needs redesign — and offers to change the conditions that produced the vulnerability rather than instrument the symptom. Costs Peter optionality (e.g., committing to broker work-hour expectations directly with the partner/spouse) — the asymmetry signals genuine retention vs transactional.
Metrics Must Follow Strategy
When shifting team priorities or strategic direction, the communication alone will not drive behavior change. Engineers may acknowledge the new direction but continue existing behavior patterns without clear, explicit metrics holding them accountable.
Constrain the Mechanism, Not the Access
When AI or automation raises a governance concern, Peter does not restrict who or what may reach the data. He constrains HOW the reach happens, so the pathway becomes auditable and deterministic. The failure mode he designs against is non-determinism, not leakage - a wrong filter in inspectable static code is a bug you fix once, while a model that sometimes pulls the wrong field is an unbounded, unauditable liability. He will therefore accept imperfect filtering and eventual leakage as the price of adoption speed, but will not accept a non-inspectable pathway.
Systemic Investment Over Short-Term Metrics
When short-term metrics conflict with systemic infrastructure improvements, invest in the infrastructure. Systems that prevent future problems are more valuable than optimizing current metrics.