If you have a strongly cross-functional, collaborative team, then a new person isn't nearly as much of a problem to bring on. As an example, Atomic Object is a midwestern software development shop that follows practices like pair programming, collective code ownership, short iterations, and a lot more. For them, interships and apprentices aren't a big problem, and have been key to their growth:
https://spin.atomicobject.com/2011/10/04/interns-and-apprent...
I also think it's worth looking at why people change jobs. I agree it's common, but I also believe that sucky jobs are common. If people leaving is such a problem, I'd like to see companies put more effort in to making them happy where they are. Not only would that be the humane thing to do, but it would make the ROI on investing in employees higher.
^ this, can't agree enough.
In Asia, it's not as cut throat as USA, where you shop around every 2-3 years. Japan they'll train you, and quitting isn't something that's easily done -- watch any Japanese netflix series about slice of life/normal life and you'll see the daily struggle or just read the news, or if you have the chance, go to Japan. Death by overwork is real and on the other hand, companies such as Rakutan will hire newly minted devs from schools that may know nothing and use the herd of workers to make them catch up.
Philippines and Indonesia is also similar with OJT training and filling seats.
Can't comment for anywhere else in Asia. But it is really 180 compared to USA.
Back when I was graduating, we had TCS come to our Tier-I college. The recruiter started off by telling that the salary they will be offering was 250,000INR/yr (then about 7K USD/yr) and that those who found it too low were free to leave. About half the class walked out. The rest stayed, most were offered a position.
which is where the service contract comes in
Also, you bring up an important point about time at the company. Anecdotal, but seems like a lot of devs spend 2-3 years at a company before moving on. That cycle is so short that the company doesn't think it's worth investing in junior people and doing so may even be considered counterproductive; the common view is that it's like investing in competitors. I'd like to think I'm wrong about that, but so far it remains a nagging impression.
I mean, a mediocre engineer that knows the system well is way more useful than an excellent engineers that just got his hands on it, for like half a year or more depending on complexity. If you give guidance you don't need excellent engineers. At least not as many. It's kinda surprising the way companies think of this.
Rather than officially allocating a developers time for introducing new employees or writing documentation for the system, Company 101 is to put 10 or 100 times the amount of dev time into catching up for the devs replacement when he quits, after he quits.
<plug> http://skillerwhale.com </plug>
Speaking with a CTO of a small web company recently I got to understand the issue from both perspectives.
CTO’s thoughts when hiring junior devs:
- Can be great for company but only if it makes economical sense I.e the developer stays with the company long enough after training
- From experience, the best devs from training move on to other companies soon after training
- Junior devs ask for frequent pay rises that aren’t viable for the company, holding the companies investment in the dev against them
Thoughts of a junior when considering other roles: - How respected & valued will they be old vs new
- How interesting is the work, and will there be continued opportunity to develop themselves and learn new skills old vs new
- Salary old vs new
- The potential for future career prospects old vs new
Good junior devs will naturally be very enthusiastic and eager to learn, and the company needs to support this through and beyond the training to keep them motivated and engaged. On top of this, juniors will want to see regular progressions through the training process in forms of clear recognition and increases in pay and responsibilities as they progress. If these are not given, it’s likely the junior will feel under appreciated / taken advantage of.
Progression through a training course like this is motivated by success, and rewards, not unlike video games.
In my opinion the best way a company can keep a junior happy is to follow this and apply some of the proven methods researched and applied all over the video games industry.
- Progressively difficult but achievable tasks (missions)
- A sense of accomplishment from these (contributing towards real projects)
- Regular checkpoints ( targets and 2-3monthly reviews to support these)
- Regular rewards (small but regular pay increases, matched with greater responsibility and clear recognition of progression in the company; mutual respect is important!)
The list goes on.
If an approach like this is followed, the dev is much more likely to come out of training with a great sense of achievement and an attachment to the company for the support and rewards that were received. I think this massively increases the chances of a dev staying on, Provided salary, job title and sense of respect are matched with other members of the team in similar roles. I feel this is something many companies don't put enough thought into considering the large investment they're putting into the dev.