SDLC, DevOps & Developer Experience · Chapter 7 of 15
Day zero to the first pull request
The path a new developer actually travels in a regulated enterprise — and the metric that tells you whether your platform works.
The previous chapter is about whether anyone wants your platform. This one is the test of it. Everything a platform team builds is exercised, in order, by one person on their first week — and if that week is bad, no adoption dashboard is measuring anything real.
The number to hold yourself to
A merged pull request by the end of week one.
In most banks it is three to six weeks, and almost all of that delay is access, environment and certificates — not the work itself and not the developer's capability.
Which means it is a platform defect, not an onboarding fact. Treating it as a fact of life is how three weeks becomes permanent.
Phase 1 — before they arrive
Background checks run first: criminal, credit, employment, education, and for regulated roles a check against the relevant register. This is a hard gate and it is outside your control — plan around it rather than complaining about it.
The identity system is the load-bearing part. Workday, SuccessFactors or Oracle HCM is the authoritative source, and everything downstream keys off it: employee ID, job code, department, cost centre, manager, location, worker type. Get the job code wrong and every access decision for the next year inherits the error, usually silently.
From that record, birthright access should fire automatically — directory account, mailbox, standard groups, network entitlement. Nobody should have to request the things every developer gets. The laptop is ordered against the same worker record, imaged with the standard build, enrolled in device management with encryption and endpoint protection already on it.
The single highest-leverage fix in this entire chapter, and it is a calendar change rather than an engineering one.
Have the manager approve the developer access bundle BEFORE the start date.
If approval starts on day one, you have already lost a week to a queue — and you will spend that week explaining to a new hire that this is normal.
It costs nothing, needs no platform, and it is skipped almost everywhere because the approval sits with someone whose calendar nobody manages.
Phase 2 — day one
- Badge (usually driven from the same identity feed), first login with a one-time credential, forced change, multi-factor enrolment, device registration.
- The network client — VPN, or a zero-trust access client. Note that zero-trust policy is itself identity-driven, so a missing group here presents as a broken network and gets debugged as one, sometimes for a day.
- Mandatory training — code of conduct, information security, data privacy, and in a bank anti-money-laundering, personal account dealing and records management. Frequently a hard gate on everything after it, which is worth knowing before you promise a productive day one.
- Communication tools, the intranet, and the portal itself — which is where the rest of this journey is supposed to be self-served.
Phase 3 — role access, and it must be one bundle
Every item below should arrive from a single access request, not eleven. This is what an identity governance platform is for, and it is the difference between a day and a fortnight.
| System | What the developer gets |
|---|---|
| Source control | Organisation and team membership — which drives repository access through code ownership rules |
| CD platform | A project role, typically execute on non-production and view on production |
| Artifact repository | Read on the virtual repositories. Write belongs to CI service identities — humans should not be pushing binaries |
| Code quality and scanning | Browse and see issues on their own team's projects |
| Cloud consoles | Read-only day to day. Elevation is just-in-time and time-boxed — never a standing admin role |
| Secrets manager | A namespace policy scoped to their team's paths |
| Observability | Read on their own services |
| Ticketing and change | Raise changes, see their team's backlog |
In a regulated environment the request runs a separation-of-duties check before anything is provisioned. The classic violations: the same person able to write code and approve its release to production, or to raise and approve a change. Catching that at request time is cheap; catching it in an audit is not.
Phase 4 — a working environment, and where the days actually go
This is the most under-estimated stage in the whole path. On a corporate network almost nothing works with default settings, because every package manager, every runtime and every command-line tool has to be told about the proxy and made to trust the inspection certificate that the network puts in front of everything.
Each of those is a support ticket waiting to happen, and they are not interesting problems — they are the same problems, for every joiner, forever. There are two ways out and the second is strictly better:
- A documented setup guide. Better than nothing, goes stale immediately, and still costs every joiner a day.
- A development container. The proxy settings, certificates, registry configuration, runtime versions and tools are in the image. The developer runs one command and it works the first time. This is the single fix that removes phase 4 rather than shortening it.
Then the things that are easier to do now than later: an approved IDE extension set including the scanners that make later gates painless; pre-commit hooks for secret scanning — catching a credential before it reaches the remote is worth more than any downstream scanner, because a secret that reached the server must be rotated whether or not it was ever exposed; and commit signing enrolled on day three, not on the day their first pull request is blocked by it.
Phase 5 — the first line of code
If the first four phases were done properly, this is an afternoon, and it is the part the platform was built for.
- The portal answers ‘what does my team own, and where is its source’ without asking a colleague.
- The scaffolder takes four inputs — a name, an owning team, a cost centre, a data classification — and creates the repository from a template, code ownership, branch protection, the pipeline, the scans, the artifact repositories, the observability wiring, the on-call rota and the catalog entry. Compliance by construction: the developer never had to know the standard existed.
- It runs locally in one command, because of the container from phase 4.
- A signed commit on a branch. Branch protection requires an owner review and a green pipeline.
- Findings appear as comments on the pull request, not in a separate portal the developer has to remember to open. A finding nobody sees is not a control.
- Merge builds an immutable artifact, publishes it, and deploys it to development automatically.
The metric
Time from start date to first merged pull request
Instrument it. Publish it monthly. And treat every week of it as a defect in the platform rather than a fact of life.
It is the single most honest measure of whether the platform works, because it is end-to-end, it cannot be gamed by a team optimising its own stage, and unlike adoption counts it measures something a human actually experienced.
And it has a property most platform metrics lack: every person who suffers it can tell you exactly where the week went. The data collection is a conversation.
Compare it with ‘teams onboarded’, which goes up whether or not anything got better. See the measurement chapter for why that distinction is the whole argument.
The uncomfortable reading: almost none of the delay in a bad first week is technical. It is an approval that nobody scheduled, a training module that gates everything, a group membership that presents as a network fault, and a proxy certificate. Which is why this is a platform-team problem rather than an IT one — the platform team is the only group that sees the whole path, and everyone else optimises their own segment of it.
Check yourself