Chapter 19
Productize the repeated constraint
Updated
Three customers need similar integrations, each living on a different branch.
Inspect
Separate shared behavior, variable configuration, domain policy, and genuinely unique work. Count upgrade effort and support exceptions, not just initial reuse of code.
Decide
Promote a capability when repeated evidence justifies its maintenance contract. Keep ownership, versioning, evaluation cases, and upgrade paths with the package.
Bring to a review
A second engineer deploys to a second environment; measure effort, exceptions, and the remaining dependency on the original author.
Common trap: Copying a repository creates another instance. It does not establish a supported product.
Read
- What FDE means at OpenAI Start with a business outcome, then make the solution repeatable.Focus: Focus on customer-defined evaluations and replacing repeated custom implementations with reusable capability. Apply: Identify one repeated field constraint and propose a shared change with a second-deployment test.
- Team Topologies · 2nd edition BookCognitive load, team boundaries, and interaction patterns.Focus: Read for team boundaries and interaction modes: collaboration, facilitation, and service consumption. Apply: Name when an embedded engagement ends and how the customer team gets a supported service afterward.
- Agents CLI · lifecycle and deployment reference Inspect an integrated scaffold, evaluation, deployment, and observation workflow.Focus: Review lifecycle commands, evaluation, infrastructure, CI/CD, observation, and upgrade paths. Apply: Create a vendor-neutral package checklist and have a second engineer deploy from the documented inputs.
- Eliminating Toil · The Site Reliability Workbook BookMeasure operational work and choose worthwhile automation.Focus: Read identifying, quantifying, and prioritizing toil; inspect the case examples. Apply: Record support time per successful task and compare automation cost with recurring manual effort.