2) All new team members were automatically assumed to be terminated within a month or so. This was usually true. Any new employee that didn't pull their weight, sat around waiting for someone to tell them what to do, or lied in any way was terminated.
I've seen this more and more in places and I absolutely hate this. HATE.
Here's why.
#1. Some else mentioned "gladiator school" and I couldn't agree more. While funny, there is also quite a bit of truth to this. Programming et al is not sales and we should not treat it like sales. If someone isn't hitting their quota in sales, then sure, they can go (or stay for another quarter...who knows), but programming is different and we should have a different set of criteria for "not making the cut". But, by default, telling all new people "you will not be here past 30 days unless you are pulling your weight" is not the right way to motivate someone to do their best. Quite frankly, this is lazy management. EXTREMELY LAZY management (I'm saying this as a manager, fyi).
#2. I work for a multinational, so I also realize that most of these policies are in place where firing someone takes an act of god, but I also hate these policies b/c it takes so much out of the hands of the manager and removes responsibility from the manager. Bottom line, managers should be accountable for their employees and try to help them succeed. Policies like this make it too easy for below average managers to remain employed. And if there are few things I hate more than bad managers...we need many, many less bad managers.
#3. This is LAZY on the corporations part as well. I said it was bad management, but it is also bad corporate onboarding. The hard part of hiring someone, after finding a good fit, is bringing them up to speed. There are small things they need to know and, frankly, they SHOULD NOT HAVE TO ASK for, they should be told them on day 1. Policies like this make it all to easy to assume it is the new employees responsibility to find these things out. Hint, it is not.
What would I do? Well, as a former exec of a startup and now a high-level manager at a multinational, this is what I like:
#1. Have some sort of "welcome to the company" wiki page that has things like where to get the code, who to talk to about x, y and z, where to get access to various systems. What those systems are and why they exist. All high level stuff. Even more mundane things like communication channels and suggested software would be appropriate. Couple that with more mundane things like system setup, packages and versions to install (if needed).
This is all high level stuff. Almost anyone in the company would need these.
#2. for devs, how to setup the projects, get them running and showing positive signs they are working. All appropriate systems should be accessible and things like getting access to data, database etc etc should be something the person could walk through and do.
#3. Make sure the new employee knows they have a responsibility in this process to MAKE THE PROCESS BETTER for the next person. Meaning, as they go through the process and see something is wrong, missing or something else, they should fix it. This is the first positive contribution they are making. Inevitably, this happens and it is an easy and cost effective way to make sure the onboarding material is up to date and always improving.
#4. The manager must sit down, on day one and again at the end of the first week, and go over things like expectations, communication, reviews, how someone will be judged on performance etc etc. These are manager's responsibilities and set the tone for the company. If the manager appears disorganized, too busy or disinterested, imagine what the knew employee thinks? Take the time for the new employee...it is an investment...think of it that way.
#5. Give some clear goals for the first 30 days. You don't need to be concrete...but, point the person in the direction you want them to go and see if they start walking or running and see how/when they get to the point.
I could go on and on, but at the end of the day, I feel that lazy and poor management are a real problem and this point is an indication of that.
#3. Make sure the new employee knows they have a responsibility in this process to MAKE THE PROCESS BETTER for the next person. Meaning, as they go through the process and see something is wrong, missing or something else, they should fix it. This is the first positive contribution they are making. Inevitably, this happens and it is an easy and cost effective way to make sure the onboarding material is up to date and always improving.
This can be a lot harder and more stressful than it seems if the problems in the process are not something the new employee can actually fix and is expected to bug other people to make the necessary adjustments (gaining access to systems and following proper procedures wrt coding style and documentation, in particular). This forces the new employee to immediately become a pain in the ass rather than an actual contributor.
A mentor tasked with onboarding the new employee will be far better equipped to be responsible for tweaking the process. (Whoever actually pushes the buttons matters less than who owns the job in this case). Too often a new employee facing an onboarding problem will be stumped not even knowing the right question to ask. Leaving them to figure it out on their own is horribly inefficient.
I have seen this nearly every place I've worked and inevitably, it's months before the new employee actually acquires the mundane institutional knowledge, relationships, and perspective required to effect the necessary changes, meanwhile there were plenty of other options for worthwhile contribution that don't involve fixing an onboarding process that should have been someone else's repsonsibility.
* db table named x no longer exists, new name is y
* email setup didn't work anymore...I did x, y and z and it worked
That sort of thing. The overarching process, you are correct, and I didn't mean to impart that responsibility onto the new employee...more specific details they might find in the process of going over documentation etc.
Your 1, 2, and 3 would have saved me (and others) quite a lot of time in some places I've worked. It helps for new hires and (in a large company) transfers from other parts of the company. Sometimes it even saves long-time employees a lot of effort when setting up a new machine or helping out on something they haven't touched in a while.
I've seen this more and more in places and I absolutely hate this. HATE.
Here's why.
#1. Some else mentioned "gladiator school" and I couldn't agree more. While funny, there is also quite a bit of truth to this. Programming et al is not sales and we should not treat it like sales. If someone isn't hitting their quota in sales, then sure, they can go (or stay for another quarter...who knows), but programming is different and we should have a different set of criteria for "not making the cut". But, by default, telling all new people "you will not be here past 30 days unless you are pulling your weight" is not the right way to motivate someone to do their best. Quite frankly, this is lazy management. EXTREMELY LAZY management (I'm saying this as a manager, fyi).
#2. I work for a multinational, so I also realize that most of these policies are in place where firing someone takes an act of god, but I also hate these policies b/c it takes so much out of the hands of the manager and removes responsibility from the manager. Bottom line, managers should be accountable for their employees and try to help them succeed. Policies like this make it too easy for below average managers to remain employed. And if there are few things I hate more than bad managers...we need many, many less bad managers.
#3. This is LAZY on the corporations part as well. I said it was bad management, but it is also bad corporate onboarding. The hard part of hiring someone, after finding a good fit, is bringing them up to speed. There are small things they need to know and, frankly, they SHOULD NOT HAVE TO ASK for, they should be told them on day 1. Policies like this make it all to easy to assume it is the new employees responsibility to find these things out. Hint, it is not.
What would I do? Well, as a former exec of a startup and now a high-level manager at a multinational, this is what I like:
#1. Have some sort of "welcome to the company" wiki page that has things like where to get the code, who to talk to about x, y and z, where to get access to various systems. What those systems are and why they exist. All high level stuff. Even more mundane things like communication channels and suggested software would be appropriate. Couple that with more mundane things like system setup, packages and versions to install (if needed).
This is all high level stuff. Almost anyone in the company would need these.
#2. for devs, how to setup the projects, get them running and showing positive signs they are working. All appropriate systems should be accessible and things like getting access to data, database etc etc should be something the person could walk through and do.
#3. Make sure the new employee knows they have a responsibility in this process to MAKE THE PROCESS BETTER for the next person. Meaning, as they go through the process and see something is wrong, missing or something else, they should fix it. This is the first positive contribution they are making. Inevitably, this happens and it is an easy and cost effective way to make sure the onboarding material is up to date and always improving.
#4. The manager must sit down, on day one and again at the end of the first week, and go over things like expectations, communication, reviews, how someone will be judged on performance etc etc. These are manager's responsibilities and set the tone for the company. If the manager appears disorganized, too busy or disinterested, imagine what the knew employee thinks? Take the time for the new employee...it is an investment...think of it that way.
#5. Give some clear goals for the first 30 days. You don't need to be concrete...but, point the person in the direction you want them to go and see if they start walking or running and see how/when they get to the point.
I could go on and on, but at the end of the day, I feel that lazy and poor management are a real problem and this point is an indication of that.