Wow - how do we even classify this - it's clearly not just a story. Is it a case study? Series? It feels like it's almost book length - sort of thing we'll be readying for days (if not weeks).
Has NYT ever done an article in this format before?
The "Blind Hiring" section starts off great:
A few years ago, Kedar Iyer, an entrepreneur in Silicon Valley, became acutely aware of a problem in his industry: A surfeit of talented coders were routinely overlooked by employers because they lacked elite pedigrees. Hiring managers, he thought, were too often swayed by the name of a fancy college on a résumé.
Let's not go crazy here, it's 11 pages / 5.6k words. While it's unusual to have magazine articles that length these days, it's not a huge amount of time since that was more normal.
It's an excerpt from a book:
> Charles Duhigg is a Pulitzer Prize-winning reporter for The New York Times and the paper’s senior editor of live journalism. He is the author of ‘‘The Power of Habit’’ and the forthcoming book ‘‘Smarter Faster Better: The Secrets of Productivity in Life and Business,’’ from which this article is adapted.
I'd be willing to bet that Sakaguchi has read "The 5 dysfunctions of a team" [1]. One of my favorite books about how people jell together in groups.
Like him I was also in a military setting before I became a programmer. I haven't yet experienced the same level of engagement and team cohesion outside of the military but I believe that the answers are to be found in the kinds of insights that studies like this uncover.
Even if it turns out this is a puff piece supplied to the Times by Google, it's still a very well written and insightful article explaining a bit of why psychological safety is critical for teams to perform optimally. It's probably my favorite Google-related article this year, actually. I'd much prefer reading about companies trying to improve their working environments than about whatever incremental new product feature they're launching.
Indeed - what I enjoyed and got out of this article is a fairly easy correlation to what separated good teams that I have been on from bad ones. I had classified the difference as "camaraderie" - but the idea of psychological safety is a little more useful. Camaraderie is the superficial outcome, while psychological safety is the enabler.
Not really, one term is the popular term the other one is a term from behavioral psychology. So they describe the same phenomenon but by different people.
Someone could fit very nicely into a given working culture despite that culture not being 'psychologically safe' by the author's definition. They are not the same concept.
On the contrary. Culture fit is a pretty normative term: It says to me, we act like THIS at this company, and we're looking for more people who act like THIS. It's pretty explicitly anti-diversity, and speaks to a search for cultural homogeneity.
Psychological safety is less normative: It's about being in a space where it's safe to voice an opinion, and feel that you're heard and valued for your contributions. It's a term that can apply in a very culturally diverse team.
Maybe in theory, but in practice? Either the team has a shared culture of open-mindedness, or a culturally diverse team will have opinions which are held by some and taboo for others. Either way, you need a common culture, even if it's fairly broad and flexible.
> It's probably my favorite Google-related article this year
It's Feb. :D
> I'd much prefer reading about companies trying to improve their working environments than about whatever incremental new product feature they're launching.
Google has set the right precedent for the tech-industry, and I am grateful for them having done that. 'Cause other big tech-cos like Amazon sure don't give a damn about employee well-being (not just warehouse workers, but engineers too).
As a counter point, the best team I ever worked on was at Amazon, and years later many of us are still friends. Further, AWS is cleaning Google's clock with number of features, delivering new services, and providing customer value.
I remember a gig I had where one of the developers was someone who didn't seem to be technically that deep. Yet every project she worked on did better because of something nobody at the time understood. I remember having such a great feeling about working with her every day. I didn't get that from other people. I think this article explains why she was so awesome: She made people feel safe. When she talked to you, you felt like the most important person in the room.
If it was a situation where most of the devs were men and your colleague was one of the only women, it seems likely that gender dynamics and stereotypes about women made a big difference in her getting perceived as "non-technical and comforting" (that's one of the usual stereotypes about women developers, after all).
In this case not a stereotype. I think she had tremendous raw intelligence but she was a fulltime mom with kids and was caregiving for her aging parents at the same time and a husband on the road a lot. This just didn't leave her much time to deep dive on anything. If I were in her shoes I'd probably been fired for not keeping up. So she likely had the potential of being the most technically deep person on the team but her life didn't really give her much time to develop that. In the end it didn't matter for the team as a whole: she made things better because she simply was a better and more preceptive person than most people.
Interesting. If the previous comment had used male pronouns, would it even have occurred to you to associate the described attributes with gender stereotypes?
Yes. There is a very visible pattern. Yes in 2006, but times have changed around 2011-2013 (Twitter's IPO, Mozilla CEO fired, GitHub CEO fired, conferences excluding people for sexual jokes), and if in 2016 I had on my team a woman whose role was to be talkative rather than technical, I would find it sexist.
The pattern is "If a junior woman can't code, let's promote her as team lead; If a junior man can't code, let's teach him to code" - and this is wrong because both sides have everything to lose with this behavior.
But the better team is the one where she becomes the team lead. That's not sexist. Some of the most important skills are leadership skills. And leadership skills are not about command and control. They're about understanding and leveraging (often intuitively) a million complicated things we barely understand about our ancient primate wiring. Those things make computer programming look like preschool skills.
As long as she becomes the team lead after learning the technical skills like everyone, and as long as it's not out of prejudice that males don't have people skills, yes. After 7 years trying, I've left the corporate game which was rigged in favour of women, and I've created my own company, and I vote against women rights, which is also a racist party. I really don't want to vote for the racist part, but I've worked in 3 companies, in 3 different countries, 19 women met, 18 were in management positions, including 11 promoted in my presence, not all of them skilled, and I've seen only 1 male be promoted. Feelings were hurt. Fairness is out of the window. You bet it's going to take long to repair.
For future reference, here's how you achieve that effect when talking to people: 1) make and keep eye contact, 2) listen more than you speak, 3) ask follow up questions, 4) if your phone buzzes, ignore it 5) if your computer dings, ignore it, 6) turn towards people when talking with them, 7) reposition yourself so your eyes are on the same level if possible, 8) don't tower over people, 9) always approach from the side, not the back or the front
Basically, give people your full attention when talking to them, and avoid primal displays of dominance or subservience. Mostly the attention part.
Stand back from them. In the immortal words of The Police, "don't stand so close to me." From 3 or 4 feet away most people realize I'm tall but when I stand directly next to them there's zero ability to make eye contact.
Lean back slightly if you have to stand. Also look at someone face on but stand a little sideways and back. I am 6'4" and most people don't notice it until I end up standing over them accidentally, they suddenly comment "WOW you're really tall" and it actually surprises them because I work very hard at not being intimidating. Approaching from the side is good advice and so is making sure people notice other things first.
Another important bit is that if someone is sitting down, you should sit down next to them. If they're at their desk and there's no chair, squat or kneel.
I learned the best advice for approaching women only after I became happily married:
Leave escape room.
Whether it's a bar or a cubicle, a woman will (in general, according to my wife and other female friends) be aware of being pinned in. For those not thinking of it, it's perfectly natural to stand at the end of a bench seat or in a cubicle opening to talk, but this gives them no "escape" from the situation and increases tension. Simply standing to the side of that escape path makes the situation less tense.
On the generally-male side of things, (drawing purely from my own experiences) I definitely notice when tall people are close to me, but if they stand a little further back I don't really notice their height.
Honestly, just stand a little bit farther back. The main factor seems to be the angle at which each participant has to crane their necks in order to make eye contact.
Sounds like you know your Dale Carnegie quite well! :)
Also, don't sit straight across from them, police interrogation style. It's intimidating, especially in situation like an interview. Sit at the orthogonal side of the table.
Michael Lewis had an article a few years ago where he described this effect using Shane Battier as the example - none of his stats were spectacular, but somehow his team played better when he was on the court. http://www.nytimes.com/2009/02/15/magazine/15Battier-t.html
I don't think this piece should be read as "come work for Google" (although you can interpret it that way). Rather, I think the researchers would want see all companies to take advantage of this research and use it to make every workplace better.
(Disclaimer: This is my opinion, not that of my employer.)
I love the topic and like this particular article. Having said that, this still feels like a puff piece. The notion of psychological safety certainly matters but not always. My experience is it matters less when you have teams made up more of "thinkers" (vs "feelers"). Also matters less when the team has a clear vision and set of requirements and just needs to adapt their past expertise to minor variations in new problem. Sometimes teams are more efficient and innovative when truth wins over harmony. Depends on team's purpose, etc. Let me be clear, I prefer the more psychologically safe mode of group work. Yet it's still pretty clear to me that hinders, not helps, in plenty of cases.
> Sometimes teams are more efficient and innovative when truth wins over harmony.
I'll just quote what the Rust team said about their code of conduct, because it's spot-on: "The Rust community doesn't subscribe to the notion that there's a dichotomy between intellectual discourse and kindness."
That's pretty much it. If your team considers those two mutually exclusive, you're headed for trouble. It might not be today or tomorrow, but you will pay for it long-term.
That's not what the article is going for, and that's the common mistake I see in teams.
A thick skin is necessary, but the point of psychological safety is that it must be normal and expected for someone to make mistakes and to be wrong. It happens inevitably. How teams handle it is the important part. The most successful teams I've experienced are those where someone can say "yeah, I messed up, I'll fix it" and the team sees this as a necessary part of a team's long term function.
That means nobody on the team says "I told you so," and that team members can disagree intensely without making it personal or emotional.
The big problem with "without making it personal or emotional" is that the people most guilty of making disagreements personal or emotionally charged are also least likely (in my experience) to recognize that they're instigating. These people are toxic without realizing it themselves.
Good points, these replies. I think it is fair to question what truth/harmony we are talking about. The "truth vs harmony" dichotomy has become a bit loaded especially with all the folks invoking truth as a license to be jerky intellectual bullies.
I definitely don't mean that. More like, there are always tradeoffs. There is cost/benefit in being truthy just as there is cost/benefit in being harmonious. Each has it's own type and you get to choose which make more sense for the situation, team, etc.
I don't think you can "have it all" so much as you can choose to set the tradeoff point somewhere in the middle rather than at the extremes. For example, in the Rust code of conduct example, it sounds like they have decided they want a nice mix. This will cost them though. Maybe the cost is as small sending $some_multiplier_above_1 the amount of emails between the team because things are worded more indirectly to not offend and therefore more disambiguation has to take place. If their team instead committed to be as direct as possible, the could spend less time on follow up emails but now they'd probably turn of or drive away some good folks from the team who decided they didn't like all the directness and send of urgency.
Personally, I like a nice mix. I think it is just worth being clear with myself it is a mix and not two independent things where you can have an infinite supply of each.
Where are you getting this "harmony" junk? Maybe you're right, there is a tug of war between truth vs harmony, for some definition of 'harmony'. But who's calling for something called 'harmony'?
I believe you may be misunderstanding something about the idea of psychological safety. I can't think of any definition of "harmony" that has anything to do with psychological safety.
I'd be willing to bet that Sakaguchi has read "The 5 dysfunctions of a team" [1]. One of my favorite books about how people jell together in groups.
Like him I was also in a military setting before I became a programmer. I haven't yet experienced the same level of engagement and team cohesion outside of the military but I believe that the answers are to be found in the kinds of insights that studies like this uncover.
He may or may not have, but I can tell you that some of Google's core internal team training focuses on the same concepts in the same triangular hierarchy, so even if he hasn't, someone has! :)
The 5 dysfunctions of a team also closely echoes Maslow's hierarchy of needs.
However, I have to chime in: I don't agree with the accountability aspect. Responsibility is necessary, along with knowledge and support from the whole system: this broad "ability to be effective" makes accountability obsolete, and is superior.
That combination of Knowledge, Psychology, Systems thinking, and a fourth: an understanding of variation and statistical reality -- leads to a much more complete and functional model of the organization. This is W. Edwards Deming's System of Profound Knowledge.
However, you can see why "The 5 Dysfunctions of a Team" caught on, and his name didn't.
I may be misunderstanding as I'm not familiar with your sources, but I’m not sure how you can have an effective team without accountability? If you are responsible for delivering something and you don’t and there’s never any ramification (accountability) things degenerate. I’ve seen this more than I’d like where a manager’s team is failing and he or she constantly blames subordinates and other teams for the lack of results, always ready to pull something out of the excuse matrix. When senior leaders fail to hold these managers accountable, the process continues, new mistakes, missed targets, and new scape goats found. Responsibility without accountability seems like the life of a Roman Emperor and I’ve never seen it work well with teams or leaders.
Completely agree. The "accountability" part of 5 Dysfunctions is about the team being accountable to each other and having the ability to call each other out. It's not about checking off boxes in a spreadsheet.
Think of it this way: It's about the responsibility of members of this site to downvote non-productive comments. It's not about meeting a quota of productive comments; it's about disarming non-productive action. We hold each other accountable for having productive discussion.
@boothead: As somebody who's never been in the military (drafting for military service was suspended just before my number came up) I'm curious. Does the level of engagement and team cohesion you speak of only occur in, or afterwards derive from, combat situations, or would it theoretically be possible to recreate these levels outside a military context as well?
I think the key element is 'shared hardship'. Personally, I didn't see combat, but military life in general sucks; doing a lot of stupid stuff at the whim of others. I think you see this in other areas of life as well, sports teams, project teams meeting tight deadlines, etc...
It's really to do with the incubation of a very strong shared culture and shared experience. For example the Royal Marines has a history going back 350 years, a shared language (google jack speak), and the longest and arguably hardest basic training in the world.
I believe it is possible, albeit in a slightly different form: elite sports teams and groups of people tied together with a strong shared purpose can get there I think.
edit and yes, as marktangotango says - shared hardship and knowing you can count on the next guy because he's been through what you have and hasn't broken either is also key.
They used 'meeting behavior' to predict team performance. And not in the way you would expect. Its not about productivity in the team meetings. Its about feeling safe, respected, and sharing the load.
Makes some sense. Team meetings are not where anything gets done after all. If team members are engaged with their peers, they may invest in team goals and perform better.
Issue: they correlated team meeting metrics (talking time; socialization time vs problem solving time etc) with team success at achieving goals. They could have used behavior outside the meetings (communications per day; social interactions after work) and predicted successful teams that way. It doesn't mean that "Meetings that go like this indicates good teams"? I.e. changing your team meetings to look like what good teams do, may not improve your team at all. That might be put under 'cargo cult management'.
"Its about feeling safe, respected, and sharing the load."
You know, I think it's worth pointing something out about the word "safe" given the sense it has been used in lately. In this case, it means people feel safe to express dissent. Not "safe from dissent", as the term is often used nowadays.
Of course the two usages shouldn't be overlapping much anyhow. It shouldn't surprise anyone that a team where people actually attack each other's personal identities is not going to be very effective! But it's still worth pointing out the two very different ways the term can be used, and important not to accidentally substitute one definition for the other.
Something the Recurse Center also put a lot of work into is making it safe to express lack of understanding/knowledge. There's a huge difference between a meeting where someone feels able to say "I'm totally lost, can we rewind" and one where they just quietly panic.
That's somewhat in tension with being able to express dissent, in that being able to dissent constructively requires both social skill and an underlying environment of trust.
It's easy to cultivate only one of those (eg most OS mailing lists choose dissent) but cultivating both is harder and I haven't seen it ever happen by accident - all the communities that come to mind are ones that direct a lot of attention and effort to community structure and expectations.
The Recurse Center's social rules are really well thought-out. After I learned about them, I started to see how people who violate the "no feigning surprise" rule can make team members feel excluded and belittled, often unintentionally. This includes myself, and have since changed my behavior.
You are so close to understanding that what Google is doing is the same thing the safe space movement is doing, but now it's cool because a hot company does it.
It's interesting how you choose to represent the safe space culture by its most annoying examples, but chose to represent tech company management culture by it's most positive examples.
And it is the responsibility of the person on the "attack" to make that clear using whatever approach works in the situation. Otherwise you have a communication problem, and it is primarily your fault for being inarticulate.
This is not at all meant as a know-it-all pedantic attack, but I found it much more difficult to read your post because of "there" being used where you meant "their". I hope this helpful instead of annoying!
I'm honestly not sure if I would have had similar issues verbally. I think they maybe sound very slightly different when most people pronounce them, but there's a good chance that's just my brain adjusting based on context. But I don't think reading is the same, and I definitely think some misspellings, even of homophones, can throw me off and cause me to re-read.
In any case, I went out of my way to not be snippy! I just thought it might be helpful to you to know that the mis-use slightly tripped up at least one person. It's hard to know who will find it helpful to have things like that pointed out (like some non-native speakers trying to learn) and who will just get annoyed. Mis-judged this one!
I noticed the article also mentioned that being highly sensitive to other people's feelings was also very important, not just safety from dissent. In fact the piece seemed to focus on how groups with highly socially sensitive individuals tended to fare better.
It's reciprocal, which is the real thing missing from the collegiate-type "safe space", which only flows to certain people. You need to be able to disagree, and, reciprocally, when disagreed with you need to handle that gracefully, or you aren't doing your job. You not only get your feelings taken into account, but you must equally take other feelings into account. You've got rights, but you've also got responsibilities too.
Contrariwise, the collegiate-style safe space makes it so that the certain people have boundless rights to be offended, but no corresponding responsibilities to consider other's feelings. In a team context this leads straight back to exactly the failing the article is primarily about, one person/group speaking a great deal more than the other.
(And please do not insult my intellectual integrity by claiming that collegiate-style safe spaces are supposed to be safe spaces for everybody. That is transparently false, to the point that you are just discrediting yourself if you try to claim otherwise. It is abundantly obvious who they are for and who they are aggressively not for.)
I do apologize, I didn't realize we were talking about exclusively collegiate safe spaces. I was under the impression we were expessing something more common than that. Given that I haven't read any studies on collegiate safe spaces, nor have I extensively participated in many myself, I've got no opinion. Do you have any studies marking the style and results of a collegiate safe space you're claiming?
I can feel safe even if I really disagree with the decision someone has made.
Or I can feel unsafe even if technically we are perfectly aligned but I know they are going to backstab me in front of my boss anytime they feel like.
I can work or even share room with an Atheist, a Buddhist and a another Christian for weeks on end and we didn't bother another.
I think it is usually enough to respect another, and that includes for the easily offended part (often me) to respect others right to don't care about my customes as long as they don't mess with me.
I do however feel a tiny bit unsafe (for the lack of a better word) in online foras whenever I see people getting online-lynched for not having the correct opinion.
I think these are good qualifiers in some respects. The teams I felt the most comfortable working in were ones where I felt like I was respected by my peers, that everyone was doing their part, and that it was okay to go against the flow if you had an idea.
The problem is in attempting to attain the things above, I've also been on teams in a company where I was clearly the strongest person on the team, and was chastised for providing too much guidance because management had the idea it was better for people to fail on their own (in production) than it was for only one person on the team to be the primary contributor of plans/the way to go. Maybe they were right, but the end result was that it made /me/ feel disrespected by management, and my own contributions suffered, causing the overall team to suffer because the other team members were too junior to pick up the slack when my contributions fell off.
I think there's a right way and a wrong way to try to achieve these qualities in a team. My personal experience is that when you have a team of people who are all very strong in at least one skill set and have clear pathways to communication it works much better than having a team which is relatively weak/junior with only one or two people who are strong unless there are clear lines of seniority. It's a consequence of the idea in modern society that "all opinions are created equal" is not only true, but a good thing. It's important that either you're in a group where you can trust the equality of everyone's opinions, or that you have clear leaders that can mentor everyone else and provide strong guidance.
Basically, if you can, build an "A-Team". If you can't do that, make sure you don't actively undermine your A players. If your A players aren't jerks, they're naturally rise into leadership roles in the team and help mentor/teach everyone else to bring them up as well. Undermining the A players will end up causing the entire group to suffer and eventually the A players will leave and you'll be stuck with a group that's significantly weaker for it.
Of course my thoughts above are primarily focused on technical teams, I don't know if they apply as clearly to non-technical teams, and this Google study appears to have looked at both.
The 3 word summary I infer is "egalitarian golden rule." If you work with people that are respectful, that listen, that care about you as a person, you're far more likely to work hard and be successful both individually and as a team.
Being able to understand the emotional state of your fellow man is key to more than just good teamwork: it's key to a successful marriage and to keeping close friends.
There is a concept in Japanese culture, Wa (和), or "group harmony" that seems to nicely complement ruminations on "collective intelligence". Perhaps most interesting is how fragile the cohesion really is, a single person, a single sentiment expressed poorly even, is enough to break the spell.
The former is likely out before the later but ads on the web in general are in dire needs of improvements or they will be erased from existence by browsers.
IMO and experience, the best way to build a team is to exploit comparative advantage so that the whole is stronger than any of its parts. Assuming you've avoided hiring a sociopath, group cohesion follows from everyone having a critical skill they bring to the project uniquely.
This is of course 100% anecdotal.
This of course runs 180 degrees against the concept of fungible engineering and Google's generalist fetish.
Or TLDR: I prefer building the A-Team instead of trying to be Agile.
I tend to agree with you. I think back through a decade of coworkers, and when I take your "A-Team" approach I find myself picking "The Sysadmin" and "The UX guy" etc. And when I ask myself how they stand up against even the best generalists I met at big5 companies, well, it's no competition. (In that the specialists wipe the floor with the generalists, and I say this as someone who has followed more of the generalist route)
There is fundamentally too little time in the day, and too much to know to truly be GREAT in a domain, to expect anyone outside a select few (certainly not enough to fill out general employment at google) to be able to bridge these domains meaningfully and still be as deep as possible.
Now; there is a massive benefit to the specialists having sufficient understanding to communicate with other domains. But this to me is not what being a generalist means, and is an asset that is often looked over even in the generalist-focused agile orgs I've worked for; "are we communicating well internally in general".
(To bring this back to the article as well, I've also found the specialist groups with "eigenvectors" of skills to be MORE cohesive, as it's a great trust builder when someone can say "I'll be supporting your work in Y with X" and you know that they'll be doing X _light years_ better than you could, and you can truly TRUST them to have your back. Not that the same thing isn't very feasible in other environments, but that's an "easy way in" to trust.)
Teams in general should always be made up of specialists. Thats the point of teams, to have collaboration between people that know specifics of certain things. Teams of generalists will just be a bunch of people that are ok at a bunch of different stuff and will either end up specializing in one thing anyway, or just being mediocre at everything and bumping into each other.
One-man bands are a different story though, if a full engineering team is not feasible, a generalist who has a broad but shallow knowledge of lots of things is far preferable to a specialist of one.
And how many people are Gates, Jobs or Ellison? The CEO design review isn't where the vast majority of people spend their time, or where ANY of the important work gets done.
Cool article - though I have to wonder how they measure team performance, given that it is our all important response variable.
In modern animal breeding, our goal is typically to improve some trait through genetic means. We extract the animal's DNA, sequence it, and compare it across many different families in order to evaluate how that individual differs from others and how its genetics affects our trait of interest. We call this trait our 'phenotype', and in animal breeding, phenotype is king. We can do all of the analysis we want, but if our phenotype is inaccurately measured or uninformative, it's all a waste of time.
It is interesting that Agile movement has in general enshrined idea of time boxed team meetings for software teams. And in general - we engineers are wary of long meetings.
And yet - most of us measure ourselves, how we are performing in a team by things that happen in team meetings(according to the article anyway):
1. Is idea my ideas heard and debated before being accepted/rejected?
2. Do I get opportunity to present my idea at all.
A time boxed meeting does not by nature leave room for idle chit-chat or from my experience even opportunity to hear everyone's thoughts. Part of the problem of course is, meeting rooms in lot of companies are a scarce resource, so you better clear out after time is out.
This is really curious because we hate meetings and yet we have adopted them in a sort of haphazard way which creates more problems than solves.
I didn't mean standups as meetings. I think standup is a good idea as it is and for most teams it lasts hardly more than 5-7 minutes (and some teams have moved it to emails).
I meant 20-30 minute meetings that teams typically have, like retrospective or something.
But I was not talking about Agile per-se. I meant in general most meetings of software teams are time boxed nowadays- no matter which development methodology they are following. I am also not criticizing time boxed meetings since I have no data to back that claim.
But I am just curious, what if as a rule - teams decided to have fewer meetings but meeting last as long as they have to not because someone is knocking on the door for next slot. Will it make things easier?
The retrospective and sprint planning are supposed to be much longer than that, and not timeboxed, as far as I know.
Also one of the core ideas of Agile is adapting to suit your team, rather than following some process from a book as if it were written in stone. If time limits on certain meetings are causing your team more grief than they help, remove the timeboxes! Talk to your team and see what they think, that's what the retrospective is meant for.
I am a self-professed terrible team member, and I scored "average" (27 out of 36) on "Reading the Eyes" test. Its not that I can't read people's faces, its that I don't care.
This reminds of the comment I had left about another post here about the "Costs of under-confidence", where I posted what I though made a great team. Essentially, that we create a "safe zone".
This is an interesting article since he cites a pub quiz and sports - something I participate in.
I've been playing for about 4 years in a pub quiz. We've won once and are considered a strong team. However, the difference between the a strong team, and the better team in a night, is the fact that our team fosters a "no suggestion is a dumb suggestion" policy. No matter how stupid you think your answer is, you are encouraged to say it. In fact, if we see body language from a person hesitating we're quick to jump in and say "Spit it out! Just say it!"
We essentially create a safe zone for our team members to not worry about the consequences of a wrong answer. There were so many times where a completely wrong suggestion makes another teammate say, "Hey! Wait, I think I remember!"
We also have a policy of if a person has a different answer than the rest, then he/she has to "fight for it". That is, you have to convince the rest of the team. By having a "fight for it" rule, we put controlled confrontation on the centre of the table and let people hash it out. There is no regret, or fear, or worrying about feelings. It's just a normal part of our evening that is done with humour and friendliness. Firm, but friendly!
By doing the above, we instil confidence in every team member. Those that are more confident by their nature, can still be challenged by anyone and keeps them in check, and the weaker confident ones feel safer to step forward when they need to. It balances out and our team has absolutely great chemistry because of it.
I've also played team sports for most of my life and some of the best teams I've played for had former professional athletes. Since they were stronger than the rest and more confident, they always raised their hand and took the blame for any mistake! It was quite funny because we knew my screw up was not their fault, but they would make an excuse about how they should've done 'X' and I wouldn't have screwed up.
Needless to say, that allowed players like me that weren't former pros, to be at ease and to be more confident and give my best, knowing that the strongest player on the team wasn't going to look down on me for every mistake.
It was a very interesting dynamic where the more confident person ensured that the less confident person is playing their best and it raised their confidence. Again, it is a kind of delicate balance that can change on any given night.
> "It seemed like a total waste of time," said Sean Laurent, an engineer. "But Matt was our new boss, and he was really into this questionnaire, and so we said, sure, we'll do it, whatever."
I started cracking up at this point because me and every engineer I know would have said the same thing in response to a survey designed to promote team building.
The irony is, a lot of the time these "dysfunctional teams" were formed due to some managerial decision, and basically without the team members input. So it's natural to eye-roll when the same management structure comes in to preach about "you need to gel together! We need to measure you!"
When people mostly pick who they work with and how, it's usually quite automatic and natural for things to work out without managerial baby-sitting.
Something I always wish existed was a recruiting platform that hired a team as a whole. Today it's pretty much just a recruiter coming to me, and saying "Hey wanna change the future at xyz?" where the only criteria that I might work is based on my skill set on my resume. Instead i'd rather fill out a survey, and get matched with some people I would probably work really well with. Maybe you hack together for a weekend. Once your team has a set of strengths and weakness, and a price, companies can bid, and the team as a whole judges where to go.
I think how well a team works together is sometimes more important then how much knowledge you may have of some arcane framework.
It feels like you may, in the longer-term, sacrifice different thinking for productivity. If I worked with the same team for years, unless we were some how really, really pushing ourselves as a group, I think I would miss out on whole worlds of approaches to problems.
I think it's way more important. When you're working productively with people you enjoy working with, it's almost hard to imagine feeling bad about your job.
This is one key advantage of startups, actually. Just take your dream team, and co-found a startup with them. Find the business that your particular group can excel at. The more this becomes a viable alternative to just taking a job, the more we'll be optimizing the matching of great teams to big opportunities.
That's a fun way of thinking, but it distorts the reality of a startup. Startups are far more then JUST a team, its a combination of a good idea, and resources. Added to that, the team is probably a much different kind of team then what your average enterprise is probably looking for. Though much of the skillset that makes a great startup team converges with what makes a great say enterprise software team, there's also significant differences. For instance a startup team isn't going anywhere without a member with suburb marketing skills. In an enterprise though the team that markets the software is very likely to be different than those that develop it.
Of course you need a good idea and resources. But success in an enterprise environment also requires more than just the team. It requires developing a clear vision of what you're going to build, participation from marketing and sales teams, and navigating internal politics. Not to mention ongoing commitment of resources. If you think about the mechanics of providing reasonable guarantees of such support to a group that already identifies as a team, you'll find they mostly reduce to either venture investment or consulting service contracts.
This is very similar to the way my team of subcontractors works. The only downside is when you are the only member of the team who is not up for a particular job. That can cause some friction.
1 - A team can succeed in one environment but fail in another.
2 - If the team does fail, you have a lot more rebuilding to do.
3 - Teams that are independent of company can have different loyalties. The principal-agent problem [0] gets a lot worse if an entire team is being held hostage.
4 - Many times you're not building the project team from scratch. You start with people who have succeeded on other projects.
We already do this @ Gigster. Except you don't get hired to be full time employees. You get "hired" to work on short term projects (that you can accept or deny) which is arguably more fun.
Multiple developers are common on (mobile) apps that require custom backends and larger projects that need to hit a tight timeline. All projects have more than one person on them and typically at least 3 (dev, pm, designer)
Just a couple of anecdotes: one thing I've seeing in 2 diff companies now is the new CTO bringing in their posse. It not only didn't work (for the CTO and his gang), it also undermined the rest of the company, who immediately felt "left out".
I've also watched an entire frontend team quit and go work at a different company because, well - they were a pretty well-knit team, but more loyal to each other than to the company...
I think management "teams" are a completely different beast to "regular" teams that are mostly individual contributors. I think it would only really be smart to hire a "regular" team as a unit.
The frontend team case in point didn't actually have any managers. That's complicated because what you're buying there is a group of people with already-set practices and that works well together - if you're not careful, you'll end up with a "silo" that just doesn't communicate with the rest of the company.
That kind of thing happens when a big company acquires a small startup, for instance (and it's the main reason I always see acquisitions/acquihires failing spectacularly) - again, all anedoctal...
My current company consists primarily of people who got the shits with our previous, much larger organisation. The problem is any new hires will be years behind on organisational culture (clients, history, in-jokes, references, shared adversity, etc). Still, 'having a strong team' is one of those good problems to have.
Yes, that sounds like a terrible idea - unless the CTO and his gang were very self-aware and made sure they integrated themselves into the team. Which it sounds like they did not.
I read a study of 'lift outs' - teams poached from one firm to another, to perform similar roles [1]. In investment banking, these liftouts are focused on one or two key analysts who bring juniors with them to the new firm.
Sometimes these worked because the acquiring firm had no expertise in a particular area. The biggest impact moving in teams has is that you are familiar with a lot of the business customs already - you have a support team in place. Your shared network can grow a lot more quickly. However, with a liftout, you have enormous pressure to succeed; there's less 'onboard' time since you should know how to work in your team already.
This happens all the time - they are consulting firms. I have plenty of friends that get hired as teams and go in and do excellent jobs that a single person could not accomplish. The sum is greater than the parts.
Thanks for posting this link, I went looking for it when I saw the parent comment. I think there's obviously a lot of value in this (with some drawbacks as well). It's strange that acquihires are typically the only time it happens.
Gabe Newell at Valve believes in this and it worked well when they brought in the team that made Portal.
"RPS: We’re really interested in your view on the independent games scene. I’ve just spoken to the Portal team and discussed Narbacular Drop and the job offer, and their shock and delight at finding themselves in that position…
Gabe: Something that gamers should probably understand is how important it is that game teams stick together. No matter how good a job a team does the first time they make a game they’re going to do a much better job the second or third time. There’s just so much value in a team having shared experiences to draw on, and my reaction looking at these kids was that they had done this fabulous thing. I go to all these trade shows and see all these tedious, derivative, lifeless games, and these kids had done something that was better than 98% of the gameplay I see. The idea that they wouldn’t work together again was a tragedy. They needed an opportunity to work together and ship a full-on game. If they were able to do that exciting a game the first time, then it’s nothing to what they’ll be able to do in the future. It turned out to be a really good idea."
Reminds me of Jim Collins' Good to Great. Step 1 - Get all of the right people on the bus, even before you know where it's going. Steve Jobs would hire the right people even before he knew what to do with them. Netflix hires the best of breed knowing that titles and roles are only as relevent as the task at hand. Being able to rely on people to work together, collaborate well and get the job done with quality is the definition of success.
The business model for app companies and contract software firms comes to mind. The team is really a small business itself and signs contracts with other companies to build things. Is there something different to these that you'd see? Or is it the idea of a team being hired on directly by company after company vs building to a contract?
The problem of hiring individuals to join the firm still exists though. Although I like the approach you propose more than the "dump a bunch of resumes" approach.
The problem with this approach is you would inevitably end up breaking the team as your budget may not fit the team available. This approach also ignores the managers who allowed the team to flourish in the first place. There is something fundamentally wrong with this whole article as it ignores the high hiring bar that Google already has in place which creates a self selection bias.
- Teams and focusing on team cohesion, team building, and team performance is far more important than individual performance.
- Understanding psychology (of individuals, of individuals in teams, and of organizations) is critical for making companies work. "Psych Safety" amounts to the foundation of Maslow's hierarchy of needs, as but one example.
This stuff is important. Build good teams, don't just hire good individuals.
Psychological safety is a double edged sword. If you feel free to interrupt people, express dissent, and joke around during meetings then people might begin to resent you. It's a big risk. Despite feeling "safe", it's still a risk that could affect your job security and finances.
It's about being able to determine when people are resenting you and why. The article focused on people who were sensitive enough to determine when others in their group were feeling upset or left out or something. Also if everyone speaks and interrupts and jokes as much as you, they should be allowed to also express their dissent in that they don't think your jokes are appropriate or that you don't listen or whatever.
Hm, now that I read well, I feel this research group does too much "snapshotting" of dynamics. Groups not performing well could have had their "norms" subjected to a harsh external force, such as, say, performance reviews, hire / fire / downsize / layoff, etc.
And where is the discussion of sociopathy and other classic psychological manipulations? You'd figure that subtle disruptors would be critical to the study, since I argue that middle management collapses in most large organizations due to the Machiavellian predilections of petty power brokering.
I enjoy reading these articles because they always seem to trick me into thinking I got to know of a new insight when I didn't. I don't know why we still cling to psychology when its been shown over and over that the vast majority of psychology is junk science that cannot be reproduced.
I don't understand what is wrong with their methodology as described in this article that makes it junk science. Can you source something that says that the vast majority of psychology can't be reproduced (studies, etc)?
>I don't understand what is wrong with their methodology as described in this article that makes it junk science.
There is nothing wrong with this article and their methodology because it's not about real science at all. Science produces models, with predictability (among other things) where you or I could go out and get the same results. That is far from what Google has actually demonstrated - and I don't know whether they intended to do that in the first place.
Psychology has never been accepted as a science because they don't produce accurate, reproducible models. I don't want to sound rude, but all this stuff isn't exactly new and can be searched for online. A random set of links from 10 seconds of googling:
No rudeness taken; I just would rather people making the claims to have some links for people who don't really search for the reciprocity of fields of pseudoscience/science.
What would you call this thing in the article that people did then? Statistical analysis?
This is a strange cultural thing. On the surface I agree with you. And I'm not a huge fan of forced ratings. But I will say that at some of the places I've worked, there was such a strong culture of sharing that this transcended the forced ranking system.
If anything, I've seen the lack of sharing a bigger issue in places with a culture of competing metrics. "You get paid on revenue, and I get paid on time to completion." I've seen terrible sharing behaviors absent the forced ranking.
267 comments
[ 3.3 ms ] story [ 217 ms ] threadHas NYT ever done an article in this format before?
The "Blind Hiring" section starts off great:
A few years ago, Kedar Iyer, an entrepreneur in Silicon Valley, became acutely aware of a problem in his industry: A surfeit of talented coders were routinely overlooked by employers because they lacked elite pedigrees. Hiring managers, he thought, were too often swayed by the name of a fancy college on a résumé.
It's an excerpt from a book:
> Charles Duhigg is a Pulitzer Prize-winning reporter for The New York Times and the paper’s senior editor of live journalism. He is the author of ‘‘The Power of Habit’’ and the forthcoming book ‘‘Smarter Faster Better: The Secrets of Productivity in Life and Business,’’ from which this article is adapted.
Like him I was also in a military setting before I became a programmer. I haven't yet experienced the same level of engagement and team cohesion outside of the military but I believe that the answers are to be found in the kinds of insights that studies like this uncover.
[1] http://www.tablegroup.com/books/dysfunctions
Never the less, one of the terms is from psychology, one of the terms is from pop culture and may not overlap completely
Psychological safety is less normative: It's about being in a space where it's safe to voice an opinion, and feel that you're heard and valued for your contributions. It's a term that can apply in a very culturally diverse team.
Because being open-minded is their enforced conformity.
And if the leader of the team doesn't respect a member, he won't listen to the member, no matter how long the member gets to talk.
It's Feb. :D
> I'd much prefer reading about companies trying to improve their working environments than about whatever incremental new product feature they're launching.
Google has set the right precedent for the tech-industry, and I am grateful for them having done that. 'Cause other big tech-cos like Amazon sure don't give a damn about employee well-being (not just warehouse workers, but engineers too).
The pattern is "If a junior woman can't code, let's promote her as team lead; If a junior man can't code, let's teach him to code" - and this is wrong because both sides have everything to lose with this behavior.
Basically, give people your full attention when talking to them, and avoid primal displays of dominance or subservience. Mostly the attention part.
Could you elaborate on this? How do you resolve significant differences in height?
Another important bit is that if someone is sitting down, you should sit down next to them. If they're at their desk and there's no chair, squat or kneel.
Leave escape room.
Whether it's a bar or a cubicle, a woman will (in general, according to my wife and other female friends) be aware of being pinned in. For those not thinking of it, it's perfectly natural to stand at the end of a bench seat or in a cubicle opening to talk, but this gives them no "escape" from the situation and increases tension. Simply standing to the side of that escape path makes the situation less tense.
On the generally-male side of things, (drawing purely from my own experiences) I definitely notice when tall people are close to me, but if they stand a little further back I don't really notice their height.
E.g. NBA players who huddle around their coach
Also, don't sit straight across from them, police interrogation style. It's intimidating, especially in situation like an interview. Sit at the orthogonal side of the table.
(Disclaimer: This is my opinion, not that of my employer.)
If you have to pick, your team sucks.
I'll just quote what the Rust team said about their code of conduct, because it's spot-on: "The Rust community doesn't subscribe to the notion that there's a dichotomy between intellectual discourse and kindness."
That's pretty much it. If your team considers those two mutually exclusive, you're headed for trouble. It might not be today or tomorrow, but you will pay for it long-term.
edit: or if it does hurt their feelings, that they'll be able to express that safely, and you'll all be able to resolve the conflict.
A thick skin is necessary, but the point of psychological safety is that it must be normal and expected for someone to make mistakes and to be wrong. It happens inevitably. How teams handle it is the important part. The most successful teams I've experienced are those where someone can say "yeah, I messed up, I'll fix it" and the team sees this as a necessary part of a team's long term function.
That means nobody on the team says "I told you so," and that team members can disagree intensely without making it personal or emotional.
The big problem with "without making it personal or emotional" is that the people most guilty of making disagreements personal or emotionally charged are also least likely (in my experience) to recognize that they're instigating. These people are toxic without realizing it themselves.
I definitely don't mean that. More like, there are always tradeoffs. There is cost/benefit in being truthy just as there is cost/benefit in being harmonious. Each has it's own type and you get to choose which make more sense for the situation, team, etc.
I don't think you can "have it all" so much as you can choose to set the tradeoff point somewhere in the middle rather than at the extremes. For example, in the Rust code of conduct example, it sounds like they have decided they want a nice mix. This will cost them though. Maybe the cost is as small sending $some_multiplier_above_1 the amount of emails between the team because things are worded more indirectly to not offend and therefore more disambiguation has to take place. If their team instead committed to be as direct as possible, the could spend less time on follow up emails but now they'd probably turn of or drive away some good folks from the team who decided they didn't like all the directness and send of urgency.
Personally, I like a nice mix. I think it is just worth being clear with myself it is a mix and not two independent things where you can have an infinite supply of each.
I believe you may be misunderstanding something about the idea of psychological safety. I can't think of any definition of "harmony" that has anything to do with psychological safety.
In other words, a very worthy read.
Like him I was also in a military setting before I became a programmer. I haven't yet experienced the same level of engagement and team cohesion outside of the military but I believe that the answers are to be found in the kinds of insights that studies like this uncover.
[1] http://www.tablegroup.com/books/dysfunctions
edit formatting
However, I have to chime in: I don't agree with the accountability aspect. Responsibility is necessary, along with knowledge and support from the whole system: this broad "ability to be effective" makes accountability obsolete, and is superior.
That combination of Knowledge, Psychology, Systems thinking, and a fourth: an understanding of variation and statistical reality -- leads to a much more complete and functional model of the organization. This is W. Edwards Deming's System of Profound Knowledge.
However, you can see why "The 5 Dysfunctions of a Team" caught on, and his name didn't.
Think of it this way: It's about the responsibility of members of this site to downvote non-productive comments. It's not about meeting a quota of productive comments; it's about disarming non-productive action. We hold each other accountable for having productive discussion.
I believe it is possible, albeit in a slightly different form: elite sports teams and groups of people tied together with a strong shared purpose can get there I think.
edit and yes, as marktangotango says - shared hardship and knowing you can count on the next guy because he's been through what you have and hasn't broken either is also key.
Makes some sense. Team meetings are not where anything gets done after all. If team members are engaged with their peers, they may invest in team goals and perform better.
Issue: they correlated team meeting metrics (talking time; socialization time vs problem solving time etc) with team success at achieving goals. They could have used behavior outside the meetings (communications per day; social interactions after work) and predicted successful teams that way. It doesn't mean that "Meetings that go like this indicates good teams"? I.e. changing your team meetings to look like what good teams do, may not improve your team at all. That might be put under 'cargo cult management'.
You know, I think it's worth pointing something out about the word "safe" given the sense it has been used in lately. In this case, it means people feel safe to express dissent. Not "safe from dissent", as the term is often used nowadays.
Of course the two usages shouldn't be overlapping much anyhow. It shouldn't surprise anyone that a team where people actually attack each other's personal identities is not going to be very effective! But it's still worth pointing out the two very different ways the term can be used, and important not to accidentally substitute one definition for the other.
That's somewhat in tension with being able to express dissent, in that being able to dissent constructively requires both social skill and an underlying environment of trust.
It's easy to cultivate only one of those (eg most OS mailing lists choose dissent) but cultivating both is harder and I haven't seen it ever happen by accident - all the communities that come to mind are ones that direct a lot of attention and effort to community structure and expectations.
I feel the "social rules" are quite valuable both inside and outside the workplace. I wish more employers and groups practiced them: https://www.recurse.com/manual#sec-environment
It's interesting how you choose to represent the safe space culture by its most annoying examples, but chose to represent tech company management culture by it's most positive examples.
However, most people let there identity and there ideas get tied together. So, it can feel similar.
And it is the responsibility of the person on the "attack" to make that clear using whatever approach works in the situation. Otherwise you have a communication problem, and it is primarily your fault for being inarticulate.
In any case, I went out of my way to not be snippy! I just thought it might be helpful to you to know that the mis-use slightly tripped up at least one person. It's hard to know who will find it helpful to have things like that pointed out (like some non-native speakers trying to learn) and who will just get annoyed. Mis-judged this one!
Also, they really are pronounced the same, if your hearing a difference it really is just in your head.
I don't think that's a fair characterisation of what "safe" in "safe space" means.
Is that not a safe space?
Contrariwise, the collegiate-style safe space makes it so that the certain people have boundless rights to be offended, but no corresponding responsibilities to consider other's feelings. In a team context this leads straight back to exactly the failing the article is primarily about, one person/group speaking a great deal more than the other.
(And please do not insult my intellectual integrity by claiming that collegiate-style safe spaces are supposed to be safe spaces for everybody. That is transparently false, to the point that you are just discrediting yourself if you try to claim otherwise. It is abundantly obvious who they are for and who they are aggressively not for.)
This makes me wonder if your only exposure to the concept is through the media, which tends to complain about students a lot.
Or I can feel unsafe even if technically we are perfectly aligned but I know they are going to backstab me in front of my boss anytime they feel like.
I can work or even share room with an Atheist, a Buddhist and a another Christian for weeks on end and we didn't bother another.
I think it is usually enough to respect another, and that includes for the easily offended part (often me) to respect others right to don't care about my customes as long as they don't mess with me.
I do however feel a tiny bit unsafe (for the lack of a better word) in online foras whenever I see people getting online-lynched for not having the correct opinion.
The problem is in attempting to attain the things above, I've also been on teams in a company where I was clearly the strongest person on the team, and was chastised for providing too much guidance because management had the idea it was better for people to fail on their own (in production) than it was for only one person on the team to be the primary contributor of plans/the way to go. Maybe they were right, but the end result was that it made /me/ feel disrespected by management, and my own contributions suffered, causing the overall team to suffer because the other team members were too junior to pick up the slack when my contributions fell off.
I think there's a right way and a wrong way to try to achieve these qualities in a team. My personal experience is that when you have a team of people who are all very strong in at least one skill set and have clear pathways to communication it works much better than having a team which is relatively weak/junior with only one or two people who are strong unless there are clear lines of seniority. It's a consequence of the idea in modern society that "all opinions are created equal" is not only true, but a good thing. It's important that either you're in a group where you can trust the equality of everyone's opinions, or that you have clear leaders that can mentor everyone else and provide strong guidance.
Basically, if you can, build an "A-Team". If you can't do that, make sure you don't actively undermine your A players. If your A players aren't jerks, they're naturally rise into leadership roles in the team and help mentor/teach everyone else to bring them up as well. Undermining the A players will end up causing the entire group to suffer and eventually the A players will leave and you'll be stuck with a group that's significantly weaker for it.
Of course my thoughts above are primarily focused on technical teams, I don't know if they apply as clearly to non-technical teams, and this Google study appears to have looked at both.
https://en.wikipedia.org/wiki/Wa_%28Japanese_culture%29
Do you mean Shockwave, or ads? ;)
This is of course 100% anecdotal.
This of course runs 180 degrees against the concept of fungible engineering and Google's generalist fetish.
Or TLDR: I prefer building the A-Team instead of trying to be Agile.
There is fundamentally too little time in the day, and too much to know to truly be GREAT in a domain, to expect anyone outside a select few (certainly not enough to fill out general employment at google) to be able to bridge these domains meaningfully and still be as deep as possible.
Now; there is a massive benefit to the specialists having sufficient understanding to communicate with other domains. But this to me is not what being a generalist means, and is an asset that is often looked over even in the generalist-focused agile orgs I've worked for; "are we communicating well internally in general".
(To bring this back to the article as well, I've also found the specialist groups with "eigenvectors" of skills to be MORE cohesive, as it's a great trust builder when someone can say "I'll be supporting your work in Y with X" and you know that they'll be doing X _light years_ better than you could, and you can truly TRUST them to have your back. Not that the same thing isn't very feasible in other environments, but that's an "easy way in" to trust.)
One-man bands are a different story though, if a full engineering team is not feasible, a generalist who has a broad but shallow knowledge of lots of things is far preferable to a specialist of one.
How do you get a group of cynical alphas to take-off their game-face for work? This screams for a How To manual.
In modern animal breeding, our goal is typically to improve some trait through genetic means. We extract the animal's DNA, sequence it, and compare it across many different families in order to evaluate how that individual differs from others and how its genetics affects our trait of interest. We call this trait our 'phenotype', and in animal breeding, phenotype is king. We can do all of the analysis we want, but if our phenotype is inaccurately measured or uninformative, it's all a waste of time.
And yet - most of us measure ourselves, how we are performing in a team by things that happen in team meetings(according to the article anyway):
1. Is idea my ideas heard and debated before being accepted/rejected?
2. Do I get opportunity to present my idea at all.
A time boxed meeting does not by nature leave room for idle chit-chat or from my experience even opportunity to hear everyone's thoughts. Part of the problem of course is, meeting rooms in lot of companies are a scarce resource, so you better clear out after time is out.
This is really curious because we hate meetings and yet we have adopted them in a sort of haphazard way which creates more problems than solves.
I meant 20-30 minute meetings that teams typically have, like retrospective or something.
But I was not talking about Agile per-se. I meant in general most meetings of software teams are time boxed nowadays- no matter which development methodology they are following. I am also not criticizing time boxed meetings since I have no data to back that claim.
But I am just curious, what if as a rule - teams decided to have fewer meetings but meeting last as long as they have to not because someone is knocking on the door for next slot. Will it make things easier?
Also one of the core ideas of Agile is adapting to suit your team, rather than following some process from a book as if it were written in stone. If time limits on certain meetings are causing your team more grief than they help, remove the timeboxes! Talk to your team and see what they think, that's what the retrospective is meant for.
The article in this post echos what I had felt: https://news.ycombinator.com/item?id=10731071
This is an interesting article since he cites a pub quiz and sports - something I participate in.
I've been playing for about 4 years in a pub quiz. We've won once and are considered a strong team. However, the difference between the a strong team, and the better team in a night, is the fact that our team fosters a "no suggestion is a dumb suggestion" policy. No matter how stupid you think your answer is, you are encouraged to say it. In fact, if we see body language from a person hesitating we're quick to jump in and say "Spit it out! Just say it!"
We essentially create a safe zone for our team members to not worry about the consequences of a wrong answer. There were so many times where a completely wrong suggestion makes another teammate say, "Hey! Wait, I think I remember!"
We also have a policy of if a person has a different answer than the rest, then he/she has to "fight for it". That is, you have to convince the rest of the team. By having a "fight for it" rule, we put controlled confrontation on the centre of the table and let people hash it out. There is no regret, or fear, or worrying about feelings. It's just a normal part of our evening that is done with humour and friendliness. Firm, but friendly!
By doing the above, we instil confidence in every team member. Those that are more confident by their nature, can still be challenged by anyone and keeps them in check, and the weaker confident ones feel safer to step forward when they need to. It balances out and our team has absolutely great chemistry because of it.
I've also played team sports for most of my life and some of the best teams I've played for had former professional athletes. Since they were stronger than the rest and more confident, they always raised their hand and took the blame for any mistake! It was quite funny because we knew my screw up was not their fault, but they would make an excuse about how they should've done 'X' and I wouldn't have screwed up.
Needless to say, that allowed players like me that weren't former pros, to be at ease and to be more confident and give my best, knowing that the strongest player on the team wasn't going to look down on me for every mistake.
It was a very interesting dynamic where the more confident person ensured that the less confident person is playing their best and it raised their confidence. Again, it is a kind of delicate balance that can change on any given night.
I started cracking up at this point because me and every engineer I know would have said the same thing in response to a survey designed to promote team building.
When people mostly pick who they work with and how, it's usually quite automatic and natural for things to work out without managerial baby-sitting.
I think how well a team works together is sometimes more important then how much knowledge you may have of some arcane framework.
This is one key advantage of startups, actually. Just take your dream team, and co-found a startup with them. Find the business that your particular group can excel at. The more this becomes a viable alternative to just taking a job, the more we'll be optimizing the matching of great teams to big opportunities.
1 - A team can succeed in one environment but fail in another.
2 - If the team does fail, you have a lot more rebuilding to do.
3 - Teams that are independent of company can have different loyalties. The principal-agent problem [0] gets a lot worse if an entire team is being held hostage.
4 - Many times you're not building the project team from scratch. You start with people who have succeeded on other projects.
[0] https://en.wikipedia.org/wiki/Principal%E2%80%93agent_proble...
I've also watched an entire frontend team quit and go work at a different company because, well - they were a pretty well-knit team, but more loyal to each other than to the company...
That kind of thing happens when a big company acquires a small startup, for instance (and it's the main reason I always see acquisitions/acquihires failing spectacularly) - again, all anedoctal...
Sometimes these worked because the acquiring firm had no expertise in a particular area. The biggest impact moving in teams has is that you are familiar with a lot of the business customs already - you have a support team in place. Your shared network can grow a lot more quickly. However, with a liftout, you have enormous pressure to succeed; there's less 'onboard' time since you should know how to work in your team already.
[1] http://press.princeton.edu/titles/9128.html, Chapter 7
I think team-matching service as you described would be something a lot of people from diverse fields will be interested in?
I'm sure they worked better as a team than each one in a different company now.
"RPS: We’re really interested in your view on the independent games scene. I’ve just spoken to the Portal team and discussed Narbacular Drop and the job offer, and their shock and delight at finding themselves in that position…
Gabe: Something that gamers should probably understand is how important it is that game teams stick together. No matter how good a job a team does the first time they make a game they’re going to do a much better job the second or third time. There’s just so much value in a team having shared experiences to draw on, and my reaction looking at these kids was that they had done this fabulous thing. I go to all these trade shows and see all these tedious, derivative, lifeless games, and these kids had done something that was better than 98% of the gameplay I see. The idea that they wouldn’t work together again was a tragedy. They needed an opportunity to work together and ship a full-on game. If they were able to do that exciting a game the first time, then it’s nothing to what they’ll be able to do in the future. It turned out to be a really good idea."
https://www.rockpapershotgun.com/2007/11/21/rps-exclusive-ga...
Whole interview is great.
The business model for app companies and contract software firms comes to mind. The team is really a small business itself and signs contracts with other companies to build things. Is there something different to these that you'd see? Or is it the idea of a team being hired on directly by company after company vs building to a contract?
The problem of hiring individuals to join the firm still exists though. Although I like the approach you propose more than the "dump a bunch of resumes" approach.
Some conclusions:
- Teams and focusing on team cohesion, team building, and team performance is far more important than individual performance.
- Understanding psychology (of individuals, of individuals in teams, and of organizations) is critical for making companies work. "Psych Safety" amounts to the foundation of Maslow's hierarchy of needs, as but one example.
This stuff is important. Build good teams, don't just hire good individuals.
And where is the discussion of sociopathy and other classic psychological manipulations? You'd figure that subtle disruptors would be critical to the study, since I argue that middle management collapses in most large organizations due to the Machiavellian predilections of petty power brokering.
There is nothing wrong with this article and their methodology because it's not about real science at all. Science produces models, with predictability (among other things) where you or I could go out and get the same results. That is far from what Google has actually demonstrated - and I don't know whether they intended to do that in the first place.
Psychology has never been accepted as a science because they don't produce accurate, reproducible models. I don't want to sound rude, but all this stuff isn't exactly new and can be searched for online. A random set of links from 10 seconds of googling:
https://www.theguardian.com/science/2015/aug/27/study-delive...
https://www.newscientist.com/article/dn20447-journal-rejects...
http://psychsciencenotes.blogspot.com/2011/05/failing-to-rep...
What would you call this thing in the article that people did then? Statistical analysis?
These results seem like a condemnation of any management practice based on competitive exclusion.
If anything, I've seen the lack of sharing a bigger issue in places with a culture of competing metrics. "You get paid on revenue, and I get paid on time to completion." I've seen terrible sharing behaviors absent the forced ranking.