Arthur Tyde
May 8, 2026 - Nov 9, 2026
14
Decisions
0
Active Todos
19
Patterns
Categories
Decisions (14)
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.
RESF and OpenELA asks are real work - the answer is yes, it goes to your manager and into Jira at high priority, and refusals escalate to Peter
At the Reno onsite Peter told the whole Linux org that when Lee or Jonathan Dieter asks for help with the RESF the answer is yes: tell your manager, get it into Jira, treat it as real work and prioritize it super high. On 11/5 Arthur Tyde described OpenELA as unsupported and himself burning out; Peter applied the same rule to Arthur asks and gave him an escalation path - if anyone says they are too busy, bring it to Peter and make it his problem. Peter committed to talk to Lee about OpenELA from his own perspective, to keep dialing into OpenELA calls, and asked Sarah for an ongoing biweekly meeting with Dieter.
Award the Linux and RAT teams for the CVE onslaught - deliberately sequenced: Greg thanks them publicly, Peter praises them at the Wednesday on-site, award announced then; Greg disowns Ginux-as-replacement
Greg asked whether Peter had reservations about an award for everyone on the Linux and RAT teams dealing with the CVE onslaught. Peter said none and asked for it to be intentional: Greg posts publicly and thanks them (as agreed earlier), Peter praises them in person Wednesday at the Reno on-site, and the award is announced at that point. In the same thread he asked Greg to tell Arthur Tyde that Ginux is not the solution and does not compete with the RLC kernel, because the joke fed the team concern that Greg sees Ginux as a replacement. Greg then publicly called Ginux a research project that will never compete with Linux.
Customer-specific asks go through Work Ingestion and RAT build/validation - no side channels, even under deal pressure
On 10/23 two escalations from Justin hit the same rule. Toss (Viva Republica) AWS private offers, tied to a $2.4M TCV deal with a frustrated customer: Peter joined the channel to ensure the ask goes through regular Work Ingestion - in Jira, with Product visibility, balanced against other work - and aligned with Bjorn that it goes on the product priority list. OCI HPC base image being built outside the normal path: if CIQ will stand behind it, it must come through the main RAT org, which runs the consistent build and validation process; same message in #team-asia-pacific.
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.
Sensitive Decision
Cover the OpenELA TSC seat gap personally with Nathan and Leigh, and put Tim Pepper on the RESF relationship question
Sarah Almaraz relayed Arthur Tyde concern in #ea-team that CIQ holds two OpenELA TSC seats assigned to Nathan Blackham and Damen Knight, neither had been participating, and SUSE and Oracle were showing up consistently while CIQ as a founding member was not represented. Arthur asked for three things before the Sept 10 call: confirm Nathan and Damen or name replacements, get a PR submitted for OpenELA issue 36 with confirmed prod access, and name one CIQ engineer to own the import queue. Peter answered with the attendance roster - Myself, Nathan, and Leigh. Separately in the window he told Nathan he has Tim Pepper on as a contractor to look at CIQ relationship with the RESF and how CIQ grows community there, described the role as an OSPO advisor sort of guy here on a contract, asked Nathan for pointers to docs on unifying build infrastructure, and told Nathan to talk to Tim about the structure of his team, how he interfaces with the RESF, and how he wants to evolve that interface. Peter also forwarded Arthur OpenELA TSC threads to Tim Pepper directly.
Put the NVIDIA Spark bootable-Rocky USB on Justins org - and size it to carry meeting materials
On 9/2 Arthur Tyde asked whether CIQ could produce a Rocky-on-NVIDIA-Spark artifact for events. Peter confirmed the current Spark version of Rocky already is a bootable USB stick and called it super doable, then named the constraints and the owner. Constraint one: the image he holds is old, the current one sits with someone who is out, and he expects to have it in a couple of weeks. Constraint two: it only runs on an NVIDIA Spark - a Mac or other target would need different packaging and drivers, which is a separate ask. He then allocated the work outright: Justins org can build something. He also specified the form factor rather than leaving it open - small ones are fine, like a 128 gig would allow us to include additional meeting materials - turning a bare boot stick into a carrier for collateral.
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.
Make the LG meeting 100 percent about understanding their problem - no selling, no refusing - and pull Justin in for that purpose only
After a Jul 30 pre-brief in which the sales team delivered what Peter called a giant mea culpa - we are sorry we have been pitching solutions that do not work, but we still want to do something for LG, and we have realised we do not understand LGs problem - Peter set the shape of the next meeting explicitly in his Justin 1:1. I want to make that meeting 100 percent about understanding their problem. Not telling them, no, we will not do this. Not telling them, no, we cannot. Just lets understand their problem. And then you and I will come back and we will write down what we think is a good thing for CIQ to do in response to that. One option might be walk away. One option might be, I do not know what. He was equally explicit about what the invitation was not: the signup is not, hey, Justin, look what you get to build. Step one is we are going to go chat, learn. He also drew the line he will hold once a response exists: I am going to stand on, if we provide it, we are giving some surety that it is supportable and that it will work. And even if we shake your hands on you are not going to come back and complain at us, we know you are going to. So I want to make sure we are staffed for that. He distinguished that from not blocking them - well, we are not going to stop you, and that is different from we are going to provide it. He admitted openly that he cannot currently explain what LG actually wants: they seem to want a repo that does not point at anything, and I do not understand why they would want it or what problem they think it is solving.
Kill the reuse justification - the LG solution does not get to be reused for other customers
In the multi-party LG group DM with Bjorn, Arthur Tyde, Ally Cho, Tommy Ho Sung Yi and Justin Haynes, Peter closed off the argument that building the LG package-layering solution would pay for itself across the customer base. His construction: either every customer would need different testing, or CIQ would be handing customers packages it had done zero testing on. He named the second branch as not good business, and restated the conclusion in plain form - that is another way of saying the solution for LG does not get to get reused for other customers.
Willing to pull C3 into engineering, gated on Product confirming it is a priority
In his 1:1 with Art Tyde, Peter said he is willing to pull C3 into his engineering org, conditional on Product (Bjorn) actually confirming it is a priority. C3 ownership is currently ambiguous (Peter was told Greg owns it, which he called a terrible answer, and nobody under Peter owns it), it is degraded (reported ~50 percent down, Fathom-approximate), and it is blocking a Huawei evaluation. Peter made a note to figure out who is responsible for keeping it up and how to fix that.
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.
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.
Related Patterns (19)
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.
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.
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.
Name It Without Staffing It
Applies when a structural change is directionally clear but the specific person, budget or reporting line is not settled. Peter names the structure - the role, the reorg, the governance reform, the ladder - and deliberately does not attach a name, a req or a commitment to it. The 2026-05-21 observation states the economics plainly: cost of naming is near-zero, cost of premature commitment is high, and he consistently chooses naming. The 2026-08-24 observation adds the sequencing reason: once a specific person is attached to a framework, the framework stops being the subject. Mined from 6 independent observations between 2026-01-12 and 2026-08-24.
Different Diagnosis, Different Remedy
Applies when a directive or a problem spans several people or cases that superficially look alike. Peter refuses a uniform answer and sorts by diagnosis first, then applies the remedy that diagnosis calls for. The 2026-08-28 observation states the consequence for recording his decisions: when he gives a directive spanning several cases, the decision is almost never any single remedy - it is the rule that produces DIFFERENT remedies, and four cases with four different answers under one rule means the rule is the decision. The 2026-04-17 observation confirms he holds this as an explicit framework rather than an instinct. Related to Three-Lever Talent Management but distinct: that pattern runs hire, develop and exit in parallel, this one is about diagnosis determining which lever a given case gets. Mined from 6 independent observations between 2026-02-03 and 2026-08-28.
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.