Tissa
Jan 12, 2026 - Aug 28, 2026
10
Decisions
0
Active Todos
11
Patterns
Categories
Decisions (10)
Attack the live-patching gap through Google co-development as a paid deliverable while keeping the req open - buy the timeline, do not just wait for the hire
In the 2026-08-25 Exec Product Prioritization session Peter named kernel live patching as his single biggest capability gap, and said he does not need more heads beyond the requisitions already open to deliver the top of the board - with live patching the exception. Rather than waiting on that hire, he took a 5:15pm sync with Tissa Senevirathne at Google the same day, scoped specifically to whether Google can accelerate the live-patching timeline and whether it can be added as another paid deliverable to the existing engagement. He described the approach to Chris Baek and Bjorn Hovland as throwing co-development options at the wall to see what sticks. The Rex requisition stays open, so this is an additional path rather than a substitute for the hire.
Price the Google live-kernel-patching ask at 2 HC for 3.5 months plus 1 ongoing, and take the honest slower timeline back to Tissa rather than fit their October date
Tissa asked for a quote on live kernel patching as paid work in addition to the existing monthly full-kernel contract: evaluate whether an incoming CVE patch can be delivered as a live patch, deliver it that way when it can, and still roll it into the next monthly drop. Volume unpredictable - might be 70 percent of a months patches, might be zero. Google wants something working by October so they can test before a January go-live. Peter opened the request to Nathan and Justin with a pre-commitment that removes the usual objection - assume we get headcount to cover this work - then interrogated the shape rather than the number: 2 engineers for 3-4 months and less ongoing, or 2 forever? He landed on 2 HC for 3.5 months and 1 ongoing after that. He then did the arithmetic out loud against Googles date - lets assume a month to hire, and 4 after that to have something, as the reasonable case - concluded I think that gets it to them too late and they will say no, and chose to go back with it anyway: but lemme go back to tissa with that and see where it lands. He closed with lets go fishing and see what we can catch. He also flagged that Tissa appeared unaware of internal discussion on the topic - Tissa seemed in the dark - and asked whether that discussion had ever reached Google.
Override your own teams stated intent to delete the RL 8.6 source tree, and apologize to Google directly rather than defend the position
Tissa Senevirathne emailed Kelly Hall on Jul 30 saying CIQ had informed Google it wanted to delete the RL 8.6 OS and kernel source tree, and asked that it be preserved for contractual traceability and auditability. Peter replied to Tissa the next morning without consulting his team first: I do not know why my team informed you they wanted to delete that tree. I apologize. There is little cost associated with us keeping it live. I hope it was presented as a discussion, not as CIQ is doing this. I will dig in with them to understand what was motivating that, but your request is more than reasonable. In parallel he told Nathan in DM: we cannot shut this down right now, it does not cost us to leave it up except for a few dollars, and pressed for the reason - but why would we need to delete it? I do not want to do anything at all to rock the boat with them right now unless we need to. He named the underlying stake: I want to make sure we have the actual contracts completely signed in blood, and pushed back on the suspected motive - I do not want to do anything that they are nervous about right now, especially if the reason is that its existence makes our metrics look bad.
Release the Google 6.18 build; hold the line on future deliverables until Google resolves the LTS question
On 7/22 Peter lifted his own 7/21 hold on the Google/GDC 6.18 image. He connected with Bjorn first, then told Justin Haynes in #google-partnership-governance and in DM to Kelly Hall: give Google the build. He emailed Tissa Senevirathne at Google the same morning confirming the release, restating a firm stance that the LTS work has already been provided to Google, and stripping Mahdu and Alyssa off the thread. He paired the release with an explicit condition: future deliverables are held until Google sorts out the LTS commitment.
Committed CVE categorization + kpatch estimates to Google by Monday
After Tissa agreed no one can answer Madhus blanket questions, committed CIQ to deliver a CVE-type classification table with kpatch coverage estimates by Monday. Reshaping an unanswerable request into a structured, defensible answer by category.
FIPS 6.18 Option 2 Engineering Kickoff
After Manu at Google did not respond to the relationship reset email sent Sunday, Peter escalated the FIPS proposal to Tissa via Kelly. Tissa authorized CIQ to proceed. Peter then directed Nathan to begin engineering work on Option 2 (faster timing path) while awaiting the Atsec contract. Engineering was held in reserve until external confirmations landed to avoid thrashing.
Unified Google Proposal — Present Combined GDC/GCE to Rohan
Aligned Kelly and Bjorn on presenting a unified GDC/GCE proposal to Rohan (Google senior director) instead of negotiating separately. Reframing from pro-serve/ticket model to value-driven partnership with a large fixed annual fee ($8-9M).
Google Partnership Strategy - Build Rapport with Tissa
Decided to shift the Google contract renegotiation strategy from confrontational to collaborative. Peter will personally meet with Tissa (Google) to build rapport and empathy, framing CIQ's financial pain as a shared problem to solve together. Greg will be excluded from this meeting to ensure a non-antagonistic conversation.
Google Scope Change - Hold the Line on Commercial Terms
Decided to personally join the Monday lunch meeting with Tissa to lead negotiation on Google scope change. Google was trying to bundle Rocky 8 and 9 into one version (reducing from 8 to 5 versions) and push release next format without updated commercial terms.
Google Scope Change - Hold the Line on Commercial Terms
Google is pushing scope changes that bundle 8 versions into a 5-version contract, omit EOL dates, and include undefined dev streams. This creates scope creep risk and jeopardizes the Extended LTS revenue stream (~$300k/year per product). Decision to personally attend the Monday meeting with Tissa (with Max) to hold the line. Greg will NOT attend to preserve escalation path.
Related Patterns (11)
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.