Ramesh
Dec 24, 2025 - Sep 2, 2026
20
Decisions
0
Active Todos
12
Patterns
Decisions (20)
Refuse the 9.10-as-of-today letter for KT - give them 9.6 LTS now with its real support window and a required migration, and correct the numbers publicly when they turn out to be wrong
Arthur Tyde pulled Peter and Ramesh Srinivasan into an early-morning call on 9/2 over a roughly 1.x million dollar KT deal. The Korea AE had drafted a letter, largely AI-written, committing CIQ to deliver RLC 9.10 LTS as of today. RLC 9.10 does not exist - it is a November-December release - and KT cannot move to 10 because their ISV and telco software is certified on 9. Peter refused the letter shape and reframed the question first: why do they want early access, what do they want to do with it, what are they trying to accomplish. He then constructed the alternative himself - ship 9.6, which is the actual LTS build (9.8 is not), now, and extend support on 9.6 toward the 9.10 LTS window - and committed to verify feasibility with Nathan Blackham before anyone signed. He noted CIQ has done nothing on 9.10 builds yet, so early access to 9.10 does not exist to give. Later the same day in the group DM with Arthur, the Korea AE and Ramesh, Peter worked the actual support windows: 9.6 support is 4 years, 9.10 is not 10 years but 8, so the gap cannot be bridged - we can give them 9.6 now but they would need to migrate to 9.10 within 4 years. He posted the correction against himself unprompted: And I was wrong - 9.10 is 8 years, not 10. But still the same overall problem.
Ratify sales engineers owning first-pass demos as the permanent structure - reframing Chris Wolfords self-reported staffing error as having kickstarted the right thing
Chris flagged as a back-of-mind item that he had made the tactical error of letting Godlove and Wolfgang take vacation the same week, and described the workaround he had arranged with Ramesh, Godlove and Horn: sales engineers run first-pass demos, Jonathan supports them, and Chris himself only takes deep dives. Peter converted the workaround into the standing structure on the spot: that is what it should be anyway, so I agree - I am with you on the tactical error, but it sounds like you might have kickstarted the right structure anyway. Sales should be doing that. When Chris characterised it as knee jerk with the plan already in the back of his head, Peter closed the reframe: I know, the pieces were all there. Just forced me to do it.
Took the Fuzzball pitch to Axiom Space himself rather than letting Sales carry it - and set the closing path at NDA then contract
On the 7/28 Axiom Space CTO introductory call (Mark Seigle and Ethan Leas, with Tom Shingler, Ramesh Srinivasan and Bjorn on the CIQ side), Peter learned Axiom is building an orchestration platform for sovereigns and immediately concluded CIQ needs to get Fuzzball in front of them. When Bjorn asked whether Tom was pitching it, Peter answered I did. He read out the technical fit in real time - they will need post-quantum work which is already on the roadmap and they seemed happy with that, and they will need Ascender plus updates to run well over low-connectivity satellite links - set the next step as sign an NDA and start talking contract, and named the strategic window: they are just starting, so they are in a position to choose OS cleanly right now. Mark said he wants to close in weeks. Peter told Bjorn yeah if we lose this we suck and posted in the deal channel sounds like it is ours to lose. Ramesh confirmed Axiom is moving forward with the NDA.
Everfox desktop - CIQ is an integrator, not a builder of novel desktop technology; convert the ambiguity into integrator-shaped requirements
Max raised that the Everfox desktop requirement had reached him third-hand through Nathan as something about launching multiple GUI programs with some running in a special memory-protected mode. Max said CIQ can be great as an integrator pulling patches together and writing tests, but cannot build brand new security-critical technology into Linux. Peter agreed - not with the tiny team that we have - and made that the operating constraint. He tasked Max, with Bjorn and possibly Brady, to convert whatever Everfox is actually asking for into a series of requirements that fit an integrator posture, and stated he does not want CIQ designing a new desktop. He offered the shape he hopes the answer takes: which desktop are we shipping, which variant, and is there a set of a few applications we ensure run.
Everfox desktop-OS: require explicitly scoped and funded eng-investment before supporting the deal
On the Everfox desktop-OS deal, Peter framed it as a fundamentally different business (be like Ubuntu while also being like RedHat, not add desktop support to Rocky) and insisted the unknowns around hardware enablement / driver support and a dedicated lab be made explicit. His engineering-side conditions: the MSA must fix the hardware scope with out-of-scope hardware priced separately, and CIQ should proceed only with an explicit commitment to fund the engineering regardless of revenue. He tasked Max to assess technical feasibility with Nathan before committing. Relates to the prior logged Everfox decision d1ea8ed9; this is the engineering-stewardship condition layer.
Hold the margin line - willing to walk from bad-economics deals (currently applied to Rakuten)
In his 1:1 with Baek, Peter articulated a generalized stance and named its current target: stop playing the tell-the-customer-yes-to-anything game, and hold a hard line even if it means losing the deal. He will not spend 2M to capture 400K. He confirmed this is a generalized principle that at this moment absolutely applies to Rakuten as those negotiations finalize.
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.
Rakuten RFQ prioritized over Board prep + vulnerability response — scope-discipline enforced at line-item level
After conferring with Bjorn 5/15 afternoon, Peter reordered the week to put Rakuten RFQ response above both Tuesday 5/19 board prep and continued kernel vulnerability work. Held the boundary against scope creep in the submission itself: stripped runc nohz_full / ACC100 commits (Reqs 19, 37, 10, 38), scrubbed AI-generated CIQ Rapid Security Patch SLO Framework (48h/72h/14d commitments), softened Validated-for-[hardware] to Supported-on, kept RT kernel position to vmcore-dump-analysis-plus-recommendations only — no hands-on-keyboard custom patches. Deal size is $2M/year per Ramesh — different business with Rakuten than the existing engagement.
Reject open-ended LGU+ RHEL/OEL support commitments — best effort only
Nathan surfaced (via Justin) a CIQ <> LGU+ contract proposal requiring CIQ to provide workarounds and answer customer SR tickets for RHEL 6 (already EOL), RHEL 7/8/9, and OEL 6/7. Peter intervened in the same-day group DM with Bjorn, Art, and Ramesh to draw the line at best effort only — no commitments to deliver workarounds or answers. Asked Nathan if it is not yet in force so he can get in front of it before signing.
Peter delivers Reno QBR C-suite intro Thursday — covering Bjorn late arrival
Peter will deliver the C-suite intro at Reno QBR Thursday morning, since Bjorn arrives Thursday afternoon. Peter arrives 8:45 AM Thursday. Greg travels to Houston with Adam for a 1 PM Thursday sales meeting.
Three-tier Rakuten kernel proposal — 8.10 preferred, 8.6 sustaining, $800k-$1M PS for full 8.6
Push Rakuten to migrate RLC 8.6 to 8.10. Three-tier proposal: (1) preferred — full support on 8.10 with CIQ vendor coordination to accelerate hardware recertification; (2) alternative — sustaining support on 8.6 with no new patches/backports (security risk on Rakuten); (3) PS engagement — $800k-$1M/year to fund two dedicated kernel engineers for full 8.6 support, framed explicitly as Professional Services cost not mainline engineering. June renewal is the forcing function. The original handshake-pricing deal with Tarek is void.
Everfox: require ~$2M front-loaded year-one payment, reject back-loaded $600k structure
Peter is requiring a large upfront payment ($2M floor with the proposal team; $4-6M float with Greg) for the new Everfox custom work (legacy CPU support, custom desktop) and rejecting the back-loaded $600k year-one structure. The $20M/10-year deal will be restructured to front-load payments, potentially by reducing total contract value if needed. CIQ will not absorb non-reusable engineering work without immediate funding.
Engineering veto required on custom deals and new lines of business
Peter is implementing a formal process where Engineering has review-and-veto authority on custom deals and new lines of business. Engineering must be consulted to assess cost and feasibility before any deal is finalized. Discussed in Peter <> Chris 5/1 and applied immediately to the Everfox proposal restructuring on 5/4.
Fuzzball PoC ownership belongs to Sales Engineering, supported by Engineering
When Bjorn asked who should own Fuzzball PoCs (Sales Engineering vs Wolfgang/Godlove vs Support), Peter answered definitively: Sales Engineering, supported by Engineering. Bjorn agreed with the framing — pushback was strictly about Sales Engineering not being enabled on Fuzzball today (resourcing gap), not the principle. The default routing stands.
Advocate for in-person Anduril POC kickoff in Seattle
Decided to advocate for an in-person technical kickoff meeting in Seattle for the Anduril POC, with both Peter and Max attending. Set clear boundaries on duration - a day or two is fine, but two weeks would break February delivery dates.
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.
Everfox partnership requires ARR-target-level contract to proceed
Participated in technical scoping meeting with Everfox to understand feasibility of supporting their RHEL 8 to RHEL 10 migration for 100k+ hardened thin client units. Meeting was exploratory - no commitment made.
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.
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.
ProServe Work Prioritization Process
Established new process for handling professional services work: ProServe work will be prioritized against existing roadmap, not by dropping in-flight work. Product (Brady) owns prioritization decision, Engineering determines timing based on capacity.
Related Patterns (12)
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.
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 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.
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.
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.
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.
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.
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.
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.