Andrew
Dec 24, 2025 - Sep 2, 2026
14
Decisions
0
Active Todos
8
Patterns
Categories
Decisions (14)
Hold the write-static-code guardrail at the 98 percent it actually buys - concede the escape case publicly and still refuse to mandate replacing third-party MCPs
At the 9/2 engineering all-hands Peter clarified the missive he had sent two weeks earlier about writing static code rather than pointing Claude at an MCP server. He gave the concrete failure it came from: someone stood up a Claude skill pointed straight at the HubSpot MCP server, and it deleted an org worth of data and 14 customers. The rule he wants: have the AI write Python or JavaScript, scope the token to exactly what that script needs, and let the skill know only that the script exists - not that the MCP server does. Jamin Collins pushed back hard and correctly - an over-helpful agent will eventually route around any tool that is not an actual guard, and once it learns it can, it will stop using the guard entirely. Peter conceded it in front of the whole org twice - he is right, he is completely right - and then held the line anyway: I do not think it is worth throwing out a pattern that works 98 percent of the time because of the 2 percent. If there is a better pattern you want to pitch, I am all for it. He named the tradeoff explicitly: the full fix is replacing each third-party MCP, which means an admin approval process per service, and I do not want to constrain our usage and our experimentation right now. Once we find that a certain set of tooling is really valuable, then it is worth investing in doing exactly that. He framed it as accepting a little bit of risk so that we can experiment as a team, and set the target as getting rid of the 100 percent failure case, not solving every edge case.
Extend abort-the-loop authority from the hiring manager down to every individual interviewer - anybody can pull the ripcord alone, without a debrief or consensus
At the close of the Friday roundtable the hiring manager mentioned that he already pulls candidates before they reach a debrief, so the panel will not see a roundtable for everyone they interview. Peter extended that authority downward rather than leaving it with the manager. He said he is a huge believer, we are a small team, everybody on this call is a super smart individual, and he is really comfortable with anybody just pulling the ripcord on an interview and saying this one is not moving on. He added that in past environments he was fine with someone standing up and walking a candidate out mid-loop on the grounds of not wasting anybody else time. He explicitly declined to impose it - the hiring manager might not be comfortable with it and Peter said he would leave that up to him. The hiring manager then agreed, saying at this stage in the game he was happy to do that. The exchange happened immediately after a debrief in which the panel had spent roughly twenty minutes on a candidate they all ended up rejecting, and after two of them had traded stories about aborted loops at a previous employer.
Re-anchor the no-more-Amazon-blood rule on the deficit it was actually naming - what the org is short of is people who have had a startup collapse under them, not people with different opinions about Linux
Across the Friday roundtable and the Nathan 1:1 Peter restated a hiring rule he had previously given as no more Amazon blood. In the roundtable he opened on the first candidate by saying he almost wanted to disqualify him purely on years of Amazon experience, that it has become absolutely critical to get a broader set of blood into the organization, and conceded that since stating the rule he has let two more people in and gets why. He then corrected Nathan reading of it - it is not about bad Amazon, it is that there is so much Amazon that there is not enough discussion about how we solve problems. In the 1:1 he specified it precisely: the thing he is pushing on is how you internalize the risk of not moving quickly. At Amazon the cost of slowness is somebody misses a promotion or a bonus; at CIQ the company goes under. He said Nathan is not less aggressive because of ability but because he has not had a startup collapse underneath him, and that what it boils down to is a few more people in your org that just have experience at startups. He closed by saying explicitly he is not shooting for differences in how people think about Linux - it is differences in work experience.
Sensitive Decision
Crown Andrew owner of NARF with real authority and an explicit cannot-wait instruction - accepting the recommendation while rejecting its stated rationale out loud
The programs previous steward produced an assessment of why NARF had not moved forward during his absence, with recommendations. Peter read it and took the main one - hey, Crown Andrew is king of NARF, I am fine with that - but named his objection to the logic in the same breath: the one problem I have with it is it is Crown Andrew is king of NARF, in part because Andrew has not moved NARF forward. I have trouble with that linkage. But whatever, I can get over it. He then converted the recommendation into a delegation instruction for Justin with three distinct components: You need to tell Andrew he has to own this thing. And run it like he owns it. He has got the authority to do what he wants with it. He cannot wait on the previous steward. The last clause was the operative one - it pre-emptively removes the dependency that had produced the stall, rather than waiting to see whether it recurs. He linked it explicitly to the stewards impending step-back from day-to-day delivery. Three days later the org-wide announcement named the handover of NARF stewardship to Andrew and Nathan as a fact.
Yes to anointing Andrew NARF tech lead - but Max confers it, so it does not set a precedent that the CTO blesses tech leads
Max proposed formally naming Andrew tech leader for NARF with full review and merge authority. Peter interrogated why Andrew could not simply claim it, and Max explained Andrew is afraid of stepping on Maxs toes and needs to be told it is his ballgame. Peter approved - we will say yes to this - while stating plainly that he does not personally believe in the anointed tech lead model. He then separated the approval from the ritual: on learning Max could confer the title himself, Peter routed the naming to Max specifically so the org would not learn that authority flows from a CTO blessing. Max will speak to Andrew before their Thursday 1:1.
Fix performance-review confirm-receipt acknowledgment — hand-deliver packets now, push HR for global wording change
When Andrew Jorgensen objected that Ripplings mid-year review flow forces employees to click confirm receipt before they actually have the packet, Peter sided with him. In his lane he directed an interim fix: managers download and hand-deliver packets directly so employees physically have them before acknowledging (told Nathan to send Andrew his packet; floated telling all his managers to email packets to everyone this round). As advocacy in HRs lane, he asked Mariah to change the button globally to access your packet and remove the receipt-confirmation sentence. Final wording decision deferred to the 6/16 C-Suite.
Committed to Improve Team Bandwidth Visibility in Monday Meeting
Committed to discuss with Nathan how to improve visibility in the Monday meeting on team bandwidth and impact, after Andrew raised he lacks visibility into other teams' work and hesitates to ask for help for fear of disrupting higher-priority work.
CentOS Bridge Deprioritization Held Despite Customer Risk
Confirmed to Andrew Jorgens that CentOS Bridge is consciously deprioritized. Acknowledged customer reputation risk (customer re-evaluating contract after only 4 CVE fixes) but held the line, explaining that 'important' is insufficient justification - a project must be more important than something else currently being worked on.
Sensitive Decision
Leadership 1:1s with Maple, Dieter, Andrew
Decision to begin regular 1-on-1s with Maple, Dieter, and Andrew (when onboarded) to build trust and ensure unified messaging.
Andrew Jorgensen Level Flexibility Confirmed
Clarified with Brianne that Andrew does not need to come in as Maxs peer. Happy to slot him into either the more senior or less senior position based on his comfort. Want him coming in feeling happy and excited about what hes signing up for.
Andrew Jorgensen Hiring Approved
Approved hiring Andrew Jorgensen for an IC role reporting to Nathan Blackham. Offered flexibility on level - he can come in at senior or less senior position based on his comfort.
Andrew Jorgensen Hiring - Deferred to Role Clarity
After CTO interview for Sr. Linux System Engineer, did not fill in final hire/dont recommendation. Deferred to Max/Nathan to clarify what they want him doing and culture fit concerns.
Related Patterns (8)
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.
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.
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.
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.