You hired three engineers and delivery did not increase for a quarter. Each new person spent weeks getting an environment running, then more weeks discovering conventions that exist but are written down nowhere. This is not a hiring problem and it is not about individual capability - it is a property of the system they joined, and it is measurable.
01Measure time to first meaningful change
Track the days from a new engineer's start to their first merged change that affects users. Not a documentation typo - a real change. This single number captures environment setup, access provisioning, code comprehension and review latency in one figure that is hard to argue with.
Where that number is measured in weeks, the details of where the time went are usually well known to the person who just experienced it. Ask each new joiner to record what blocked them, and treat the resulting list as a defect backlog rather than as feedback to file away.
| Stage | Common blocker | Fix |
|---|---|---|
| Environment setup | Manual multi-day process | Scripted setup or containers |
| Access provisioning | Requests handled ad hoc | Role-based access on day one |
| Understanding the domain | Nothing written down | Architecture and decision records |
| First change | Unclear where to start | Curated starter issues |
| Review | Days of waiting | Review expectations and rotation |
02Local setup should be one command
If starting the application locally requires following a wiki page of manual steps, that page is out of date and every new joiner will lose days rediscovering the corrections. The steps that are missing are precisely the ones existing engineers configured long ago and no longer remember.
Aim for a single scripted command that produces a working environment with seeded data. Verify it by having the next new joiner use it without assistance and record every point at which it fails, then fix those before the following hire.
03Write down why, not what
Code shows what the system does. It cannot show why one approach was chosen over an alternative, what was tried and abandoned, or which constraint made an odd decision correct. That reasoning lives in people's heads and leaves when they do.
Short architecture decision records - context, options considered, decision, consequences - address this at low cost. A page per significant decision saves repeated explanation and prevents new engineers from proposing approaches that were already ruled out for reasons nobody recorded.
| Document | Answers |
|---|---|
| System overview diagram | What are the pieces and how do they connect? |
| Decision records | Why is it built this way? |
| Runbooks | What do I do when this breaks? |
| Local setup script | How do I run it? |
| Glossary of domain terms | What does this word mean here? |
04Curate the first tasks
A new engineer given a vague large task spends weeks reading code before writing any. A curated small task in a well-understood area produces a merged change in the first days, which establishes the full workflow - environment, review, deployment - while the stakes are low.
Maintain a set of such tasks continuously. They are usually small improvements that experienced engineers keep deferring, which makes them genuinely useful work rather than artificial exercises.
05Review latency compounds
When review takes two days, a new engineer completes a fraction of the learning cycles they otherwise would in their first month. Each cycle is where feedback on conventions and expectations arrives, so slow review directly extends ramp-up beyond the delay itself.
Set an expectation that review happens within a working day, and pair new joiners with a named person responsible for unblocking them. That relationship handles the many small questions that would otherwise each cost hours of independent searching.
Topics
Lena Voss
Lead Architect · SyncTrix
Writes about the engineering decisions behind production systems - architecture, delivery and the trade-offs that only show up at scale.
Building something like this?
SyncTrix engineers AI, SaaS, platform and cloud systems for enterprises and high-growth teams. Tell us what you're shipping and we'll scope it with you.
Talk to an engineer