Chris Baek

Judge the Atlas code on its engineering merits alone - keep it, port it off the laptop, and stop building skills with direct data access

After a deep dive through the revops-motherbrain repo and a walkthrough with Karl Lowenbjer, Tabatha Wilmot and Chris Baek, Peter delivered a written verdict on 8/31. He opened by refusing the question he was not asked: I am making ZERO statements about whether what this code was written to do is something we need at CIQ - that is a discussion for others. On the code itself: keep the bulk of it. API, frontend, warehouse and agents are independently separable with no cross dependencies. Data access is SQL direct rather than through hallucination-prone skill paths, read-only is enforced at the right layers, the MCP server sits above those layers, test-to-code ratio is roughly 2:3 and the documentation has not drifted. Fixes named: pull the business logic out of the code into a human-readable rule set (he called it the most valuable part of the project), delete the dead Trust Anchor, remove a write token that should be read-only, de-duplicate the mql LLM screen defined in two codebases. The real problem is what runs on the contractor laptop - Claude skills against the claude.ai MCP connector with direct HubSpot write scope, running without asking permission, bypassing the pipeline-approval and closed-edit rules HubSpot enforces on humans. Verdict on the open PRs: approve the move to a consolidated server, do NOT proceed with the interim laptop-resident lead router, fix it properly instead. And a standing instruction: the process of building out skills with direct access to data should stop immediately. In the 8/31 sync with Bjorn and Chris Baek he also confirmed he could pick up and make good use of the code if the contractor who wrote it did not stay - separating the keep-the-code question from the keep-the-person question.

Sep 2

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.

Aug 28

Scope the Atlas review to how it works, not whether it is worth it - and restate the rule that Claude must call a script, never an MCP directly

In the Motherbrain / Atlas sync with Tabatha Wilmot, Karl Lowenbjer and Chris Baek, Peter set the terms of his own code review. He told them outright that he would not wade into whether Atlas is valuable - that is a Tabatha-and-sales question - and that what he wants to answer is how it works, how it is architected, how it stores and persists data, how it does security protections, what should run on a laptop versus centralized, and what the scheduler should be. He asked for the scripts and skills that still live only on Tabatha laptop to be pushed into the repo first so he can read both ends of the system, asked for half-sentence direct answers to Marlon open questions rather than more narrative, and committed to a four-to-five-hour deep dive by Saturday evening with a follow-up the middle of next week. When Tabatha described reps closing deals wrongly through the HubSpot MCP, Peter named the cause - Claude writing code at runtime against a system of record - and restated the standing rule that Claude should never call an MCP directly, it should call a script that structurally cannot do that.

Aug 28

Accept Bjorn conclusion on the Stratum name while refusing his reason - dont make a decision now that you dont have to make

Naming the new CIQ Kubernetes product. On Aug 23 in the executive group DM, Bjorn Hovland put up five candidates - CIQ Lattice, CIQ Stratum, CIQ Formation, CIQ Maestro, CIQ Marshal. Peter opened against the field with his own pick: my vote is Lattice, Marshal does not fit. Bjorn raised an SEO conflict, that an HR platform already owns Lattice, and Peter switched in one message - Stratum for the win, shrug. Chris Wolford independently backed Stratum and noted Lattice is also Quantum object storage system. Chris Baek started the trademark search. In the Aug 24 Kubernetes sync Bjorn laid out his actual reasoning - that over time he expects to combine the back ends into one and simply route a workload to Kubernetes or Fuzzball, but that is not the world today, so calling it the Fuzzball Kubernetes engine would muddy the waters too early and he needs to run keywords against Kubernetes as a discrete product. Peter agreed with the destination and rejected the route: he gets to the same place for totally different reasons, does not believe Bjorn story about the way the world ends up, and points out that if you do not believe it then you want the thing to have its own referenceable name anyway. Peter also asked that the final form match the naming convention used elsewhere.

Aug 24

Show the half-migrated TPS report to the whole leadership room even though it was not perfect

On the morning of the 7/28 Engineering Weekly, Peter asked in #department-heads-engineering for the repointed TPS report to be shown on that days call in its current state rather than held until it was clean - can you show the current state of the report briefly on todays call, even if not perfect. Ryan presented it in the meeting, flagged that there were 33 items and that the report pulled from the Engineering Deliverables board now diverged from the product-priorities view, and that segment is what opened the 17-minute re-ruling of both board purposes in front of the full room.

Run a Monday state-of-the-Linux storytelling session on pipeline, and have Baek carry the same rah-rah into the all-hands

Acting on a morale signal that surfaced in Gregs round of one-on-ones, Peter committed to sitting down with the Linux org on Monday to walk them through what he is seeing in the Middle East and with Google. He framed it explicitly as storytelling and cheerleader rah-rah about why he feels so bullish, not as a status update, and asked Chris Baek to sprinkle a little bit of the same into the upcoming company all-hands. He gave the diagnosis comparatively - the Linux org is meh on our future while Fuzzball is gangbusters and Ryans org is gangbusters, and there is no reason for Linux to be less positive about our future than everybody else - and bounded the response with it is not a risk right now. Sarah had already blocked Monday for the session.

The NGD board never bends to serve the TPS report - the report changes, and pulls from two data sources if it has to

In the 7/29 Baek 1:1, Baek surfaced the live consequence of repointing the TPS report at the Engineering Deliverables (NGD) board: most of Ryan Smiths work does not belong on NGD under the cross-functional-coordination definition, so Ryans work no longer appears in the report. Baek offered the ruling - under no circumstances should the NGD board change to accommodate it - and Peter took it, then extended it with the remedy: if the TPS report is not showing Ryans work, then the TPS report needs to change and maybe pull from two data sources or whatever, but the NGD board stays the same. Peter also named the recurring pattern he is fighting: almost daily somebody is using these boards for something different than what he said they were for.

Sensitive Decision

Sensitive

Google ELTS: pay or I stop the work - and CIQ eats the disputed 150k out of the existing discount to remove the excuse

In the 7/28 CIQ ELTS payment discussion with Google (Madhu, Alyssa, Arun, Katur and Kelly Hall), Peter went in deliberately hot and said so. Madhu was trying to hold Kelly to account for who made a technical decision back in February, with the implication that if CIQ made it Google would not pay for work since then. Peter refused the premise - these are technical decisions, they get made by the team, they get recorded by your people as the decisions of the consolidated team, and then we move forward - and then removed the money as an obstacle by offering to absorb it against an existing concession: I gave you a 250,000 dollar discount over here, so you are bitching about 150,000. I will shake your hand right now that that is on us. That 250,000 discount just turned into a 100,000 discount. With the excuse gone he put the actual question: are we getting paid or are we not getting paid, and if we are not getting paid I am taking my toys and going home. Madhus boss and others stopped the meeting and committed to closing it out by the next day. The call also ended abruptly, which Peter read as someone telling Madhu to stand down.

Re-ruled the two boards from first principles in the room - prioritization vs dates-and-confidence - and told the org to delete any column serving a third purpose

Seventeen minutes of the 7/28 Engineering Weekly went to re-landing the board doctrine after Ryan reported that Chris Baek had told him all work must move to the Engineering Deliverables (NGD) board. Peter said flatly he is wrong, then re-derived both boards from purpose. Product Priorities board: prioritization only - not work tracking, not delivery dates, not confidence numbers - and engineering continues to own the engineering-order-of-operations column that has existed for nine months. NGD board: only work that must be visible to the company because it is tied through value drivers to go-to-market, with exactly two required fields kept current in real time, a confidence number and an engineering target delivery date, and no statement about whether items are epics, stories or tasks. He also ruled that Wolford does not get to choose whether his work appears in NGD, that internal-quality-only work should not be on NGD at all, and that where duplicate order-of-operations columns exist the answer is derivable from purpose - if there are columns there to serve any other purpose, they are wrong, remove them.

Bring Ryan to SKO (Aug 19-21, LA) - make the ask on his behalf and let him choose his own duration

In the 7/23 Ryan 1:1 Peter learned nobody had asked Ryan about the sales kickoff. He decided support should be represented, said he would take it to Chris Baek himself, and explicitly refused to dictate how long Ryan should attend - I am going to turn it around, I am going to support whatever you want. He called Baek the same evening and confirmed back to Ryan an hour later that Baek was on board. Peter himself attends only Thursday the 20th.

Require all agent/LLM access to systems of record to go through inspectable static code, never direct LLM access

Peter opened the 7/24 Jira Automation call with Karl Lowenbjer by setting a condition before taking Karls agenda. The rule: no LLM gets direct access to a system of record. In every instance the LLM writes code that accesses the system, and that code is inspectable by a human or by another LLM. He stated he wants this true for everything Karls team builds, and that as long as it is true he is comfortable. He explicitly accepted that the filters themselves may be wrong - we might make a mistake in terms of what we pull in and out and that is fine, I do not mind mistakes - but the mechanism is non-negotiable. Karl confirmed Atlas already works this way. Peter then closed the topic without further discussion.

Slow-roll Googles request for kernel-build documentation until the contract is signed

On 7/23 Google asked CIQ for documentation on how it builds its kernels. Peter decided to slow-roll any response until after the contract is signed, and said so in both a group DM and directly to Justin Haynes - correct, at least until contract is signed, after that I am fine. He read the motive out loud: they are asking so they can build their own.

Narrow the NGD board to cross-company coordination only - not a deliverables tracker and not a complete decomposition of product acceptance criteria

In the 7/24 Brian Dawson / Brady Dibble sync Peter ruled against the working assumption that the NGD board is the comprehensive ordered list of engineering deliverables. His ruling: the boards only purpose is coordination across the company for things that drive value. It is not for tracking deliverables, not for holding engineering accountable to delivery dates, and does not need to be a complete decomposition of the acceptance criteria in a product ticket. Anything that should not link to a value driver is a component and belongs in Jira, which Peter will never look at. Engineering may blend several product-priority items into one NGD ticket or ship one top-level ticket, as long as the board forms a palette that overlays the product priority and engineering can say when these are done, this product priority is complete. Separately he fixed the product priorities list as strategic priorities full stop - no delivery dates, plus an engineering order-of-operations column and nothing more.

TPM charter + one-owner-per-release accountability mandate (problem/solution/owner grid)

In the TPM sync with Chris Baek, Peter locked an accountability framework: TPMs solve problems and coordinate but do not own engineering processes (engineering owns its own processes and its coordination with Product); every new process must be defined on a 3-column grid of Problem, Solution, and a single named Owner; and every release gets one clear accountable owner (one throat to choke) empowered to make the go/no-go call. The incomplete NGD board is the named blocker, with engineering managers (Nathan, Justin) accountable for completing it so it feeds dates and confidence into the Value Drivers Board bottom swim lane.

Jun 30

Repair the mis-framed Engineering All-Hands - hold a PIC/Fuzzball follow-up and proactively notify the slighted PIC team

After Jonathan Anderson and others read the recent State of Linux session as the Engineering All-Hands - leaving the PIC team feeling ignored - Peter diagnosed it as a framing/naming failure (Linux-only, Wolford not on it, no Fuzzball content) and directed the fix: a PIC/Fuzzball-focused follow-up session in the next few weeks, Baek to own the Fuzzball angle, and the PIC team to be told now that it is coming because yesterday was bad for them - they felt completely ignored.

Jun 18

Hold the margin line - willing to walk from bad-economics deals (currently applied to Rakuten)

In his 1:1 with Baek, Peter articulated a generalized stance and named its current target: stop playing the tell-the-customer-yes-to-anything game, and hold a hard line even if it means losing the deal. He will not spend 2M to capture 400K. He confirmed this is a generalized principle that at this moment absolutely applies to Rakuten as those negotiations finalize.

Jun 18

Value Drivers Board becomes source of truth for engineering dates and confidence; JPD dates become computed

In the 6/03 working session that Peter recorded (Peter + Nathan + Justin + Chris Baek, during the in-person engineering F2F), Peter locked the architecture that distinguishes the JPD from the Value Drivers Board. JPD stays purely for product strategy and prioritization (not work tracking). The Value Drivers Board is the Engineering-to-GTM coordination instrument that captures context (the why) and dependencies. The concrete decision: engineering target dates and confidence numbers live on the Value Drivers Board engineering lane as the source of truth, kept current on a tight cadence (always right on a Friday), and JPD dates and confidence become computed properties pulled from the Value Drivers Board rather than manually entered.

Jun 4

Take on Value Drivers Board restructure as the next coordination lever after JPD doctrine

In the 6/01 Leadership Roundtable, Peter committed to bring a formal proposal to restructure the Value Drivers Board, explicitly sequenced as the next move now that the product-priorities board (the JPD-doctrine work, closed 5/29) is aligned where he wanted it. Took the Fathom action item to draft the proposal and share with Chris Baek and the group within a couple of days. Triggered by Lindsay surfacing marketing/product misalignment (premature RLC+AMD announcement before AMD validation; Fuzzball multicloud date churn May 28 to June 4).

Jun 1

Sensitive Decision

Sensitive

JPD board scope locked to ordered priority list — Peter drew the line in writing to Nathan

In a long Slack DM thread on 5/27 (~25 Peter messages, 09:15–09:41 AM PDT), Peter rejected Nathan's draft framing for JPD scope and replaced it with an absolute definition: JPD is an ordered list of product's priorities used to drive company strategy, and nothing else. Not project planning, not marketing coordination, not a control surface for engineering order-of-operations. Tickets should be as large as possible and only split when product strategically cares about sub-priority. Value Drivers carry GTM linkage and dates. Every time someone tries to widen JPD scope, Nathan is instructed to push back. Reinforced same day in Baek 1:1 (Peter-recorded Fathom) and surfaces in the RLC cross-functional standup where Nathan is tasked with drafting the formal product-board structure proposal.

May 28

Engineering hiring forecast: 2-3 engineers every 6 months, Linux Security next, Bay Area preference

Peter committed to a 12-month engineering hiring cadence of 2-3 net new engineers every 6 months. Next 6 months: Linux Security Engineer (target hire 4-6 months out), plus potentially one more for Nathans team contingent on bug volume. Hiring location preference: Bay Area. Mariah updates the shared headcount/salary forecast spreadsheet to reflect this for Bjorn.

May 27

No bugs, only change requests — structural reframe for product/engineering interaction

Peter coached Brady (with Brian Dawson present) to eliminate the bug terminology in JPD/Jira entirely and replace it with change-request framing — borrowed from a CRM system Peter used at a smaller company earlier in his career, where the bug-tracking system had no bugs category type to eliminate the QA-vs-engineering-vs-product debate. Code works this way at this moment, I want to change it. Whether it's a bug or a new request — not material. Brady committed on the spot to roll out the change with Chris and Jamie and through Nathan's team. Brian aligned. Goal: remove the psychological/defensive trigger that makes prideful engineers slow to ship.

May 19

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.

May 13

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.

May 12

Commit engineering to vuln-handling infra/automation at Leadership Roundtable

At the 5/11 Leadership Roundtable, Peter accepted an explicit action item to prioritize vulnerability-response infrastructure and automation work in engineering, and to update Chris Baek as the interim process owner. The commitment converts the 5/8 internal-to-engineering commitment (build/test infra to eliminate reactive interrupts) into a cross-functional commitment with Bjorn, Greg, Chris, and Lindsay in the room.

May 12

Peter delivers Reno QBR C-suite intro Thursday — covering Bjorn late arrival

Peter will deliver the C-suite intro at Reno QBR Thursday morning, since Bjorn arrives Thursday afternoon. Peter arrives 8:45 AM Thursday. Greg travels to Houston with Adam for a 1 PM Thursday sales meeting.

May 5

Documentation process — Product defines exit criteria in Jira, Engineering delivers

Formalize documentation ownership: Product defines documentation requirements in Jira ticket exit criteria (e.g., docs suitable for blog post). Engineering delivers content meeting those criteria. Product or Marketing (Lindsay) refines technical content into user-friendly format.

May 4

Engineering veto required on custom deals and new lines of business

Peter is implementing a formal process where Engineering has review-and-veto authority on custom deals and new lines of business. Engineering must be consulted to assess cost and feasibility before any deal is finalized. Discussed in Peter <> Chris 5/1 and applied immediately to the Everfox proposal restructuring on 5/4.

May 4

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.

Apr 17

Delivered Jira Hygiene Mandate to Engineering

Apr 15

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.

Apr 14

Agreed to Uber Value Drivers Framework for Strategic Clarity

Agreed with Bjorn and Chris Baek to restructure value drivers into a two-tier system: 'Uber Value Drivers' (Theme/Epic level) that group related granular drivers. This resolves the tension between strategic clarity (too many granular items fail to communicate corporate strategy) and operational granularity (engineering/marketing need precise items to sync on).

Apr 11

Reinforced Product Owns Exit Criteria — Engineering Cannot Unilaterally Remove Requirements

Directed Brady and Brian that Product defines the 'what' and the 'when' while Engineering owns the 'how'. Engineering cannot unilaterally remove requirements from exit criteria. The correct response when a requirement is challenged is 'When can you deliver it?' not to debate or remove it. Forwarded the meeting recording to Bjorn and Chris Baek to align them on this prod/eng interface vision.

Apr 11

Reinforced Product Ownership of Exit Criteria

Engineering unilaterally removed the NVIDIA CUDA toolkit requirement from RLC Pro 9.6 LTS exit criteria, citing lack of automation. Peter clarified in the Brian/Brady sync that Product owns exit criteria and prioritization, Engineering owns the solution and date. When a requirement is challenged, Product asks When can you deliver it - not whether to include it.

Apr 10

Value Driver Consolidation from ~50 to ~3 Core Drivers

Peter demanded that the current list of ~50 'value drivers' be reduced to ~3 core, company-wide drivers that articulate CIQ's mission and differentiation. Called the current list a 'shotgun approach' and 'pile of stuff' that prevents focus. Test: if a product's value pillars cannot be tied to these core drivers, its strategic value to CIQ should be re-evaluated. Also requested a 1-year product vision for RLCAI/RLCH from Brian Dawson.

Apr 8

Set April Engineering Delivery Miss Target at 3-6 Items

Set a specific target of missing 3-6 items out of ~50 April engineering deliverables at Leadership Roundtable. The list contained mis-categorized items, granular sub-tasks, and placeholder dates. Follow-up: Chris Baek and Bjorn to prune the list tomorrow, engineering leads must update Jira with realistic dates by 9am.

Apr 7

RESF JIRA Date Reset for Realistic Expectations

Peter directed Nathan and Justin to adjust April/May JIRA items with low confidence due to RESF resource drain. Move them out now to give marketing a high-confidence scope for 4-6 weeks.

Apr 4

AI/Data Security Audit Commitment to Greg

When Greg raised concerns about CIQ leaking data through AI agents/bots/services, Peter committed to getting Michelle's oversight team to do an assessment/audit of what's running and with what access.

Apr 4

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.

Mar 13

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.

Mar 4

Directed March engineering priorities to come from Bjorn (Product)

When Chris Baek asked Peter to present engineering deliverables for March at the Leadership Roundtable, Peter redirected: the top priorities for March should come from Bjorn (Product), not from Engineering. Peter offered to go over them but insisted the framing should come from Product.

Mar 3

Approved retention check-in strategy for must-keep employee list

Approved the must-keep employee list prepared by Mariah and Chris. Committed to personally leading retention check-ins with must-keep engineering employees. Bjorn leads check-ins for his org. Mariah and Chris excluded their own teams (already monitored closely).

Feb 25

Directed AMD inclusion in Project Odin approach document

Peter reviewed Adam Jackson's first draft of the Project Odin approach document and approved it with one specific direction: slides 6/7 should include AMD. Otherwise approved as a great first draft.

Feb 17

Enforced Product-owns-prioritization process with Greg

Pushed back directly on Greg when he tried to route engineering work outside the established prioritization process. Insisted Product owns the priority list and work requests must flow through the proper channel. Simultaneously reminded Chris Baek that his team owns signoff authority and should use it rather than escalating through Greg.

Feb 6

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.

Jan 24

Instituted ARR and CVE gap metrics visibility at weekly meetings

Decided to communicate both current ARR (as determined by finance) and CVE gap metrics at weekly meetings. Proactively communicated this to Bjorn and Greg, anticipating potential concerns but proceeding anyway.

Jan 22

Value Drivers document cannot be automated from Jira - fills a gap Jira lacks

Clarified that the Value Drivers Release Plan document cannot be automated from Jira. The document was created specifically to fill a gap in Jira - linking engineering deliverables to GTM deliverables around WHY certain work is being done. Since Jira does not contain this linkage data, automating from Jira would just reproduce the gap.

Jan 21

Engineering dates commitment by Friday - reprioritize for revenue impact

Committed to publishing updated engineering dates/milestones by Friday for Monday group review. Acknowledged January deliverables are unrealistic - many items were newly added and cannot complete in remaining ~10 days. Will reprioritize toward revenue-impacting items first. Tomorrow all-day session with Chris Baek to rework H1 plan into aggressive but achievable targets.

Jan 21

Estimation philosophy: move dates early, hold them late

Project dates should be moved when new information is learned, rather than just dropping confidence when dates pass. Early SWAG dates should be updated once actual scoping begins. Red patterns in dashboards reflect engineers being trained not to move goalposts - this needs to change.

Jan 19

All-Hands messaging: acknowledge Q4 miss, pivot to pipeline optimism

Aligned with leadership on All-Hands messaging strategy: directly acknowledge Q4 revenue miss, then pivot to optimistic outlook highlighting $22M H1 pipeline and unified GTM plan. Peter to present tech updates (service endpoints, Nerf) and guide Mural board walkthrough. No naming specific deals to avoid premature expectations.

Jan 17

Conference Travel Approval - David Godlove HBCSF

Approved David Godlove travel to speak on Apptainer at HBCSF conference in Chicago in late March (~$2,200 cost). Required Chris Wolford to coordinate with Lindsay (Marketing) and Chris Baek (Finance) as part of the approval.

Jan 16

Strategic Map Framework - Value Drivers vs Internal Efficiency Separation

Established new H1 strategic planning framework that separates customer-facing Value Drivers from Internal Efficiency Drivers. Framework uses three lanes: middle lane for Value Drivers (the WHY), top lane for GTM activities, bottom lane for engineering deliverables. Also established phased estimation process: low-confidence ballpark dates first, then engineering-only session to raise confidence.

Jan 15

H1 Planning Framework - 3-Lane Model

Pushed for the team to focus on ICPs, goals, and milestones rather than getting lost in metrics and mid-level tactics. Established a 3-lane framework (GTM, Value Drivers, Engineering) to align all work.

OSPO Restructure - New Mandate and Leadership

OSPO moved under Customer Engineering (Ryan Smith). Chris Short removed as head. New leadership: Brian Clemons (VP, RESF) and Lee Hennig (former RESF MD). New mandate: govern ALL open source CIQ touches, not just RESF. Top priority: eliminate extinction event risks. RESF board resolution target by H1 2026. Self-sufficiency goal: enable CIQ to internally reproduce Rocky Linux.

ICP Consolidation - RLCH and RLCAI into Fuzzball

Consolidated RLCH (Rocky Linux Confidential Hardened) and RLCAI ICPs with Fuzzball ICPs to simplify GTM. RLCH targets regulated industries, government, power distribution. RLCAI targets AI-inferencing and compute-heavy industries. Rocky Pro kept separate for mid-market RHEL/SUSE/Oracle replacement motion.

H1 Planning Framework - 3-Lane Model

Introduced a new 3-lane planning model to address GTM and Engineering misalignment. Top Lane (GTM): marketing campaigns, messaging. Middle Lane (Value Drivers): the why - market state change, ICP, business significance. Bottom Lane (Engineering): deliverables driven by Value Drivers.

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.

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.

Dec 31