Engagement model
Add experienced engineers without giving up control of delivery
Our engineers work inside your team, in your process, against your priorities. Your leads still lead. What changes is how much your team can carry, not who decides what it carries.
- Best for
- You know what to build and need more hands to build it.
- Engagement type
- Ongoing capacity inside your existing team.
- Your involvement
- Daily. You set priorities, run standups and review the work.
- Our responsibility
- The people, their capability, and their continuity on your team.
- Primary outcome
- More delivery capacity, same delivery ownership.
You probably need this when
This model is bought by teams that are working well and simply cannot get through enough — not by teams looking for someone to take over.
The roadmap is agreed and the team is the bottleneck
Nobody is confused about what to build. There are simply more committed priorities than engineers to work on them.
Hiring is too slow for the window you have
The requisition is open and the search is months long, but the work is now. You need capacity before a permanent hire could realistically land and ramp.
You need a specific skill for a defined stretch
A migration, a platform, a piece of infrastructure — a capability your team needs for a while, but not permanently on the payroll.
You do not want delivery ownership leaving the building
Handing a workstream to an outside team is the wrong answer for you. The processes, standards and decisions need to stay yours.
Cover is needed without restructuring the team
Parental leave, a resignation, a secondment. You need the seat filled by someone senior enough to be useful quickly.
What this engagement means
You are buying capable people who work the way your team works. You are not transferring responsibility for what gets built or how it is judged.
This isn’t
- An outsourced team running its own process alongside yours
- CipherCru taking responsibility for your delivery or your roadmap
- A fixed scope with an agreed end state and an acceptance step
- A managed outcome that we are accountable for reaching
- Interchangeable contractors rotated in and out of the seat
This is
- Senior engineers working inside your team and your delivery structure
- Your priorities, your board, your standups, your definition of done
- Code reviewed by your reviewers, against your standards
- Specialist skills added for as long as you need them
- Continuity — the same people, staying long enough to be genuinely useful
What you get
The output of this model is capacity, so it is judged on the people and how well they fit — not on documents.
- Senior engineers who have shipped and maintained production systems
- Contribution to your existing backlog, not a parallel one
- Capacity that scales up or down as the work changes
- Depth in a platform, language or domain your team is thin on
- Experience of the specific problem, from having done it before
- Knowledge that transfers to your team while they are here
- In your tools, your ceremonies and your review process from the start
- Working to your standards rather than importing ours
- Handover and documentation as they go, so nothing leaves with them
How we work together
This is the most client-led model we offer. Almost everything sits with you by design — that is what you are buying.
| Responsibility | Client | Shared | CipherCru |
|---|---|---|---|
| Roadmap and product decisions | Included | Not included | Not included |
| Day-to-day priorities | Included | Not included | Not included |
| Engineering standards | Included | Not included | Not included |
| Code review and quality gates | Included | Not included | Not included |
| Delivery management | Included | Not included | Not included |
| Technical decisions | Not included | Included | Not included |
| Engineer capability and fit | Not included | Not included | Included |
| Continuity and cover | Not included | Not included | Included |
How the engagement runs
The lifecycle is about getting someone useful inside your team quickly, then keeping them there.
Role definition
We agree what the seat actually needs — the skills, the seniority, and what this person will be working on in their first month.
Selection
We put forward engineers we would want on our own work. You meet them and decide; we do not allocate people to your team without that.
Onboarding
They join your tools, your ceremonies and your codebase, and work to your standards. We do not import a parallel process.
Delivery cadence
They work your board under your leads, reviewed by your reviewers. Day to day, the engagement is invisible.
Continuity
We keep the same people on your team, cover planned absence, and make sure knowledge is written down rather than carried.
Is this right for you?
This model assumes a functioning delivery structure to plug into. Where that does not exist, adding people usually makes things worse rather than faster.
A strong fit when
You have the direction and the process, and need more capacity inside them.
- You have engineering leadership able to direct and review the work
- The backlog is understood and prioritised
- You want delivery ownership to stay firmly in your team
- You need a specific skill for a defined period
Consider another model when
There is no structure to join, or you would rather not run the work at all.
- You have no one available to direct, review and unblock the work
- You want a team that brings its own delivery leadership and standards
- You want CipherCru accountable for reaching an outcome
- The need is occasional support on a live system, not sustained capacity
Another model may suit you better: Dedicated Engineering Team — You want a standing team that brings its own delivery leadership and engineering standards. Managed Delivery — You would rather hold CipherCru accountable for an outcome than manage the work yourself.
This sounds like what we need.
Tell us what your team is trying to get through and where it is stuck. We will help work out whether adding capacity is genuinely the fix.
How it works commercially
Capacity is bought as an ongoing commitment per engineer, and it is meant to be adjustable as the work changes.
Rates are agreed per role. Contractual detail lives in our engagement terms.
Compare relevant models
The question that separates these three is simple: how much of delivery do you want to keep?
| Staff Augmentation | Dedicated Engineering Team | Managed Delivery | |
|---|---|---|---|
| Who controls day-to-day work? | You do | Shared | CipherCru does |
| Who manages delivery? | You do | CipherCru, to your roadmap | CipherCru |
| Whose engineering standards? | Yours | Ours, aligned to yours | Ours |
| Is CipherCru accountable for delivery? | No | For the team’s output | Yes, for the outcome |
| How much management does it need from you? | Daily | Roadmap and review | Direction and acceptance |
Other ways to work with us
If you would rather not run the work day to day, these two move that responsibility across.
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.
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 adding engineers to their team.
Do we get to choose who joins the team?
What happens if the engineer leaves or is unavailable?
Whose process do they work in?
How quickly are they productive?
Can this become a dedicated team later?
Who owns the code they write?
Add capacity without changing how you work
Tell us what your team is carrying and where it is short. We will tell you what kind of engineer would actually help.
Staff Augmentation
Engagement model