Melissa Kivisto
Jun 12, 2026 - Sep 23, 2026
5
Decisions
0
Active Todos
13
Patterns
Categories
Decisions (5)
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.
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.
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.
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.
Prioritize RLC 10.2 to the top, drop AI+H work — and validate the JPD deprioritization as correct
After a Citadel-driven escalation (10.2 needed for a ~$200k contract + expansion), Peter pulled Nathan, Justin and Max into a 5-minute call, made 10.2 priority-one for Linux eng above RLC AI and H work (only 3 critical CVEs rank higher), and was willing to drop other work if needed. He then posted an actionable timeline range to #department-heads (inner bound Fri 6/19, outside June 30, gated by CVEs). Crucially, he endorsed that the team had correctly deprioritized 10.2 per the JPD board and framed the whole episode as a communication failure (Bjorn got a single June-30 date without the range/assumptions), NOT an execution failure.
Related Patterns (13)
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.
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.
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.
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.