It has nothing to do with the robustness of processes. Product companies usually have well defined robust and practical processes. The point is, how are you going to replace somebody with say 5 years experience in font technology and responsible for lac's of lines of code in the system with somebody new to the team with no experience in that area. The documentation will be there, the code is there to see, there will be thousands of unit tests, but its still not going to be easy.
With this notion, it should take 5 years of ramp-up/transition period for the new hire to be a perfect replacement!
But why would you hire a person with no experience to replace a 5yr exp position? I was exactly in the same situation once but it wasn't painful at all.
--- I just deleted long explanations around the processes we follow, as my company's PR department won't allow such discussions on a public forum without their consent. I'll see if I can get the case-studies on our work culture that's part of Harvard/Yale curriculum. It'll be then easier for you to understand how lacs of lines code cannot be the responsibility of just one person. ---
In short: It's all about planning. LOE for each activity is well defined, even for a 2yr long project. Based on the complexity of the phase, buffers are incorporated to take care of any contingencies (sick time, attrition, server downtimes etc). Backups are identified for each person and are trained to handle more than one module (for swaps during downtime). Critical time is only for few days - so we can always figure in redundancies. Everything is shared with the clients. With so much planning and regular training, it's not at all difficult to make up for a missing employee.
And if the vacant position is a crucial one then you don't have to replace it with a total stranger. Provided you conduct cross-module training regularly, someone else from the existing team can take over the position, while the new hire is given a less complex module/position etc. It happens all the time in my company. We maintain skill-matrix at various levels, where everyone including managers/directors are required to gain knowledge of another module/business-area in a stipulated timeframe. This is separate from company level training and is part of the project contingency plan.
There will be reviewers and there will be other people who can take over in case of an emergency as well, but they have their own work to take care and the loss of employee still has to be balanced out. Its not like 2 of your colleagues would be ready to work 4 hours over-time for next 4~5 months because you are leaving the company and don't feel like properly preparing another person to transition into your role before you leave.
Employee leaving midway is a known risk and like all other contingencies, a mitigation plan/buffer is incorporated during project planning. 4~5 months overstretch is too much. A replacement takes place much sooner.
I am not advocating leaving the company without notice or proper handover. It's about sudden/unplanned exits, as well as stretching the notice period unnecessarily (beyond the transition period).
Every company faces day-to-day operational issues, but most of them are repetitive in nature and that gives you the option to plan better for the next occurrence. If you see yourself suffering because of employees leaving in huff and puff, won't you do something about it? It's easy to introduce bonds and notice periods but what about the worst case scenario (where someone just walks away or dies)? Just by ensuring regular cross-module training, updated ramp-up docs etc you can have the best of both worlds. This is the 'robust' process that many companies lack or just have it on paper.
Being able to replace anybody with anybody else in 3 working days can only happen in software services sector and there too, there will be some exceptions. For example, if a employee working on a mission critical real time embedded software decides to leave, you cannot randomly pick some java developer off the bench, give him a 3 day crash course on embedded systems, RTOS, C and assembly and have him working on the project and relieve the guy who wants to leave.
Why would you pickup a Java guy for something unrelated? At times we've resorted to something similar (tech guy moving to QA) but obviously not in 3 days and not even on the project time/billing.
We've got an internal process where a person can move from one technology to another, which entails training, tests and stuff like that. It's for certain roles and not applicable to everyone as they might not possess the required experience. Obviously, we just hire a person with required skills/experience if we don't have a ready back-fill.
I agree with you that it's easier to implement such processes in software services sector. But there's no reason that a product based company can't adopt better processes.
I've seen such struggle when I happened to work alongside Amazon team. It wasn't Amazon's project though... lots of companies use Amazon's platform for their business. People from this team didn't know how their system integrates with others (no insight of the project apart from their own stuff). It was usual to touch base with at least 5 people to understand a simple business flow. At times I had to walk kilometers up and down the building just to find out how a particular SKU gets created.
No wonder you can't replace such employees... even with years of transition.
While working on a bank merger during the 2008 slowdown, I met lots of aged coders and some were at VP level. These guys were writing code for the last 30 years. No matter how much you'd coerce them, they won't open up and share their module details. They didn't have any sort of documentation either. This is hard to digest but it's also one of the realities why US banks didn't know that they were heading for a disaster. They used to capture mortgage details on loose sheets of paper. They would update the system at their will.
No amount of transition time can ever be sufficient to replace such people.
Yes, I understand how product based companies are managed (or rather mismanaged). In both the above examples, the work was getting transferred to us. That means the broken processes of these product based companies were about to get fixed. Getting anything done during those years was a nightmare for me.
Also, Product companies don't hire people in herds and over allocate to projects or have them on bench as standby. In many cases, anybody with over an year or two years experience would be expected to work like an individual contributor with their own individual responsibilities.
Even we don't have that much capability to maintain a bench but we strictly don't allow anybody to work in a silo. By allowing people to work individually, you are just building up for the mess that gets created when such a person leaves. Nobody is irreplaceable in my company.
...but if the person who is leaving is around for a reasonable period to help with the transition, it usually gets done a bit faster.
Of course! No two thoughts about it. Leaving a company without proper handover is unethical.
My own strategy that I follow is to transition knowledge to others at every opportunity I get. My motto is that I should be able to resign anytime and the company should also be able to fire me anytime they want to.
^^ the same reason we insist on daily meetings and up-to-date repositories... if everyone follows such processes company-wide then you won't suffer due to untimely exits and also be able to cut costs on entertaining employees serving on notice periods. Transition time can be planned better. Right now, it deliberately gets stretched to 30/60/90 days.
