The best teams I've ever worked for had this set of common traits:
1) On the offer day, potential employees were told there were high expectations and no fixed rules to govern what that meant. There was leniency in some cases, but manager/supervisor judgement was the only rule that mattered. No handbooks or rule sets.
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.
3) Human mistakes (fat fingers, brain farts, etc.) were reprimanded internally but covered, responsibility-wise, by the manager or supervisor externally. (I got this treatment at least once a year...)
4) Repeated or dumb mistakes meant being terminated, usually within the same business day. (I saw this happen many times. Not fun but then again they were dumb or repeated mistakes.)
5) Lots of communication within the team. Supervisors and managers were always available or actively participating in the projects.
In other words, there were high expectations and they were strictly enforced, with nowhere to hide mistakes or divert responsibility. Or, more bluntly, "we want to work with adults, not children".
Sounds harsh perhaps, but these were the best teams I've ever worked for and no one who stayed for more than 6 months felt used, abused, or anything other than lucky to be working with fine people. When long-time employees left, it was to start their own businesses or go back to school and there were always a few tears in the parting days.
Now, if you read in some book or learned in a training course that you need to cover your butt legally at all times, give everyone plenty of chances to do the right thing, and take everybody's situation into consideration before taking disciplinary action, your teams are going to start sucking. Why? Because all of those things are the opposite of management. Those things are what you do to avoid management.
This whole article, to me, says "boy, it'd be so much easier to run this business if I didn't have to actually run this business". Here's a hint: If your strategy for managing a team or community or whatever is "people should do the right thing and we should give them every opportunity to do that", then your team's problems aren't actually your team's problems.
> 3) Human mistakes (fat fingers, brain farts, etc.) were reprimanded internally but covered, responsibility-wise, by the manager or supervisor externally. (I got this treatment at least once a year...)
I don't understand why you would reprimand people for making human mistakes. The only thing it does is encourage people not to report their mistakes. A better response, in my opinion, would be to look at circumstances of the mistake, and build tools that make the mistake much harder to make. The VP of Ops at my company wrote more about our philosophy here: http://codeascraft.etsy.com/2012/05/22/blameless-postmortems...
> 4) Repeated or dumb mistakes meant being terminated, usually within the same business day. (I saw this happen many times. Not fun but then again they were dumb or repeated mistakes.)
What's the difference between a dumb mistake (rule 4 applies) and a human one (rule 3 applies)? I guess I don't understand what this means.
A human mistake comes from the fact that we are fallible humans with crappy memories and fat fingers and a working set of beliefs about the world that may be entirely wrong. Type something in wrong? Why didn't you verify or have someone else verify? Forget something or leave something out? Where's the checklist that you made for yourself to prevent that from happening? Make a bad assumption? Why assume at all when you could have verified?
You get the reprimand to be reminded that, while pushing the envelope is a good thing, there are real consequences to screwing up and not having all of the loose ends tied up. Saying "I didn't know" or "I didn't realize" is like saying "it's not my fault". In reality, you can't prevent these things from happening, but you better damn well try. That's what you get paid to do, in other words, to prevent your humanity from screwing up your hard work and brilliance.
Oh, I should have mentioned, that you're expected to yell at yourself more than your boss does. It really helps prevent having your boss do it for you!
But, like I mentioned in point 3), thesearecovered by management. No need to have them get in your review or affect your future at the company. You're human, it's OK, just be sure and learn from it.
A dumb mistake is one where youknowbetter. Like you just decide out of the blue that you'll take that call from an old client during business hours, while your boss's boss is taking clients through the building. Or you were told not to do something, explicitly, but you decide that you'll do it anyway. Repeated mistakes are ones where you make the samemistake and didn't learn your lesson.
Some_Developer "m104, I screwed up the system because I pushed out the development build on production."
m104 "Well Some_Developer, next time you make a list or you're fired, you should be kicking yourself for this mistake"
That doesn't solve the problem of why Some_Developer was doing a build, why Some_Developer could have done a dev build on production and why there is no pre-production environment.
If you read the blog post (http://codeascraft.etsy.com/2012/05/22/blameless-postmortems... ) you'll see that there are two opposing views to human error. The side I stand rather firmly on is the idea that if ANY person can bring our system down with a few keystrokes or cause hours of pain then we have a VULNERABILITY in the system. I don't care about fat fingering, I don't need to remind people they are stupid, I don't need to give warnings or last chances. I don't care about WHO ore WHY I want to know HOW to fix it.
Reprimanding for human error achieves the opposite effect and is a common trait of weak/inexperienced management.
Ah, I can see why our opinions differ so much: you believe that human error can be mitigated or eliminated with the right systems, training, documentation, procedures, etc. In other words, you can build a system that, while being run and maintained and managed and extended by humans, will prevent human weakness from crippling the system. Within that view, blaming humans for human problems is counter productive, since you've got a better way to prevent failure.
I don't share that view, but I think I can tell you why it's working for you (now) and what sorts of issues you'll run into eventually and why:
You've got great people working for you. I don't need to tell you this, of course, but it's true. That's why you're having success. Great people are already preventing most screw-ups and blaming themselves for their own screw-ups, so there's no need to apply much in the way of corrective management. Adding tools and documentation and procedures to help everyone learn from this process is great, but your people would do fine without all of that. They're going to do their job well, in any case. That's what great people do.
But, not all of your people are great. You've got at least a few in there who have started to (or always have) felt that their issues and problems and screw-ups aren't actually their fault. They can hide now, fairly unseen amongst their coworkers. But they are there, regardless, causing small issues here and there which are mostly taken care of by their more responsible peers. More documentation, training, and system verification won't help them, unfortunately. These people either need to face the music or be terminated before they cause real damage. Identify them, if you can, before things get worse.
The worst employers I've worked for have all had a "blameless" culture. They didn't call it that, of course. What it meant was that if the cause of a problem or failure was difficult to face, the problem was blameless. I don't think any one of them started out that way, but weakness crept in and suddenly the company just couldn't pin blame where it needed to go, because (for what ever reason) that was uncomfortable.
And this is where the breakdown ultimately happens, and why: Management decides that it's soooo uncomfortable or legally risky to hold an employee's (or another manager's) feet to the fire that they come up with all sorts of rules and procedures and training and even philosophies to avoid having to, you know, actually manage the team. And the employees that don't like feeling personally responsible love it because they've got an out for their mistakes. "I didn't know!" "I didn't realize!" "No one told me!" "What was I supposed to do?!?" And management can go back and order their more responsible employees to "fix the system" so that their irresponsible employees don't cause as much damage next time.
And anyone who questions this is being judgmental or biased or seeking a vendetta or in some way not being the caring and compassionate soul that the company's "blameless" policy demands. Greater employees leave eventually or are fired for causing trouble. Eventually, the continued wave of failure overwhelms the company itself.
(Of the three employers I've worked for with this sort of environment, two no longer exist and one is cresting this year. Anecdotal, of course, but this is how my opinions on teams has been forged.)
Ok, so back to your blog post. You're telling the world and your employees that this is exactly the type of environment that you want to create and maintain! Not one of failure, of course, but one in which no one person can be, ultimately, responsible for failure. It would be so cool if this actually works, but think about what you're actually saying.
The great people in your team(s) don't need this sort of support and the irresponsible people will lap it up and ask for more. If you're not prepared to deal with the second set, they will drive the first set out and use company policy as their justification.
"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."
Quite frankly this just sounds like whomever is in charge of hiring in these teams does a shit job of it. If, during an extended interview or round of interviews, a person cannot manage to get enough of an idea about how a candidate is going to mesh with the team that new hires often last less than 30 days, that person should not be hiring. If that person also does the firing as well they shouldn't be allowed near personnel management whatsoever, and their overall ability to lead should be questioned.
If the goal were to minimize the number of false positives, I would agree. But the managers of these teams had enough experience to know that they'd rather hire one person a month for a year and only keep one gem than to spend days or weeks trying to find that one gem and then agonize over firing them (knowing that the hiring process is slow and expensive) when the gem loses its shine.
Having done a fair bit of hiring myself, I can't even begin to reliably identify gems. If you know of a way or can explain how multiple rounds of interviews can do a reliable job of identifying them, I'm all ears. I can tell the stinkers right away I think, but gems, no that's really hard. The best candidates I've interviewed (resumes, work experience, knowledge testing, etc.) haven't had any better luck becoming great team members than those with a mediocre interviewing quality.
Cause here's the thing about gems: They only work within their setting and can be created, with some effort and skill, right out of raw material.
I disagree with what your idea of proper hiring apparently is; to hire and test out a lot of people often is better than to spend extra time finding the right person. In my experience, a work environment that is a revolving door of often failing new staff is a waste of everybody's time, whereas a work environment with more carefully selected new staff that sometimes fails is only a waste of management's time. Such are the burdens of management.
I agree. This sounds like bad/lazy management, and a broken on-boarding process.
As a consultant, I've grown used to working around bad on-boarding processes but most FTEs aren't used to jumping into existing teams without being given a lot of knowledge. I can imagine tons of great people washing out of such a team not for any good reason but just because they aren't used to self-service on-boarding.
Sales has its own high-risk / high-reward culture that goes along with the people who hunger for it as a career. Since most sales positions are paid on commission, failure to meet sales goals tends to result in a firing.
In my experience salespeople do need some ramp-up time (although it depends on inside/outside, size of sale, etc.), so 30 days may not be reasonable.
Commission vs. base actually argues for letting them stay LONGER. They self-select to leave if not making commission -- at a startup, that could be due to the product not being in the right place, though, so in a startup you often pay more base than at an established provider.
The other issue is that the cost of a "seat" for a salesperson, especially outside, can be really high, independent of production. It's pretty reasonable in enterprise for a great salesperson to be burning $500-1000/day in expenses (flying every couple of days, hotels, cars, meals with clients, etc.). Plus, potentially needing a sales engineer or engineering support from the development team, and of course the opportunity cost of giving them certain sales leads ("these leads are shit! give me the Glengarry leads!").
Enterprise sales is one of the reasons it sucks to do an Enterprise startup.
I don't think interviews, even with technical components, can tell you even with 75% certainty how a candidate is going to perform at the actual job. There are considerations like work ethic and how well someone can grok the actual issues the company faces (as opposed to a toy problem) that you just can't really know until they're actually doing the work (or not). Some people are really smart but turn out to be lazy. How do you weed them out in an interview?
I disagree and having gone through such systems I would again. Here's why.
Right out of college I applied for and got a temporary job at Google in their Adwords program. Going in I new it was a trial by fire. I interview well, and frankly the bar wasn't very high to get in. However I washed out after a few weeks because the job sucked. I hated it, it was boring and repetitive, and so I did a poor job. Most of what I was doing has since been automated.
I thought I wanted the job going in. They thought I had the potential to be a good employee. We were both wrong, but it took just over a month to figure that out.
For my last two jobs I really wanted to work for the company but, on paper, I wasn't qualified. Instead I offered to do an unpaid internship. I worked my ass off for both, learned a lot, and was offered fulltime positions. If I hadn't created a work-to-hire situation for myself I would never be where I am today.
In both situations the key factor was that I knew, going in, that I could wash out at any time. It was a tryout.
As I'm sure you'd agree, if I had the expectation of a guaranteed position, only to have to taken away one month in that would have been devastating.
I would encourage more people to expand their hiring pools with these kinds of programs. I feel it is more realistic (and honest) that it will take at least a month to get to know a person and for them to get to know a job to see if there is a reasonable fit.
The parent post said that "all new team members" were subject to this. It's fine if you're willing to bring on candidates you aren't sure about on a temporary basis, but you're just going to send a lot of good candidates elsewhere if your blanket policy is "you will be terminated after a month by default". In particular, as other commenters have pointed out, you will be filtering out lots of good candidates who currently have stable jobs, but might be interested in your organization if not for the (justified or not) perceived risk of being fired for no reason.
It's not one organization, it's the commonality I've noticed from three of the ten that I've worked for that had fantastic teams. The other seven have had wildly different measures and procedures for employees, but each with worse results.
I think this kinda stuff always creates a two-tiered team, so it shouldn't be relied on as a way to hedge anything. You get the A-team/"our people" and the B-team/"their people" and right from the start everyone knows this. Then there's differences in pay, benefits, and expectations, etc. In other words, to use interns or contractors as a potential employee filtering method, to me, just sucks. I haven't seen that work well.
But, but, but! If you're looking to give people a chance to learn and expand, with no future obligations, internships are definitely the way to go. The key point being: an intern that doesn't turn into an employee is not a failure.
Take someone who doesn't even know what they can do and put them with a great team, part time, with real responsibilities, and with the idea that they're there to help out and learn and see if anything happens. Usually, it won't. If it does, great. If they become a future employee, excellent! My career was built from this, but it requires an employer that's willing to take a risk.
I want to work with a team where I'm motivated intrisically to do so; not because I know if I don't hit number X or Y I'm going to be terminated immediately. This may work for some people, but I couldn't handle having that over my head.
Why the hell would I want to pay the job switching costs to work at that company when they have an itchy trigger finger, especially if I'm doing pretty well where I am already?
That's a really good point and I think that, for the employees who didn't last more than six months (or were terminated right away), this was a bitter experience. In other words: if you, as an employee or employer, are looking for more of a committed relationship, I think the points I made aren't going to help at all and probably seem distasteful.
If you're looking to maximize the team's value and effectiveness, though, I've seen those points work, consistently, in a variety of environments. And I have no hard feelings about it. "It's business", as they say.
Your problem is that the company can get a reputation as a revolving door. Which over time means any good programmer in the know is not even going to apply. Why take the risk? There's no guarantee to me as a candidate that your company is firing people for the right reasons and not because you're expecting too much, or something illegal, or because I don't like the cubs vs sox.
After a while the quality of your pool is going to drop. Which is just going to reinforce your belief that most employees don't work out after a few months.
Exactly. Nobody I know would ever want to take the risk of working at a place like that.
Especially with the Dunning-Kruger effect: the best (e.g.) programmers tend to underrate their skills, and will not be motivated to apply to a place like that for fear they will be fired.
My points are based on the commonalities of the three great teams I've worked for at ten different employers. It's not one company, just a set of observations.
And they weren't all IT/software/web companies, either. One was the best IT team that I've worked with, period, at a non-IT company no less. Another was a fairly well-known restaurant chain. The third was a small startup-ish design company.
You are absolutely right about the reputation thing. You get that reputation for firing people, especially from the fired. But when you talk with the people that do or did work there for any length of time and see that, when the time comes, leaving will be difficult or was difficult, it all makes sense. The team manager wanted a great team that had great output and nothing less. And there was never any pressure to do the wrong things, illegal things, or base decisions on personal whims. That kinda stuff doesn't happen very easily with a room full of responsible adults, knowing that today may be their last if they screw up.
So I'm not saying there's no drawbacks to the points I listed, but I think they do work out overwhelmingly on the positive side.
Right, not to say that they weren't "great" teams. But do you have any evidence/numbers to show the rest of us "why" they were "great" - if for nothing else, than for perspective. I could tell you my high school stint at McDonald's was the greatest team I ever worked with - but I can't provide anything other than anecdotal evidence to support my claim (edit: actually, McDonald's is one of the most successful corporations on the planet - which proves my point, right? - right). I guess the question, in other words, is why should we care about your opinion?
There were a few fields of contract work in the 1990s for which a number of companies were always hiring. They clearly didn't have the headcount or growth rate to account for this, and scuttlebutt pretty quickly got around that they were simply chewing through candidates.
Turns out that the base talent pool was rather smaller than they may have presumed, and numerous top talent I was aware of quickly learned to steer clear of them.
Different circumstances might make for different strategies, but in my experience, making an investment in your hires sends a strong positive signal. Yes, firing is occasionally necessary, but IMO it represents a failure on both sides.
Or do this openly and call it "contract to hire". Both sides can call it off with no regrets.
Excellent, I'm glad that's been your experience. Mine hasn't been like that and I've waded through too many everyone's-so-friendly-and-getting-nothing-done-and-always-stressed teams with weak leadership and low standards. I'm hoping that your experience is more typical than mine!
It's not typical. But when it's not, lack of #1 and sometimes #2 is the key missing ingredient, not an aggressive churn through new hires until the perfect combination of employees is found.
The word that popped into my head when I read the OP was "bullying".
A few additional thoughts:
1. You're going to lose out on good people. GOOD people will see a toxic environment and run like hell. Who wants to work like that?
2. The people you manage to hire under "the cloud" may not be the ones that you want. I've seen people work in precarious situations, and I was not impressed with their capabilities or integrity. In the top echelon their work and ethics seemed to mirror the screwed-up environment they were in. In the ranks, moral was terrible and there was no loyalty, only fear.
My "cloud" was such that I felt I might be fired any day, for roughly a year. It turned out to be a phantom -- when I talked to our director a few years later she said, "You really took that seriously?"
Years later what I went through is still negatively affecting how I work. Don't get me wrong, things are going fine externally, but I could feel a whole lot better about the politics, the annual review madness, and interactions that involve managers.
It sucks to live in fear. Don't do this to your employees.
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.
Well, good to know. I won't be joining your team. I make mistakes all the time, though seldomn the same one twice. I haven't deployed bugfree code into production in my life, but we strive to prevent the same kind of bug from occurring twice. All in all, I believe me and my colleagues do a very decent job, striving to prevent ourselves from making errors as much as possible. They stillnget made and it would be a great loss to have to fire someone over one.
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.
If I were foolish enough to accept a position in which some stupendous mental giant of astronomical power made this terrifyingly brilliant announcement, I would quit after 30 days if by some accident I wasn't fired.
> All new team members were automatically assumed to be terminated within a month or so.
If I was ever hired in a place with that kind of assumed termination, I'd have to start job hunting again on day 1. Because, in my experience, it takes at least 2 weeks to get through most hiring processes. (Between sending in an application, waiting to hear back from the HR guy, interview 1, interview 2, technical interview, potentially a technical assignment, and then overhead of coordinating everyone's schedules, AND waiting to hear back on each stage of the journey).
And you do that dance (or part of that dance) 3 or 4 times during that month, which having this full time job.
It would be even worse if, while I had this 30 day assumed termination job, that I got an interview with one of these "new hiring practice" companies. You know the ones: "We want to contract you in for a week to see if it works out", or "Can you complete a 30 hour programming assignment for us?"
Even something as simple as, "We'd like a series of in face, 4 hour long interviews with you during business hours" makes you look bad to the job you have-but-may-not-be-retained-in.
Because now you have to make some excuse why you can't show up to a job you know you'll (probably) be fired from, but that very action could be the thing is probably going to be noted on your record, "Brilliant guy, and we'd love to have him, but he missed 4 afternoons because of personal reasons - he obviously is undependable, do not retain."
I would classify all five items as a work, team, and personality fit. You worked well in that environment because it fit with what you expected of yourself and others. The people who left, or were fired, did not fit as well. At the end of the day, the fit is more important than any list.
This is really interesting. I know a few other places with up or out cultures and that tends to leave only high performers, though that's usually after 2 years, not 1 month!
I'm not sure if a 1 month up or out is causal to a good company, or just coincidence, but thanks for sharing.
I'm surprised so many people are balking at the "incompetent until proven otherwise" clause, especially with the clarifying reasons you listed. When I read that I thought it was a great policy. I've worked at a few places where we hired people that didn't work out, but nobody would step up and fire them. It was a horrible situation, because we had to keep trying to work with incompetents and dead weights who either couldn't or wouldn't do their jobs and usually made our jobs a lot harder. It was awful for morale.
What is the problem with terminating people who aren't pulling their weight? A month seems like enough time to figure out someone's M.O.
1) On the offer day, potential employees were told there were high expectations and no fixed rules to govern what that meant. There was leniency in some cases, but manager/supervisor judgement was the only rule that mattered. No handbooks or rule sets.
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.
3) Human mistakes (fat fingers, brain farts, etc.) were reprimanded internally but covered, responsibility-wise, by the manager or supervisor externally. (I got this treatment at least once a year...)
4) Repeated or dumb mistakes meant being terminated, usually within the same business day. (I saw this happen many times. Not fun but then again they were dumb or repeated mistakes.)
5) Lots of communication within the team. Supervisors and managers were always available or actively participating in the projects.
In other words, there were high expectations and they were strictly enforced, with nowhere to hide mistakes or divert responsibility. Or, more bluntly, "we want to work with adults, not children".
Sounds harsh perhaps, but these were the best teams I've ever worked for and no one who stayed for more than 6 months felt used, abused, or anything other than lucky to be working with fine people. When long-time employees left, it was to start their own businesses or go back to school and there were always a few tears in the parting days.
Now, if you read in some book or learned in a training course that you need to cover your butt legally at all times, give everyone plenty of chances to do the right thing, and take everybody's situation into consideration before taking disciplinary action, your teams are going to start sucking. Why? Because all of those things are the opposite of management. Those things are what you do to avoid management.
This whole article, to me, says "boy, it'd be so much easier to run this business if I didn't have to actually run this business". Here's a hint: If your strategy for managing a team or community or whatever is "people should do the right thing and we should give them every opportunity to do that", then your team's problems aren't actually your team's problems.