Adam Jackson
Feb 9, 2026 - Nov 3, 2026
25
Decisions
0
Active Todos
16
Patterns
Categories
Decisions (25)
Keep Stratum out of the Core42 IRIS deployment - take the win we have; Stratum can go into Grenoble
Adam Jackson proposed adding Stratum to the Core42 IRIS deal. Peter refused: deploy what is already agreed, do not reopen the contract, and let Stratum go into Grenoble when that happens.
Grenoble pitch - Peter quarterbacks the technical answers and capabilities due within 6-8 weeks are presented as in final test
In the 10/26 Grenoble prep, with Bjorn unavailable for part of the call, Peter quarterbacked who answers which questions. The spreadsheet had been answered affirmatively although some items need six to eight weeks of development; the agreed posture was to engage on them as capabilities in final dev and test that will exist by rollout. Bjorn set the sales posture of not pushing the full stack on a customer that wants Stratum.
Core42 10/29 - CIQ is not the bottleneck; the only CIQ task is a best-practice doc for Warewulf in secure environments, routed to Michael Shinn
After the 10/29 Core42 calls Peter stated it is very clear to Core42 leadership that CIQ is not the bottleneck and network is. The only immediate CIQ deliverable is a best-practice design doc for deploying Warewulf into a secure environment (ILO, FE, OOB network requirements, where Warewulf sits, what must be open between zones), mirroring other secured deployments, to Core42 security. Peter routed it to Michael Shinn with Adam as the delivery path.
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.
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.
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.
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.
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.
Clear Wolfgang for the UAE, cut the on-site window to week one, and hand the final pick to Wolford
Following the 9/16 decision to put a technical body on the ground in the UAE, Peter closed out the open questions in three moves across two days. He talked to Wolfgang, who wants to go. He asked Adam Jackson directly whether a German national can be sent and got a yes the same morning. He told Bjorn in the C-Suite Sync that he does not think the engineer needs to be there for the entire deployment - just the first week or so, when we are going to need to push a button. Then, when Chris Wolford raised Randy as an alternative, Peter said he is fine with it being Randy, that he does not mind, that it is 100 percent Wolford call, and attached the only real constraint: if it is Randy, tell Adam now so the security paperwork starts now for whoever is chosen.
Refuse to build the non-OS Core42 work on top of Ubuntu - getting moving is fine, doing the work entrenches the competitor
Ahead of the Sep 22 Alex meeting in LA, Bjorn argued for starting the Core42 HLD items that are not gated on the operating system, on the reasoning that the deeper CIQ is embedded the more leverage it has to push Rocky through certification. Peter agreed with the aim and refused the method. He separated getting moving from doing the technical work: most of the boxes on that list get built into and integrated with the OS itself, so building them now would be doing the wiring to embed Ubuntu with Core42 rather than embedding CIQ. He also reclassified the expanded scope as SOW3 rather than SOW2, on the grounds that an extra step - getting Rocky in everywhere - has been inserted ahead of it, and told Bjorn that what he wants out of the Alex meeting is a handshake on the gates to swap Ubuntu for Rocky: certification, an application test-and-certify pass, a swap plan, a timeline and a project plan. He accepted Adam Jackson two-section meeting structure and Bjorn sequencing, agreeing to open on what CIQ can do for Alex, then take ten minutes on the removal gates. In the same exchange, after Bjorn reacted to his absolutes, Peter located the fix in his own framing rather than in the position - leave the black and white statements out, make no statement about can or cannot, just walk through the gate.
Put a technical body on the ground in the UAE through Oct 5 rather than run the Core42 deployment fully remote
The Core42 SOW landed the morning of Sep 15 and hardware arrives Sep 18 with a hard Oct 5 deployment date. The deployment was nominally supposed to be fully remote. Bjorn asked whether CIQ needs a body in the UAE just in case, and offered to go himself if there were safety concerns. Peter said he would be a lot more comfortable with someone there, framed it as belts and suspenders rather than a technical necessity, and made the case on a concrete mechanism: having somebody there who can physically push a button is different from having to do this without being able to push a button. He agreed with Wolford that if CIQ sends anyone it should be a technical person. Wolford named Godlove first pick and Wolfgang second; Peter took the assignment conversations himself and said he would have them that morning, including Arsalan on the support side. Bjorn funded business-class travel and a hotel through Oct 5, and declined Adam Jackson offer to ask the customer to cover flights. Peter also declined Bjorn offer to fly out personally and declined the suggestion of sending two people. At the Leadership Roundtable the day before, when Bjorn asked where they had netted out on sending somebody, Peter answered that they should.
Constrain the AMD commitment to lab validation on an MI300 rather than promising CIQ will acquire one
In the group DM with Bjorn Hovland and Adam Jackson on Sept 9, after Adam reported progress on the AMD motion, Peter cut back what could be promised. He told Adam to be careful about promising CIQ will acquire MI300s, allowed the exception that if Adam actually has one in hand from a contact then fine, and said that otherwise he does not think CIQ could get one in the timeline that matters. He substituted the commitment CIQ can keep: telling AMD that CIQ will run validations on a 300 is fine, because he is confident Scott Shinn can get CIQ test access in AMD own lab. He bracketed the correction with support, telling Adam the work is awesome and to let him know how Engineering can support. In the same thread he raised the harder problem nobody had asked about - that AMD will not leave themselves partly on Rocky and partly on Ubuntu, so CIQ needs to get into the weeds on what a cutover looks like and make sure plans are in place, or AMD will keep deploying Ubuntu because their setup and management infrastructure is all designed and tested for it.
Set a floor on personal data CIQ staff hand Core42 - passport yes, property deed no, and demand the required list
Core42 sent a request for personal information as part of background checks for site access ahead of the Sept 18 hardware access date. In #core-42-escalation-members Peter answered with his own position first, tagging Adam Jackson: he will give them a passport, not a deed. In the eight-person Core42 group DM he told Adam there is going to be a problem with that request for info, that he will not give them the deed to his house, that he is confident the bulk of the people on the Linux team will not either, that passports are fine, and that CIQ should be super clear about exactly what information is required. In the DM with Nathan Blackham he repeated that CIQ needs clarity on what info is absolutely required and that he has no interest in giving them his address either. He then tested the requirement himself - he submitted his address, judging it enough for a background check and public record anyway, and reported back that Core42 had emailed asking for additional info including a proof of residency document, for which they accept a utility bill.
Refuse to guarantee Oct 5 for Core42 if CIQ is deploying Ubuntu - give a likely range unless the customer demands a guarantee
Asked by Adam Jackson in #core42-build-and-deploy whether CIQ could commit to an Oct 5 completion starting Sept 18, Peter answered no for the full-Ubuntu-deployment scope: there is absolutely a chance CIQ would hit it, but CIQ cannot guarantee it. He then separated the scopes - if it is just Fuzzball, and Ubuntu is already stood up on the racks and networked, and CIQ gets access Sept 18, then absolutely CIQ could hit that date. He gave the rule for how to answer the customer: be VERY careful about guarantees in a new environment and an OS that is not ours, because a guarantee puts CIQ in a position to lose future business when this is the first time CIQ is doing this; if Core42 MUST have a guarantee that is one thing, but if they only want a likely range then give the range and do not make an unforced error. He then asked the four scoping questions that decide which scope applies - is Ubuntu already installed, is networking already set up, is there a provisioning machine available for ELM, and exactly how many machines.
Refuse to green-light the HPE indemnity escalation - this is a Bjorn call, not an Engineering call
HPE was blocking the Core42 Stargate deal on the grounds that Rocky is not a certified OS on the GB300s, against a contract where HPE has guaranteed 99.999 percent uptime with penalties. On 9/1 Adam Jackson proposed that CIQ absorb HPEs support penalties for the first cluster and contract the risk out to an insurer, laid out a six-step plan starting with an immediate call to HPEs Russ Fromkin, and asked Peter and Bjorn for permission to make that call. Six minutes later Peter answered with one sentence: This is a Bjorn call, not an Engineering call. Adam stood down - I will not reach out to Russ unless I am given the green light - and Bjorn took ownership, slowing the solutioning until the actual contract terms were known. Dave Dickerson pressed the same way, asking repeatedly to see the contract. The exposure being discussed turned out to be roughly an 8 million dollar guarantee against roughly a 10 million dollar future deployment stream.
Call the Core42 SOW1 won mid-call and forbid reopening anything that does not need reopening
During the Aug 24 Core42 and CIQ call, the customer side kept probing why the SOW does not cover the broader logical control set, and the CIQ team started engaging on where work splits under partials. Peter intervened twice in four minutes in the internal channel running alongside the call. First he reframed the confusion: I think we have lost track of the fact that ultimately there will be 2 SOWs. Then, once Alex Trafton had asked whether they could sign, he closed it: this is won, we should be careful not to re-open ANYTHING that does not need to be reopened. When Adam Jackson asked whether he could stop screen-sharing the HLD, Peter answered yes please stop sharing. The team changed behaviour inside the same minute - Bjorn said I will wrap, Brian Dawson said he would refrain from additional comment and let Bjorn and Adam land it, and Adam stopped sharing. The SOW1 final package went out to Core42 by email that afternoon.
Show Core42 the responsibility matrix filled in, not blanked - a first cut we are flexible on beats arriving with an empty working sheet
In the Core42 implementation-review pre-call on 2026-08-18, Michael Shinn was uneasy about showing his RACI/responsibility diagram because it assumed a much larger scope than Core42 might want, and offered to blank the boxes so the conversation could fill them in. Adam Jackson agreed and asked for the letters removed so CIQ would go in with no expectation. Peter challenged that directly and argued for leaving the chart filled in, framed as a first cut with an explicit statement that CIQ is flexible and not married to any of it. Adam conceded. On the following morning call the control matrix was in fact presented as a draft rather than as a blank working sheet.
Fork the Core42 engagement into two SOWs and let nothing delay the first - land the GB300 paper now, put the expanded security architecture in a separate SOW
On the Aug 19 CIQ-C42 Gap Analysis Part 2 call, Alex Trafton (Core42 CISO, roughly 10 weeks into the role) opened a scope far wider than the existing SOW - PAM consolidation across 4-plus tools, continuous vulnerability management, AI-specific security, physical and OT telemetry correlation, and future AMD MI350X deployments. The room read it as a much larger opportunity. Peter, facilitating, held the immediate GB300 deployment SOW as a closeable unit on its own and pushed the expanded scope into a separate second SOW. In the debrief immediately after the call he put it to Adam Jackson directly: But you agree, Adam, that for the next couple of days, it is just about getting that first SOW across. Adam: Yeah, 100 percent, Peter, 100 percent. Peter: I just do not want to put anything in the way of that. The same instinct had been set the night before in the pre-call, where the agreed play was to propose a second SOW or a simple addendum rather than expand the current paper.
Redirect the entire Core42 solution-review effort away from the people on the call and toward whoever watches the recording afterward - and make every answer technical, never personal
Peter reframed the Core42 engagement in his Nathan 1:1 and again in the group prep. His read: the Core42 security team is married to a Red Hat solution and is using the calls to collect disqualifying gaps, so there is no answer that converts the room. He therefore instructed the team to assume the people on the call are antagonistic, to stop optimizing answers for them, and to tailor everything to the decision-makers who will review the recording. Concretely: stay calm, concise and confident; give less detail rather than more; say yes we can do that repeatedly; and convert every rebuttal from a personal challenge into a technical statement - the FreeIPA docs confirm session recording is possible, not why are you saying it cannot. He also killed Bjorn framing that the win depends on having the best prepared answers.
Defer ARM64 Pro Hardened build until Core42 commits — group decision Peter endorsed
In Apr 26 Sovereign AI response review meetings, the team — with Peter participating — decided the response language to Core42 will acknowledge that Pro Hardened on ARM64 (and FIPS-143 ARM certification) is contingent on a client commitment, not unilateral CIQ investment. ARM64 build estimated weeks not months once committed; FIPS-143 ARM is ~$200k / 4-6 months and gates on a deal commitment. Peter explicitly told the room: "We are going to need Nathan to say when. I am not going to be able to say on this call."
Core42: pivot from Fuzzball sale to full-stack compliance partnership
After the Core42 Tech Dive Part 2 surfaced Core42 wants a single OS vendor for their full UAE compliance stack (NIST 800-53, BIS, IDAM, physical security) across three EOY-2026 GPU clusters, Peter immediately convened an internal Impromptu Zoom to reposition the opportunity. CIQ will propose a comprehensive partnership framing CIQ as the only group that can provide all requirements, with RLC Pro Hardened + Fuzzball + Ascender as the core stack and partners filling the remaining ~20%. Consultative play: CIQ will advise Core42 on which requirements in Eric Grundstrom's doc would cause unacceptable performance degradation vs. which can be met. Nathan to draft the proposal doc by EOD Saturday so CIQ can deliver an answer by Monday.
Set Sales Scope Discipline on Nokia Opportunity
In MPDM with Adam Jackson, Bjorn, Greg, and Jonathon, set firm boundaries on product scope for the Nokia deal. CIQ should sell what it has and is good at, not build custom solutions to close individual deals. The bar for adding new capabilities is company-level strategic pivot territory — not deal-level customization. Stated 'enough money is a LOT' and 'its not going to be for another 500k, or just to close the deal.'
Saudi training — Confirmed Dieter for May 5-6 Linux training program
Confirmed Jonathan Dieter as the trainer for Saudi Arabia Linux training program (May 5-6). Discussed in Dieter 1:1 and relayed confirmation to Adam Jackson. Pending security review.
Directed AMD inclusion in Project Odin approach document
Peter reviewed Adam Jackson's first draft of the Project Odin approach document and approved it with one specific direction: slides 6/7 should include AMD. Otherwise approved as a great first draft.
Core42 Technical Assessment - Multi-Product Positioning in UAE
Attended Core42 meeting in Abu Dhabi with Greg, Bjorn, Max, and Adam Jackson. Provided real-time technical assessment to the team via Slack, identifying product-customer fit across four CIQ product lines: RLC-H for defense customers (CVE remediation pain), Rocky as guest OS on Signature Cloud, Fuzzball as potential replacement for their unhappy AI cloud orchestration partner, and Ascender Pro for their heavy Ansible usage. Followed up personally with Raghu (EVP Engineering, Core42 US) offering in-person meetings.
Related Patterns (16)
Protect Engineering Capacity
When external demands threaten to overload engineering capacity, protect capacity by either requiring the demand to come with additional resources, or forcing hard prioritization choices upstream.
Executive Sponsorship for Strategic Partnerships
Strategic cross-company initiatives and major client partnerships require executive-level accountability to move at the right pace and ensure proper prioritization.
Lead by Example with New Tools
When championing new tools or processes, personally use them and share results rather than just advocating. Learning by doing and demonstrating value through example is more effective than mandates.
Small Circle for Sensitive Operations
When executing sensitive strategic operations, keep the circle of informed people as small as possible to prevent leaks that could accelerate hostile action or undermine the initiative.
Protect Engineering Focus Through Process
When faced with requests that would disrupt engineering focus (from sales, governance, product, or other stakeholders), establish processes that protect engineering ability to innovate while still satisfying legitimate concerns. Prefer systematic solutions over ad-hoc responses.
Reclassify to Route - Decide Who Owns It, Then Give a Criterion Not a Verdict
When a question arrives at Peter framed in one domain, he often does not answer it in that framing. He reclassifies it into the domain that actually governs the outcome, which relocates ownership to whoever owns that lane, and then hands down a decision criterion rather than a verdict. The reclassification IS the decision - it determines who decides. He does this rather than adjudicating on the merits himself, even when he was explicitly cc-ed and even when a direct report challenges him on the substance.
Purpose Is the Decision Procedure
When someone asks how a process, board, tool or artifact should handle their specific case, Peter refuses to answer on the askers terms. He re-derives the answer from what the artifact is for, states that purpose as the only decision procedure, and lets the answer fall out. Anything found to be serving a second purpose is deleted rather than debated. Tools and views are explicitly subordinate to definitions. He will accept that the askers real problem is simply not solved by this artifact rather than widen the artifact to cover it.
Route Non-Differentiating FTE Classes to Partners
When CIQ would otherwise need to staff a function whose work does not differentiate the company — compliance bureaucracy, audit/cert paperwork, ongoing regulatory attestation, etc. — Peter routes the load to a partner who already owns adjacent capability rather than adding the FTE class internally. Org-shape decision dressed as a partnership decision.
Demonstrate the Standard, Then Collect It
When a new leadership expectation has to land across multiple orgs, Peter does not write a spec. He runs a live exemplar in public with the strongest performer first, says openly that the ordering was deliberate, keeps the form of the deliverable open so the ask stays about the thinking rather than the artifact, lets the delta be self-evident to the people who will have to close it, and then collects the same from everyone else on a named rotation. He prefers showing imperfect work now over polished work later.
Decide on the Precedent, Not the Case
When a request arrives framed as a one-off, Peter does not evaluate the one-off. He evaluates the rule that granting it would write, and answers that instead. Peter generalized this himself on 2026-08-11: it is always about understanding precedent - whether it is a comp change or anything that structurally affects the company. It is therefore NOT a compensation pattern; the domain of the presenting request is incidental. The tell that this pattern is live is that the stated reason for the answer refers to future cases rather than to the merits of the present one.
Metrics Must Follow Strategy
When shifting team priorities or strategic direction, the communication alone will not drive behavior change. Engineers may acknowledge the new direction but continue existing behavior patterns without clear, explicit metrics holding them accountable.
Switch Instrument, Not Intensity
Applies when a message, rule or ask has already failed through the channel Peter is currently using - repeated advocacy that has not landed, coaching that produced defensiveness rather than improvement, exhortation that did not change behaviour, or a rule that keeps losing case by case. His response is never to restate the same thing more forcefully. He changes the instrument and usually names the switch out loud. Mined from 7 independent observations between 2026-01-06 and 2026-08-21.
Time Over Cost
Peter treats elapsed time as the scarce quantity and money as the abundant one, and will spend cash to buy schedule, clarity or optionality. Notable because he named it himself as a transferable principle on 2026-05-21 and coached the lens explicitly to a direct report, which is rare - most of his patterns are inferred rather than stated. It generalises past procurement: he will pay to convert an ambiguous dispute into a binary one, remove cost as a variable entirely when a priority has executive visibility, and reason about a commitment in terms of lead time rather than budget. Mined from 5 independent observations between 2026-02-01 and 2026-09-11.
Promise Only What Is Inside CIQ Control
Applies when someone asks CIQ to commit to an outcome whose delivery depends partly on something CIQ does not own - a lead time, a third-party publisher, a customer-provided environment, an unsigned contract. Peter does not accept or refuse the request as posed. He isolates the specific component that sits outside CIQ delivery chain, refuses that component by name, and substitutes an adjacent commitment CIQ can actually keep - then often adds a harder problem worth solving in its place, so the counterparty gets more engagement rather than less.
Install the Criterion Before the Argument
Applies to a contested question that has not been argued yet - a meeting about to start, a test about to run, an escalation just received, a proposal about to be written. Peter moves first to fix the criterion, the boundary or the posture, before anyone argues the substance. The consistent effect, named explicitly in the 2026-07-29 observation, is that the other party cannot win by being more persuasive on the merits, because the merits are no longer the axis. Distinct from Reclassify to Route in mechanism: that pattern reassigns who owns a question, this one controls WHEN the criterion lands relative to the debate. The two frequently co-occur. Mined from 7 independent observations between 2026-01-20 and 2026-08-31.
Measure, Commit Publicly, Then Execute
A three-beat escalation arc Peter runs when he needs a commitment from a peer or the CEO that private pressure has not produced. Beat one: measure the thing and get a number. Beat two: state the commitment in a venue where the people who matter are watching. Beat three: execute against it. The 2026-04-15 observation names the sequence explicitly and notes he does not skip steps, because each beat builds the legitimacy of the next. The venue choice is treated as a decision in its own right, separate from what the message says. Mined from 8 independent observations between 2025-12-29 and 2026-08-28. NOTE: scope this to the venue-and-sequence mechanism specifically - forcing function is a phrase that appears loosely across many unrelated decisions and should not be taken as a match on its own.