Services
Engineers, but nobody running the work
A common and expensive position. The people are good, the work is real, and what is missing is the layer that decides sequence, holds scope, and tells you the truth about the date.
Fixed-fee discovery · Planning · Reporting · Launch
01 / Delivery, end to end
Diagnosis
Recognise any of these?
Four symptoms of a missing delivery layer. If none of them describe your situation, you do not need this page, and knowing that quickly is the point.
-
Symptom 01
Work happens. Completion dates do not.
There is always activity to point at and never a date anyone will stand behind. Busy is not the same as finishing.
-
Symptom 02
Estimates stopped meaning anything.
Numbers arrive padded, slip anyway, and everyone has learned to double them privately and hope.
-
Symptom 03
Scope arrives sideways.
Requests reach engineers through direct messages and corridor asks, skipping any decision about order, cost or whether to do them at all.
-
Symptom 04
The date slips in defensible increments.
Two weeks here, three days there, each shift reasonable on its own. Half a year later the deadline is next quarter.
Fit
Alongside a team you already have
The usual worry is disruption. Here is what actually changes, which is less than most firms admit.
Your engineers keep reporting to you.
We run the work, not the people. Direction, reviews and pay stay exactly where they are.
No inserted management layer.
One delivery lead working directly with your team. Messages reach you without passing through three desks.
No methodology conversion.
We work inside whatever the team already uses and make it honest. Mid-project religious conversion is disruption dressed up as improvement.
Scope of the role
What we take on
Six jobs that were going undone. None of them involve replacing your engineers.
Intent into a plan
What everyone agreed in meetings becomes sequenced, costed work on paper that can be argued with, adjusted and signed.
Holding scope
New requests get priced and scheduled deliberately instead of being absorbed silently into somebody's evenings.
Running the rhythm
A cadence of standups, demos and shipped increments, set once and then kept deliberately dull.
Readable reporting
One page a week: what moved, what is moving, what is stuck, who owns unsticking it. Written for people with other jobs.
Managing risk early
Risks get named, owned and revisited while they are still cheap. The uncomfortable conversation lands in week two rather than as a month four surprise.
Getting it launched
A launch run as work rather than hoped for as an event: checklist, rollback plan, named owners, a date on the calendar.
Afterwards
What stays with you
- The plan
- Written decisions
- The risk register
- The reporting format
All of it lives in your tools, in formats your own people can open without us.
A delivery engagement that leaves nothing behind has to be renewed forever. That suits us and not you, so this one is built to end.
Limits
What this service will not do
It does not add engineering hands
The role decides order, holds scope and tells you the truth about progress. Keyboards stay with engineers.
It is not product management
Choosing what to build and why is a different discipline with a different buyer. We deliver the decided thing.
The one that matters
It cannot create time
If engineers are asked to hit a date that was set without them, delivery management will not conjure the missing weeks. It will document the gap clearly and say so early. That honesty is worth something. It is probably not what you were hoping to read.
How the work runs
Three steps. The first one is the product.
Everything else on this site follows from these three steps.
- 01
Discovery that ends in a written plan
A short piece of paid work. We sit with the problem and you get back a document that says what is being made, how it fits together, what order it gets built in, and what it costs. The plan is yours unconditionally. Take it to us, take it to another firm, or decide not to build at all.
- 02
A named team, and one person you can reach
The people who understood the problem build the thing. You get names rather than a rotating cast, and one lead who answers to you directly. If someone is not working out, we raise it first and manage the replacement ourselves.
- 03
Progress you can check, changes you can price
Work arrives in increments you can see and use, not in a reveal at the end. When scope moves, and it will, the change is costed in writing before anybody starts it.
On this service
In a delivery engagement, discovery produces the written plan, and the delivery lead then runs exactly that plan. You meet the lead during discovery, not after.
Ownership
What you own
From the first commit, everything belongs to you. Not at handover. From the beginning.
-
Code and repositories
All of it, in accounts you control. There is no private framework underneath and no dependency on continued payment to keep the thing running.
-
Infrastructure and keys
Cloud accounts, domains, credentials and certificates are created in your name. We hold nothing that you cannot revoke yourself.
-
Documentation
Decisions, diagrams and runbooks are written while the work happens, so the knowledge leaves with the documents rather than with the people.
-
The freedom to leave
If you stopped paying us tomorrow, the product would keep running without us. That is the test we design against.
Questions
Answered before you ask
Will you impose a methodology?
Will you impose a methodology?
Who do the engineers report to?
Who do the engineers report to?
What does reporting look like?
What does reporting look like?
What if the date is already promised to the board?
What if the date is already promised to the board?
Next step
Tell us where the delivery is going wrong.
One message is enough. It reaches the person who would run the work, not a sales desk.
The delivery problem
A few lines about the situation is plenty. We read every one.
It is with us.
Expect a reply within two business days. If we are not the right fit for the work, the reply will say so rather than dodge.