Learn · Handover

Boundaries and conduct

A partner credential is a claim about you that a customer relies on. This unit is about the obligations that come with that.

Do not launder a compromise into a recommendation

Implementations involve constraints you did not choose: a security policy, a migration deadline, a platform team that will not staff the work. You build the best thing available inside them, and often that is not the best thing.

When you write it up, say which is which. A configuration described as “the recommended approach” outlives the constraint that produced it. Two years later nobody remembers there was a deadline, and a suboptimal shape has become institutional knowledge that a future engineer will defend.

“This is a compromise; we did it because X; if X ever lifts, do Y instead” costs you one sentence and saves the customer a genuinely expensive misunderstanding.

Know what your credential claims

Your credential says you demonstrated a set of skills on a date, against a stated exam version. It does not say your implementation is endorsed by Buildkite, that a configuration you produced is a Buildkite recommendation, or that you are acting as Buildkite when you deliver.

Representing any of those is the fastest route to having a credential revoked — and every attempt keeps an append-only record of what was assessed, precisely so that a withdrawal can be explained rather than asserted. See what a credential attests.

Escalate product gaps as product gaps

Sometimes what a customer needs does not exist. The honest move is to say so and escalate it, not to build an elaborate workaround and present it as the intended design.

Workarounds are legitimate. Workarounds documented as architecture are how a customer ends up maintaining something nobody at either organisation understands the purpose of.