Lindsay
Jan 2, 2026 - Nov 9, 2026
35
Decisions
0
Active Todos
22
Patterns
Decisions (35)
Public CVE campaign page - yes to the page, no to auto-updating it; each CVE needs curation to tell the story
In a thread on a public page describing the CVE campaign, Peter said the page is really valuable but questioned dynamic updating: each CVE is a potentially different effort and process for CIQ, so the page needs manual curation to properly tell the story.
Get CIQ onto the embargoed security lists, Linux first - treat the absence as our failing; give upstream hours from the Stratum engineers to wherever Tim directs, and let Tim move without waiting on Peter
In the 10/21 Tim Pepper 1:1 Peter set three things. CIQ getting onto embargoed security lists is a goal - Linux matters more to him than Kubernetes - and he views not being admitted as a failing on CIQ side to be fixed by building community trust; Tim brokers the conversations. Weekly hours from both Stratum/Kubernetes engineers (one hired, one req open) go to upstream work wherever Tim directs. And Tim moves things forward without waiting on Peter: invite him to meetings rather than reschedule around him, and Peter will tell his team and Marketing to jump when Tim asks. The upstream/downstream development training Tim plans will include the Linux org.
Bjorn post-training / sovereign-stack ask goes on the Value Drivers board as a product block; engineering hangs a learn-first research effort off it
Bjorn asked for help understanding late-stage training of open-weight models on customer proprietary data as a use case pairing Stratum, Fuzzball and Open Waldo. Peter said yes, framed it as a use case for the existing portfolio rather than a new product, and refused to run it out of band: Bjorn puts a single block in the middle of the three-tier Value Drivers board saying CIQ wants to support this use case; that block triggers Peter to attach engineering (people from across CIQ engineering, possibly external contractors); step one is educating Bjorn and Peter before deciding whether anything goes into Jira. He applied the same move to Fuzzball/Stratum being agent-deployable - a block in the middle of the board with work hanging off both sides.
Approve the Spark benchmark claim in the RLC Pro AI press release - correct and defensible beats preferred wording
Lindsay asked Peter to confirm the final RLC Pro AI on DGX Spark benchmarks (Dawson had confirmed; Bjorn routed her to Peter). Peter confirmed them, noted they are not yet published on Spark Arena, and approved the first-paragraph claim: comfortable with it, does not love the wording, but it is correct and defensible. Separately told Bjorn the word four is doing a lot of lifting since there are many more tests than four.
Endura goes into RLC-H as a feature, not a standalone product - and no public noise until engineering has audited and stands behind it
Bjorn proposed white-labeling Endura as a value-add offering early next year and bringing Eric Sheridan on in a product role. Peter objected only to a standalone product offering (another thing to sell and track, unclear Core42 needs it); when Bjorn reframed it as a feature white-labeled into RLC-H, Peter said all his objections go away. After Greg flagged it as a month-long vibe-coded project, Peter added that there is no Lindsay launch or public noise until engineering has its arms around it, even if hardening takes two months; the code may be a prototype to learn from and rewrite, or 95 percent keepable. No exclusivity; Bjorn pushes the Eric meeting while Greg examines his concern.
Desktop v1 ships at minimum scope - a concrete acceptance-test list to hold Nathan to, one desktop environment first, no date until the design plan exists
Peter asked Bjorn to have Brady add a section to the desktop doc listing the tests and validation that must pass before v1.0, made as small as possible, so there is a concrete set to hold Nathan to. When Bjorn asked for GNOME and COSMIC, Peter pushed for one environment first; Bjorn settled on whatever Everfox wants, defaulting to GNOME. Peter would take Brady draft immediately (perfect is the enemy of done) so engineering moves now, and declined to commit to Bjorn January target until he sees the design plan.
No announcements until Engineering is confident on a delivery date - applied first to killing the Desktop announcement at SC26
Bjorn asked the Leadership Roundtable whether to announce Desktop at Supercomputing. Peter said no, and stated the rule rather than the verdict: not until we actually have designs and know what we are building and know we are going to get it. Peter confirmed in review that this is a general standing rule - CIQ does not do announcements until Engineering is confident on a delivery date - and that Desktop at SC26 is simply the first case it was applied to. December, which came up in the same exchange, is the ask from Product and Marketing rather than an Engineering estimate. Bjorn accepted immediately and substituted Stratum as the SC26 headline. Peter separately named Desktop designs as one of only two things he needs from Bjorn org, and Bjorn committed a newly hired designer to it.
Sensitive Decision
Abstain from the product-naming decision and pre-commit to supporting whatever Marketing picks
In a DM with Lindsay Aamodt on Sept 10, discussing candidate product names Cake, Stratum and Wolfy, Peter removed himself from the decision. He said he does not need to be a part of any decision making on this, that he will happily support Cake, Stratum or Wolfy, and that they should just tell him what the thing is called and he will make it look that way. He added that he will not be in her way. Asked what he cares about, he said he cares that it is a good enough name, and that for him all three are. He supplied his own history and preference without converting either into a position - he told her that he and Bjorn already made a product called Cake and it failed, that he loved the name in the past, and that he will support Cake if she wants to push for it.
Pull Max Spevack Spark work into a CIQ-managed repository before the announcement, and define the outbound publication path
In the group DM with Nathan Blackham and Brett Mastbergen on Sept 9, Peter pointed at Max Spevack NVIDIA Spark work living at github.com/maxspevack/spark-rocky, noted Brett already has access, and said he would like to get it pulled into a CIQ managed repository, asking one of them to make that happen. He paired that with a request to talk about a process for making it available to the world on the heels of the announcement Lindsay Aamodt wants to make in the coming week or so. He did not route the request through Max. In the same window he told Brett he would try to chat with Max but that Max can be hard to reach currently, and told Lindsay and Bjorn that Max is so hit-miss on getting back to him on things like the benchmark publication.
Cap the Spark benchmark chase at one or two wins - the deliverable is bits in RLC-AI on Portal, not a leaderboard listing
Across four channels Peter set the scope of the NVIDIA Spark benchmark work ahead of the Tuesday announcement. To Nathan Blackham and Brett Mastbergen he said not to spend too much time there, that all CIQ really needs is one test to point to, two is awesome, more is not necessarily better, and that after one or two what is actually needed is the right bits baked into RLC-AI and available on Portal for download, at which point CIQ can declare victory. He also directed benchmark selection by relative rather than absolute result - pick whichever benchmark showcases Rocky best against the other distros on the leaderboard and can produce results quickly, because this is not about the raw number. In the group DM with Brian Dawson, Bjorn Hovland and Lindsay Aamodt he corrected the plan: the leaderboard is third party, not controlled by NVIDIA, CIQ cannot guarantee any posting there by any date, so make plans that involve self-reported benchmarks. With Lindsay and Bjorn he put the third-party publication odds at about fifty percent while calling confidence in CIQ own benchmarks high.
Approve the NVIDIA-supported Fuzzball hackathon at SC - with a Wolford engineer on site a day early and a month of hardware notice from NVIDIA
In the L/P Quick Sync on 2026-08-18, Lindsay Aamodt brought the NVIDIA hackathon she has been building - in person in Chicago, Friday November 13 kickoff, build Saturday and Sunday, judging Monday, winner presented in the booth Tuesday as SC opens - and asked Peter to name the risks that would make it a flop in person. Peter approved it and attached conditions: someone who works for Chris Wolford goes on site a day ahead to stand the clusters up, explicitly not Lindsay; and NVIDIA must confirm exactly what hardware they are providing a month in advance so the networking is handled beforehand. He committed himself as a judge alongside Bjorn, Greg and Scott, and Wolford as mentor staying through Saturday.
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.
Take on Value Drivers Board restructure as the next coordination lever after JPD doctrine
In the 6/01 Leadership Roundtable, Peter committed to bring a formal proposal to restructure the Value Drivers Board, explicitly sequenced as the next move now that the product-priorities board (the JPD-doctrine work, closed 5/29) is aligned where he wanted it. Took the Fathom action item to draft the proposal and share with Chris Baek and the group within a couple of days. Triggered by Lindsay surfacing marketing/product misalignment (premature RLC+AMD announcement before AMD validation; Fuzzball multicloud date churn May 28 to June 4).
RHEL patching support: same-day customer-facing document with explicit Ubuntu carve-out
Peter wrote and shared a Google Doc same-day (within 32 minutes of the Leadership Roundtable action item) outlining CIQ Engineerings agreed scope for supporting RHEL patching. Sent to Bjorn and Ramesh for review with the intention of forwarding to Art for customer-facing use (lead-gen + knowledge-transfer). The doc explicitly does NOT cover Ubuntu — Peter made the Ubuntu carve-out explicit in the DM thread when Ramesh raised Canonicals different model.
Peter Computex condition: product must be production-ready, not a POC
For the proposed early-June Computex Fuzzball-on-DGX-Spark announcement, Peter set one engineering-side condition: the product must be production-ready (not just a POC). Bjorn separately set the GTM-cadence gates (max 6-week lag between announcement and delivery; sufficient PR-runway for Lindsay and Cathay). Peter held the engineering line cleanly and let Bjorn hold the product-marketing line.
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.
Slip Fuzzball V4 date now and drop confidence rather than fight to hit it
In the Chris Wolford 1:1, Peter coached Chris to take the V4 target date (end of May, 80% confidence) out by ~2 weeks immediately, drop the confidence number now if his gut said 50-50, and tell the team explicitly: we are sliding so we hit. Frame the new date as a high-confidence communication contract with Go-to-Market (Lindsay) rather than a hope.
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.
Jira confidence-as-contract doctrine codified across engineering directs
Codified explicitly in Justin 1:1 5/21 and same-day endorsed via Chris W DM: Jiras confidence number is a communication contract between engineering and GTM. Rules: (1) drop confidence immediately when a date is at risk (e.g., 80%→50%), (2) slide the date by a calculated intentional amount, (3) once confidence is high (95%), the date is a firm commit and must be hit even at extra cost, (4) treat ALL work as change-requests (no bug-vs-scope debate), (5) any change in understanding triggers immediate date/confidence updates. Engineering Order of Operations vs JPD prioritization formally separated: engineering owns operational/health priority (e.g., image build pipeline rework), JPD = product-value priority. Significant misalignment triggers a conversation. Same doctrine to be rolled out to Nathan and Max next.
Commit engineering to vuln-handling infra/automation at Leadership Roundtable
At the 5/11 Leadership Roundtable, Peter accepted an explicit action item to prioritize vulnerability-response infrastructure and automation work in engineering, and to update Chris Baek as the interim process owner. The commitment converts the 5/8 internal-to-engineering commitment (build/test infra to eliminate reactive interrupts) into a cross-functional commitment with Bjorn, Greg, Chris, and Lindsay in the room.
Documentation process — Product defines exit criteria in Jira, Engineering delivers
Formalize documentation ownership: Product defines documentation requirements in Jira ticket exit criteria (e.g., docs suitable for blog post). Engineering delivers content meeting those criteria. Product or Marketing (Lindsay) refines technical content into user-friendly format.
Ship CIQ kernel patch with extra fix; contribute upstream; race to be first/best on CVE response
Linux kernel CVE response: CIQ shipping 10 fixes vs CentOS Stream's 9 (CIQ found and is fixing an extra issue related to the CVE). Extra commit submitted upstream to centos-stream and acknowledged for inclusion. CIQ pushing to be first EL distro to release, with primary goal of customer reassurance and secondary goal of public proof point that CIQ contributes to security and is large enough to serve big customers. Also pushing patches to RLC kernels as fallback in case RH doesn't move quickly.
RESF JIRA Date Reset for Realistic Expectations
Peter directed Nathan and Justin to adjust April/May JIRA items with low confidence due to RESF resource drain. Move them out now to give marketing a high-confidence scope for 4-6 weeks.
RESF Communication & Information Control Strategy
Established multi-layered communication control for RESF transition: (1) Posted own #engineering message with different language than Greg's draft, emphasizing visibility requirement. (2) Told eng-management nobody talks on RESF Zoom calls because RESF members can hear. (3) Asked Lindsay to confirm no social media leaks. (4) Told Max to keep RESF off Department Heads agenda Thursday.
Post-RESF Consolidated Deliverable Reset
Decided to deliver a single consolidated update to Lindsay on revised March deliverables after RESF work stabilizes, rather than incremental delay announcements. Nathan will reset all project dates at once.
Demanded war-room or date ranges for RLC Pro release dates
Marketing (Lindsay Aamodt) published release dates in #department-heads: Feb 19 RLC Pro, Feb 26 RLC Pro AI, Mar 5 RLC AMD. Justin Haynes responded that dates were 'written in light pencil.' Peter directed Justin: if dates aren't confident, either commit with a war-room to hit them, or provide GTM with ranges now so they can plan. Justin acknowledged and scheduled time with leads.
RESF crisis comms - single source of truth
In a RESF crisis, publish one official blog post as the central source of truth. All responses on social media (Hacker News, LWN, HPC forums) link back to that post. Do not engage in real-time debates. Own the traditional news cycle, not social media.
Engineering dates commitment by Friday - reprioritize for revenue impact
Committed to publishing updated engineering dates/milestones by Friday for Monday group review. Acknowledged January deliverables are unrealistic - many items were newly added and cannot complete in remaining ~10 days. Will reprioritize toward revenue-impacting items first. Tomorrow all-day session with Chris Baek to rework H1 plan into aggressive but achievable targets.
All-Hands messaging: acknowledge Q4 miss, pivot to pipeline optimism
Aligned with leadership on All-Hands messaging strategy: directly acknowledge Q4 revenue miss, then pivot to optimistic outlook highlighting $22M H1 pipeline and unified GTM plan. Peter to present tech updates (service endpoints, Nerf) and guide Mural board walkthrough. No naming specific deals to avoid premature expectations.
Conference Travel Approval - David Godlove HBCSF
Approved David Godlove travel to speak on Apptainer at HBCSF conference in Chicago in late March (~$2,200 cost). Required Chris Wolford to coordinate with Lindsay (Marketing) and Chris Baek (Finance) as part of the approval.
Strategic Map Framework - Value Drivers vs Internal Efficiency Separation
Established new H1 strategic planning framework that separates customer-facing Value Drivers from Internal Efficiency Drivers. Framework uses three lanes: middle lane for Value Drivers (the WHY), top lane for GTM activities, bottom lane for engineering deliverables. Also established phased estimation process: low-confidence ballpark dates first, then engineering-only session to raise confidence.
Marketing ICP Validation - Collaborative Research Approach
Pushed for marketing to validate ICPs with real data rather than just executing on what was decided in the planning room. Established that ICPs are hypotheses to test, not fixed targets, and Lindsay has permission to explore outside defined ICPs if data warrants.
Partner/User Management Tech Debt - Accept for Speed
Explicitly acknowledged and accepted that Partner Portal, Fuzzball SaaS, and Portal Depot will have separate user/account systems rather than integrating them. Flagged the future cleanup cost but chose speed over architectural purity.
Commitment to Present Engineering-to-GTM Messaging Framework
Committed to presenting a framework next week that ties engineering work to changes in market state and corresponding go-to-market messaging. Triggered by Fuzzball Service Endpoints press release that was 98% HPC-focused, missing the critical AI angle despite AI being the strategic priority.
Related Patterns (22)
Proactive Talent Pipeline Investment
Invest in building leadership bench and talent relationships before there is an urgent need. Use proven relationships from past experience to create optionality.
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.
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.
Accountability Follow-Through
When you issue a warning or mandate with stated consequences, you follow through. Warnings are not threats - they are commitments. The credibility of future accountability depends on following through now.
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.
Three-Lever Talent Management
When pursuing a velocity or performance mandate, simultaneously operate on all three talent levers — upgrade (hire better), retain (protect key people), and exit (remove blockers) — rather than sequentially. This creates compounding momentum: exits free capacity for upgrades, retention preserves institutional knowledge during transitions, and upgrades raise the performance bar that justifies further exits.
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.
Redesign Conditions Over Policing Symptoms
When a direct report names a vulnerability and proposes surveillance-style verification mechanisms (breathalyzers, daily check-ins, monitoring rituals), Peter accepts the disclosure but pushes back on the surveillance model. Treats the verification proposal as a signal that the underlying environment needs redesign — and offers to change the conditions that produced the vulnerability rather than instrument the symptom. Costs Peter optionality (e.g., committing to broker work-hour expectations directly with the partner/spouse) — the asymmetry signals genuine retention vs transactional.
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.
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.
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.
Constrain the Mechanism, Not the Access
When AI or automation raises a governance concern, Peter does not restrict who or what may reach the data. He constrains HOW the reach happens, so the pathway becomes auditable and deterministic. The failure mode he designs against is non-determinism, not leakage - a wrong filter in inspectable static code is a bug you fix once, while a model that sometimes pulls the wrong field is an unbounded, unauditable liability. He will therefore accept imperfect filtering and eventual leakage as the price of adoption speed, but will not accept a non-inspectable pathway.
Conscious Tech Debt for Execution Speed
When facing time pressure, explicitly acknowledge and accept technical debt rather than blocking progress. The key is making the trade-off consciously and visibly so it can be addressed later.