Steve Wallace
Dec 19, 2025 - Sep 7, 2026
75
Decisions
0
Active Todos
16
Patterns
Decisions (75)
Collapse nineteen engineering titles into four groups - and put senior principal back only if a manager makes the morale case
In the Nathan 1:1 Peter walked the leveling sheet and set the target explicitly: nineteen distinct titles across sixty people becomes four titling groups. He opened by declining the framing Nathan offered - this is not about correcting overinflated titles, it is about simplifying titling - and said his religion is the simplification, not any specific person. He asked Nathan to validate the mappings for his own people and to build planned promotions into the exercise rather than run them separately. On the senior principal tier, which the collapse removes, he did not decide unilaterally: he asked Nathan to probe Andrew Jorgensen and Jamie Maple on how much they actually care, and said if Nathan argues that senior principals are needed to manage morale on his team, Peter can get his head around engineer plus senior engineer and principal plus senior principal. He also told Wallace the same day that the leveling has cleared Greg and Mariah and that he will sit down per-org to make a plan, committing to Wallace next week after slipping the intent to do it this week.
An ambiguous interview verdict is a no - hold the bar rather than adding interviewers
Steve Wallace reported on the security engineer req that he had interviewed Jared, a contact of Greg, and had told Brianne and Greg that he was not a yes but not a no. Wallace proposed pushing the candidate on to CeeLo or TJ to gather more input. Peter closed it on the spot: not a clear yes and not a clear no means no, leave it as a no. He framed the rule rather than the case - he would rather hold a high bar, and if a candidate is not a giant yes, move on.
Extend Karl Lowenbjer under Wallace and land Atlas and Motherbrain in Engineering
After spending the prior week reading the Motherbrain and Atlas code Karl Lowenbjer built under Tabatha, Peter concluded it was quite good - really well architected and thought through. Chris Baek did not want to keep Karl on the Operations side. In the Thursday 1:1 Peter pitched Wallace directly on taking both the contractor and the applications, telling him he is pretty sure Wallace ends up being the one asked to maintain things like Motherbrain and Atlas anyway. Wallace agreed the same call, having independently run a compliance and security read of the code and landed in the same place. On Saturday Peter DMed Karl himself, told him his contract ends in about a week and a half, and asked whether he wanted to let it end or extend it under Peter - then asked Sarah for 30 minutes with Karl on Tuesday or Wednesday to work it out.
Sensitive Decision
Deliver the AI-spend message myself at an engineering all-hands instead of letting the AI committee write a policy
In the 2026-08-27 Ryan Smith 1:1, Ryan argued that the next AI committee meeting should produce a company-wide best practice on AI spend - consensus around spend, do not use Fable for everything, be self-aware of usage. Peter declined the policy framing but conceded the underlying point: the conversation has to happen and has to be delivered directly to engineering rather than routed through a committee or left to individual managers. He committed to an engineering all-hands the following week and flagged it verbally for capture in the moment. He scoped it explicitly to engineering, excluding Ryan own organization.
Sensitive Decision
Diagnose every AI overage case individually and apply the remedy that case calls for - without squashing AI usage
Facing an AI token run rate heading toward roughly 3 million dollars a year, with the top ten spenders accounting for about 95 percent of it, Peter refused both a spend cap and a single blanket fix. He directed each manager to work out why the overage is occurring for their own people, case by case, and to do whatever is appropriate for that specific cause - with the standing constraint that the answer must never be to suppress AI usage. He gave different answers for the cases he had already looked at himself: one engineer at roughly 60k a month is justified and was told to keep going; two others at roughly 100k a month between them are low-return and their manager was already digging in; Zorina team burned 12k in August purely because they were hitting the Claude API directly rather than the enterprise plan, so Justin Haynes action is a plan switch. Peter also declined Ryan Smith push to have the AI committee issue a company-wide best-practice policy on spend.
Govern AI spend by notification and trust rather than a cap - alert at a thousand over, and if the person knows what they are doing get out of their way
Peter met with Steve Wallace and Scott Moody on AI and cloud costs Aug 24 at 11am, then recounted the outcome to Ryan and Bjorn an hour later. What he asked for is visibility plus a Slack notification when someone goes a thousand dollars over their limit, followed by a second one. The rule attached to the notification is not a stop - it is: if you do not know you are doing that, stop what you are doing and figure it out, and if you do know what you are doing and it is right and you are a smart person and it is right, I do not want to get in your way. He explicitly declined a single best-practice standard, differentiating by workload: Sultan costs are fine because he is dealing with a CVE swarm and the right behaviour is solve it as fast as you possibly can, whereas Jason Rodriguez spinning up 13 Opus or Fable agents makes no sense - but Peter attributed that to missing visibility rather than to judgment. He named his own next step as a person-by-person conversation with each leader over what he can now see. Separately on cloud costs he closed the question rather than opening it: the split is 100 percent Fuzzball, and he told Bjorn and Ryan they just need to get used to that being the new normal, while committing to sit with Wolford to slice it up.
Move the metrics conversation with Nathan off the tooling and onto the why - which metrics, which were discarded, and how the team is told the reason
Peter closed the Nathan 1:1 by resetting what he wants from the metrics workstream. He stood it on the foundation that if you do not measure it, it does not change. He then said Max document was a fine first cut and he does not know whether Nathan wants to use it, but that is not the conversation - it is not about what Butler shows. Butler is just building a tool and it will not show me the whys, and it is the whys I want to talk about. He named the specific agenda for the next 1:1: why this metric, why this metric, which metrics you have discarded, and how you are communicating them to your team so they understand why you are tracking certain things. He connected it to his standing complaint that he is not seeing the change in pace he wants and that pounding that drum gets him nowhere - he wants to engage in the concrete bits of what Nathan is holding people to and why, acknowledging that Nathan knows how his own org will respond to a given metric better than Peter does. Nathan took it further himself, saying he should start adding the why to the dashboard, and Peter agreed with a second reason: it keeps people from making an incorrect assumption about why you care and gaming it through misinterpretation rather than intent.
Restate every RESF request as a request to CIQ rather than to Nathan - publish the secure-boot ask to all of Linux Engineering so someone else can raise a hand
Nathan reported that Dieter had asked him explicitly to help with a secure boot POC, and that he would demo it to Sharif, Scott and Dieter on Monday, building it on CIQ hardware because CIQ needs it too. Peter approved the substance and re-cut the framing: let me tweak things ever so slightly to the RESF has asked CIQ to do this, not Nathan. It may be Nathan who is doing it, but the ask should be published in Slack to all of Linux Engineering - the RESF has asked for help with secure boot, I know secure boot, so I am sitting down with them Monday, and if anybody else is interested in understanding how this works or how they can plug into that world, here is the opening. Peter said chances are it is nobody and everyone just pats Nathan on the back, but he wants to buy the chance that one person wakes up and goes that is interesting. He tied it to the wider problem: the RESF needs to stop being five or six people who think it is their clubhouse, and Nathan should be willing to say this contributor should get a structure and a title inside the RESF. In the Steve Wallace 1:1 the same day he committed to pressing Dieter on the same point next week - nobody at the RESF is asking CIQ for things directly, and both Nathan and Steve orgs have resources available.
Sensitive Decision
The five-week leader presentations are baseline once, then deltas forever - show me what you changed to move the number, not the same dashboard
Closing the Engineering Weekly Sync on 2026-08-18, Peter defined what the recurring per-report presentations are for now that nearly every direct report has completed one iteration. He said he is deliberately giving little feedback on the first round because its only job is to set a baseline for each team. From the second round on he wants the conversation to be about what changes the leader is making to drive improvement in the metrics they report, what they are changing when those changes do not produce the expected movement, and whether the metrics themselves should still be the metrics. He explicitly said he does not expect the org to be tracking the same metrics a year from now and that this is fine.
Value delivering things over doing work - ship three items all the way out the door and nothing elsewhere, rather than move nineteen forward
Closing the Aug 18 Engineering Weekly Sync, Peter gave the whole engineering leadership group a standing priority instruction: I really want everybody here to value delivering things over doing work. He put it concretely - I would much rather see you do fewer things all the way to completion and get stuff shipped to customers than be reporting status of, look, I am moving the ball forward on 19 different items. And not across the finish line on any of them, but forward on 19 items. I would way rather see us ship three items and do nothing anywhere else. He grounded it in the prior half: we delivered just enough in a bunch of areas to squeak across the finish line. And we built up a bunch of tech debt. He then closed the obvious loophole - I do not want to do less just to do less - and converted the instruction into standing permission to re-allocate: if pulling people off one project and putting them on another is going to allow us to get that second one out the door, let us have a conversation and advocate for that, make that change. The engineering order of operations is the named venue for making that argument.
Refuse to act on the AI spend number until it is decomposed - one-time hardware out, recurring API in - then treat the remainder as usage discipline rather than a spend cap
Steve Wallace raised rising AI costs at the end of the Aug 18 Engineering Weekly Sync. Peter did not accept the number as presented. He said the AI costs finance is counting include one-time purchases like the giant chassis just bought from NVIDIA for the 200s, and: I do not want to get hung up on one-time costs. I care way more about the recurring cloud costs and making sure people are being smart there. He set a meeting with finance for Thursday in LA to decompose it, and named what the response will be once the number is clean: model-tier discipline (teaching people not to do every single thing with Fable and Opus - Sonnet is still there for a reason and still really good at some things), possibly monthly per-person budgets, and a quality bar on AI-assisted work. Nathan raised that copy-pasting a prompt in and the answer out adds no value; Peter closed it with: we should be holding each other accountable and not accepting work at that bar.
Sensitive Decision
Require every five-week org review to show the delta against the prior review and what was done to move it - not a fresh static report
Peter gave Nathan and Steve the same instruction on Aug 13. The first round of five-week presentations is a level-set; from the second round onward he does not want to see the same presentation again. Each leader picks their own metrics - Max supplied a candidate list but Peter explicitly allowed rejecting any of them - and then must show how those numbers changed since the last review, what they did to change them, which metrics they dropped, which are new, and why. He named the intended side effect directly: so that you are feeling some pressure during the intervening five weeks to know that I am going to have to report against these metrics, what am I doing. Nathan is standing the metrics up as a self-service dashboard app rather than a slide, so the org can see them without him.
Refuse to start the incident-response conversation from the premise that an on-call system is needed - require an SLA first, and put accepting overnight downtime on the table as a real option
Ryan brought Peter a plan: after the Portal outage he had asked Justin and Nathan whether engineering had an on-call rotation, got a no, and wanted to build one at the Tuesday Aug 18 meeting. Peter agreed to the meeting, added Chris Wolford to the invite, and then inverted the agenda. His first question would be do we need this - not dismissively, but because he wanted both branches evaluated: accept that some systems are down overnight and publish a status page the way Apple does, or commit to short SLAs and staff an on-call rotation to meet them. He named the decision rule: define the SLA for each class of thing first, and if any SLA is under 12 hours, that implies on-call; if none is, it does not.
Take the engineering re-leveling from principle to a concrete ladder - 13 levels down to 4 (open to a 5th), leadership down to Director and VP - and commit that no mapping ships without the direct report in the room
Across three 1:1s on Aug 13 (Nathan, Steve, Ryan) Peter walked each direct report through a spreadsheet he had shown nobody, collapsing roughly 13 engineering levels into Engineer / Senior / Principal / Distinguished, and collapsing his own leadership layer from directors, senior directors and head-of titles down to Director and VP. Nathan argued for a fifth level (Staff) to separate Jeremy from Sultan; Peter took it as reasonable without committing. Ryan was placed in the VP bucket and told so directly. Peter named two hard constraints: nobody gets a pay cut, and existing option grants cannot legally be reduced. Timeline given to Ryan: weeks, not months. Sequence: get Mariah bought into the framework first, then walk each org through its own mapping.
Institute the inspectable-function rule for AI data access as company-wide hygiene - and refuse to make it either a shared library or retroactive
At the Friday AI Committee, Peter re-delivered the rule he had set once before and watched not land. He used Mini-Me as the worked example: AI helped create the capability, but AI is not part of the runtime function of accessing the repositories. Claude cannot get to Slack except through that function. It does not have the keys. He asked for exactly one thing - if you are pulling data in or out of a CIQ system, do it through a function that you write and could inspect - and explicitly declined two obvious extensions. He would not make it a shared implementation, because there is no value in building a library of these things and because forcing an MCP server would block people from experimenting with technology being stood up today. He would not apply it retroactively, because a year from now we are going to have 100 times as many tools running around the company, so he is way more worried about the giant tsunami of stuff that is coming. He named three reasons rather than one: inspectability, 100 percent repeatability, and teaching the company the right pattern, since Claude is going to make everybody at the company a developer and that is incredibly terrifying if we do not teach people to be better developers. He extended the bar to local models when asked, and licensed Michelle to publish the message with his name attached.
The engineering re-leveling lands as a conversation with each direct report, not a directive - and Wallaces org is over-titled but not over-paid
Peter settled how the engineering leveling and compensation review will be delivered. The artifact is a spreadsheet comparing each orgs leveling and compensation against all of engineering, and he will walk it through individually with each direct report next week. He pre-emptively stripped it of authority in both 1:1s where it came up. To Ryan: it is going to be the spreadsheet I am putting together is the beginning of a conversation with each of my direct reports to say, here is how your org is structured from a leveling perspective, here is how all of engineering is structured, here is how your org is compensated, here is how all of engineering is compensated. I am not going to shove it down your throat. To Steve, twice: it is not something I am going to force down your throat or anybody else throat, it is the beginning of a conversation, that is all it is - and I will get it in front of you sometime next week, but it is for a conversation, not for this is what I am doing to your team exercise. He also delivered the specific diagnosis for Wallaces org directly to Steve: your team has titles that are far above the rest of the organization, so there is going to be some leveling reset that ends up impacting your team - but from a comp perspective your team is not overly compensated, in fact they may be low in some places, so I think you are going to have a fine story to tell. To Ryan he was blunter about the same finding: the number of directors we have across Wallaces org is just stupid, and it does not fit what I am doing everywhere else in engineering. He deliberately left the remedy open - we could change it by making more people VPs, we could strip away VP titles, we could do a lot of different things to level it - and named Mariah as involved with probably Bjorn a bit. He deferred the Steve walkthrough to Monday because he was slammed both days.
The 1:1 tracking spreadsheet becomes Nathans choice - suggest, do not mandate - but whatever replaces it must be measurable and must never go to HR
Nathan asked whether Peter still wants his direct reports using the individual 1:1 tracking spreadsheets, noting he is not leveraging them much right now. Peter released the mechanism and held the outcome: Look, I find them useful. I am confident at this point that I have spent enough time going over them with you. I am happy transitioning more to you decide if they are useful. My answer is I suggest yes, but I do not mandate yes. And if you have a better way, that is super fine. Two constraints attached. First, if Nathan builds a different method, that method is what he presents at the Tuesday engineering sessions - this is how I am managing my team - with Wolfords different approach as the contrast case. Second, the hard requirement: I just want to make sure there is something there that is measurable, that is driving conversations about whether people are doing what you want, and that there is some sort of a record produced as part of it that does not go to HR so that it is open and honest and unpolluted. Peter also said he will keep pulling them out from time to time and is moving his own cadence with Nathan from monthly to roughly quarterly. He gave Steve Wallace the same latitude the same day: what I care is that there is something documented between you and employees that you can point to, whether it is the spreadsheets or not is not the important point for me.
Deliver the code-driven-not-agent-driven rule personally at Fridays AI committee as a single top-down message, because the first attempt did not land
Ryan told Peter that data governance is a full-time job and needs a headcount, and that adoption will not happen until the mandate comes from the top: I think that is as simple as you coming to an AI committee meeting and make it a mandate. This stuff does not get fixed until it comes from the top. Peter agreed and committed to attend the Friday 1pm session. He named the exact message: I am betting that dashboard was agent-driven, not code-driven. I want us using AI to write code, but what data can get pulled into that dashboard is hard-coded in that function. The agent cannot just wake up on a Tuesday and do something different and pull some columns that we were not expecting it to pull. That is the single message I am going to deliver tomorrow. Because if we do that, now everything is inspectable and we can have clarity on exactly what data is going where. He explicitly acknowledged the rule already exists and did not stick: a few general rules that we all need to adhere to as we are pulling data in and out of systems, I am happy sitting down at this point and making that clear to the AI subcommittee. And I thought I had. But we will come back and redo it. Because the kind of thing that happened with Atlas should not be able to happen.
Purchase approvals below a managers own threshold must never route to the CTO - told Nathan to expense it anyway and took the fight to Finance rather than the person executing the policy
Nathan bought a roughly 100 dollar remote KVM for the NVIDIA DGX Spark so other engineers could access it, after asking Peter first and being told yes. Erin Fong flagged that company-funded equipment must be tracked through an IT ticket before purchase; Nathan said it was not worth the hassle and would pay out of pocket. Peter intervened in three places. In DM to Nathan: No. Tell them No and that the CTO said it was fine. I do not want stuff like this to continue - and, repeatedly, But I already just said you can just expense these things. In the group DM he took the diplomatic line publicly - Nathan asked me prior to purchasing if it was ok. I said yes. Did not know this policy existed. If a ticket can be created rapidly in a way that does not burden Nathan, great - and Stephen Moody opened IT-6605 to document the approval. Then he located the real owner: he asked Steve Wallace whether the policy came from him (it did not, it came from Finance via Erin), and stated the fight he intends to pick: you have a threshold you can approve up to, Nathan has a threshold, I have a threshold. If it is below your threshold and you approved it, I do not want it routing to me. I do not want to know about it. I do not want to think about it. I never want to see it. Separately he coached Nathan on target selection: ask yourself whether you are solving this for yourself, for CIQ, or trying to make Erin recognize the policy is stupid - Erin works for us a couple hours a week and her job is to click buttons on the policy, she does not own it, so there is nothing you can say that will change it.
Every org owes its own delivery-performance metric system, and Wolfords dashboard is the deliberate exemplar - used to train the Linux side of the house
Peter restructured the 7/28 Engineering Weekly into a fast breadth-first TPS pass followed by a single-org deep dive, and made Wolford go first on purpose. After Wolford walked through his PIC tooling - PR review latency, time-to-merge, bug-vs-feature ratio, commit distribution, release cadence, internal and external documentation coverage, plus a per-quarter epic assignment board - Peter named the ask explicitly: I dont care whether there is a dashboard or just a system that reports a set of metrics, but this is the kind of thing I am going to be looking for from every org. It is not an accident that Wolfords going first here. He then propagated the exemplar three ways: forwarded the Fathom recap to Bjorn saying he was using it to help train the Linux side of the house, told Nathan to watch the recording because there are critical things in there that will impact your teams and that I want to be able to talk through in terms of team management, and told Wolford directly that the presentation was exactly what I wanted/needed to kick that all off - while warning him you will not be impressed when Linux and the other portions of eng deliver theirs. Sarah set the rotation: Wolford, then Nathan, then Steve, Ryan and Justin.
Approve a single-seat ChatGPT CVE-model trial for Sultan, narrowing Steves small-group ask to one named person
In the 7/23 Steve Wallace 1:1 Steve relayed Sultans request to trial a ChatGPT model he believes will help with CVEs and may outperform Anthropics tooling against them. Steve recommended approval on a small basis and flagged the exposure himself - AI spend is running 60 to 80 thousand a month, and opening the floodgates likely means people run tools in parallel rather than switching, compounding cost. Peter narrowed the grant to exactly one seat: I am happy to have one person test it out, I would not open it up to the entire company, giving it to Sultan is fine, totally fine. Moody will handle the program application and setup.
Clear Greg to proceed on the open-source AI-training-data initiative with no CTO gate
On the morning of 7/24 Greg told Peter by DM that the conference had reinforced for him that an open source source of AI training data is one of the most important things needed right now and that he has to hurry. Peter cleared him within about 24 seconds and made a point of saying the analysis was already done: get on it, I have been thinking about it and I do not have any concerns. Greg replied On it. Peter attached no metrics, no owner, and no scoping ask - he cleared a lane rather than taking the work.
Block the AI-cost workstream on complete per-individual measurement before any optimization - so each persons correct plan can be determined
In the 7/23 Steve Wallace 1:1 Steve reported several threads coming out of Mondays AI meeting: efficiency coaching for heavy users, model-switching guidance, and usage reporting to department heads. Peter cut across all of it and set a sequencing requirement - first get a dashboard that shows every individual in the company, including himself. His evidence was his own absence from it: he shows as zero on every cost dashboard despite Claude running 8 to 10 hours a day, with CIQ apparently paying around 200 dollars a month for him. He rejected the manager-level rollup as a starting point and rejected pushing justification down to department heads. All of the costs, not just some of them.
Sensitive Decision
Sensitive Decision
Institute a rotating per-team deep dive at the Tuesday staff meeting, anchored on empirically measurable metrics co-designed in the room
Peter gave the same instruction independently to Chris Wolford and Steve Wallace on 7/23. Each org lead will take roughly 45 minutes of the Tuesday staff meeting on a five-week rotation. Three parts: a functional overview or demo of what the team delivered in the last month and is working on next; a project-plan view with milestones, tracking, who is on what, and how team time is being spent; and a set of empirically measurable metrics. The metrics do not have to be right the first time - the explicit purpose of doing it in front of peers is to argue out which metrics are the correct ones for each org. Metrics differ by domain: on the Linux side Peter wants automation measures such as the percentage of PRs auto-approved by Nerf versus human-approved; on PIC Chris proposed PR volume and the rate at which releases require bug fixes over time. Chris Wolford presents first, Tuesday.
Pause the AI Data Management policy approval and route it to Greg
Steve Wallace asked for Peter Google-Doc approval on the AI Data Management Policy (an effective-date fix). Rather than approve it, Peter flagged that Greg is now exploring training open-source models and said the whole approach may need to be revisited, telling Steve to get the doc in front of Greg to ask what he wants to do. Peter declined to ratify a policy that an in-flight strategic pivot could immediately obsolete.
Sensitive Decision
Mandate Snyk vulnerability-remediation SLA compliance across all engineering teams
In his 1:1 with Steve Wallace, Peter committed to mandate Snyk vulnerability-remediation SLA compliance across all engineering teams, not just Steves. Snyk SLAs are being breached, putting the fall ISO 27001 audit (broader scope than SOC 2) at risk, and the breaches span other teams repos including the PIC team and Ryans customer-service app. Steve will draft a high-level doc of the required compliance behavior, and Peter will push it out across engineering with CTO authority behind it. The mandate is decided; issuance is pending Steves doc.
Rippling Jira Asset Mgmt add-on approved — 12mo commit + cancellation push
In a 5/29 Slack DM with Steve Wallace, Peter approved the Rippling Jira Asset Management add-on under negotiated terms. Rippling proposed a 19-month commit co-termed with the main Rippling agreement (~$21.9k total: $6,420 upfront after 2 free months due 8/21, then annual billing at $12/user/month for 107 users, includes monitoring/maintenance). Peter pushed back on lock-in, accepted one year, asked about cancellation terms. Steve replied he would offer 12-month commit with cancellation for convenience at month 11+ with 30 days notice. Peter said works for me. Decision is contingent on Steve actually securing the cancellation clause.
Sensitive Decision
Hire dedicated cloud-security engineer — Steve drafts JD, Peter champions, dovetail with Nathan STIG/FIPS gap
In Steve 1:1 5/21, TJ flagged CIQ is doing the bare minimum on infrastructure security across 4-5 clouds. Peter asked Steve to have TJ (or Steve) draft a quickie JD describing what the role does and is responsible for — explicitly NOT urgent, but needed as a champion artifact so Peter can take it to Bjorn/Greg with a concrete ask. Steve flagged that the same hire could dovetail with Nathans STIG/FIPS expertise need on the technical side; Peter agreed ("Awesome"). QBR 5/22 made it official as a Steve-owned area requiring formal assessment and potentially a new headcount.
Reward Yesh for responsible disclosure — CIQ first-ever bug bounty
When Yesh (pentestine@gmail.com) reported a ciq.com vulnerability on 5/21 via email, Peter responded within minutes to Steve Wallace and Bjorn: I would like us to reward here to encourage this behavior. He immediately forwarded the bug detail to Justin Haynes for the fix and aligned with Steve on severity. The reward is still pending execution as of 5/26 — this is the first bug bounty CIQ has ever paid.
Hardware lab: paint the full picture and buy the whole complement upfront
When Nathan proposed buying one server per quarter to build out the engineering hardware lab, Peter pushed back: do it backwards. Define what we want the lab to be, then buy the full complement, not slice by quarter. Only chunk it if there is a real reason (cooling, ops bandwidth) — not for budget reasons. Tied to: NVIDIA H100/GB300/B200, AMD parity, and figuring out where to put it (Reno closet vs Texas DC).
Sherif RESF hardware: Wallace owns directly — escalation triggered by Greg
When Greg pinged Peter in #distinguished-leaders saying the RESF (Sherif) had been waiting on systems and Sherif had been emailing Moody for weeks, Peter took the heat publicly ("I do not need thanking. This is a disaster.") and re-assigned ownership directly to Steve Wallace. Steve had it on Moodys plate and it slipped while Moody was out for a bereavement. Peter then DMed Steve to take ownership ASAP — Steve confirmed and committed to staying on top of it through the vendor build/ship.
Dedicated cloud security engineer role to be championed — dual-purpose JD covering cloud + STIG/FIPS
Committed in Steve 1:1 5/21 to champion a new dedicated cloud security engineer role. Steve will work with TJ to draft the JD; Peter will champion it to budget owners (Bjorn/Greg). Triggered by TJ flagging current cloud security as bare minimum and the proactive supply-chain projects (TJ on GitHub workflow SHA pinning, CeeLo on NPM package securing) needing a dedicated owner. Dual-purpose JD: also serves Nathans STIG/FIPS security expertise needs — one hire, two demand surfaces.
Rippling Asset Mgmt — time over cost; pay full $18k for end-of-June over $15k for December
The Rippling Asset Management integration project was de-scoped to ~$15k from ~$18k. Peter decided the full-scope original at $18k is acceptable IF Rippling can deliver by end of June. Steve will get the timeline from Kelly Wall to inform the final decision. Explicit framing: time over cost. The principle is conditional — if Rippling slips on the end-of-June timeline, the math changes and $15k-for-December may be the right call.
Moody Citibank card hard cutoff 6/15 — force-action via past-tense framing after 9 months of soft asks
After Kelly Wall described 9 months of soft asks to Steve Moody to switch from the personal-history Citibank card to the Ramp card (forcing manual finance journal entries every month), Peter directed Kelly to send Moody a notice that the card has been disabled and will stop working on June 15. CC Steve Wallace. Phrase it past-tense (has been disabled) plus future-fact (stops working 6/15) — not request language. Peter explicitly affirmed his prior gate (Kelly checks with him before shut-offs) while greenlighting this one because Kelly is giving a month notice — the notice IS the legitimacy gate.
Discretionary bounty offered for Yeshs vulnerability disclosure — case-by-case mode, no formal program
Yesh privately disclosed a vulnerability in ciq.com on 5/19. Peter forwarded to Greg/Bjorn asking if CIQ has paid bounties before. By 5/21 Peter emailed Steve+Bjorn endorsing reward: This is well done on his part, both technically and from a good-actor perspective. I would like us to reward here to encourage this behavior. Steve drafted a response: We do not currently operate a formal public bug bounty program, but would like to offer a discretionary reward for your efforts once validation is complete. Peter explicitly endorsed via DM (Yup!). Peter separately forwarded the disclosure to Justin to fix. Bjorn aligned on the wording earlier. Steve owns the response thread; Justin owns the fix; Bjorn owns sign-off; precedent-setting case for future disclosures.
Lab hardware acquisition shift — buy all 8-10 servers at once, Texas DC over Reno, NVIDIA+AMD outreach
Committed in Nathan 1:1 5/21 to a hardware acquisition strategy shift: buy all needed lab hardware at once (8-10 servers) instead of one-per-quarter. Cost is not the barrier; speed of development is. Reno office ruled out (1Gbps shared, no after-hours support, 5-6 server power/cooling cap). Texas DC preferred — to be re-evaluated against Reno after Nathan defines the full hardware list. Peter to email Scott at NVIDIA (H100/B200/B300) and discuss strategy with Steve directly. Nathan to email AMD for equivalent GPU hardware. Hardware sits inside the broader CI/CD acceleration goal — shift to Koji for automated signed kernel builds in a secure enclave to handle frequent builds and zero-day vulnerabilities. Hardware-acquisition shift is what unblocks the Koji shift.
Engineering QBR format — collaborative discussion with three topics, not a presentation
Peter directed that the 5/22 Engineering QBR will be a collaborative working session rather than a formal presentation, organized around three questions: what is working well, what needs improvement, and how to streamline communication and increase work visibility. Chris Baek owns the shared prep doc that will collect bullet-point inputs from engineering leads ahead of the session.
CVE response strategy — three-pillar overhaul (process + tooling + strategic kernel review)
In Engineering Weekly Sync, Peter operationalized the 5/11 Leadership Roundtable vuln-handling commitment into three concrete pillars: (1) Chris Baek to restructure the embargo/CVE comms doc with Jamie, separating process from tooling/templates; (2) tooling strategy — Peter commits to email Greg requesting Claude Opus 4.7 whitelist for CIQ accounts AND to set up unbridled internal LLM models on Fuzzball for vuln investigations; (3) schedule strategic kernel philosophy review for early June, with Nathan and Justin to provide a list of downstream automation efforts to prioritize.
Late-August dedicated security hire timing (6 months post-Jasons departure)
Aligned with Steve in 1:1 that a dedicated security resource hire is appropriate in late August — six months after Jasons departure. Options on the table: full-time hire, fractional resource, or expanding the Shin Brothers role. Steve currently at 70% capacity on ISO 42001 documentation; workload expected to normalize after this week, with SOC 2 and ISO 27001 audits expected to be lighter.
Moody accountability: step up to senior contributor or be managed — framed as response to his growth ask
Flagged Moodys recent missed deadlines and failure to track work to Steve in 1:1, with explicit framing: this is a direct response to Moodys stated desire to become a senior contributor, not a punitive measure. Expectation set: Moody must step up and handle responsibility independently, not require close management. Steve aligned. Moody is out May 15-20 — coaching window is now.
Mariah escalates Stephen Moody project delays directly to Peter (bypass Wallace)
Mariah will notify Peter immediately when Steve Moody delays HR-relevant project work. Triggered by a 6-week unresponsiveness pattern on the Rippling/JIRA integration that Steve Wallace had not escalated. Direct-escalation bypasses the manager (Wallace) for HR-adjacent commitments while Peter assesses whether this is a Moody problem or a Wallace prioritization problem.
Ship CIQ kernel patch with extra fix; contribute upstream; race to be first/best on CVE response
Linux kernel CVE response: CIQ shipping 10 fixes vs CentOS Stream's 9 (CIQ found and is fixing an extra issue related to the CVE). Extra commit submitted upstream to centos-stream and acknowledged for inclusion. CIQ pushing to be first EL distro to release, with primary goal of customer reassurance and secondary goal of public proof point that CIQ contributes to security and is large enough to serve big customers. Also pushing patches to RLC kernels as fallback in case RH doesn't move quickly.
Approved ISO 42001 AI User profile addendum (~$30k)
Approved adding the optional AI User profile to CIQs ISO 42001 certification for approximately $30k, aligning the audit cycle for both Provider and User profiles over the three-year certification period.
Delivered Jira Hygiene Mandate to Engineering
In Engineering Weekly Sync, mandated immediate improvement in Jira hygiene after presenting 3.5 months of data showing >50% of tickets updated after their due date (most slips 2-4 weeks). Prioritized communication over speed — proactive updates required, aggressive initial targets (20-30% confidence) acceptable. Directed Chris Baek to add a 'blocked reason' field to Jira for stakeholder visibility.
Delivered Jira Hygiene Mandate to Engineering
In Engineering Weekly Sync, mandated immediate improvement in Jira hygiene after presenting 3.5 months of data showing >50% of tickets updated after their due date (most slips 2-4 weeks). Prioritized communication over speed — proactive updates required, aggressive initial targets (20-30% confidence) acceptable. Directed Chris Baek to add a 'blocked reason' field to Jira for stakeholder visibility.
Committed to engineering date hygiene confrontation with directs
Peter publicly committed in Leadership Roundtable to holding a tough conversation with his directs about deliverable date hygiene. Requested date-slip magnitude data from Chris Baek (days vs weeks) to focus on significant delays rather than minor variance.
Sensitive Decision
AI Governance Single-Track Pivot for ISO 42001
Pivoted AI governance from dual-track (internal vs products) to single rigorous model because CIQ products (RLCAI, Fuzzball, Werewolf) now directly integrate AI, changing the liability profile.
RESF Monday Cutover — Finalized 3 PM PT Execution Plan
Finalized the RESF infrastructure cutover plan for Monday March 16 at 3 PM PT, including DNS NS record flip, AWS VPC firewalling, account disabling (Lewis, Neal), and security audit — accepting up to 24 hours of DNS-related downtime.
RESF Operational Security — Compartmentalize Until Board Action
Directed that Brian must not be told anything until after the RESF board notification. Emphasized extreme caution about leaks to Lewis. Approved Joseph being read into the initiative but warned about leak risk. Sequenced information flow: board action first, then notifications, then credential recovery.
Sensitive Decision
Team Building Mandate — 6-Month Priority Over Features
Directed all engineering managers to prioritize team building over feature delivery for the next six months. Includes permission to swap out low performers, with Peter providing air cover for the risks involved.
Directed RESF counter-narrative to Bjorn to prevent premature escalation
Directed Steve Wallace to email Bjorn (CC Peter) with evidence of positive RESF engagement through Mirror Manager project before Bjorn potentially takes aggressive action. Steve's team has made progress with Neil — environment access granted, Mirror Manager epic unblocked — while other teams report significant friction.
Delegated Jason Lewis termination coordination to Mariah for March 3
While preparing for Dubai trip, delegated coordination of Jason Lewis termination logistics to Mariah Rippee, asking her to work with Steve Wallace during the week Peter is out, targeting the first Monday of March (March 2).
Jason Lewis Termination - Ready to Action
Confirmed readiness to proceed with Jason Lewis termination now that the ISO 27001 certification letter has been received. Will coordinate with Steve Wallace and Mariah Rippee (HR) to execute. Jason recently requested a seat at the table for self-service discussions, unaware of the pending action.
Infrastructure Cost Savings Approval
Approved a $10K infrastructure savings proposal from Steve Wallace with the condition that it does not burden development work.
Clarified bonus evaluation framework - above and beyond for step-function impact
Clarified to Steve Wallace that bonuses are awarded for actions that are above and beyond standard role expectations and provide a step function for CIQ - not for standard job performance, which is covered by salary. Also confirmed TJ bonus (Greg approved Jan 23 via private DM) and committed to close the loop with Greg.
Approved transfer of Depot operations from Justin to Steve team
Approved transferring Depot operations from Justin team to Steve team as a test of Steve team SRE capabilities. Justin team will define the architecture for moving Depot to object storage, then hand off execution to Steve team who will own provisioning, infrastructure, and monitoring.
Require mandatory tagging of all fully AI-generated content
AI Committee established policy that all fully AI-generated content must be tagged to manage user expectations. Applies only to fully AI-generated content, not human-reviewed or AI-assisted work. Format and placement of tags is flexible.
Transfer Depot operations from Justin team to Steve team
Depot operations will transfer from Justin team to Steve team. Justin team will define the architecture for moving Depot to object storage, then hand off execution to Steve team for provisioning, infrastructure, and monitoring.
Jason Lewis layoff with Steve Wallace as compliance owner
Decided to proceed with Jason Lewis departure (structured as layoff) due to expectation misalignment and damaged relationship with Bjorn. Steve Wallace will assume all compliance responsibilities (ISO 27001, SOC 2, ISO 42001). Budget reserved for full-time replacement after 6-month layoff waiting period. Fractional hire and external auditor approved for interim.
Depot Management Transfer to SRE
Decided to transfer Depot management (monitoring, maintenance) from Justin org to Steve SRE team. Committed to connecting Steve and Justin to define the work distribution.
Jason Lewis Retention Review - Requested Written Impact Case
Paused final decision on Jason Lewis role and requested Steve write a formal case detailing the operational impact of Jason departure - specifically on ISO 27001/42001 certifications and CIQ Federal work.
Trinity Quirk & Chris Short Terminations Executed
Terminated Trinity Quirk for failing to progress NARF/CVE automation integration despite clear expectations. Terminated Chris Short for failing to deliver on critical RESF-related goals. Sent transparent communication to all of engineering explaining the WHY behind these decisions.
H1 Planning Strategy - Aggressive Goals with Staggered Milestones
Articulated H1 strategy: shift from hope to concrete plan with aggressive audacious goals. Achieve goals differently not just faster. Staggered milestones every 4-6 weeks for course correction. Missed milestones trigger retrospectives for process or personnel changes. Clear prioritization at Reno eliminating everything is P0 problem.
Championing AI Butler Adoption Internally
Shared detailed Slack MCP setup instructions with team members. Hosted/recorded AI Dashboard session demonstrating Butler setup. Personally using and advocating for meeting prep automation.
Championing AI Butler Internal Adoption
Hosted and recorded the AI Dashboard/Butler setup session to drive internal adoption of Claude-based personal productivity tools across CIQ. Shared personal use case of creating meeting prep notes from Slack/email/docs.
Related Patterns (16)
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.
Accountability Follow-Through
When you issue a warning or mandate with stated consequences, you follow through. Warnings are not threats - they are commitments. The credibility of future accountability depends on following through now.
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.
Three-Lever Talent Management
When pursuing a velocity or performance mandate, simultaneously operate on all three talent levers — upgrade (hire better), retain (protect key people), and exit (remove blockers) — rather than sequentially. This creates compounding momentum: exits free capacity for upgrades, retention preserves institutional knowledge during transitions, and upgrades raise the performance bar that justifies further exits.
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.
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.
Constrain the Mechanism, Not the Access
When AI or automation raises a governance concern, Peter does not restrict who or what may reach the data. He constrains HOW the reach happens, so the pathway becomes auditable and deterministic. The failure mode he designs against is non-determinism, not leakage - a wrong filter in inspectable static code is a bug you fix once, while a model that sometimes pulls the wrong field is an unbounded, unauditable liability. He will therefore accept imperfect filtering and eventual leakage as the price of adoption speed, but will not accept a non-inspectable pathway.