Engagement model
An engineering team attached to your product, not to a project
A standing team that works your roadmap and brings its own delivery leadership, standards and quality practices. It ramps up, and then it stays — so the knowledge compounds instead of resetting.
- Best for
- You need a long-term team without building the capability internally.
- Engagement type
- A standing team on a recurring commitment.
- Your involvement
- You own the roadmap and the product decisions. You do not manage engineers.
- Our responsibility
- The team, its delivery leadership, its standards and its continuity.
- Primary outcome
- Sustained delivery against your roadmap.
You probably need this when
This model is bought when the work is permanent but the internal capability is not — and building that capability from scratch would take longer than the product can wait.
The product needs a team, and you do not have one
There is a real roadmap with years in it, and no engineering organisation to deliver it. Recruiting one is a multi-year project of its own.
You have engineers but no engineering leadership
There are capable people and nobody whose job is delivery — standards, review, planning and quality all fall between roles.
Project teams keep forming and dissolving
Every initiative starts with people relearning the same system. Nothing accumulates, because nobody stays long enough for it to.
Quality is inconsistent between workstreams
Some parts of the product are well built and some are not, because there is no shared standard being applied across all of it.
You want to stop managing individual contractors
Coordinating several augmented engineers has quietly become somebody's full-time job, and that somebody was hired to do something else.
What this engagement means
You are buying a team and the leadership that runs it. You keep the roadmap and the product decisions; we take responsibility for how the work gets done.
This isn’t
- Individual engineers for you to direct and review yourself
- Ownership of your roadmap or your product decisions
- A fixed scope with an agreed end state and an acceptance step
- Accountability for a business outcome — we own the delivery, you own what it is for
- A team that dissolves at the end of each initiative
This is
- A standing team working continuously against your roadmap
- Delivery leadership included — planning, sequencing and accountability for the team’s output
- Engineering standards and quality practices we bring and apply
- Continuity: the same people, accumulating knowledge of your product over time
- A team that ramps up and then remains attached to the product
What you get
You are buying an ongoing capability, so the outputs are the things that make a team more than a group of engineers.
- Engineers matched to what the product actually needs
- A composition that shifts as priorities move, without rehiring
- People who stay long enough to know the system properly
- Planning, sequencing and accountability for the team’s output
- Engineering standards applied consistently across the work
- Code review, testing and quality practices we own rather than ask you for
- Steady backlog progress against your roadmap
- Documentation and decision records kept as the work happens
- System knowledge that stays with the engagement rather than with individuals
How we work together
The split here is genuinely shared, and the line is clean: you decide what the product should do, we decide how it gets built and take responsibility for building it.
| Responsibility | Client | Shared | CipherCru |
|---|---|---|---|
| Roadmap ownership | Included | Not included | Not included |
| Product decisions | Included | Not included | Not included |
| Day-to-day priorities | Not included | Included | Not included |
| Technical decisions | Not included | Not included | Included |
| Engineering standards | Not included | Not included | Included |
| Quality assurance | Not included | Not included | Included |
| Team management | Not included | Not included | Included |
| Delivery management | Not included | Not included | Included |
| Reporting | Not included | Included | Not included |
How the engagement runs
The lifecycle is about standing a team up properly and then letting it compound. The last stage never finishes.
Team design
We work out what the roadmap actually requires — skills, seniority, shape — rather than starting from a number of engineers.
Onboarding
The team gets into the product, the systems and the domain, and we agree how planning, review and reporting will work between us.
Ramp-up
Output builds deliberately as system knowledge builds. We would rather be honest about this curve than claim full velocity in week two.
Delivery cadence
A steady rhythm against your roadmap, with progress and decisions visible to you without you having to chase them.
Continuous improvement
The team keeps working on the system it works in — reducing friction, paying down debt and improving what slows delivery.
Is this right for you?
A dedicated team is worth its overhead when there is sustained work to feed it. For anything shorter or smaller, a lighter model will serve you better.
A strong fit when
The work is continuous and you want the capability without owning the hiring.
- There is a roadmap with sustained work in it, not a single project
- You want engineering standards and delivery leadership brought to you
- You would rather own the roadmap than manage engineers
- Continuity and accumulated product knowledge matter to you
Consider another model when
The work is bounded, occasional, or you want to keep delivery control.
- You want to direct the work yourself, under your own process
- The scope is defined and finite, with a clear end state
- The system is live and needs periodic work, not a standing team
- You want accountability for a business outcome rather than for delivery
Another model may suit you better: Staff Augmentation — You want individual engineers working under your team’s own process and leadership. Retained Engineering — The product is live and needs reserved capacity rather than a full standing team. Managed Delivery — You want CipherCru accountable for a business outcome, not just for the team’s delivery.
This sounds like what we need.
Tell us what your roadmap looks like over the next year. We will help work out whether a standing team is the right shape for it.
How it works commercially
You are buying a team on a recurring basis, priced as a team rather than as a collection of individuals.
Team cost is agreed per engagement. Contractual detail lives in our engagement terms.
Compare relevant models
Three models put CipherCru engineers on your product for the long run. They differ in who leads and how much is reserved.
| Dedicated Team | Staff Augmentation | Retained Engineering | Managed Delivery | |
|---|---|---|---|---|
| Is the team persistent? | Yes | Individuals are | Reserved, not standing | For the outcome |
| Who manages delivery? | CipherCru | You do | Shared | CipherCru |
| Whose engineering standards? | Ours | Yours | Ours | Ours |
| Who owns the roadmap? | You do | You do | You do | Shared, against the outcome |
| Capacity is | Continuous | Continuous | Reserved and prioritised | Sized to the outcome |
Other ways to work with us
If a standing team is more than the work needs, or less control than you want, these are the near neighbours.
Staff Augmentation
Senior engineers inside your team, under your process, your standards and your review. You direct the work day to day.
Best when you know what to build and lack the people.
- Where it fits: a roadmap that is agreed, funded and behind schedule.
- Knowledge transfer is a deliverable, so capacity does not become dependency.
- You own the backlog, the priorities and the delivery risk.
Retained Engineering
Reserved senior capacity for a system already in production — changes, integrations, incident support and the improvements a live business keeps needing.
Best when the software is live and the work never fully stops.
- Where it fits: a live system your team can run but not extend.
- Unused capacity is a signal to reduce the retainer, not to invent work.
- You own the operation; we own the engineering capacity you draw on.
Managed Delivery
We take an outcome rather than a specification — assembling the team, running the delivery, and reporting against the business result you asked for.
Best when the result is agreed and delivery has no owner.
- Where it fits: an organisation with the outcome but no engineering function to run it.
- Reporting is against business milestones, not against hours booked.
- We own planning, staffing and delivery; you own the decisions and the result.
Not sure which model fits? Tell us the situation and we will point you at the right one. See all seven engagement models
Common questions
What clients ask before standing up a dedicated team.
How is this different from just hiring several augmented engineers?
Can the team change size as our roadmap changes?
Who decides what the team works on?
How long before the team is at full output?
What happens if we end the engagement?
Can this run alongside our own engineers?
Build the capability without building the org chart
Tell us what your product needs over the next year or two. We will tell you what team would deliver it, and whether you need one at all.
Dedicated Engineering Team
Engagement model