Suppose an engineering org has, without realizing it, assigned its most experienced engineers to a generic subdomain (like internal logging and observability tooling) while a junior-heavy team owns the company's actual core subdomain. What symptoms would you expect to see in the business and the codebase over the next year, and how would you diagnose that this is a subdomain-classification problem rather than a hiring or process problem?

## Talent follows gravity Misclassification, or more commonly no classification at all, means engineering effort follows organic gravity rather than business value: - technical interestingness; - whoever champions loudest in planning; - historical inertia. Senior engineers, given latitude, often gravitate toward the most technically satisfying problem, which frequently is a generic subdomain, because generic problems have well-known 'good' solutions and clear craft signals, whereas core-subdomain work is messy, requires constant negotiation with domain experts, and rarely feels done. Meanwhile the core subdomain, being closest to the messy realities of the business, often gets treated as unglamorous product work and staffed with whoever is available, frequently newer engineers. ## What the starved core looks like Why this produces visible symptoms: the core subdomain is, by definition, where model quality directly drives business outcomes — pricing logic, matching, personalization, whatever it is. When under-modeled — a junior team without deep domain-expert collaboration, quick patches instead of refactoring — the domain logic degenerates into scattered conditionals rather than first-class domain concepts. This shows up as: - feature lead time growing quarter over quarter for anything touching the core subdomain; - regression rates climbing specifically there; - and, most tellingly, business stakeholders describing the core capability as 'hard to change' and asking for workarounds instead of proper features. ## The other half of the tell Symmetrically, the generic subdomain absorbing senior talent shows its own tell: it accumulates capability far beyond what the business needs, because senior engineers optimizing a low-stakes area default to engineering elegance as the measure of success, with no domain expert pushing back with 'that's not what the business needs.' It shows up as: - pluggable backends it will never switch between; - configuration options nobody uses; - internal tooling more polished than the product itself. ## A trade-off worth naming There's a real trade-off worth naming honestly: generic-subdomain work is genuinely lower-risk practice ground, and rotating engineers through it isn't wasted. The failure is specifically leaving the most senior people parked there long-term while the core subdomain, which needs the most experienced domain modeling, gets the least experienced hands. ## Telling it apart from a hiring or a process story Diagnosing it as a classification problem rather than a hiring or process problem: ask whether an explicit subdomain map exists and is visible to whoever makes staffing calls. If leadership hesitates or names a list that doesn't match where the strongest people actually sit, that's the smoking gun — resource allocation was never deliberately aligned to strategic classification, it just accreted. Contrast this with: - **a genuine hiring gap**, which would show as unfilled reqs and overall velocity problems everywhere, not a lopsided quality gap between two subdomains; - **a pure process problem**, which would show as the core team having capable people but poor throughput across the board, not model quality that specifically degrades in complexity over time. ## The fix The fix once diagnosed: reallocate senior engineers to the core subdomain, even if that means the generic tooling temporarily stops improving, which is fine — 'good enough and stable' is an acceptable steady state for something generic — and pair remaining engineers on the generic subdomain with lightweight guardrails, since a bought or vendor solution reduces how much engineering judgment is needed there. Adding junior headcount to the core team without this senior reallocation typically doesn't fix the underlying problem, because the issue is model quality and domain-expert collaboration depth, not raw capacity. ## Logistics, worked through Worked scenario: a mid-size logistics company's delivery-route optimization, its core subdomain, is maintained by two mid-level engineers rotating in and out, while its internal deployment tooling and CI dashboards, a generic subdomain with comparable SaaS/OSS products available, has three senior staff engineers who've built an elaborate custom platform. Over a year, the routing algorithm barely improves, a competitor visibly starts offering faster delivery windows, while the internal tooling wins engineering praise nobody outside the team notices. Leadership initially responds by hiring more engineers for the routing team — but the real fix, once the classification problem is named, is moving two senior staff engineers from tooling onto routing.