Duane
Jul 29, 2026 - Aug 19, 2026
4
Decisions
0
Active Todos
9
Patterns
Categories
Decisions (4)
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.
Confidence numbers stay human and per-leader - Brady translates them, Engineering does not remap to his scale
Bjorn brought Brady Dibbles push for a uniform, consistent cross-team definition of the confidence column. Peter rejected it in a DM thread on 7/29 evening and repeated the same ruling to Nathan on 7/30. Confidence is a human thing. That is why we call the column that. It is not computed immutable expectation of delivery for a reason. Justin is risk averse, so he will not put a 99 when he can imagine millions of ways for something to go wrong. Another leader might. The team will learn over time what Justins 90 means. On Bradys ask: the real and only question is what does Brady want to do with these numbers that he cannot do - what is he going to do with a 95 different than a 90. If Brady wants to turn the numbers into high/medium/low or into ranges in his own process that is fine, but that is him translating, not asking Engineering to fit an arbitrary mapping. If he wants a structured definition of exactly what high/medium/low means, now he is losing the experience of engineering leadership and having a function fill out his numbers. Peter also rejected high/medium/low outright: the minute you have high/medium/low it is not functional enough and you end up with twelve gradations and the same problem. And he told Bjorn to test it empirically - ask Duane if he can work with the numbers Justin is providing, the answer will be yes.
Confidence must rise as the target date nears - slide the date early rather than carry a 60 percent to the wire
Reviewing Justin Haynes automated-repo-testing item on the NGD board, Peter ruled that a low confidence number a few days from a target date is itself the failure. His instruction: this close to the end of the week we need to be communicating to the company, through those two numbers, whether they are getting something - so a few days from the end I do not want to see a 60 percent confidence number, what I want to see a few days ago is that date sliding out now so that we are communicating a higher confidence number when we are this close to a target date. He grounded it in consumer value: the company cannot do anything with 60 percent confidence July 31st, they cannot take attention on that. Immediately afterwards, when Duane Carson acknowledged a cross-team miss on the 10-2 bits, Peter drew the complementary line - I do not mind misses as long as the team recognizes, hey, we have a miss here, and here is how we are going to get better.
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.
Related Patterns (9)
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.
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.