Manager is responsible for the whole team results. Making sure the team operates well requires not only managing software development processes, but also managing people, each one of them actually.
And manager’s duty is to actually manage the whole “lifecycle” of a developer — “from hire to fire”.
A manager should consider unexpected resignation letter from a developer as a “red flag”, a big sign of a fact that she’s got some trust issues in the team.
I think a good manager needs to know re-hire cost and time for each developer in her team, and plan replacement actions before the situation where a developer might leave emerges.
I am stating that working proactively is more effective than working in a usual reactive way.
By “proactive work” I assume following at least these guidelines:
- make sure you encourage both growth/career development and also accept the fact that some people are just fine playing the same role
- build trusting environment
- maintain professional ethics and support proper labour culture.
However, regardless how hard you try being proactive and trusting etc., people do leave sometimes, they leave for the reasons far beyond your ability to control.
A manager has to understand that she can’t possibly keep everyone loyal to the company forever, but as soon as she starts considering developer’s leave as a normal event that eventually will happen anyway, she will think more on what she and the team can achieve with this individual together.
As soon as the manager does that, she reduces her stress of managing developer’s leave.
I have a couple of advices on managing developer’s leave.
There’s a good saying that precisely characterises a catastrophic situation of managers’ low competency in the industry: “people join the company and leave bad managers”.
This saying is almost always true: a new starter has some trust and loyalty credit which diminishes more and more with each managerial fuck-up: starting with “cargo-cult” implementations of some practices and ending with abusing developer’s trust.
A good example of abusing developer’s trust is ignoring the issues she brings.
Now to the point: good manager can positively influence the newjoiners, showing them that pretty much any issue can and should be discussed in a stress-free way:
- manager shows that she accepts the fact that the employee will eventually leave the company anyway;
- manager will do her best to increase employee’s “market value” by supporting as much growth as the employee feels comfortable.
This is quite paradoxical: earlier the manager starts preparing the developer’s leaving, longer the developer stays.
Software development process generally is a process of constant knowledge accumulation.
It’s usually a good practice to record information that will be used in the future — test plans, product documentation, ADRs etc.
So it also might be a good idea to start collecting all the appraisal-worthy information for the employee — her growth history, her achievements, her participation in projects.
This record can be considered a “takeaway package” for the developer when she leaves — essentially a log record of how she helped the company and how she grew as a specialist.
If the manager explains a newjoiner that her takeaway package would have all this information, I don’t think she’d reject this nice addition to a good reference.
This approach also adds to employee’s feeling that the manager cares of both parties interests, not only about the company’s. And as a consequence, employee’s loyalty boosts.
So, earlier the manager starts preparing employee’s leave, longer and better the employee works.