Ryan Smith

Answer the Gauntlet adoption fight as a cross-team communication problem and take it to the managers meeting as a case study rather than mandating the tool

Ryan Smith team reads core engineering non-adoption of the Gauntlet test framework as a not-invented-here rejection. Justin Haynes team has an existing test harness that already meets their needs, so Gauntlet does not solve a critical pain point for them and the switching cost and risk are high. In the 2026-08-28 Justin 1:1 Peter diagnosed the friction as a communication breakdown rather than a technical one, and declined both available shortcuts - he did not mandate adoption and he did not arbitrate the tool. Instead he took it as the concrete case study on cross-team dynamics for the next managers meeting, with an action item on himself to add Gauntlet and cross-team communications to the Tuesday Horde agenda and to ask Justin to remind him.

Deliver the AI-spend message myself at an engineering all-hands instead of letting the AI committee write a policy

In the 2026-08-27 Ryan Smith 1:1, Ryan argued that the next AI committee meeting should produce a company-wide best practice on AI spend - consensus around spend, do not use Fable for everything, be self-aware of usage. Peter declined the policy framing but conceded the underlying point: the conversation has to happen and has to be delivered directly to engineering rather than routed through a committee or left to individual managers. He committed to an engineering all-hands the following week and flagged it verbally for capture in the moment. He scoped it explicitly to engineering, excluding Ryan own organization.

Diagnose every AI overage case individually and apply the remedy that case calls for - without squashing AI usage

Facing an AI token run rate heading toward roughly 3 million dollars a year, with the top ten spenders accounting for about 95 percent of it, Peter refused both a spend cap and a single blanket fix. He directed each manager to work out why the overage is occurring for their own people, case by case, and to do whatever is appropriate for that specific cause - with the standing constraint that the answer must never be to suppress AI usage. He gave different answers for the cases he had already looked at himself: one engineer at roughly 60k a month is justified and was told to keep going; two others at roughly 100k a month between them are low-return and their manager was already digging in; Zorina team burned 12k in August purely because they were hitting the Claude API directly rather than the enterprise plan, so Justin Haynes action is a plan switch. Peter also declined Ryan Smith push to have the AI committee issue a company-wide best-practice policy on spend.

Shut down department-heads as an intake path for engineering work - I raised it to product, they will either ask for it or they will not

In a #department-heads thread about who owns and maintains the C3 RPMs and about hardware certification playbooks, Ryan Smith offered to tweak Gauntlet to run certification playbooks and asked for hardware to be sent to him. Peter cut it off directly: this channel is not how work gets in front of engineering. He restated the path he had actually used - he asked who maintains it, got back currently nobody, and took the follow-up question of whether it should be publicly visible to product, where Brady Dibble owns it. If product asks for it, it becomes a project and gets the right people and the right hardware support.

Sensitive Decision

Sensitive

Govern AI spend by notification and trust rather than a cap - alert at a thousand over, and if the person knows what they are doing get out of their way

Peter met with Steve Wallace and Scott Moody on AI and cloud costs Aug 24 at 11am, then recounted the outcome to Ryan and Bjorn an hour later. What he asked for is visibility plus a Slack notification when someone goes a thousand dollars over their limit, followed by a second one. The rule attached to the notification is not a stop - it is: if you do not know you are doing that, stop what you are doing and figure it out, and if you do know what you are doing and it is right and you are a smart person and it is right, I do not want to get in your way. He explicitly declined a single best-practice standard, differentiating by workload: Sultan costs are fine because he is dealing with a CVE swarm and the right behaviour is solve it as fast as you possibly can, whereas Jason Rodriguez spinning up 13 Opus or Fable agents makes no sense - but Peter attributed that to missing visibility rather than to judgment. He named his own next step as a person-by-person conversation with each leader over what he can now see. Separately on cloud costs he closed the question rather than opening it: the split is 100 percent Fuzzball, and he told Bjorn and Ryan they just need to get used to that being the new normal, while committing to sit with Wolford to slice it up.

Aug 24

Define the forward-deployed deployment hire as a spearhead and work-distributor whose job is to work themselves out of a job - and reject the all-remote premise outright

In the Aug 24 Ryan/Peter/Bjorn session on the forward-deployed engineering org, Bjorn framed the headcount - one head for deployment, sitting under Ryan, Core42 as the prototype, jack of all trades, paid real money rather than the slightly junior mold-them profile Ryan usually favours. Peter locked onto Bjorn word spearhead and redefined the role around it: it is great if this person can do a pile of the work and they should be able to sanity check it, but the core capability is getting to know the rest of Ryan org, knowing the capabilities, and being able to tap a shoulder and say I need Arsalan for 14 hours here, I need somebody in Nathan org for 14 hours here. They do not need to do it all themselves, they need to be a distributor of work. He added the geographic requirement - willing to be anywhere in the world - and rejected the stated Core42 premise flatly: the plan with Core42 is that it is all remote setup, 100 percent, my confidence that that is true is zero, absolutely zero. On the long-term shape he split from Bjorn deliberately: Bjorn does not want the person plugged in long-term, Peter said he expects they will be, and that he is not arguing, he wants them acting as if their job is to not be there later. He named why he likes it as a support role - the person stands up repeatable, stampable systems so that most customer issues funnel into Ryan down-the-middle support funnels rather than back to the deployment person. Ryan took the JD first draft and named a candidate, Chris Wolford former number two based in Florida.

Aug 24

Sensitive Decision

Sensitive

Claim the Core42 Dubai build-out for engineering outright - there is no sales engineering function, so if it gets built it gets built by engineering, and every scope increase still arrives with headcount

In a DM with Nathan on 8/20, Nathan was worrying about the scale of what Core42 is asking CIQ to stand up. Peter walked the argument to its end rather than reassuring him. He said CIQ does not have a sales engineering function, maybe one day it will, but today if something is going to get built at this company it will be handled by engineering - and that does not mean the people who work here today. He then named the pattern: we have seen over and over for the last year that requests for additional scope have come with a demand for headcount, and me and Bjorn be aligned on that. He asked Nathan directly whether Jimmy, Larry or Patrick were going to build out a datacenter of that scale, and if not, whether Nathan wanted Bjorn managing it or Peter. He closed by absorbing it: all the resources I listed will report to me, so it is not a Nathan problem, it is 100 percent a Peter problem - and asked how do we get you to a place where you never spend another brain cell worrying about that kind of thing. The staffing shape he named was consult where needed, heavy lifting from the Shin brothers plus one or two from Ryan world, then see if another contractor or two is needed.

Aug 21

The five-week leader presentations are baseline once, then deltas forever - show me what you changed to move the number, not the same dashboard

Closing the Engineering Weekly Sync on 2026-08-18, Peter defined what the recurring per-report presentations are for now that nearly every direct report has completed one iteration. He said he is deliberately giving little feedback on the first round because its only job is to set a baseline for each team. From the second round on he wants the conversation to be about what changes the leader is making to drive improvement in the metrics they report, what they are changing when those changes do not produce the expected movement, and whether the metrics themselves should still be the metrics. He explicitly said he does not expect the org to be tracking the same metrics a year from now and that this is fine.

Aug 19

Refuse to debate the cause of the Rocky download reversal until the metric itself is validated - either it is the number we track and it warrants attention, or we track a different one

Ryan Smith sent Peter a note that Rocky usage via Fedora DNF count-me stats had reversed for the first time since RESF started, correlating with Alma rise, and that Brian Clemens attributed it mainly to Neil and Lewis leaving with Lewis publicly promoting Alma since. Peter posted the whole note to #distinguished-leaders on 2026-08-18 flagged for the next morning meeting, and rejected the attribution: I do not buy that caused 250k less downloads of Rocky Linux. Something smells funny there. When Greg asked for his gut feeling, Peter declined to give one on causation and reframed the agenda instead: What I want to talk about is whether we believe the number is the number we should be looking at. If we do, then I think it warrants attention. If it does not, then I want us tracking a different numbers. In the C-Suite Sync the same morning he repeated the magnitude objection to Greg and named where the analytics capability should sit - that is what Dieter should plug it into.

Aug 18

Refuse to start the incident-response conversation from the premise that an on-call system is needed - require an SLA first, and put accepting overnight downtime on the table as a real option

Ryan brought Peter a plan: after the Portal outage he had asked Justin and Nathan whether engineering had an on-call rotation, got a no, and wanted to build one at the Tuesday Aug 18 meeting. Peter agreed to the meeting, added Chris Wolford to the invite, and then inverted the agenda. His first question would be do we need this - not dismissively, but because he wanted both branches evaluated: accept that some systems are down overnight and publish a status page the way Apple does, or commit to short SLAs and staff an on-call rotation to meet them. He named the decision rule: define the SLA for each class of thing first, and if any SLA is under 12 hours, that implies on-call; if none is, it does not.

Aug 13

Take the engineering re-leveling from principle to a concrete ladder - 13 levels down to 4 (open to a 5th), leadership down to Director and VP - and commit that no mapping ships without the direct report in the room

Across three 1:1s on Aug 13 (Nathan, Steve, Ryan) Peter walked each direct report through a spreadsheet he had shown nobody, collapsing roughly 13 engineering levels into Engineer / Senior / Principal / Distinguished, and collapsing his own leadership layer from directors, senior directors and head-of titles down to Director and VP. Nathan argued for a fifth level (Staff) to separate Jeremy from Sultan; Peter took it as reasonable without committing. Ryan was placed in the VP bucket and told so directly. Peter named two hard constraints: nobody gets a pay cut, and existing option grants cannot legally be reduced. Timeline given to Ryan: weeks, not months. Sequence: get Mariah bought into the framework first, then walk each org through its own mapping.

Aug 13

Sensitive Decision

Sensitive

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

technical

The engineering re-leveling lands as a conversation with each direct report, not a directive - and Wallaces org is over-titled but not over-paid

Peter settled how the engineering leveling and compensation review will be delivered. The artifact is a spreadsheet comparing each orgs leveling and compensation against all of engineering, and he will walk it through individually with each direct report next week. He pre-emptively stripped it of authority in both 1:1s where it came up. To Ryan: it is going to be the spreadsheet I am putting together is the beginning of a conversation with each of my direct reports to say, here is how your org is structured from a leveling perspective, here is how all of engineering is structured, here is how your org is compensated, here is how all of engineering is compensated. I am not going to shove it down your throat. To Steve, twice: it is not something I am going to force down your throat or anybody else throat, it is the beginning of a conversation, that is all it is - and I will get it in front of you sometime next week, but it is for a conversation, not for this is what I am doing to your team exercise. He also delivered the specific diagnosis for Wallaces org directly to Steve: your team has titles that are far above the rest of the organization, so there is going to be some leveling reset that ends up impacting your team - but from a comp perspective your team is not overly compensated, in fact they may be low in some places, so I think you are going to have a fine story to tell. To Ryan he was blunter about the same finding: the number of directors we have across Wallaces org is just stupid, and it does not fit what I am doing everywhere else in engineering. He deliberately left the remedy open - we could change it by making more people VPs, we could strip away VP titles, we could do a lot of different things to level it - and named Mariah as involved with probably Bjorn a bit. He deferred the Steve walkthrough to Monday because he was slammed both days.

Jul 30

Sensitive Decision

Sensitive

Deliver the code-driven-not-agent-driven rule personally at Fridays AI committee as a single top-down message, because the first attempt did not land

Ryan told Peter that data governance is a full-time job and needs a headcount, and that adoption will not happen until the mandate comes from the top: I think that is as simple as you coming to an AI committee meeting and make it a mandate. This stuff does not get fixed until it comes from the top. Peter agreed and committed to attend the Friday 1pm session. He named the exact message: I am betting that dashboard was agent-driven, not code-driven. I want us using AI to write code, but what data can get pulled into that dashboard is hard-coded in that function. The agent cannot just wake up on a Tuesday and do something different and pull some columns that we were not expecting it to pull. That is the single message I am going to deliver tomorrow. Because if we do that, now everything is inspectable and we can have clarity on exactly what data is going where. He explicitly acknowledged the rule already exists and did not stick: a few general rules that we all need to adhere to as we are pulling data in and out of systems, I am happy sitting down at this point and making that clear to the AI subcommittee. And I thought I had. But we will come back and redo it. Because the kind of thing that happened with Atlas should not be able to happen.

Jul 30

Sensitive Decision

Sensitive

Sensitive Decision

Sensitive

Show the half-migrated TPS report to the whole leadership room even though it was not perfect

On the morning of the 7/28 Engineering Weekly, Peter asked in #department-heads-engineering for the repointed TPS report to be shown on that days call in its current state rather than held until it was clean - can you show the current state of the report briefly on todays call, even if not perfect. Ryan presented it in the meeting, flagged that there were 33 items and that the report pulled from the Engineering Deliverables board now diverged from the product-priorities view, and that segment is what opened the 17-minute re-ruling of both board purposes in front of the full room.

The NGD board never bends to serve the TPS report - the report changes, and pulls from two data sources if it has to

In the 7/29 Baek 1:1, Baek surfaced the live consequence of repointing the TPS report at the Engineering Deliverables (NGD) board: most of Ryan Smiths work does not belong on NGD under the cross-functional-coordination definition, so Ryans work no longer appears in the report. Baek offered the ruling - under no circumstances should the NGD board change to accommodate it - and Peter took it, then extended it with the remedy: if the TPS report is not showing Ryans work, then the TPS report needs to change and maybe pull from two data sources or whatever, but the NGD board stays the same. Peter also named the recurring pattern he is fighting: almost daily somebody is using these boards for something different than what he said they were for.

Sensitive Decision

Sensitive

Every org owes its own delivery-performance metric system, and Wolfords dashboard is the deliberate exemplar - used to train the Linux side of the house

Peter restructured the 7/28 Engineering Weekly into a fast breadth-first TPS pass followed by a single-org deep dive, and made Wolford go first on purpose. After Wolford walked through his PIC tooling - PR review latency, time-to-merge, bug-vs-feature ratio, commit distribution, release cadence, internal and external documentation coverage, plus a per-quarter epic assignment board - Peter named the ask explicitly: I dont care whether there is a dashboard or just a system that reports a set of metrics, but this is the kind of thing I am going to be looking for from every org. It is not an accident that Wolfords going first here. He then propagated the exemplar three ways: forwarded the Fathom recap to Bjorn saying he was using it to help train the Linux side of the house, told Nathan to watch the recording because there are critical things in there that will impact your teams and that I want to be able to talk through in terms of team management, and told Wolford directly that the presentation was exactly what I wanted/needed to kick that all off - while warning him you will not be impressed when Linux and the other portions of eng deliver theirs. Sarah set the rotation: Wolford, then Nathan, then Steve, Ryan and Justin.

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.

I dont know is the right answer - Support does not guess how Oracle does it, and LG questions are an Engineering/Product call not a Support call

With Bjorn about to dig into the LG U+ escalation and likely to reach out directly to support engineers, Peter set an information-hygiene rule and had Ryan Smith push it to his team. The rule has three parts: if the team does not know how Oracle is doing it, the answer is we do not know - not they must be doing blah blah blah; answer his questions truthfully but do not lead the witness; and the LG question itself is an Engineering and Product call, not Support. Ryan confirmed his team had acked it and named Amr as the likely contact point, and Peter said he was doing the same thing with Howard. Peter closed with answer his questions. No guessing.

Sensitive Decision

Sensitive

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.

Jul 27

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.

Jul 27

Bring Ryan to SKO (Aug 19-21, LA) - make the ask on his behalf and let him choose his own duration

In the 7/23 Ryan 1:1 Peter learned nobody had asked Ryan about the sales kickoff. He decided support should be represented, said he would take it to Chris Baek himself, and explicitly refused to dictate how long Ryan should attend - I am going to turn it around, I am going to support whatever you want. He called Baek the same evening and confirmed back to Ryan an hour later that Baek was on board. Peter himself attends only Thursday the 20th.

Block the AI-cost workstream on complete per-individual measurement before any optimization - so each persons correct plan can be determined

In the 7/23 Steve Wallace 1:1 Steve reported several threads coming out of Mondays AI meeting: efficiency coaching for heavy users, model-switching guidance, and usage reporting to department heads. Peter cut across all of it and set a sequencing requirement - first get a dashboard that shows every individual in the company, including himself. His evidence was his own absence from it: he shows as zero on every cost dashboard despite Claude running 8 to 10 hours a day, with CIQ apparently paying around 200 dollars a month for him. He rejected the manager-level rollup as a starting point and rejected pushing justification down to department heads. All of the costs, not just some of them.

Sensitive Decision

Sensitive

Hand mainline TPS report ownership to Ryan pointed at the NGD board; abandon Peters private fork and deprioritize the Linux software-delivery lifecycle doc

In the 7/23 Ryan 1:1 Peter made three linked calls on his own reporting stack. First, Ryan takes ownership of getting the mainline TPS report pointed at the right source - now that the NGD board sits as a layer below value drivers, the report should point at that. Second, Peter drops his own private branch of the TPS report and will consume the mainline one instead. Third, he explicitly deprioritized the Document Lifecycle for how we deliver software in Linux item that carries both Ryan and Max names - if you see that in MiniMe, that is not my highest priority - and said he will push Max on it separately. He also declined Ryan offer to deliver by tomorrow: I do not need it tomorrow.

Approve +1 US headcount for Ryan to build forward-deployed engineering in-house for Citadel; re-evaluate in six months rather than scale per customer

In the 7/23 Ryan 1:1 Peter resolved the forward-deployed-engineering disagreement between Ryan and Bjorn. He drew a boundary - Bjorn gets to decide he wants the capability in-house, Bjorn does not get to decide that Ryans team has capacity - then asked Ryan what he needs to build it. Ryan asked for one US-based head who would serve as TAM plus Fuzzball subject-matter expert and half-operate as an SE. Peter granted it, confirmed the separate APAC backfill rec for Owen is already Ryans, and said he would get it across the line with Gordon. He also set the guardrail explicitly - the story to Bjorn is not plus-one-head-per-customer; it is one head now, scoped to Citadel, re-evaluated in six months.

Back keeping forward-deployed/TAM in-house under Ryan; own the capacity assessment

In the C-Suite Sync, Bjorn killed the plan to outsource the TAM/forward-deployed-engineering function (sold to Citadel) to Cutting Edge and gave it to Ryan team instead. Ryan pushed back that he lacks capacity. Peter backed the in-house call and took ownership of the capacity question: he will work with Ryan to figure out capacity and come back only if they are short people. He also offered that forward-deployed engineering should ultimately report into go-to-market, not core engineering.

Jul 21

Sensitive Decision

Sensitive

Sensitive Decision

Sensitive

Sensitive Decision

Sensitive

Engineering owns defining the ask, success criteria, and documentation; CS responds to specific asks

In a DM with Nathan about friction with Ryan, Peter drew the Engineering-CS interface boundary: core engineering owns defining the ask and the success criteria and owns ensuring documentation exists; it is not Customer Support job to dig out engineering details. CS cannot follow everything and is expected to respond to specific, well-defined asks. AI can do much of the doing, but engineering still owns defining the ask and what success looks like.

Jun 30

Mandate 24-hour Sev-1 outage auto-escalation to estaff and AE

After the Fyr Fuzzball outage ran roughly 5 days without surfacing to leadership and the customer had to ping Horn directly to force escalation, Peter directed that any Sev-1 or customer outage open past 24 hours must automatically notify estaff and the account AE, built into tooling so it does not depend on a human judgment call. Ryan operationalized it as Zendesk automation plus CCing named-account AEs at ticket creation.

Jun 17

Establish 3 as the performance-review norm — close alignment with Bjorn and Greg

Peter established that a 3 on the 5-point scale is the expected/solid norm in performance reviews (not a 5), and closed alignment on this calibration standard with Bjorn and Greg, resolving a leadership split that had become visible to the org during the active review cycle.

Jun 8

Sensitive Decision

Sensitive

Mandate CIQ build/test pipeline converge with the RESFs — one unified project, Nathan accountable, coordination over speed

Peter laid down a mandate that CIQs Linux build/test pipeline will become functionally identical to the RESFs over time — a single consolidated project rather than parallel tooling. Nathan drives and is held accountable for closing the CIQ-to-RESF gaps (hardware parity, cut over to Koji, mirrored build infrastructure, a full validation framework that runs PR-specific tests). Justins build world must sign on and use it everywhere. Ryans gauntlet/outfitter tooling and Leighs RESF-side work are welcome only if they plug into the one project rather than forking. Peter explicitly chose coordination over speed even though it slows Ryans faster build-it-now instinct.

Jun 5

Refuse holiday-weekend pressure on people — Mariah review deadline AND Ryan reviews

Two paired actions on 5/24. (1) When Mariah pushed Peter Sunday evening that mid-year reviews were 50% complete on the day-of deadline, Peter held the line — no pushing direct reports who are on a 3-day holiday weekend. Drew distinction between the people who plan ahead (will finish on time) and those who do not (will finish Tuesday night either way). Committed to thinking about better engagement separately. (2) Same evening Peter DMed Ryan: I am not going to read your reviews today or tomorrow — you should take a break. Same posture applied to a direct report Peter could see was burning out from a hard week.

May 26

Engineering owns docs content; Customer Engineering or Marketing owns customer-ready packaging

In Ryan 1:1, Peter split docs into two layers and assigned ownership cleanly: (1) the technical content, details, and accuracy IS engineering responsibility — same as QA. If Ryans org helps fine, but not held to it. (2) Making docs customer-ready/pretty is NOT engineerings responsibility — that lives with Ryan or Lindsay; they decide between themselves where it lives, Peter does not care which.

May 26

Engineering owns all QA — Nathan accountable; tests required for Done; Ryans team builds tooling not rescue

Non-negotiable directive issued to Ryan: engineering is responsible for its own QA, Nathan is named accountable for quality, and a ticket is not Done until it has documented executed tests. Ryans role is re-shaped: build QA automation tooling (Gauntlet CLI, Outfitter, CIQCTL) that empowers engineers, NOT take over QA responsibility from engineering. Documentation also clarified: engineering provides all technical content; the customer-ready presentation layer is a Ryan-and-Lindsay conversation. Ryan to define a Definition-of-Done lifecycle visual for H2 to standardize across the org. Peter committed to email Nathan and Justin directly to reassert.

May 21

Engineering QBR format — collaborative discussion with three topics, not a presentation

Peter directed that the 5/22 Engineering QBR will be a collaborative working session rather than a formal presentation, organized around three questions: what is working well, what needs improvement, and how to streamline communication and increase work visibility. Chris Baek owns the shared prep doc that will collect bullet-point inputs from engineering leads ahead of the session.

May 13

Ask Bjorn to deliver ARR/dilution/Series-B rationale to engineering org

Committed to ask Bjorn to clarify the link between doubling ARR (to $20M), Series B funding with minimal dilution, and employee stock value — to be delivered in All Hands or in Peters org meeting. The intent is for Bjorn to walk the team through the knife-edge: failure forces more investor funding with significant dilution; success enables Series B with minimal dilution and a clear path to profitability.

Icicle viability gate: AI inference benchmark on H100 decides go/no-go

Set a clear decision gate for the Icicle project: viability is determined by performance on a real-world AI inference workload, not synthetic benchmarks. Omer to run the RLC Pro AI benchmark on an H100 GPU. 2-3x synthetic CPU/memory degradation is acceptable IF power savings are significant for AI inference; otherwise project gets punted.

technical

Reassign Owen to Maxs AI tooling for definitive performance evaluation

In Ryan 1:1, decided to assign Owen to Maxs AI tooling projects when Max returns from leave (~3 weeks). Defines the project with Nate beforehand so it is ready to deploy day one. Resolves conflicting feedback: Ryan sees senior Golang engineer underutilized; Bjorn questions value; Max and Nathan have called recent work AI slop.

Assign Owen to Max AI tooling for definitive performance evaluation

Decision in Ryan 1:1 (Wed 5/6 12:30 PM) to assign Owen Wood to Max Spevack AI tooling projects on Max return from leave (~3 weeks). Definitive evaluation to resolve conflicting team feedback — Ryan sees senior Golang underutilized; Bjorn questions value; Max and Nathan have called recent work AI slop. Peter confirmed in DM with Ryan: We will get it rolling.

Ryan to POC AI-driven Veeam image builder, gated on Justin-approved test suite

Ryan will POC an AI-driven image builder, starting with Veeam, that automates custom image builds, testing, and documentation. Hard gate: AI-generated images must pass a Justin-approved test suite to prevent hallucinations. Long-term vision: a 'Chipotle line' image configurator letting users compose custom, repeatable builds from validated components.

May 1

Ryan Smith owns docs.ciq.com

docs.ciq.com was orphaned after Gwen's departure. In Ryan's 1:1, Peter assigned ownership to Ryan, who will coordinate with Arian and Steven on the existing work.

May 1

Manage Max situation — protect privacy, halt org outreach, decline his calendar

Peter is actively shielding Max Spevack from organizational pressure during a personal/private situation. Directed Sarah to access Max's calendar and decline all his meetings for the week, told Ryan to stand down ("No reaching out"), told Nathan to stand down ("worst thing Ryan can do is involve himself"), declined Mariah's offer to use Max's emergency contact ("let's give it a little more time"). Committed to talk with Max himself early this week.

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

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

Sensitive Decision

Sensitive

Delivered Jira Hygiene Mandate to Engineering

Apr 15

Committed to engineering date hygiene confrontation with directs

Peter publicly committed in Leadership Roundtable to holding a tough conversation with his directs about deliverable date hygiene. Requested date-slip magnitude data from Chris Baek (days vs weeks) to focus on significant delays rather than minor variance.

Apr 14

Agent IQ: Requiring Bjorn to Justify Before Supporting

Peter directed that Bjorn must articulate how Agent IQ augments CIQ's portfolio before it gets engineering resources. Not killing the project outright but requiring strategic justification.

Apr 4

Sensitive Decision

Sensitive

Sensitive Decision

Sensitive

Shared Mini-Me Source Code to Internal Org

Shared Mini-Me source code by creating repo at ctrliq/min-me in CIQ GitHub org, after Ryan, Nathan, and Michelle independently asked for it. Proactively noted never having seen the code, setting quality expectations. Requested internal-only repo visibility.

Mar 18

RESF Operational Framework — CIQ Resources Work Under RESF Direction

Established and communicated to entire engineering org that all CIQ work for RESF must be done 100% at RESF direction, with every request flagged for Peter's visibility. Reinforced individually with Ryan (get accounting of in-flight work, ensure RESF person directing), Nathan (hold then green-light Taylor contact with specific messaging), and Mustafa (offer resources under RESF direction, recommend MatterMost for coordination).

Mar 18

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

technical

Excluded Brian from RESF Pre-Transition Planning

Decided to exclude Brian from pre-transition RESF planning based on synthesizing risk signals from multiple sources. Brian's role will be carefully managed post-transition.

Mar 13

RESF Monday Cutover — Finalized 3 PM PT Execution Plan

Finalized the RESF infrastructure cutover plan for Monday March 16 at 3 PM PT, including DNS NS record flip, AWS VPC firewalling, account disabling (Lewis, Neal), and security audit — accepting up to 24 hours of DNS-related downtime.

Mar 13

Sensitive Decision

Sensitive

Custom Engineering Scoping Process — Nathan as Gate

Established formal process for unplanned custom engineering requests from sales: Nathan provides quick effort estimate (days/weeks/months), enabling formal prioritization. Nathan can say no, escalation goes to Peter.

Mar 6

Sensitive Decision

Sensitive

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

Sensitive Decision

Sensitive

Decided to carefully surface Icicle results to Bjorn

After validating Icicle test methodology with Ryan (BIOS change applied before both with/without comparisons — apples-to-apples), and learning Ani was told by Bjorn to stand down on Icicle, Peter decided to personally and carefully bring the validated results to Bjorn's attention.

Feb 27

Shaped Ryan's H-1 strategic plan with specific direction

Reviewed Ryan's H-1 plan and gave specific strategic direction: reframe team skill tracking to outcome metrics, loop Product into GTM translation validation, create simplified 4-page sales pitch deck, align with Max on Rocky Linux upstream strategy (pure RESF vs hybrid best-of-breed) before engaging community, and present AI-assisted goal-setting process at Engineering Weekly Sync.

Feb 27

Sensitive Decision

Sensitive

Set AI adoption/spending policy: pace over cost, fund passion project tokens

Codified org-wide AI tool policy: pace is priority over cost, high token spend signals productivity. CIQ will fund tokens for passion projects (learning) but not work-hour time for non-core work. Work-hour AI projects must align with core responsibilities.

Feb 20

Approved Professional Services strategy pivot

Approved Ryan proposed PS strategy pivot: align PS with Ramesh product-first vision, discontinue unprofitable standalone training deals and custom engineering work, focus only on product-aligned services (Rocky Linux migrations, dedicated support engineers/TAMs, HPC services) delivered through third-party vendors to scale without increasing headcount.

Jan 30

Sensitive Decision

Sensitive

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

COGS data access unblocked for Ryan - Bjorn to grant via Kelly

Convened Bjorn and Ryan to resolve Ryans 6-month block on accessing official COGS data. Ryan had been forced to recreate the data independently, which conflicted with Bjorns H1 directive to use a single official source. Bjorn agreed immediately and will email Kelly Marlin today to grant Ryan full access.

Jan 21

COGS Visibility - Escalate Finance Data Access via Bjorn

Committed to scheduling a tri-party meeting with Ryan and Bjorn to secure finance data access (loaded rates) for Ryan's Intelligence Hub. Finance (Marlon, Kelly) previously denied Ryan's direct requests.

Jan 15

OSPO Restructure - New Mandate and Leadership

OSPO moved under Customer Engineering (Ryan Smith). Chris Short removed as head. New leadership: Brian Clemons (VP, RESF) and Lee Hennig (former RESF MD). New mandate: govern ALL open source CIQ touches, not just RESF. Top priority: eliminate extinction event risks. RESF board resolution target by H1 2026. Self-sufficiency goal: enable CIQ to internally reproduce Rocky Linux.

Jan 12

Trinity Quirk & Chris Short Terminations Executed

Terminated Trinity Quirk for failing to progress NARF/CVE automation integration despite clear expectations. Terminated Chris Short for failing to deliver on critical RESF-related goals. Sent transparent communication to all of engineering explaining the WHY behind these decisions.

Jan 11

NARF Performance Accountability - Public Termination

Decided to execute a public termination within Nathan's org on Monday if NARF deliverables are not met. This is specifically intended as organizational signaling to drive accountability and force motion across the team. A second termination (Chris) may be required for legal reasons.

Jan 2

Advocate for Ryan's Strategic Seat

Committed to securing Ryan Smith a seat at the strategic decision-making table for RESF/Rocky Linux matters. Specifically promised to advocate for his inclusion in key meetings with Bjorn and Greg.

Dec 31

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

Bonus Criteria - Strategic Alignment Required

Established bonus criteria: bonuses should be for accomplishments aligned with strategic goals that help scale or deliver faster, not just for being an awesome developer.

Dec 24

RESF Infrastructure Independence - Technical Execution

Directed Nathan to mirror all RESF repositories and initiated build environment duplication. Created #internal-resf-escalation channel with strict confidentiality rules. Keeping technical circle small (Nathan, Max, Justin, Dieter) while moving quickly.

Dec 24

RESF Crisis Response - Infrastructure Independence

After learning of hostile plans by RESF board members (Louis, Neil, Brian Clemens) to publicly attack CIQ, dismantle Rocky Linux infrastructure, and damage the project, initiated emergency response to replicate RESF infrastructure for Rocky 8, 9, 10 with minimal team awareness.

Dec 23