Engagement model
Hand over the delivery, keep the outcome
You agree what needs to be true at the end. We design the delivery, assemble the team, run the execution and report on progress — and we are answerable for reaching it, not for closing tickets.
- Best for
- You know the outcome you need and do not want to run the delivery.
- Engagement type
- Outcome-based delivery, led by CipherCru.
- Your involvement
- Define the outcome, take the business decisions, review progress.
- Our responsibility
- Delivery design, team, execution, management and reporting.
- Primary outcome
- The agreed result, reached.
You probably need this when
This model is bought when the outcome matters more than the method, and there is nobody available to own the method.
You know the result you need, not the route to it
The business objective is clear. What should be built, in what order, by what kind of team is not — and working that out is itself the job.
There is no one internally to own delivery
You could hire engineers, but the missing piece is the person who would direct them, sequence the work and be accountable when it slips.
Previous attempts produced output but not outcomes
Work shipped, budget was spent, and the thing it was supposed to achieve did not happen. Specifications were executed faithfully and the result was still wrong.
The outcome matters more than any particular feature
You care that the number moves. Which features move it is a question you would rather delegate to people who will be measured on the answer.
You need one accountable party, not several suppliers
Coordinating vendors has become the risk. You want a single point of responsibility for whether this actually lands.
What this engagement means
You are buying responsibility for a result. We own how it gets delivered, including the decisions about what to build — which is the part that distinguishes this from every other model here.
This isn’t
- A team you direct — if you want to run the work, this is the wrong model
- A fixed scope with a specification agreed and frozen at the start
- Ownership of your business strategy or your commercial decisions
- A guarantee of a market result we do not control
- Engineers to allocate to whatever you decide each week
This is
- An agreed business or product outcome, with agreed measures of success
- CipherCru accountable for reaching that outcome, not merely for executing a specification
- Delivery design, team composition, execution and delivery management, all owned by us
- Technical decision-making within the boundaries you set
- Regular reporting against the outcome, in terms the business recognises
What you get
The output is the outcome, and the evidence that it is being reached. Everything else is in service of those two.
- A route from the current position to the agreed outcome
- What gets built, in what order, and why that order
- The decisions and trade-offs recorded as they are made
- A team composed for what the outcome actually needs
- Delivery leadership, planning and day-to-day management
- Composition changed as the work reveals what it requires
- Working software delivered against the agreed outcome
- Progress reported against the outcome rather than against activity
- Risks raised while there is still time to act on them
How we work together
This is the model where CipherCru holds the most. You keep the business decisions and the definition of success; almost everything between those two is ours.
| Responsibility | Client | Shared | CipherCru |
|---|---|---|---|
| Defining the outcome | Included | Not included | Not included |
| Business and commercial decisions | Included | Not included | Not included |
| Product decisions | Not included | Included | Not included |
| Roadmap and sequencing | Not included | Not included | Included |
| Delivery design | Not included | Not included | Included |
| Team composition | Not included | Not included | Included |
| Day-to-day priorities | Not included | Not included | Included |
| Technical decisions | Not included | Not included | Included |
| Engineering standards | Not included | Not included | Included |
| Quality assurance | Not included | Not included | Included |
| Delivery management | Not included | Not included | Included |
| Reporting | Not included | Not included | Included |
How the engagement runs
Six stages, beginning with the hardest one. If the outcome cannot be stated and measured, nothing after it is worth starting.
Outcome definition
We agree what has to be true at the end and how it will be measured. Vague outcomes are where this model fails, so we push hard here before agreeing anything.
Delivery design
We work out the route — what to build, in what order, and what has to be true along the way for the outcome to be reachable.
Team assembly
We compose the team the delivery actually needs, rather than fitting the work to a team that already exists.
Execution
We run the delivery: planning, building, testing and managing it, with the decisions ours to make within the boundaries you set.
Measurement
Progress is reported against the outcome and its measures, not against activity. If we are not moving the number, that is visible early.
Evolution
What we learn changes the plan. The outcome holds still; the route to it is expected to change, and does.
Is this right for you?
This model asks you to give up control of the method. Clients who cannot do that are better served elsewhere, and it is fairer to say so before starting than after.
A strong fit when
The outcome is clear, the route is not, and you want one accountable party.
- You can state what has to be true at the end and how you would measure it
- There is no one internally who can own delivery end to end
- You want a single party accountable rather than several suppliers coordinated
- You are comfortable delegating decisions about what gets built and when
Consider another model when
You want to keep the method, or the work is already specified.
- You want to direct priorities and decisions yourself
- The scope is already defined and simply needs building to specification
- You need capacity inside your existing team and process
- The outcome cannot yet be stated clearly enough to be accountable for
Another model may suit you better: Fixed-Scope Delivery — The work is already specified and what you want is it built to that specification. Dedicated Engineering Team — You want to keep the roadmap and product decisions while we run the engineering. Staff Augmentation — You want engineers working under your own leadership and process.
This sounds like what we need.
Tell us what has to be true at the end. We will help work out whether it is stated clearly enough for anyone to be accountable for it.
How it works commercially
You are buying responsibility for an outcome, so the arrangement is built around the outcome rather than around a headcount or a specification.
Outcomes, measures and commercial structure are agreed per engagement. Contractual detail lives in our engagement terms.
Compare relevant models
The question separating these is how much you want to decide, and what you want us answerable for.
| Managed Delivery | Fixed-Scope Delivery | Dedicated Team | Staff Augmentation | |
|---|---|---|---|---|
| CipherCru is accountable for | The outcome | The agreed scope | The team’s delivery | The engineers |
| Who decides what gets built? | CipherCru, to your outcome | Agreed up front | You do | You do |
| Is scope predetermined? | No — the outcome is | Yes | No — the roadmap is yours | No |
| How much client management? | Direction and review | Scope and acceptance | Roadmap and review | Daily |
| Is the team persistent? | For the outcome | No | Yes | Individuals are |
Other ways to work with us
If handing over the method is more than you want, these keep progressively more of it with you.
Fixed-Scope Delivery
A defined piece of work, scoped and priced up front, delivered end to end. Scope changes are re-priced in the open rather than absorbed quietly.
Best when the scope is stable enough to write down and hold.
- Where it fits: a replacement, an integration, or a first release with firm edges.
- Fixed budget, so the risk of a wrong estimate is ours, not yours.
- We own scope, estimate and delivery risk; you own acceptance.
Dedicated Engineering Team
A standing team that works to your roadmap with our own delivery lead, engineering standards and quality bar. It ramps up and stays with the product.
Best when the roadmap is long and the requirements keep moving.
- Where it fits: a product roadmap that runs longer than any single project.
- A named delivery lead who is in the standups, not reporting on them.
- You own direction and priorities; we own how the team delivers them.
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.
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 handing over delivery responsibility.
How is the outcome agreed and measured?
How much control do we give up?
Are you guaranteeing the business result?
How do we know what is happening?
What if the outcome changes?
Can this work alongside our existing engineers?
Give the delivery to someone who will answer for it
Tell us what has to be true at the end, and by when. We will tell you what it would take, and whether we are the right people to be accountable for it.
Managed Delivery
Engagement model