Professionalism & Ownership

The technical skill gets you in the door. Whether a team trusts you with real ownership comes down to something smaller and less glamorous: can you say "done" and mean it, and can you say how you know.

When this matters

Every time you're about to call something finished — a PR ready for review, a bug "fixed," a task "done" — and every time you're deciding how much rigor a piece of work actually needs. It's also the standard your teammates are silently holding you to before they'll hand you something bigger.

The practice

Evidence before "done." Claiming something works because it should work is not the same as claiming it works because you ran it and watched it pass. "Should pass now," "looks correct," and "the agent said it worked" are all confidence, not evidence — confidence isn't verification. Before any completion claim, name the command or check that actually proves it, run it fresh, and read the full output.

Provenance — be able to say how, not just that. "I verified it" is not itself verification; the test is whether you can describe the exact steps: which command, what output, what you read to confirm it. If you can't reconstruct how you checked something, you probably didn't check it closely enough.

Honesty over convenience. When you're not sure, say you're not sure — don't round uncertainty up to confidence because it's a more comfortable thing to report. A teammate who hears "I think this is fine" and later finds out you'd actually verified nothing loses more trust than one who hears "I haven't verified this part yet."

Watch for the four failure modes. These are the ways delegated or fast-moving work quietly goes wrong, even when every individual step looked reasonable:

Failure mode	What it looks like	The fix
Silent assumptions	Picking one reading of an ambiguous ask without saying so	State assumptions out loud; ask when genuinely unclear
Over-engineering	Building more than what was asked — extra abstraction, unrequested config	Build the minimum that solves the actual ask
Drive-by edits	"Improving" unrelated code, comments, or formatting while you're in there	Touch only what the task requires; flag other issues, don't fix them inline
Unverified done	Reporting success without having run the check	Evidence before any completion claim

Keep the working agreement. A few small habits are what let a team let you move fast without supervision: scale your design thinking to the size of the change (a five-minute fix doesn't need a design doc; a real architectural change does); land small commits; never commit or push straight to main — branch, change, one small commit; and if you ever have to bypass part of the normal process under time pressure, say so and why, in writing, rather than letting it pass silently. A bypass that's recorded is a judgment call; one that isn't is just a rule broken quietly.

Checklist

• Before I said "done," did I run the actual check and read its output — not assume it would pass?
• Can I describe exactly how I verified this, step by step, not just that I did?
• Did I say so when I wasn't sure, instead of rounding up to confident?
• Did I build only what was asked, with no speculative extras?
• Did I touch only the code the task required, leaving unrelated things alone (flagged, not fixed)?
• Is my commit small, on a branch, and nowhere near main?
• If I bypassed a step, did I write down why, instead of letting it pass unremarked?

Adapted from

• SE's verification-before-completion skill — evidence before any completion claim; "should work," "looks correct," and an agent's own success report are confidence, not verification.
• SE's coding-guardrails skill — the four recurring failure modes (silent assumptions, over-engineering, drive-by edits, unverified done) and their fixes.
• contango-procedure-for-devops.md — the real SE team working agreement: design scaled to the size of the change, and any bypass of the normal process recorded in writing rather than left silent.
• The onboarding Setup module's delegate freely, but verify and stay accountable framing, and its team git flow — branch → change → one small commit, main never touched directly.

Practice it

Ask the onboarding-tutor: "I'm about to say a piece of work is done — quiz me: what's my actual evidence, could I explain how I verified it, and did I fall into any of the four failure modes along the way?"