The delay is never the engineer's skill. Four tracks have to complete before anyone merges anything — paperwork, access, environment, codebase knowledge — and they are owned by four different teams. Environment provisioning is almost always the critical path, and it is almost always started last. Reverse that one ordering and you remove most of the wait. And measure time to first merged change rather than a start date, because the start date is a fiction everybody agrees to.
Every bank that has brought in external engineers has the same story: good people, hired to solve an urgent problem, sitting idle for weeks. It gets explained as bureaucracy, which is unhelpful because it suggests nothing can be done. Most of it is an ordering problem, and ordering problems are fixable.
Four tracks, one of them long
Why the environment is the hard one
Paperwork and account creation are well-understood processes with owners and precedents. Slow, sometimes, but legible.
A development environment that can reach a core banking host is a different proposition. Host environments tend to be shared and scarce. Any new connection between systems attracts security review. Changes land in scheduled windows rather than on request. And for a channel platform, an environment is useless without something to integrate against — provisioning a workstation achieves nothing if there is no host to talk to. We ran into exactly this constraint writing about integration against a non-FLEXCUBE core, where testing against a shared host is routinely the slowest part of the work.
Because it is technical and cross-team, it also lacks a natural owner, so it tends to be raised only when someone notices the new engineer has nothing to do.
Four things a bank can prepare before signing
Name one person accountable for access end to end. The usual delay is not any single approval, it is the gaps between four teams each waiting on another. One owner with a list collapses most of it.
Settle the device and connectivity pattern in advance. Whether the engineer uses a bank-issued laptop, a managed VM or their own machine under policy is a decision with a precedent somewhere in your organisation. Arguing it after someone has started is pure lost time.
Book the environment as a long-lead item. Not a provisioning ticket raised on day one — a scheduled resource requested while the contract is still in legal.
Prepare a sanitised codebase and its documentation that can be shared under NDA before full access exists. This is the cheapest of the four and the most consistently skipped.
What the engineer can honestly do while waiting
Real work, but less than people hope, and it is worth being clear-eyed about the difference.
With a sanitised codebase they can read it, map the architecture, write tests against mocks, draft the first changes, and ask in week one the questions that would otherwise surface in week three. What they cannot do is verify anything against a real system, so every assumption stays provisional. Work done against mocks frequently needs revisiting when the real host behaves differently — which it does, particularly around error semantics.
So treat this period as reducing the cost of the wait, not eliminating it. Planning that assumes otherwise produces a nasty week four.
On the billing clock
A vendor ought to say this plainly: the clock should not start while your engineer waits for a VPN account.
Billing from a notional start date turns an administrative delay into the client's cost. It is unfair, and it is corrosive to exactly the relationship that makes augmentation work at all. The fairer structure ties the commercial start to a defined readiness condition, with a short preparatory period covering the work that genuinely can be done against sanitised material.
It also aligns incentives properly. A vendor who is not being paid to wait has every reason to help chase the access, which is usually worth more to the client than the fee being argued over. This is the same thinking we set out in how to choose a development partner — the terms reveal whose problem the vendor thinks the delay is.
Measure time to first merged change
Not the start date. A start date records when a contract began and says nothing about capability, which is precisely why it is comfortable to report and useless to manage.
Time to first merged change captures the whole chain in one number — access, environment, comprehension, and the review process that most people forget to count. Someone can be accountable for it. Tracked across a few engagements, it becomes the fastest diagnostic you have for which track in your own organisation is actually the slow one, which is rarely the one people assume.
Questions we get asked
Why does it take so long?
Almost never the engineer. Four things must complete before a line merges — paperwork, access, an environment that can reach the real systems, and enough codebase knowledge to change it safely. Four different owners, started in the order that suits the organisation rather than the order that shortens the wait.
What's the critical path?
Environment provisioning, and it's usually started last. Host environments are shared and scarce, new connections attract security review, changes land in scheduled windows. For a channel platform the environment is useless without a host to integrate against — a workstation alone achieves nothing.
What can we prepare in advance?
Name one owner for access end to end; settle the device and connectivity pattern before anyone starts; book the environment as a long-lead item while the contract is still in legal; and prepare a sanitised codebase shareable under NDA. All four can begin before signing.
What can the engineer do meanwhile?
Read, map the architecture, write tests against mocks, draft first changes, and ask in week one what would otherwise surface in week three. What they can't do is verify anything real, so assumptions stay provisional — mock-based work often needs revisiting, especially around error semantics.
Should billing start before access exists?
No, and a vendor should say so. Billing from a notional start date turns an administrative delay into your cost — unfair, and corrosive to the relationship augmentation depends on. Tie the commercial start to a readiness condition. It also aligns incentives: a vendor not paid to wait helps chase the access.
How should we measure onboarding?
Time to first merged change, never the start date. A start date records when a contract began and nothing about capability. The former captures access, environment, comprehension and review in one number somebody can own — and across engagements it shows which of your own tracks is genuinely slow.
We work as an embedded team inside banks and their implementation partners, which means we have waited for a lot of VPN accounts. The preparation list above is what we now ask for before a start date is agreed, because agreeing one without it just moves the disappointment.