The asset that walks out every evening: HR for a software business

A senior engineer resigned from a software firm and served a full notice period. During it, he was kept on delivery work because a release was due, and the handover was a document he wrote in his last two days that nobody read until a month after he had gone. By then a system three clients depended on was producing an error nobody could diagnose, because the only person who understood how it had been built was answering a different company's email. The firm hired a contractor at a premium to reverse-engineer what it had already paid a salary for.

Software HR has a shape other sectors do not: the cost is almost entirely salaries, the risk is concentrated in notice periods, and the asset is what people know and can still reach — which walks out every evening and, at exit, does not come back unless the exit was designed to keep it.

KNOWLEDGE    systems owned, not tasks done; code and pipeline
             ownership transferred; client and stakeholder
             introductions made in person; known issues and
             workarounds written down; shared credentials rotated
ACCESS       production and infrastructure first; source control,
             cloud and admin accounts; client systems and VPN,
             notified and revoked; device returned; email
             forwarding decided by policy, not by default

The notice period exists for the first column.
Spending it on delivery is spending the asset.

The firm in the opening used the notice period for the wrong thing. Handover is not a document written in the last two days; it is the receiving engineer sitting with the leaving one for the weeks the notice provides, on the systems that only the leaver understands, with the known issues written down as they come up. That requires the manager to take the leaver off delivery — which costs a release, and is cheaper than the contractor. Making handover a task with a named receiver and a manager sign-off, rather than a hope, is the exit and offboarding process in knowledge work, and it is the step that protects the business rather than the record.

1. 1

   Name the receiving engineer on day one of notice

   Not at the end. The handover is their job for the notice period, alongside the leaver's.

2. 2

   List the systems owned, not the tasks

   'Owns the billing integration' is a handover item; 'was working on ticket 4312' is not.

3. 3

   Revoke production access first, on the last day

   Then source control, cloud, admin, client systems. In that order, because that is the order of consequence.

4. 4

   Rotate anything shared

   Credentials the leaver knew are credentials the leaver still knows.

Engineers leave for interesting work and poor managers, and rarely cite either in an exit interview. Across most software businesses, attrition concentrates under specific managers far more than it correlates with pay — which is a finding businesses resist, because pay is easier to adjust than a manager. The most common pattern is the strong engineer promoted into management with no preparation, who then manages as they were managed, and loses the two best people on the team inside a year. Building capability before the first team, not after the first resignation, is what leadership and people management work in this sector is for, and the return on it is measurable in the attrition-by-manager report six months later.

The default ladder converts strong engineers into weak managers because management is the only visible route to more pay and status. A technical track — engineer to senior to staff to principal, with scope defined by technical influence rather than headcount, and genuine parity of pay and standing with the management track — is what keeps the engineers who do not want a team. Two things make it real rather than decorative: criteria for each level stated in observable terms, and a route back from management to the technical track that is not treated as failure. Engineers try management more willingly when returning is normal, and businesses that allow it lose fewer people to the experiment.

• Parity, actually. A principal engineer paid less than an engineering manager with the same tenure has been told which track the business values.
• Criteria in observable terms. 'Technical leadership' means nothing; 'designed the system three teams now build on' is something a promotion panel can ask for evidence of.
• The route back, stated. Management is a role, not a rank. Leaving it is a move, not a demotion.
• Progression visible. People can see what the next level requires, which is most of what makes a career path feel real.

Software businesses increasingly run across locations and remote arrangements, and HR processes that assume physical presence create friction with the population least tolerant of it. Joiner, exit and document processes have to be fully digital; policies on remote and hybrid work stated rather than negotiated case by case; and the boundary between work and everything else — on-call rotations, release periods, meeting load — treated as a wellbeing matter rather than as commitment. On-call design deserves specific attention: a rotation where the same people take most calls because they answer is a burnout mechanism with a schedule attached, and it is visible in the call logs long before it is visible in a resignation.

Three policies matter in this sector more than elsewhere and are often left unwritten: data handling and confidentiality where client data is involved, the position on moonlighting and intellectual property, and what client contractual obligations mean for internal practice. Each arises regularly, and inconsistent handling — one manager tolerates a side project, another treats it as misconduct — creates the real problem. Writing the three down, in a page each, is HR policies and governance work with an unusually clear payoff, and the moonlighting position is worth stating explicitly rather than discovering through a dispute.

Software hiring has a failure other sectors see less of: the accepted offer that is declined during notice, because the candidate used it to negotiate elsewhere. The businesses that lose least to this keep contact between offer and joining — a manager call, an invitation to a team event, the laptop configured and visible — and, more importantly, hire for the actual role. A hiring process that tests general algorithmic skill for a role that is mostly integration work selects people who will be bored in three months, and the recruitment process that describes the real work honestly, including the parts that are not glamorous, produces fewer surprised leavers. The interview panel should include the people the candidate will work with, not only the people senior to them, because the candidate is interviewing the team as well.

• Describe the real work in the advert, including the maintenance and the meetings.
• Keep contact through the notice period. An offer that goes silent for sixty days is an offer being shopped.
• Put the future team on the panel. They are what the candidate is deciding about.

The thread through all of it is that the firm's cost is people and its asset is what they know. Handover as a task, managers built before their first team, a technical track with real parity, access tied to the exit event, and the three policies written — that is what HR for IT and software companies work builds. The firm in the opening paid for the knowledge twice; software HR work exists to make sure the notice period is spent keeping it.