Brady Dibble

Refuse an SDLC release-cadence contract that would bind engineering - prioritization authority stays with Product

In the weekly sync with Brian Dawson and Brady Dibble, Brian proposed defining an SDLC/release process and release SLOs, framing recurring commitments (cloud image drops, driver updates, benchmark work) as an implied contract engineering should honor without being re-prioritized each time. Peter refused the framing outright and repeatedly: engineering will ignore any such document, and the only thing engineering will not ignore is Product. He told them the document has no teeth for engineering, that Product may absolutely write one and shove it down engineering throat in the moment, but the moment it becomes a thing engineering must uphold independently, Product has handed its authority away. He used the NVIDIA driver ask from the CEO the night before as the live example: rather than absorbing it as recurring work, he turned it into a ticket in front of Product so they could rank it. He also drew the boundary for what Product should write - tickets that are changes, not tickets that restate steady-state, so a one-time automation ticket replaces a recurring one.

Sep 7

Sensitive Decision

Sensitive

Broken-in-production is an automatic fast path - small thing with embarrassing impact jumps the queue regardless of the size of the epic around it

In the 2026-08-25 Exec Product Prioritization session the errata CPE-to-product mapping item had drifted to number 30 on the board. The specific defect was that CIQ was shipping images identified as Rocky Linux when they should have been identified as RLC Pro. Peter moved it into the top ten on the spot. Brian Dawson stopped and asked what criterion drove the move, and Peter generalised it: something broken that we are shipping is an automatic fast path. He bounded it in the same breath - the broader errata epic is genuinely large and stays where it is; only the shipping-the-wrong-identifiers piece jumps, because fixing that piece is not dramatic at all. In the same meeting he pushed the reciprocal direction, arguing that some net-new items should be prioritized above keep-the-lights-on work because a two-month effort sitting at number 34 becomes a six-month effort.

Aug 28

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.

Aug 28

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.

Aug 19

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.

Aug 19

Extend the existing Claude PII policy unchanged to the new AI systems - and settle that HubSpot data is not restricted customer data

Brady Dibble raised a data-access question about additional AI systems on 2026-08-15, treating the data he had lost access to as uniformly restricted. Peter refused to answer it per-system. He ruled that (1) the things you lost are not all the same - some are restricted and some are not, (2) Hubspot data is not customer data, and a list of customers is just fine while PII is not, (3) as far as I am concerned the same rules can apply to the two systems you just listed, and (4) there should be no barrier to moving approved data to them, but they should not open the door to more data than we currently allow to Claude. He pointed Brady at the existing policy, noting Michelle has it.

Aug 18

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.

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.

Institute the inspectable-function rule for AI data access as company-wide hygiene - and refuse to make it either a shared library or retroactive

At the Friday AI Committee, Peter re-delivered the rule he had set once before and watched not land. He used Mini-Me as the worked example: AI helped create the capability, but AI is not part of the runtime function of accessing the repositories. Claude cannot get to Slack except through that function. It does not have the keys. He asked for exactly one thing - if you are pulling data in or out of a CIQ system, do it through a function that you write and could inspect - and explicitly declined two obvious extensions. He would not make it a shared implementation, because there is no value in building a library of these things and because forcing an MCP server would block people from experimenting with technology being stood up today. He would not apply it retroactively, because a year from now we are going to have 100 times as many tools running around the company, so he is way more worried about the giant tsunami of stuff that is coming. He named three reasons rather than one: inspectability, 100 percent repeatability, and teaching the company the right pattern, since Claude is going to make everybody at the company a developer and that is incredibly terrifying if we do not teach people to be better developers. He extended the bar to local models when asked, and licensed Michelle to publish the message with his name attached.

No engineering team owns C3 - the content is wrong and outdated, so manage it or kill it, and Peter explicitly does not care which

Brady Dibble asked Peter directly at 8:40pm whether any team in Engineering owns C3 yet. Peter answered within two minutes: To my understanding the explicit answer is No. I raised it with Bjorn last week. The content is wrong/outdated. We need to either manage it or kill it in my opinion. (I do not care which). Brady acknowledged - thank you for confirming. Three things are established in one message: engineering has no owner, the artifact is in a bad state, and the acceptable resolutions are exactly two with no preference between them. The escalation had already been made to Bjorn a week earlier, so this is confirming and sharpening a position rather than forming a fresh one - what is new is the binary and the explicit indifference.

Jul 30

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.

Jul 30

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.

Jul 30

Confidence must rise as the target date nears - slide the date early rather than carry a 60 percent to the wire

Reviewing Justin Haynes automated-repo-testing item on the NGD board, Peter ruled that a low confidence number a few days from a target date is itself the failure. His instruction: this close to the end of the week we need to be communicating to the company, through those two numbers, whether they are getting something - so a few days from the end I do not want to see a 60 percent confidence number, what I want to see a few days ago is that date sliding out now so that we are communicating a higher confidence number when we are this close to a target date. He grounded it in consumer value: the company cannot do anything with 60 percent confidence July 31st, they cannot take attention on that. Immediately afterwards, when Duane Carson acknowledged a cross-team miss on the 10-2 bits, Peter drew the complementary line - I do not mind misses as long as the team recognizes, hey, we have a miss here, and here is how we are going to get better.

Jul 29

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

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

Jul 29

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.

Let Brady raise the kernel-team cloud-resource block in Engineering Weekly, with the test being whether Justin agrees there is a problem

Brady Dibble DMed Peter saying he intended to surface in the Engineering Weekly a flag from Maple that the kernel team is blocked on cloud resources and is being redirected to Outfitter instead of getting the access it needs. Brady noted he had checked with Justin first, was raising it early because every day is precious for the kernel team, and explicitly offered to drop it if Peter preferred to handle it internally to Engineering. Peter replied: you can raise it, the only question I am going to ask is whether Justin agrees there is a problem.

Codify how engineering answers sales - bugs get fixed, out-of-scope features get a no, and the only next step is Product not re-escalation

Coming out of the LG episode Peter laid down the operating rule in writing in the temp-lg channel: Engineering will respond to sales requesting a fix for a bug and will deliver that bug fix without product involvement. Engineering response to a sales request for a new feature that falls outside currently supported builds or plans is no. The step after that is for Product to get involved. In the meeting he attached three companion rules: re-escalation after an answer has to stop, engineering should stop saying you can try it and it might work in favour of that is not supported, and CIQ must present a unified front so no internal voice tells a customer something is a bug after engineering has ruled it is not. He also drew the line between discussion time and decision time - internal deliberation should not be shown to sales as if it were still open.

Definitive no to LG U+ cross-distro package support - the test is whether we would ship it down the middle for everyone

LG U+ wants to run DNF update on RHEL servers pointed only at CIQ/Rocky repos, which touches bootloader packages and breaks the system on reboot. They rejected the exclude-packages workaround. In the LG - Next Steps meeting Peter refused to let the discussion be about whether the ask is a bug or whether it closes the deal, and reframed it to a single question for Justin: is this something we would do down the middle for everybody, or is it one-off work for LG. Justin answered we cannot support it. Peter then gave the definitive verdict: no, this is not something CIQ Engineering is going to support. He posted the same conclusion in the temp-lg channel after aligning with Bjorn, and handed customer messaging to Bjorn with Tommy and Art.

Reclassify the GDC MIP-listing disclosure question as a contract-timing call and route it to Kelly Hall with a decision criterion

On 7/23 Brady Dibble escalated to Peter, Bjorn, and Kelly that CIQ still had not told GDC the 8/8 MIP listing was at risk because the ESV certificate had not arrived from NIST - and that atsec had flagged NIST not asking for review or comment, typically meaning they had not reached the certificate. Justin Haynes pushed back directly with why would we not let them know. Peter did not answer the disclosure question. He assigned it: this is a Kelly Hall call, and supplied the criterion - whatever path is most likely to get a contract signed in the next couple of days. The thread resolved as non-disclosure, with Bjorn stating he would not flag it and Justin later confirming they did not bring it up and neither did we.

Jul 24

Narrow the NGD board to cross-company coordination only - not a deliverables tracker and not a complete decomposition of product acceptance criteria

In the 7/24 Brian Dawson / Brady Dibble sync Peter ruled against the working assumption that the NGD board is the comprehensive ordered list of engineering deliverables. His ruling: the boards only purpose is coordination across the company for things that drive value. It is not for tracking deliverables, not for holding engineering accountable to delivery dates, and does not need to be a complete decomposition of the acceptance criteria in a product ticket. Anything that should not link to a value driver is a component and belongs in Jira, which Peter will never look at. Engineering may blend several product-priority items into one NGD ticket or ship one top-level ticket, as long as the board forms a palette that overlays the product priority and engineering can say when these are done, this product priority is complete. Separately he fixed the product priorities list as strategic priorities full stop - no delivery dates, plus an engineering order-of-operations column and nothing more.

Jul 24

Release the Google 6.18 build; hold the line on future deliverables until Google resolves the LTS question

On 7/22 Peter lifted his own 7/21 hold on the Google/GDC 6.18 image. He connected with Bjorn first, then told Justin Haynes in #google-partnership-governance and in DM to Kelly Hall: give Google the build. He emailed Tissa Senevirathne at Google the same morning confirming the release, restating a firm stance that the LTS work has already been provided to Google, and stripping Mahdu and Alyssa off the thread. He paired the release with an explicit condition: future deliverables are held until Google sorts out the LTS commitment.

Jul 24

Codify the Product-Engineering operating model: value drivers are context, product demands date+confidence and owns prioritization

In the Peter/Brady/Brian session Peter laid down the operating contract between Product and Engineering. (1) Value drivers are context/metadata, period - not prioritized and not a vehicle to smuggle in scope. (2) Product superpower is to demand a date plus confidence number from engineering and own prioritization, while staying on its own side of the fence - not telling engineering how or who, not chasing the whys. (3) Escalation: first confirm alignment on priorities; if not aligned, mutually escalate to Peter and Bjorn immediately. (4) Engineering runs a sustainable pace; early low-confidence estimates will slide, but a re-baselined date is made intentionally with test harness and context, and must then be hit.

Jul 21

EU Cyber Resilience Act - scope hinges on legal definitions; Bjorn to engage lawyers; aim to publish our own definitions

On the CRA thread (raised by Leigh Hennig re a Sept 11 deadline for RESF/Rocky/CIQ), Peter directed that the entire scope hinges on two definitions - vulnerability and actively exploited - and delegated Bjorn to engage lawyers to weigh in. Strategic aim: ideally CIQ/RESF publishes its own definitions, reframing CRA compliance as living up to our stated market promises rather than being exposed to outside interpretation. Until legal responds, nothing to do.

Jun 18

Reject centralized AI governance and access-guardrails on internal AI tools - optimize adoption and transparency, accept eventual leakage

In the Brian/Brady sync Peter took a firm stance and described a past deliberation he had already resolved: he considered building protections so Mini-Me could not leak personnel and decision info, and decided NOT to. More broadly he rejected Brian Dawsons pull toward centralized applied enterprise AI coordination - teams should deploy their AI-built tools without approval (told Brady to just ship Cairn and expose the agent-to-agent endpoint without routing through Okta), and he would rather pay the eventual cost of a leak than slow adoption. He asked Brian to write down what he is afraid of so the fears can be weighed against each other.

Jun 18

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.

Jun 12

Product owns prioritization of everything in the JPD

In the Friday 5/29 Brian/Brady weekly sync, Peter closed the loop on a multi-week doctrine arc by making explicit that the JPD board is not just for net-new product work — it owns prioritization of EVERYTHING engineering does, including what feels like sustaining/KTLO/Bridge bug-fixing. If product wants something to receive engineering effort, it has to take a numbered slot on the JPD board. Anything not on the board should be assumed to receive zero engineering attention, and product owns that tradeoff in real time. Peter explicitly named a posture shift from Socratic teaching to directive (do-it-this-way) because the prior rounds of teaching had not landed.

May 29

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.

May 19

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.

May 8

Eliminate one-off release processes — paved-paths Jira initiative Peter commits to prioritize

Mandated elimination of all one-off release processes. Justin to file a Jira ticket for the paved-paths initiative; Peter commits to prioritize it. Companion to the Jira-as-system-of-record mandate established the same meeting. Direct response to recent CVE post-mortem revealing most products run ad-hoc release flows.

May 7

Coach Brady on 2-step framework (strategy first, tactics second) and enforce live

Taught Brady the 2-step framework in his weekly 1:1: define strategic What first, then plan tactical How with Engineering. Then enforced it live in the CVE post-mortem group DM with Brady and Brian. When Brady proposed concrete CVE-response solutions (cross-train engineers, designate a quarterback, escalation paths) without first clarifying priority trade-offs, Peter refused to engage on the solutions: Your job, your ONLY job, is prioritization. Step one is answer my question. Step two will never happen absent step one. Never. Not one time. Brady eventually conceded.

May 5

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.

May 5

PPL is being misused — push Bjorn to realign it to strategic priorities

The Product Priority List has drifted from a strategic-priority list (epic-level) into a granular project tracker, obscuring strategic priorities (RLCAI on Spark buried at #88) and creating bottlenecks (Ollama package delayed to May 15). Peters position: PPL must return to defining company strategy at epic level; granular tasks belong in JIRA. Will engage Bjorn directly to realign — this is the framing decision; the implementation is the negotiation with Bjorn.

May 4

Documentation process — Product defines exit criteria in Jira, Engineering delivers

Formalize documentation ownership: Product defines documentation requirements in Jira ticket exit criteria (e.g., docs suitable for blog post). Engineering delivers content meeting those criteria. Product or Marketing (Lindsay) refines technical content into user-friendly format.

May 4

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.

May 4

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.

Apr 29

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.

Apr 29

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."

Apr 27

Quality initiatives must be ticketed visible work, prioritized by Product

In the Brian/Brady weekly sync, Peter reinforced that quality cannot live as implicit expectations — Product must define and prioritize quality initiatives as explicit tickets that compete for resources against feature work. Engineering will only prioritize what is tracked. Companion frame: Exit Criteria are the product promise (Product owns, Engineering can challenge via debate); QA is delivery validation, split between Engineering (general releases) and Ryan's org (customer-specific fixes in mirrored environments). Brady to split test automation from build automation into a high-priority CI/CD ticket. Peter to verify with Justin that the build process at minimum runs a boot test.

Apr 18

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.

Apr 18

Delivered Jira Hygiene Mandate to Engineering

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

Apr 17

Delivered Jira Hygiene Mandate to Engineering

Apr 15

Escalated Engineering Estimation Accountability — 58% Miss Rate

Identified that 58% of engineering estimates are being missed, with most date changes occurring after the target date. Declared this unacceptable and directed Brady to present this data at the next Engineering Weekly (Apr 14). Peter committed to personally attending to ensure accountability and a clear plan to fix the process.

Apr 11

Reinforced Product Owns Exit Criteria — Engineering Cannot Unilaterally Remove Requirements

Directed Brady and Brian that Product defines the 'what' and the 'when' while Engineering owns the 'how'. Engineering cannot unilaterally remove requirements from exit criteria. The correct response when a requirement is challenged is 'When can you deliver it?' not to debate or remove it. Forwarded the meeting recording to Bjorn and Chris Baek to align them on this prod/eng interface vision.

Apr 11

Defended Global Prioritization Model with Per-Team Computed Views

Convinced Greg that product prioritization must remain a single global list, not grouped by team. Agreed to add a computed property showing priority within each team for visibility. Fuzzball was reprioritized into top 20 in Exec meeting; Greg's remaining concern about Fuzzball not being high enough was resolved via the global+computed-property approach.

Apr 11

Reinforced Product Ownership of Exit Criteria

Engineering unilaterally removed the NVIDIA CUDA toolkit requirement from RLC Pro 9.6 LTS exit criteria, citing lack of automation. Peter clarified in the Brian/Brady sync that Product owns exit criteria and prioritization, Engineering owns the solution and date. When a requirement is challenged, Product asks When can you deliver it - not whether to include it.

Apr 10

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.

Apr 9

Value Driver Consolidation from ~50 to ~3 Core Drivers

Peter demanded that the current list of ~50 'value drivers' be reduced to ~3 core, company-wide drivers that articulate CIQ's mission and differentiation. Called the current list a 'shotgun approach' and 'pile of stuff' that prevents focus. Test: if a product's value pillars cannot be tied to these core drivers, its strategic value to CIQ should be re-evaluated. Also requested a 1-year product vision for RLCAI/RLCH from Brian Dawson.

Apr 8

Taking Personal Lead on All GDC Communication for Next Month

Peter decided to personally lead ALL Google GDC communication for the next month, replacing the current multi-voice approach. New framing: 'we are technically capable; let's discuss the contract' instead of 'we can do it if you pay us.' All GDC work must be categorized into two buckets: work CIQ would do anyway (GDC accelerates it) vs work done only for GDC.

Apr 8

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.

Apr 7

Reaffirmed Speed-First Culture to Brady Before Leave

Reaffirmed to Brady that the directive is move fast and break things — leadership provides air cover. Corrected a team perception that leadership expects both speed AND perfect quality.

Mar 13

AI Governance Single-Track Pivot for ISO 42001

Pivoted AI governance from dual-track (internal vs products) to single rigorous model because CIQ products (RLCAI, Fuzzball, Werewolf) now directly integrate AI, changing the liability profile.

Mar 13

Enforcing Product Process for Greg's RLCAI Requirements

Enforcing the correct process by directing all of Greg's RLCAI requirements to the Product team rather than allowing Greg to bypass Product and give direct requirements to Engineering. Brian Dawson raised the concern; Peter is supporting and enforcing.

Mar 11

Team Building Mandate — 6-Month Priority Over Features

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

Mar 4

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.

Mar 3

Committed to Google contract restructure proposal within 1 week

Secured commitment from Google's senior management to consider a contract restructure addressing financial unsustainability. Peter committed to delivering a formal proposal for new contract terms within one week.

Feb 25

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.'

Feb 17

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.

Feb 12

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.

Feb 11

Demanded war-room or date ranges for RLC Pro release dates

Marketing (Lindsay Aamodt) published release dates in #department-heads: Feb 19 RLC Pro, Feb 26 RLC Pro AI, Mar 5 RLC AMD. Justin Haynes responded that dates were 'written in light pencil.' Peter directed Justin: if dates aren't confident, either commit with a war-room to hit them, or provide GTM with ranges now so they can plan. Justin acknowledged and scheduled time with leads.

Feb 11

Established 'what vs how' framework for Product-Engineering communication

In weekly sync with Brady and Brian, established a clear framework: Product defines the 'what' (exit criteria with specific, aggressive targets like 'ISO builds <4 hours'), Engineering defines the 'how'. Vague communication to leadership creates unnecessary reactive work and must stop. Escalation path defined: weekly syncs or on-demand to Peter for process breakdowns only.

Feb 8

Approved RLC+ and Pro product hierarchy with new naming and de-risked launch cadence

Approved a new product hierarchy: Stock Rocky (pure community mirror), RLC+ (free with NVIDIA/AMD drivers), RLC Pro (paid tiers). The RLC name now signifies CIQ value-add. Also approved a de-risked 3-phase launch cadence: Phase 1 (Feb) bundles RLC Pro + RLC Plus NVIDIA; Phase 2 (Feb) RLC Pro AI; Phase 3 (Mar) RLC Plus AMD partnership. Identified backporting vs roll-forward policy gap as a pre-launch blocker.

Feb 6

Enforced Product-owns-prioritization process with Greg

Pushed back directly on Greg when he tried to route engineering work outside the established prioritization process. Insisted Product owns the priority list and work requests must flow through the proper channel. Simultaneously reminded Chris Baek that his team owns signoff authority and should use it rather than escalating through Greg.

Feb 6

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.

Feb 4

Position Bjorn as escalation point for Tenable business readiness

Decided to position Bjorn as the escalation point for Brady to resolve Tenable business-side roadblocks on the Nessus plugin integration. Technical pipeline (Sam's work) is ~95% unblocked and can deliver data within weeks, but business side may not be ready.

Jan 31

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.

Jan 29

Losing patience with Brady - not seeing him learn

Expressed that patience is running out with Brady because he is not learning. His goals are reasonable but his execution (adding unnecessary content to PRDs) is not improving despite feedback.

Jan 28

Explored Max taking Product role for Linux

Floated the idea of Max potentially taking a Product role for Linux (or the head of Product for Linux role) while acknowledging his preference not to manage people. Framed as a question to explore optionality.

Jan 28

Reinforced Product-Engineering handoff process with tighter SLAs

Reinforced existing handoff process between Product and Engineering: simplified 2-page PRDs with clear Exit Criteria, one-business-day feedback SLA from Engineering Managers, and all communication in Jira (not Slack) for audit trails.

Jan 28

Empowered Justin to own RLC 9.7/9.6 LTS ship criteria

Directed Justin to define and own the ship criteria for RLC 9.7 and 9.6 LTS releases, bypassing Product inability to provide a clear definition of done. Justin will draft a 5-line definition and present it to Brady. Peter will provide air cover for any product fallout.

Jan 26

Require mandatory tagging of all fully AI-generated content

AI Committee established policy that all fully AI-generated content must be tagged to manage user expectations. Applies only to fully AI-generated content, not human-reviewed or AI-assisted work. Format and placement of tags is flexible.

Jan 24

Empower Justin to own RLC 9.7/9.6 LTS ship criteria

Justin will define and own the ship criteria for RLC 9.7 and 9.6 LTS releases. He will create a 5-point launch checklist and share it with Brady for approval, bypassing Product inability to provide a clear definition of done.

Jan 23

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.

Jan 23

Redirected Brady to use prioritization tools instead of pushing hard

Directed Brady Dibble to use the order of operations (prioritization list) as his tool for influencing engineering priorities, rather than pushing uncomfortably hard on individual teams. Emphasized that the prioritization list is his lever to move all of engineering, and if the order of operations is wrong, the fix is to change it formally with Peter, Bjorn, and Justin.

Jan 22

Strategic Map Framework - Value Drivers vs Internal Efficiency Separation

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

Jan 15

Work intake must flow through managers, not directly to engineers

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

Jan 14

H1 Planning Framework - 3-Lane Model

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

Jan 12

Google Scope Change - Hold the Line on Commercial Terms

Google is pushing scope changes that bundle 8 versions into a 5-version contract, omit EOL dates, and include undefined dev streams. This creates scope creep risk and jeopardizes the Extended LTS revenue stream (~$300k/year per product). Decision to personally attend the Monday meeting with Tissa (with Max) to hold the line. Greg will NOT attend to preserve escalation path.

Jan 12

H1 Planning Strategy - Aggressive Goals with Staggered Milestones

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

Dec 31

Product-Engineering Quick Estimation Process

Articulated position on providing quick, low-confidence estimates for Product prioritization. Engineering should provide 20% confidence SWAGs on demand so Product can do early prioritization - these are not commitments engineering can be held to. Distinguished between committing to work without a design (bad) vs providing a quick guess marked as such (good).

Dec 29

Engineering Blockers - Immediate Escalation Required

Established that engineering blockers (being stumped) must be escalated to Peter immediately. Product should not bail out engineering by providing solutions (like YAML files with business logic).

Dec 24

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.

Dec 24

ProServe Work Prioritization Process

Established new process for handling professional services work: ProServe work will be prioritized against existing roadmap, not by dropping in-flight work. Product (Brady) owns prioritization decision, Engineering determines timing based on capacity.

Dec 24

RLC 9.7 Launch Path Decision

Participated in RLC 9.7 Launch planning meeting to decide path forward on release and rework priorities.

Dec 19