A backend developer resigns on a Tuesday. The mail says 'better opportunity'. Her manager is startled, because last cycle's rating was strong. Three weeks later, over tea after her final day, she explains. Eight months on a legacy maintenance account. A regression suite full of flaky tests. A release window that kept ending in a Sunday rollback. And a promotion that moved her title but not her work.
That is the usual shape of an exit in a software firm. The reason on paper is generic. The reason underneath is tied to an account, a lead or a stretch of months. Below are the causes that surface most often, then a method for hearing them before the next resignation.
Weeks on the bench
When a project closes, the developer waits for the next allocation. Some firms fill the gap with internal tooling, test automation or a course. Many leave it blank. A person parked on the bench with no plan feels disposable, and recruiters scent it within days. Count idle weeks per person and find out who decides the next allocation. If the decision goes to whichever delivery head calls loudest, the bench will fall unevenly and the unlucky will leave.
Scope creep on fixed-bid work
A time-and-material engagement bills the hours. A fixed-bid one bills the outcome, so every unpaid change request is absorbed by the team in extra evenings. Developers know which of their accounts hide this. They watch the story points burn, the backlog grow and the change-request log stay empty because the account manager fears the client. Ask how many change requests were raised last quarter per fixed-bid account. A zero is a warning, not a compliment.
Night overlap and the on-call phone
Teams serving clients in other time zones work an overlap window that can run until one in the morning. Add a pager rota for production incidents and the strain compounds. People take it for a year, then take a day-shift offer. Rotate the overlap shift, pay a clear allowance, and give a compensatory day after a night with a P1 incident.
What developers say when the talk turns honest
- No time for refactoring: the payment webhook has no idempotency keys, but the sprint is full of change requests.
- Staging without parity: the schema migration passes on staging, then fails on the production Postgres replica.
- Tooling from another decade: an on-prem Jenkins box, a Java 8 monolith, no linter, no canary and no feature flags.
- Pull requests merged unread on Fridays because the reviewer is on a client call.
- A flame graph that nobody has time to open while latency complaints keep arriving.
- A Terraform change that only one person understands, and he has already updated his profile.
None of these is a pay complaint. Each is a craft complaint, and a developer who feels the craft is rotting begins reading job ads.
Release trains, rebases and the people who carry them
Every firm has a release manager, a build engineer or a DevOps hand who owns the pipeline, the staging box and the rollback script. Add the QA lead who maintains the regression pack and the support engineer who answers L2 tickets under an SLA clock. These roles keep the product alive and rarely appear in a promotion memo. A merge freeze, a failed cherry-pick and a broken nightly build all land on them. Their exits are the costliest, because the knowledge-transfer session on the last Friday never captures what lives in their heads and their runbooks.
Appraisals nobody can read
A yearly rating with no reasons teaches developers that effort and outcome are unconnected. Velocity trends, code review quality, defect leakage after release and mentoring of juniors are all visible. Yet ratings often follow whichever lead spoke last in the calibration meeting. Publish what each level is expected to do. The performance management process for custom software firms lays out the method.
A ladder that ends in fog
Many firms show a clear path from trainee to senior developer, then nothing. Is the next rung tech lead, architect, delivery manager? Strong engineers who dislike managing people look for a firm with a principal-engineer track. Draw the ladder with titles, expectations and pay bands. The competency and talent page covers skill matrices and level descriptions.
The counter-offer reflex
A counter-offer works rarely, and the person often leaves again within two quarters. It also tells the team that a resignation is how you get a raise. Decide beforehand what you will and will not match, and set pay bands so outside offers do not come as a shock.
Hearing the real reason
- 1
Tag every exit
Record account, manager, tenure band, level and last rating. Patterns surface in tags before they appear in comments.
- 2
Talk late
Meet two weeks after notice, not on the final day. The person is calmer and no longer needs the reference.
- 3
Use an outsider
An HR partner, or a senior from another team. Never the manager of the person leaving.
- 4
Ask three things
What nearly made you leave six months ago? What should the next hire ask in the interview? What would have kept you?
- 5
Hold stay interviews
One hour each with the people you cannot lose. Ask what they enjoy, what grates and what a rival offer would need.
- 6
Review each quarter
Put tags on a single page and ask which account, lead or process is over-represented.
We build such routines under retention and attrition management. Related reading sits at the software development hub.
Monday actions
- Pull the last twelve exits and tag each by account, lead and tenure.
- Log out-of-hours work for four weeks, name by name.
- Ask every delivery head who has sat on one account for over a year.
- Book three stay interviews with people you cannot lose.
To turn this into a standing routine, outline your teams through our enquiry wizard.
