Ryan Smith

Datacenter business needs its own team and deals that pay now - stop signing engineers up for work far outside their remit

In a DM to Bjorn framed for the C-suite, Peter said the team is burned out on IRIS (network still down, someone has to go back on site, half a dozen people on daily calls, Wolfgang pulled off Fuzzball work), that this is unsustainable with IRIS alone and Grenoble arrives in 8-9 weeks. Position: deals must get CIQ paid now rather than just opening future doors, CIQ must be very careful signing people up for work far outside their remit, and if CIQ is really in the datacenter business a whole missing team needs to exist today.

Nov 3

Sensitive Decision

Sensitive

Sensitive Decision

Sensitive

Sensitive Decision

Sensitive

Core42 - hold to the SOW: stock Kubernetes plus Fuzzball before Oct 31, no CIQ-installed CozyStack, technical pushback routes to Peter

On 10/23 Core42 took Fuzzball out of the Oct 31 plan (no Fuzzball before deployment, look at it together later). Peter refused to let CIQ become a pure system integrator. As soon as the network is up, CIQ installs Ascender and Fuzzball; if Kubernetes is not there, CIQ installs stock K8s for Fuzzball to sit on, without CozyStack, and Core42 can add CozyStack later. Any pushback from Maxim or Sergei gets the scripted SOW answer (after consultation with Core42 engineering we have been told to follow the SOW; Fuzzball is an integral part of the CIQ stack and does not affect any other Kubernetes offering), and technical pushback routes to Peter. Builds on the 10/22 Ryan 1:1 where Peter made stock K8s plus Fuzzball plan A. The stock-K8s-then-Fuzzball shape was proposed by Bjorn; Peter adopted it and owns the engineering plan and the pushback routing.

Oct 23

Sensitive Decision

Sensitive

Core42 - the last line in every shared thread is the Core42 action item; project-manage our own work and stay out of their internal accountability fights

Extending the 10/16 Core42 posture, Peter set a mechanism and a boundary. Mechanism: the last thing on the shared WhatsApp thread is always what CIQ needs from Core42 next - Wolfgang reposts the current blocker list (CIQ is blocked; this is what is blocking us), and Peter nudges when the thread goes quiet. Boundary: CIQ project-manages its own commitments hard and hits every at-bat as if the date holds, but does not hold any Core42 org accountable, because the org held accountable may be the one that ends up in the chair. Peter also suggested to Bjorn and Adam backchanneling to Alex that Core42 needs its own project manager - one adult in the room, and it cannot be a CIQ person - only if it can be done without blowing things up.

Oct 21

Core42 Kubernetes - never let anyone at Core42/G42 say CIQ cannot do Kubernetes; ask questions only, route Stratum to Bjorn

After a Core42 email raised Kubernetes questions, Peter set the posture: answer with capability (extensive K8s experience, a K8s offering in a month, able to configure or work with any K8s cluster); present Stratum as an option while saying off-the-shelf K8s is fine if required; do not tell Core42 what is unsupported, ask what they are trying to accomplish; stand nothing up; no engineer-to-engineer resolution - anything Stratum-shaped goes to Bjorn and their customer-facing people. On 10/21 he applied it by asking Sergei for a call with the CIQ Kubernetes team to learn whether they want CozyStack and why.

Oct 21

Wolfgang on-site role ends at the pre-VPN window - no extra travel, send someone only if a problem appears, Peter is the backstop, bonuses earned

Peter bounded Wolfgang Resch hands-on role in Abu Dhabi to the window before VPN access exists; after that Ryan team picks it up, and his priority until then is whatever makes the VPN useful. Nobody else gets flown out. Once VPN was up on 10/15: Wolfgang comes home, nobody replaces him, and if a problem appears Peter will go himself. Peter intends to get Wolfgang bonuses, and wants someone more senior available to assist on future installs.

Oct 16

Core42 partner posture - plan only in CIQ-only rooms, never program-manage Core42, zero friction, Adam coordinates

During the Core42 deployment Peter set operating rules: all CIQ planning and coordination happens in CIQ-only rooms, not the shared WhatsApp group; CIQ does not program-manage Core42 work (the network work is theirs); zero friction for two weeks - asking where to look for updates is fine, pinning people down for updates is not; Core42 should experience CIQ as the easiest partner in the world; Adam Jackson owns ensuring the right CIQ people are on each Core42 call and requests elsewhere route through him; visibility comes through documents (HLD/LLD) and introductions to their networking owners rather than chasing.

Oct 16

Core42 is a CIQ Engineering engagement, not Support - Ryan on point, Peter, Wolford and Nathan stay on the calls

Peter classified the Core42 deployment as CIQ engineering handling rather than Support, with Ryan Smith taking point. Peter, Chris Wolford and Nathan stay on the calls. Ryan on-call rotation was judged necessary but not sufficient - senior engineering (Peter, Nathan, sometimes Ryan, often Adam) must be on the Core42 calls when available. Bjorn was told he is not the overnight coordinator, and Core42 HLD/LLD documents go to Peter and Ryan org.

Oct 16

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.

Oct 2

TPS report falls back to Claude Code when no API key is present - stop paying per run for work a subscription already covers

Ryan TPS GTM summaries failed because the report referenced a hardcoded anthropic-gtm keychain key. Peter found the report was set to API billing rather than an installed Claude Code, kept the existing behavior when the token exists, added a Claude Code fallback when it does not, noted that the current setup pays for every TPS run even when Claude would have done it for free, and pushed the change upstream within about 15 minutes.

Put dates out even at low confidence so the board shows reality, and leads keep evolving their metrics - dropping the ones that get gamed

At Eng Sync, when Nathan could not get the RLC-H compliance deliverables above 50 percent and did not know if four weeks of scope remained, Peter said to put the dates out even if low confidence so CIQ is communicating reality; same for desktop (we do not have a designer, but let us make some dates up). He set a standing ask that each lead update covers how their metrics thinking is evolving - which are valuable, which are not, and why - and that unvaluable metrics get dropped because they are anti-valuable and get gamed. He shaped Justin Thursday company walkthrough: pink (humans) goes away, triggers at the top, a column of what is true at each stage; an assembly line, not a loop, held against Ryan SDLC-loop framing.

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.

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.

Joint with Bjorn: every Fuzzball deployment is white-glove for now - owned by Ryan org through workload verification, with FDE headcount added as needed

Peter and Bjorn agreed (the night of 9/23) that for now every Fuzzball deployment is white-glove: install Fuzzball, get the customer workloads running, verify they are using resources through Fuzzball, show the reports they need, then walk away. It lands in Ryan org; his forward-deployed engineer starts on Core42 only, and Peter committed that when Ryan needs another FDE, he gets one. Peter communicated it to Ryan in their 1:1 on 9/24.

Sep 25

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

Sensitive Decision

Sensitive

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.

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.

Treat every RCA as a legal document - Legal review plus Peter personal clearance before it goes to a customer

Peter and Arthur Tyde issued a standing rule to all department heads: unless a customer contract specifically addresses liability, fault and the delivery of a Root Cause Analysis, an RCA is to be treated as an internal document. Before any RCA is shared externally, Legal must review it and confirm it is appropriate to provide, and it must be cleared with Peter personally. The stated reason is that an RCA is a legal document that can unintentionally create legal exposure through statements about fault, causation, or obligations beyond what CIQ has agreed to contractually. Arthur posted the note to #department-heads under a joint Peter-and-I attribution while Peter was in a critical meeting, at Peter request that it be posted with his agreement on the record.

Affirm CIQ needs an OSPO and commit engineering time to upstream contribution as the entry ticket to new ecosystems

After spending time with Tim Pepper during the week, Peter settled a question Max Spevack had repeatedly challenged him on - why CIQ should have an OSPO office at all - and landed on the opposite of the challenge. He concluded that CIQ must have an OSPO, and that engineering has to spend materially more time upstream to be taken seriously in the ecosystems it wants to sell into: if CIQ is going to put out a Kubernetes offering, it had better be committing upstream to Kubernetes and be valued in that community. Tim gave him the magnitude - roughly a quarter of one percent of commits is enough to be seen and recognised as invested. Peter asked Tim to start building a map of where upstream activity buys the most impact and opens the doors CIQ needs, and said he will task engineers against it.

Take the customer breakage now at 100 customers rather than at 300 - but run it through Ryan and sales before it ships

Pushing Justin Haynes and Nathan Blackham on getting three to five times the throughput out of their orgs, Peter asked where the big blocks of time are. Justin said he could do something immediately that would dramatically speed things up but would break some customers. Peter answer: do you want to break customers now when we have 100 customers, or break customers in a year when we have 300? He then attached a condition - everyone sits down, Justin explains what he wants to change and what the fallout looks like, Ryan Smith and sales both understand it, and then it goes. He pre-warned Ryan in their 1:1 that this is coming.

Adopt Bjorn no-US-eyes-only call as the operating assumption - and force the principle question to be settled separately from its effects

Bjorn declared in #department-heads that CIQ has no contractual US-eyes-only obligations, that undocumented verbal commitments are not valid, that any future US-eyes-only deals route through CIQ Federal, and that the call and its risk sit with him. Ryan Smith pushed back that customers were given verbal commitments and should be spoken to first. Peter took two positions: he has no horse in the race on whether CIQ supports eyes-only obligations and a huge horse in the race that everyone marches with the same constraints against the same goals; and that whoever meets on it must COMPLETELY separate are we agreeing to act as if we have no US eyes only obligations from what are we doing. Pending that meeting he told the org he will act as if the answer to the first is no until told otherwise, and warned Dave Dickerson not to let CIQ Federal business-model decisions be made that force Bjorn call to change.

Refuse the Veeam rollback and the never-again promise - fix forward and hold the response until the RCA is understood

Veeam escalated for the third time after a CIQ portal output change broke their CVE scraping script. Melissa Kivisto asked for a rollback and, failing that, a call from Peter explaining a path forward that ensures this absolutely will not happen again. Peter rejected both halves in #department-heads: there is no world where we promise that something will not happen in the future, rolling back is not the right solution at all, we help them move forward and doing so is not complicated. A day later a second breaking change took down their rsync; Peter told the channel there is an RCA in progress and he wants the team to fully understand what happened before responding to the customer.

Sensitive Decision

Sensitive

Push speed-over-perfect down into the Justin org and ask him to produce a visible failure that goes unpunished

Peter opened the Justin 1:1 by reconstructing his own discomfort with how he had handled pushback after a talk on AI usage - the pushback was about corner cases, and Peter realised his own answer had been weak. He then asked Justin to reiterate the speed-over-perfection mantra to his people, and escalated the ask: go fast enough that a real mistake happens, so Peter can visibly decline to punish it. He paired this with a demand for QA automation investment rather than manual QA, and set up a next-week whiteboard exercise: what would have to be true to double throughput, what breaks, and what does it cost to stop each breakage.

Sep 11

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.

Sep 11

Sensitive Decision

Sensitive

Put the Core42 deployment on Ryan org to resource - Nathan stays advisor and the unfilled Forward Deployed Engineer goes on the contract list

While assembling the supported-contacts list for the Core42 contract, Nathan Blackham asked Peter whether he knew who from Ryan Smith team he wanted on it or whether Nathan should reach out to Ryan himself. Peter answered by pointing at the unfilled role first: He is hiring a new guy specifically to do work like this. So we definitely put down an entry for the Forward Deployed Engineer TBH. And then anyone else you want from Ryan world is fine - you have the pick of the litter. Nathan then reminded him of an earlier commitment - And remember when you told me that the deployment management was not going to be on my list.... - and asked whether Ryan himself should get access or only engineers. Peter drew the boundary explicitly: Definitely add Ryan. He will be tasked with the bulk of this work is the plan. You will be there as advisor. But I do not want you getting sucked into managing this. So do not pack the list with your folks either. LEt ryan spend resources as much as possible.

Aug 31

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

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.

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

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