Fixed scope vs. embedded team: how to pick an engagement model

The three models we work under — fixed scope, embedded team, technical advisory — aren't tiers, and none of them is the 'default' one. Picking wrong doesn't ruin a project, but it does create friction that a five-minute conversation up front avoids entirely.

Fixed scope fits when the requirements are already settled: you know what the thing needs to do, and you want a price and a date attached to that, not an open-ended relationship. It's the right shape for a defined build with a clear finish line.

An embedded team fits ongoing product work — when the requirements are going to keep evolving because the product is going to keep evolving, and what you actually need is capacity that scales with the roadmap rather than a scope document that goes stale in month two.

Technical advisory is the odd one out: it's not about adding capacity, it's about unblocking the capacity you already have. Architecture review, a delivery audit, hands-on pairing — usually the cheapest way out of a stall, because the problem was never 'not enough hands.'

Most engagements start in one shape and drift into another as the picture clarifies, and that's expected rather than penalised. The only real mistake is picking fixed scope for something whose requirements are still moving, and then being surprised when the fixed price stops making sense.