Andrew Jorgensen
Dec 24, 2025 - Sep 2, 2026
8
Decisions
0
Active Todos
8
Patterns
Categories
Decisions (8)
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
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.
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.