High D and high C: ship it now versus prove it first

The code review thread is forty comments deep. Your high C has flagged an edge case in the retry logic, with a reproduction, a reference, and a suggested fix. Your high D has replied "ship it, we'll patch if it bites" four different ways, each one shorter than the last.

Neither of them is wrong. The edge case is real. The release window is also real. The thread is no longer about the retry logic. It is about whose definition of done gets to win, and both of them know it.

Comment forty-one will not settle that. You will.

Why this keeps happening

What is happening: The D optimises for motion and treats risk as something you steer around live. The C optimises for correctness and treats unexamined risk as a debt with compound interest. Without a shared bar, every release becomes a referendum.

How it feels: You agree with both of them on alternating days, which means neither of them trusts your ruling. The threads get longer and the releases get later.

Why it should not be this way: Speed and proof are not opposites. They are a sequencing problem. Decide the bar before the work, and the argument disappears into the brief where it belongs.

Five questions for your next working session

1. For this class of decision, what does decision-ready mean, in one sentence each?
2. Which risks from the last release actually bit, and who called them?
3. Where would a one-page risk note have ended an argument early this quarter?
4. What is the smallest thing the other person could do that would raise your trust in their calls?
5. Which upcoming decision should we pre-agree the bar for, right now?

Coaching script

Run this before the next contested release, not during it. The whole fix is moving the argument earlier.

• Name both instincts as assets: the D is protecting tempo, the C is protecting the team from compound debt. Say it to both of them at once.
• Set the bar per decision class: which changes ship at eighty percent with a risk note, which wait for full verification. Write it where both can point at it.
• Install the one-page risk note as the standing artefact: C owns the risks, D owns the recommendation, both names on the doc.

Conflict repair script

For the live blow-up, when the thread has gone sharp and the release is tomorrow.

• Close the thread and convene fifteen minutes with both. Long threads reward stamina, not judgment.
• Have the C state the risk in one sentence and the D state the cost of delay in one sentence. No rebuttals yet.
• Make the call against the pre-agreed bar if one exists, and if one does not, make the call anyway and schedule the bar-setting session for this week. The repeat argument is the real problem.

A plan you can start this week

1. Move the argument earlier. Every D-and-C fight is a bar dispute in disguise. Agree decision-ready per class of work before the work starts.
2. Cap the thread. Ten comments, then a fifteen-minute call. Asynchronous debate is where this pairing goes to fester.
3. Make the risk note the peace treaty. One page, both names. The C gets the rigour on the record, the D gets the green light, the team gets a paper trail.

What happens if you wait

Unmanaged, one of two things happens: the D starts shipping around the C, and the defects the C would have caught arrive in production with nobody's name on the warning. Or the C wins every thread by attrition, and your fastest shipper starts interviewing.

Either way you lose the very tension that was producing good decisions.

What you'll see in Team Mode

Department Dynamics turns this page from a read into a tool you put in front of both groups this week. Two teams, plotted on the pace and focus axes, with the working agreement written for both sides.

See Team Mode

Frequently asked

How do high D and high C personalities work together?

Best of any pair, once the bar is pre-agreed. Both are task first; the disagreement is purely about pace versus proof. Define decision-ready per class of work and the fights move from the release week to the planning session.

Why do D and C teammates argue in code reviews?

Because a code review is where unstated standards collide. The D’s done means working; the C’s done means verified. Cap the thread, set the bar, and put residual risk in a one-page note both of them sign.

Who should win, speed or correctness?

The bar should win, and it should be set before the argument. Some changes deserve eighty percent and a risk note; some deserve full verification. Deciding which is which is a management call, not a thread.

How do you know a D and a C pair is failing?

Decisions are being made twice. The D ships against a thread that never closed; the C reopens the conversation a week later in private. That doubling is the failure mode; both arguments were valid and neither was decisive.

Should a D and a C lead together?

Yes, on anything where speed and durability both matter. The D protects tempo, the C protects the team from compound debt. The pair fails on shared product roadmaps without a pre-agreed bar.

Are D and C pairs good at hiring decisions?

Excellent, once you give them a rubric. Without one, the D will hire on intuition and the C will reject on technicalities, and you will lose every great candidate to whichever instinct won that week.

How long does the pre-agreed bar last before it needs review?

About a quarter. Markets move, scope shifts, and last quarter’s bar can buy you delay this quarter. Set a standing fifteen minutes at the start of every planning cycle to confirm it still fits.