Brian Dawson

Stop hiring junior engineers - hire domain experts with decades of experience and pair them with AI

Peter stated in the Brian/Brady sync that he is no longer hiring junior engineers. He hires domain experts with a couple of decades of experience and pairs them with AI, because the expert can judge whether an AI-built thing is architected, structured and backed up properly, and a new graduate cannot. Raised while explaining why Ryan citizen-developer team (smart, well-tooled, not software engineers) should not ship and maintain customer-facing tools.

Approve the Spark benchmark claim in the RLC Pro AI press release - correct and defensible beats preferred wording

Lindsay asked Peter to confirm the final RLC Pro AI on DGX Spark benchmarks (Dawson had confirmed; Bjorn routed her to Peter). Peter confirmed them, noted they are not yet published on Spark Arena, and approved the first-paragraph claim: comfortable with it, does not love the wording, but it is correct and defensible. Separately told Bjorn the word four is doing a lot of lifting since there are many more tests than four.

Desktop V1 - a minimum-requirements section from Product, a December to first-week-of-January window, latest-only as the working assumption, and an accepted black eye

With Brady desktop document in hand (the design-plan condition from 10/1), Peter asked for a paragraph or redline at the top listing the absolute minimum requirements for V1, as aggressive and small as possible, and offered a window: something in December or the first week of January. Nathan working assumption is that the first drop is on latest only, not LTS; Peter asked Brady to capture it and call it out if wrong. Brady will schedule a separate LTS discussion since Everfox technically needs it. Peter accepts burning a bridge with one or two customers and taking a short black eye, fixing UI/UX afterward.

Internal tools come under Wallace IT umbrella - he owns the map, hosting, DR and access, builders keep maintaining, and unused tools get an evaluation date and are shut down

Every internal tool any part of CIQ sits on (Mother Brain, C3, Intelligence Hub, Outfitter, Gauntlet and others) moves under Steve Wallace as IT. Wallace owns visibility and overall management: a map of what exists, where it is hosted and who maintains it, plus uniform hosting, disaster recovery, backups and Okta access. Resources stay where they are - the original builder can keep maintaining Intelligence Hub from Wolford org, Ryan team can keep building. Start with Wallace maintaining a map. The SRE team carries the run-and-manage weight, partly as a dispassionate owner watching usage: each tool gets an evaluation date, and if nobody uses it (about three months) it is discussed at Peter staff meeting and shut down a month later if still unused.

Six-month push for CIQ to be a better steward of its open-source work beyond Rocky - Tim Pepper advises, with full transparency and a seat in the Stratum open-core call

At Eng Sync Peter introduced Tim Pepper, a contractor helping him think about CIQ positioning across all its open-source efforts (not just the RESF), including Warewulf ahead of the Warewulf offering launch. Tim will join Eng Sync from time to time; his engineering asks go through Product prioritization. Peter named it his big push for the next six months. In Slack, when Brian Dawson opened a task to decide the Stratum open-core vs open-source approach by 10/16, Peter said need to talk sooner and involve Tim; when Ryan omitted a sensitive RESF staffing detail from his OSS summary for Tim, Peter said there is no need to hide anything from Tim.

Oct 1

Everyone owns their AI spend - no gates or guardrails, but unaware spending is unacceptable

At the AI Committee, the spend dashboard showed Jamin at roughly 33-39k for September. Peter said he will not put gates or guardrails on AI usage, but every person at the company (not just engineers) must know their own spend, the caps and overage thresholds of the tools they use, and treat token spend as part of their cost to the company. A deliberate, informed overage is backed even if Peter would disagree with the math; blind spending is not. Michelle was approved to tell the whole company this is on each person. Ryan 1k overage notification line accepted as reasonable; only Jamin, Sultan and Justin warrant an actual conversation.

Oct 1

Protect the inked Core42 deal - no Stratum and no new commitments until we have done discovery with the end customer

Bjorn wanted CIQ positioned to deploy Stratum (CIQ Kubernetes) on the first Core42 cluster after Core42 mentioned installing Kubernetes post-handoff. Peter walked him back: the question is not whether Stratum can be deployed (it can) but whether it meets the end customer need, which is unknowable until CIQ talks to that customer. Stratum is a child of RKE, not Rancher, and has never been deployed outside Wolford environment. Aggressive promising belongs in the sales motion; once a deal is inked, do not add commitments that could risk it. In the Core42 pre-deployment call Peter told Core42 CIQ has a Kubernetes offering but wants to understand exactly what the customer wants before recommending anything, and on Friday listed the discovery questions: what applications, why Kubernetes, how they interface with it, and what distribution experience their people have.

Sep 25

Refuse to ink Oleg contract now for a January start - treat his delay as a free search window and leave the call with Nathan

Oleg came back through HR saying that if he takes the job he would start in January. Peter told Nathan not to sign anything now. His instruction: tell him we like you, you seem to like us, let us talk in January - and use the intervening two to three months to see whether there is somebody Nathan would rather put in that chair. If there is not, bring Oleg on. Peter framed the January constraint explicitly as a gift rather than an obstacle. Underneath the timing call he made a manageability judgment - that Oleg would be a royal pain to manage - citing that Oleg named his own salary number, CIQ hit it, and he then complained that CIQ was doing the bare minimum. Oleg had performed strongly on the technical panel.

Sep 23

Documentation and training stay in Ryan org - development work does not belong there

Ryan Smith raised that the breadth of what his org produces has outgrown the label customer engineering and asked what Peter sees the function as. Peter separated the container from the placement. On placement he gave a clear two-sided answer: documentation and training legitimately sit with Ryan org and he likes them there, and development work does not belong in that org. Gauntlet was the worked example - Peter thanked Ryan for building it, said that in a perfect world it lived under Justin and should have been built by Justin org, and said explicitly that he does not want the fact that Ryan built it to reshape Ryan world so that more of that happens. He also said forward-deployed engineering will likely grow to dwarf customer support in Ryan purview, and that the title would be VP of Engineering with owned scope explained separately - both of which he treated as secondary to the placement rule.

Sep 23

Hand the Dawson document-noise complaint back to Justin with an instruction - be done with subtle

Justin DMed Peter that Brian Dawson AI-generated document output is an increasing source of wasted time for more people than just him, attached the RLC Pro HPC specification document and a related Jira bug, and closed with no direct ask for you, just awareness. Peter declined that framing, asked whether working it from my side meant being very clear with Brian, got Justin admission that it meant being polite and probably too subtle, and answered - be done with subtle.

Justify the internal LLM fleet on Fuzzball dogfooding rather than cost savings - fund it even at parity

Brady reported the internal LLM fleet is now pushing billions of tokens, that Sultan and other engineers are running real work through it, and that he is hitting concurrency caps on current hardware and queuing for Grace Hopper cycles. Brian reframed the value as opportunity unlock - uncapped long-running jobs - rather than spend reduction. Peter added a third justification and placed it above both: what he gets out of it is more Fuzzball dogfooding plus organisational learning about what can be run internally, and he said he would be interested even if it saved no dollars, and would leverage what Brady built anywhere it reaches output parity even if it costs more.

Ignore AMD until someone escalates - and decline to have an opinion on whether to confront them

Brady reported that Whitney at AMD is not answering his emails, is talking only to Greg, and is not specific about what she is asking for, and that the lack of a program cadence is becoming a blocker. Peter said his statement to Greg is that he will ignore AMD completely until somebody tells him he cannot. When Brian argued that someone should tell AMD they are a bad partner, Peter said he does not mind that happening but explicitly declined to hold an opinion on it, naming it a company strategic question and pointing Brian at Bjorn - while volunteering his read that Bjorn will agree with Brian on the diagnosis.

Bound the NVIDIA driver auto-update ticket - 24 hours is the product ask, 30 days is the contractual floor

Brady brought a ticket asking engineering to move from manual to automatic NVIDIA driver updates, with a 24 hour target he said Justin and Nathan had already accepted with just prioritize it. Peter questioned whether that acceptance had been priced, then directed that both numbers be written into the ticket - 24 hours as product ask, 30 days as the contractual commitment - so engineering knows the real floor and can choose where between them to stop.

Cap Binarly at validation-size investment - portfolio status buys no lower evidentiary bar

In the weekly sync, Brady reported Binarly is not yet of value and that he is deliberately keeping engineer involvement at zero, framing the current effort as keeping investors happy about supporting the sister company. Brian asked Peter to expand on his scepticism. Peter set the ceiling explicitly: invest enough, as long as it is small, to validate their claims the same way CIQ would if Binarly were not a portfolio company. If the claims hold, proceed. If not, get on the phone with Joel and tell him he is wasting money - and treat that as a deliverable to the portfolio rather than a failure. He broadened the scope from Brady design-partner commitment to any technical investment by anyone, and closed by saying he is not in a position to make that CIQ official position - it is what he hopes CIQ does.

Make the bleeding-edge driver the RLC-AI default over Dawson stability objection - explicitly a 3 to 6 month posture

In the weekly sync with Brian Dawson and Brady Dibble, Brady presented the product stance that bleeding-edge drivers should be available and compiled but never the default image. Peter pushed directly against it for RLC-AI: the enterprise-stability argument is correct at scale but CIQ has effectively zero RLC-AI customers in production, so the first-touch evaluation experience should be the most aggressive configuration available. He closed by telling Dawson that Dawson is right for the long tail of the product and that Peter may well change his mind in a year, but that this is the posture for now.

Set a floor on personal data CIQ staff hand Core42 - passport yes, property deed no, and demand the required list

Core42 sent a request for personal information as part of background checks for site access ahead of the Sept 18 hardware access date. In #core-42-escalation-members Peter answered with his own position first, tagging Adam Jackson: he will give them a passport, not a deed. In the eight-person Core42 group DM he told Adam there is going to be a problem with that request for info, that he will not give them the deed to his house, that he is confident the bulk of the people on the Linux team will not either, that passports are fine, and that CIQ should be super clear about exactly what information is required. In the DM with Nathan Blackham he repeated that CIQ needs clarity on what info is absolutely required and that he has no interest in giving them his address either. He then tested the requirement himself - he submitted his address, judging it enough for a background check and public record anyway, and reported back that Core42 had emailed asking for additional info including a proof of residency document, for which they accept a utility bill.

Refuse to guarantee Oct 5 for Core42 if CIQ is deploying Ubuntu - give a likely range unless the customer demands a guarantee

Asked by Adam Jackson in #core42-build-and-deploy whether CIQ could commit to an Oct 5 completion starting Sept 18, Peter answered no for the full-Ubuntu-deployment scope: there is absolutely a chance CIQ would hit it, but CIQ cannot guarantee it. He then separated the scopes - if it is just Fuzzball, and Ubuntu is already stood up on the racks and networked, and CIQ gets access Sept 18, then absolutely CIQ could hit that date. He gave the rule for how to answer the customer: be VERY careful about guarantees in a new environment and an OS that is not ours, because a guarantee puts CIQ in a position to lose future business when this is the first time CIQ is doing this; if Core42 MUST have a guarantee that is one thing, but if they only want a likely range then give the range and do not make an unforced error. He then asked the four scoping questions that decide which scope applies - is Ubuntu already installed, is networking already set up, is there a provisioning machine available for ELM, and exactly how many machines.

Cap the Spark benchmark chase at one or two wins - the deliverable is bits in RLC-AI on Portal, not a leaderboard listing

Across four channels Peter set the scope of the NVIDIA Spark benchmark work ahead of the Tuesday announcement. To Nathan Blackham and Brett Mastbergen he said not to spend too much time there, that all CIQ really needs is one test to point to, two is awesome, more is not necessarily better, and that after one or two what is actually needed is the right bits baked into RLC-AI and available on Portal for download, at which point CIQ can declare victory. He also directed benchmark selection by relative rather than absolute result - pick whichever benchmark showcases Rocky best against the other distros on the leaderboard and can produce results quickly, because this is not about the raw number. In the group DM with Brian Dawson, Bjorn Hovland and Lindsay Aamodt he corrected the plan: the leaderboard is third party, not controlled by NVIDIA, CIQ cannot guarantee any posting there by any date, so make plans that involve self-reported benchmarks. With Lindsay and Bjorn he put the third-party publication odds at about fifty percent while calling confidence in CIQ own benchmarks high.

Route the RLC-AI latest-driver override through Bjorn rather than overrule Dawson in the public channel

Peter pushed in #product-rlc-pro-ai that RLC-AI should not sit on an LTS NVIDIA driver, told Brian Dawson to have a conversation with Bjorn that day because Bjorn wanted to go out with benchmarks on Tuesday, and stated that if CIQ is bundling LTS driver versions it should NOT be going out with benchmarks. He then took the resolution off the public channel: in the group DM with Nathan Blackham and Brett Mastbergen he wrote that he had talked to Bjorn, that the team should get moving on the latest driver in RLC-AI right now, and explicitly that he was not putting this in the public channel because he did not want to publicly defang Dawson - Bjorn would talk to Dawson and the team would see a note greenlighting it.

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

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

Accept Bjorn conclusion on the Stratum name while refusing his reason - dont make a decision now that you dont have to make

Naming the new CIQ Kubernetes product. On Aug 23 in the executive group DM, Bjorn Hovland put up five candidates - CIQ Lattice, CIQ Stratum, CIQ Formation, CIQ Maestro, CIQ Marshal. Peter opened against the field with his own pick: my vote is Lattice, Marshal does not fit. Bjorn raised an SEO conflict, that an HR platform already owns Lattice, and Peter switched in one message - Stratum for the win, shrug. Chris Wolford independently backed Stratum and noted Lattice is also Quantum object storage system. Chris Baek started the trademark search. In the Aug 24 Kubernetes sync Bjorn laid out his actual reasoning - that over time he expects to combine the back ends into one and simply route a workload to Kubernetes or Fuzzball, but that is not the world today, so calling it the Fuzzball Kubernetes engine would muddy the waters too early and he needs to run keywords against Kubernetes as a discrete product. Peter agreed with the destination and rejected the route: he gets to the same place for totally different reasons, does not believe Bjorn story about the way the world ends up, and points out that if you do not believe it then you want the thing to have its own referenceable name anyway. Peter also asked that the final form match the naming convention used elsewhere.

Aug 24

Fuzzball Substrate can be an option for the Kubernetes engine, never the only runtime - ship on existing rails or nobody buys the train

In the Aug 24 Kubernetes Weekly Sync, Jonathon Anderson raised whether the new CIQ Kubernetes engine should use Fuzzball Substrate as its default or its only container runtime, framing it as the question that would drive whether Substrate gets open-sourced - a Substrate-by-default engine would put Substrate in far more places and let CIQ target the same worker nodes with both Fuzzball Orchestrate and the Kubernetes engine. Bjorn Hovland split it immediately: default yes, only no, on the grounds that forcing one runtime reduces the usefulness of Kubernetes and CIQ products should be independently viable with value-add tie-ins. Peter argued against both halves from the buyer side, taking the position of a hyperscaler already running Kubernetes and evaluating a switch to CIQ: either CIQ sits on the same Kubernetes they already sit on, which is an easy sale to reason about, or CIQ hands them a pile of validation hoops to clear before a contract can be signed. He compressed it to a rule - it has to include existing rail widths, otherwise nobody is going to buy our trains - and then kept the door open rather than closing it, noting defaults can change over time as Fuzzball starts getting traction. Jonathon withdrew the framing as overstated. Chris Wolford then supplied the decisive fact, that Substrate cannot be the Kubernetes default because the engine would fail Kubernetes conformance testing and lose certification, and proposed it as a user-selectable option in the Pro tier instead. Jonathon concluded the open-source question is therefore deferred, since it only mattered if Substrate were the shipping default.

Aug 24

Call the Core42 SOW1 won mid-call and forbid reopening anything that does not need reopening

During the Aug 24 Core42 and CIQ call, the customer side kept probing why the SOW does not cover the broader logical control set, and the CIQ team started engaging on where work splits under partials. Peter intervened twice in four minutes in the internal channel running alongside the call. First he reframed the confusion: I think we have lost track of the fact that ultimately there will be 2 SOWs. Then, once Alex Trafton had asked whether they could sign, he closed it: this is won, we should be careful not to re-open ANYTHING that does not need to be reopened. When Adam Jackson asked whether he could stop screen-sharing the HLD, Peter answered yes please stop sharing. The team changed behaviour inside the same minute - Bjorn said I will wrap, Brian Dawson said he would refrain from additional comment and let Bjorn and Adam land it, and Adam stopped sharing. The SOW1 final package went out to Core42 by email that afternoon.

Aug 24

Show Core42 the responsibility matrix filled in, not blanked - a first cut we are flexible on beats arriving with an empty working sheet

In the Core42 implementation-review pre-call on 2026-08-18, Michael Shinn was uneasy about showing his RACI/responsibility diagram because it assumed a much larger scope than Core42 might want, and offered to blank the boxes so the conversation could fill them in. Adam Jackson agreed and asked for the letters removed so CIQ would go in with no expectation. Peter challenged that directly and argued for leaving the chart filled in, framed as a first cut with an explicit statement that CIQ is flexible and not married to any of it. Adam conceded. On the following morning call the control matrix was in fact presented as a draft rather than as a blank working sheet.

Aug 19

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.

Aug 19

Decline the DGX Spark allocation for now - a queue exists, Peter owns it, and the next batch is gated on CIQ showing Nvidia progress first

Sarah Almaraz relayed a request for a DGX Spark unit for Brian on 2026-08-15. Peter refused flatly and gave the conditions that would change the answer: You cannot. When Nvidia has more to give us I can put Brian on the list. But there are other people first. And we need to show some progress to Nvidia first. Realistically it is going to be a few more weeks before we might get more. He closed by taking the explanation upward himself - I will walk Bjorn through it though.

Aug 18

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.

Aug 13

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.

Aug 11

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

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

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

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.

May 21

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

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

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

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

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

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

Demanded proper advance coordination for customer meetings involving engineering

Pushed back strongly on a Volvo customer meeting that appeared on calendar at 5pm the day before. Demanded that important customer meetings involving senior engineering staff be scheduled with proper advance notice and coordination.

Feb 20

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

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

PRD first drafts are gravel - meant to be thrown away

Get product to understand that the first iteration of a PRD exists to be thrown away. Its gravel, not precious. Engineering questions should come fast and furious, and the document should go through massive churn. Pride of authorship must be eliminated.

Jan 30

Stop coaching product, move to SLAs

Stop trying to teach product managers (Brady, Brian, Dawson) how to do their jobs better. Instead, provide prescriptive SLAs - clear timelines and direct questions. If they dont like the dates, they can restructure their requirements. Leave it on the floor and walk away.

Jan 30

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.

Jan 30

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

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.

Jan 12

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

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.

Jan 6

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

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

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.

Dec 19

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.

Dec 19