At the organizational level, what does it mean to 'focus the best talent on the core domain,' and when does extracting an Abstract Core across multiple subdomains become the right strategic move rather than a premature abstraction?

## The organizational half of distillation Focusing the best talent on the core domain is the organizational half of core-domain distillation — a decision about **people and process, not code**. Once the team has identified where the real value and complexity live, the strategic follow-through is to deliberately unbalance staffing and process around that finding: - the most experienced domain modelers, the most rigorous design review, and the most careful test and refactoring discipline go to the core; - generic subdomains get competent-but-not-necessarily-senior engineers, off-the-shelf packages, or even outsourced vendors. This is a genuinely uncomfortable organizational move because it cuts against a natural, egalitarian instinct to staff every team 'fairly' and against the pull of interesting, well-scoped generic problems that talented engineers often gravitate toward on their own. It requires a manager or architect to actively intervene — in hiring, in team assignment, in what gets attention in planning meetings — to keep the organization's investment aligned with where the real differentiation is, rather than letting it drift toward wherever the work happens to feel most tractable. ## What an Abstract Core is **Abstract Core** is the more technically demanding companion move, used when a team distilling its core discovers that what looked like several separate core subdomains actually share a deep, stable set of underlying concepts — not superficial similarity, but the same fundamental relationships and lifecycle showing up in different guises. The mechanism is to factor that shared structure out into a small set of abstract types, often interfaces or abstract classes representing very general relationships such as 'this kind of thing constrains that kind of thing' or 'this kind of thing has this kind of lifecycle', that the concrete subdomain models then implement or specialize. Done well, this abstract layer becomes the most valuable and most carefully guarded code in the whole system, because every concrete core subdomain depends on it being right; getting it right once pays off across every subdomain built on it, and getting it wrong propagates that error everywhere too. ## When the preconditions hold The trade-off, and the reason this is a **principal-level judgment call** rather than a routine technique, is that it inverts the usual advice to avoid speculative abstraction — but only when the preconditions genuinely hold. An abstract core is worth its cost specifically when: 1. the shared structure has already shown up, independently, in multiple concrete subdomains, not hypothesized in advance; 2. the team has deep enough domain understanding to state the abstraction in the domain's own vocabulary rather than generic programming terms; 3. the subdomains sharing it are stable enough that the abstraction won't need to be redesigned every quarter. When those preconditions don't hold, the identical technique becomes a classic **premature-abstraction trap**: an architect notices two subdomains that look similar on the surface, factors out a shared abstract base before either concrete case is well understood, and locks the team into a wrong shape that every subsequent concrete requirement has to be awkwardly bent to fit, with the added indirection making the code harder to change, not easier. ## Failure modes on the talent side Failure modes on the talent-allocation side show up organizationally rather than in code. - **Stated strategy and actual staffing diverge.** A company writes an accurate statement of what its core domain is but then staffs the core domain with junior rotational hires 'to give them experience' while putting senior architects on an internal tooling platform because it's more technically interesting to them — the stated strategy and the actual resource allocation silently diverge, and nobody notices until the core domain's quality visibly lags the rest of the system. - **Seniority rather than domain fluency.** Another failure mode is treating 'best talent' purely as technical seniority rather than domain fluency — assigning a strong generalist architect with no patience for sitting with domain experts often produces a technically elegant but domain-naive core model, because focusing talent on the core only pays off when that talent is also willing to do the sustained, unglamorous work of deep domain-expert collaboration that produces a genuinely distilled model. ## Failure modes on the abstract-core side Failure modes on the abstract-core side are equally concrete. - **An abstraction extracted from only two examples.** It turns out, once a third concrete subdomain arrives, to not actually generalize — the shared lifecycle the two original cases had in common was coincidental, not structural, and the abstract core has to be unwound at real cost, often after other code has already been built against it. - **Correct-but-unreadable.** A subtler failure is an abstract core that becomes correct-but-unreadable: it's technically sound and does generalize, but it's expressed in such abstract vocabulary that domain experts can no longer recognize their own domain in it, defeating the shared-language goal that distillation is meant to serve in the first place. ## A concrete example A concrete example: a healthcare scheduling company discovers that its **appointment-booking**, **resource-reservation** (rooms, equipment), and **staff-shift-assignment** subdomains — initially built as separate core models — all independently reinvented the same underlying concept of a **time-bounded claim on a scarce, conflict-checked resource**. After that pattern shows up a third time, the team distills a small abstract core, a time-bounded claim concept with conflict-detection semantics, that the three concrete subdomains now specialize, and staffs that abstract core with its two most senior domain modelers, because an error there would now silently propagate into every scheduling decision the company makes.