Melissa Kivisto

Jun 12, 2026 - Jul 27, 2026

3

Decisions

0

Active Todos

6

Patterns

Decisions (3)

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.

Jul 27
operational

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.

Jul 27
strategy

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.

Jun 12
strategy

Related Patterns (6)

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.

172 occurrences78% success

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.

169 occurrences78% success

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.

161 occurrences79% success

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.

159 occurrences77% success

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.

156 occurrences77% success

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.

42 occurrences80% success