12 ms·

Habits of High-Functioning Teams

436 points by zbentley 6y ago

troughway 6y ago
Very good article. There is a thing in leading teams, in having good team composition, structure and over all happiness and strong contribution that is analogous to what Spolsky calls the Development Abstraction Layer. (https://www.joelonsoftware.com/2006/04/11/the-development-abstraction-layer-2/ https://www.joelonsoftware.com/2006/04/11/the-development-ab...) You need to try to find at least one company, one opportunity and see it work well. It is a completely integrated system that permeates the entire organization, from the CEO and CTO, down to a recent hire. The way interviews are conducted is also impacted. Some departments are more stressful than others. Sales, Marketing are the obvious victims in most circumstances and are very competitive. But it is interesting to hear their yearning to adopt this approach.
vsskanth 6y ago
Working for a team like this with psychological safety does indeed sound magical, but I rarely encounter teams like this, big or small corps. I'm not saying they don't exist, just rare. With that being said, two questions arise: 1. What kinds of incentives, business area and market forces create or prevent such teams from forming (since I feel these teams are rare), and how does one ensure a pit of success here ? 2. Is it already hopeless when you inherit a team with low psychological safety or flat out incompetent team members ? Are there incremental steps to get there ?
- kradroy 6y ago
  I have some experience with these questions. 1. Management, and involvement of management in particular. When you're an individual contributor, it can often be motivating and validating to hear praise and interest from a manager, director, VP or beyond. 2. It's not hopeless. In that case there are two courses of action required a) engage the team and build an atmosphere of psychological safety; this is done by giving focused, time-relevant feedback, both positive and critical, on behavior in group settings (e.g. "That question you asked in stand-up was critical. I'm glad you brought it up.") b) push out (fire, transfer, etc) negative influencers and those who don't contribute, once enough time has passed since instituting team culture changes. 2.b might sound harsh, but in normal circumstances a group of people will reject and disassociate with a member who no longer shares their values. In a work setting a manager has to do this or they risk the productive and positive team members leaving.
- momokoko 6y ago
  I’ve found a pretty simple formula. 1. Team deeply cares about the product. Not just the tech. 2. Team deeply cares about each other and has things they deeply care about outside of work. 3. Team has a high level of skill and talent and teammates rarely have to ask for help(as opposed to suggestions / ideas). So in a way it’s hopeless if you don’t have all three. Some people simply do not have a lot of passion for life and work and some people just don’t have enough talent and skill. But sometimes they do and it’s the original culture they inherited that causes the problems. In that case you can fix things. With that said, we all play with the cards we are dealt and you can still achieve great things without a high functioning team.
  - bradlys 6y ago
    Are you saying those are key elements to psychological safety? I’ve never found any of those correlated with psychological safety.
    - momokoko 6y ago
      1. When a team cares deeply about the product as opposed to just the tech, everyone’s goals tend to be more aligned and people tease things less personally because they realize the other person is saying or doing something to make the product better. As opposed to picking favorites or picking tech they want for their resume / career growth. 2. When a team cares deeply about each other there is less distrust and misinterpretation of statements. When people have things the care about outside of work they are less likely to get over emotional about a decision. 3. When there is a high level of skill all around, people are less likely to feel nervous about looking bad or covering up a deficiency. All of this results in greater trust and perspective which correlates quite heavily with psychological safety.
      - bradlys 6y ago
        In a perfect world where there were no managers - maybe this would be true? I can imagine this being more true in a flatter organization or in one where everyone has similar authority inside the company. But, in a more common place, I don't see this being sufficient. The effect a manager/skip-level-manager has on the psychological safety of an environment heavily outweighs any contributions an IC makes (or even a group of ICs). I'd like to add: High level of skill isn't sufficient to say someone is less likely to feel nervous about looking bad or trying to cover up a deficiency. It's entirely up to management and how they punish/reward you. If you are perceived to be high level but make a simple mistake that a lower level employee would make - certain kinds of management would punish you for it. So, you might be nervous because of how management treats you - not because you're bad in your abilities and lack some years of confidence thing. There are certain skills I have that are in the top 1%. You can bet your ass if someone is evaluating me - I get nervous. But if no one is evaluating or I don't even know they're evaluating - I'm not nervous. My point is: I don't think high of level skill is sufficient criteria to say you're less likely to be nervous... It's very environment dependent and not skill dependent.
- itronitron 6y ago
  Not hopeless. Teams with low psychological safety can recover after the toxic people leave. You still need a manager or team lead to show people the path but in my experience 90% of the people want to help their coworkers and be part of something valuable/bigger. It's important that the team be highly connected (in how they coordinate their work), if it's one person talking one on one with everyone else then that's not going to result in a high-functioning team. You also need excitement among at least some of the team members.
- pugworthy 6y ago
  It is rare, which is why we often have that great team/project that we miss so much because it was just right. You can interpret the Steve Jobs quote about A players hiring A players, and B's hiring C's (and so on) as a reflection of technical skill, but I think it's a lot more about personality and psychological safety than technical skill. A good team often seems to focus job interviews on the person, not the technology. Yes, make sure the person can do the job technically, but really focus on whether they'll get along and work well with the team. Make sure they are a good fit. That's A players hiring A players.
Traster 6y ago
>In this post, I’ll try to document the characteristics and habits of the highest-performing teams I’ve been on. One of the real weaknesses of studying high performing teams is this focus on the behaviours of high perfoming teams. So often you end up with horrible activities that are a disaster for teams that have this instituted. Feedback week sounds like a disaster in the making. I'm not doubting it worked for this person, but I think sometimes you need to back away from the examples. What you need to think about when creating a high performance team is understanding that the high performance enables other things. Retrospectives don't enable psychological safety, psychological safety is a pre-requisite for a retrospective to be useful. It's like winning the lottery and then writing about how you chose to spend the money as if that is going to help other people win the lottery.
- wtracy 6y ago
  This reminds me of the Extreme Programming "bubble" (for lack of a better word). Really awesome Practice A (skipping up-front requirements development, shorter QA cycles) is made possible by really tedious Practice B (pair programming, TDD). If you try to cherry pick the obvious shiny stuff while skipping the slow/expensive less-obvious things, you are doomed to fail. Getting back to the subject at hand: I think what would be much more helpful than case studies of existing successful teams would be case studies of teams that were successfully turned around. Not only does that quickly winnow down what factors actually have an impact, it provides more actionable advice in other ways. There are certain factors that are only helpful if you start with a magically perfect team from day one that may not help (or actually be harmful) when implemented with B players or a team with existing dysfunctions. (You are probably right about detailed retrospectives falling into this category.)
  - jacques_chester 6y ago
    Denise's case studies are coming from time at Pivotal, which performed a lot of turnarounds by embedding client teams in order to demonstrate the possible world. I've also worked at Pivotal and I was allocated to several rescue missions in both Labs and R&D. A lot of the work was patiently modelling the possible and continuing to make small, incremental steps towards the better condition. From week to week the situation may appear to be impossible, but one day you look back and realise how much better things are than 4 weeks, 12 weeks, 6 months ago.
bryanrasmussen 6y ago
So like if I was on a team one time with Ken Iverson, John McCarthy, and Peter Norvig and the team did a lot of acid and masturbating at their desks whenever they found a really cool bug to fix I would write an article (and probably found a management movement) to have programmers take acid and masturbate at their desks. hence, stuff like this "Some teams go even further and require that the issue number is tracked in every commit." well, I was on a team that did this and a lot of other stuff listed here but as it happens it wasn't one of the most productive teams I've ever been on.
- danans 6y ago
  > hence, stuff like this "Some teams go even further and require that the issue number is tracked in every commit." well, I was on a team that did this and a lot of other stuff listed here but as it happens it wasn't one of the most productive teams I've ever been on. This shouldn't be interpreted so narrowly. In situations where you are adding small features for fixing bugs to an existing system, having a separate issue per commit really helps communicate the background and intent behind the commit, because a lot of problem solving takes place before any code is changed, and can be very helpful for people who have to change the code later on, or reviewers of the code just prior to commit. If however you are working on a new concept by rapid prototyping, or working on a single large feature comprised of multiple commits, it makes more sense to have a single issue that represents that effort, and all commits related to it point to the same issue. This minimizes issue management overhead while still maintaining the link between the commits and their motivating rationale. Either way, a link to the human conversation that gave rise to a commit or series of commits is very important for understanding the intent behind the code change.
- telesilla 6y ago
  In my experience, aspiring to this while allowing the odd outlier has been very productive. It means the team isn't off fixing random bugs they come across but are focused on what needs to be done.
  - sgift 6y ago
    That you think the team doesn't know whether the "random bug" or something else is "what needs to be done" is a big red flag.
MattGaiser 6y ago
Feedback week seems like a way to introduce a tremendous amount of politics to the workplace. "Feedback week" is not an outcome I would leave to chance unless I trusted management to an extraordinary degree. Getting good feedback would become my priority for the week before and I would be forming partnerships with people to play up certain aspects, especially if management (the people who decide my paychecks) are going to be hearing it. Why would I do all this? It is very hard to shake a negative impression, so preventing one is imperative. Feedback week tells me to spend the week before not asking for help which may be hard to provide, investing in colleague lunches, sending them job postings and encouraging them to seek a promotion, withholding cool productivity improvements until just before feedback week (I have this cool new automation script), and planning my feedback with close team members. That seems like a worse outcome than having me actually doing work.
- jacques_chester 6y ago
  > "Feedback week" is not an outcome I would leave to chance unless I trusted management to an extraordinary degree. I worked for the same company as Denise and yes, I had that kind of trust in my management. I have received at times quite blunt feedback, but it has never to my knowledge put me at threat of losing my job. I have at other times been left feeling cynical, hurt or angry, but expressing those feelings has never put me at threat of losing my job. It's doable. It's just hard and takes a lot of time, a lot of patience and willingness to improve in small steps.
  - z6 6y ago
    I would say losing your job is at the extreme end. There are many ways it could have impacted you without you even knowing. Obvious ones are missing out on promotions, getting a lower raise, bonus, etc. I think it's incredibly naive to think there would be no impact.
    - jacques_chester 6y ago
      I was involved in student politics and then grownup politics, so I feel qualified to exercise all due cynicism about people's motivations. Once I got over literally every other professional experience I'd ever had, Pivotal was the real deal.
michaelborromeo 6y ago
High functioning teams start with high functioning individuals. After that it’s up to the group to not waste effort, not go in the wrong direction too long, avoid toxic behavior, and otherwise stay healthy. But teams start with individual talent.
- BeetleB 6y ago
  > High functioning teams start with high functioning individuals. There's a spectrum between a team with no high functioning individuals and one with all high functioning. In my experience, only 1-3 people in the team need to be "high functioning". Also in my experience, if the whole team is high functioning, then the chances of dysfunction go up significantly. In my career, I've been in a bunch of teams that were full of high functioning folks. And not one of those teams acted as a team. The management almost always graded you based on your individual achievements and not on how you helped the team. As a result, every one of those teams had instances of individuals doing brilliant things that hurt the team effort, but would get rewarded for it. Everyone of those teams had the majority of team members working against each other to get their idea to the fore, due to the reward structures. In every one of those teams, when something went wrong, the focus was on finding out which individual(s) were responsible. I don't believe that what I saw will always be the case, but the correlation is high and I think it is the natural state unless actively guarded against. In other teams where not everyone is high functioning, the focus on working as a team was much greater, and much more successful. It wasn't "Who is responsible for snafu X?", but "How did we allow snafu X to occur?" But of course, a team with no high functioning individuals will be mediocre.
  - michaelborromeo 6y ago
    Mythical man hour describes it this way too right? But yeah I think the incentive structure helps determine outcomes like the one you describe. Maybe a good way to handle having a team FULL of high functioning individuals is to break it up and have them each lead their own team eventually?
    - BeetleB 6y ago
ripvanwinkle 6y ago
I'd love to see an article on how to create psychological safety in the first place where non exists or where the opposite is true. From there all sorts of good habits can take root but without that things like feedback week can become bitterly political events. I suspect creating psychological safety boils down to things like the rewards and incentive system, org structure and transparency of decision making but I'd love to hear if anyone has first hand experience
- PacifyFish 6y ago
  Psychological safety is 10% job security and 90% how comfortable you feel with the people you work with. Simple to understand, hard to make happen - you need to hire well.
  - ckdarby 6y ago
    >you need to hire well This! It is odd to write but the more time I spend in the industry the more I find myself thinking back to that statement, "You can't teach an old dog new tricks." The five dysfunctions of a team have been the hardest things to change in my opinion once habits form that prevent them. I ponder at times if this is truly why "hyper growth" startups tend to hire on average much younger candidates and our industry says that ageism is rampant.
    - joejerryronnie 6y ago
      I just passed on a recent candidate who was a perfect technical fit for an open position on my team (far better than the candidates I’m now considering). He did, however, come across as extremely arrogant and abrasive. I can work with a junior team member growing into a role but I can’t jeopardize the entire team dynamic based on one person’s inability to work well with others, regardless of how proficient they might be.
  - koheripbal 6y ago
    And this is 50% not hiring insufferable assholes, and 50% not hiring fragile snowflakes. 90% of office conflicts I've encountered is between two individuals of these types.
blargmaster33 6y ago
I'm currently enjoying a front row seat of the destruction of a High-Functioning team I managed to build over the last year. I'd fascinating in a sad way how fast the wrong manager can destroy a software team. And it's all about High Psychological Safety.
deleted 6y ago
[deleted]
kevindeasis 6y ago
I've seen this exact information before, multiple times actually. It seems like it's just a rehash of the same generic advice What I'd like to see, is if you enforce this in a dysfunctional team, would that team still be dysfunctional? Are these habits things that come out organically from some high functioning team? Cause I bet if you enforce these kinds of habits to a dysfunctional team, that team would still be dysfunctional, but most likely better. Highly functional teams, would always make things happen, and if you join highly functional teams, you will be part of their culture and reinforce habits There are also, enjoyable teams. Teams that have an amazing culture. Those teams are great to be in, but have a different culture compared to highly functional teams
- baron816 6y ago
  Dysfunctional teams == 10X engineers: https://twitter.com/skirani/status/1149302828420067328?lang=en https://twitter.com/skirani/status/1149302828420067328?lang=...
- pizlonator 6y ago
  I don’t know if enforcing these things on a dysfunctional team would fix anything. It probably depends on the team. But stuff like redistribution of XP and active measures to create psychological safety are necessary components of a functional team. So, it stands to reason that if you want a dysfunctional team to become functional then the manager will have to make those two things happen. It may not be enough if there are more fundamental problems (like toxic team members, toxic upper management, or a toxic code base) so I’d say it’s a “necessary but not sufficient” sort of thing. I also suspect that this lists and others like it are not exhaustive. Probably the best teams have emergent dynamics that even very smart people don’t know how to describe or reproduce.
- zoomablemind 6y ago
  > What I'd like to see, is if you enforce this in a dysfunctional team, would that team still be dysfunctional? I was wondering the same. It seems that the 'good' team dynamics just happens, mostly due to a combination of factors. People, of course, are firstmost. Then the company organism is a big factor too. An isolated team might enjoy a feeling of superiority, yet at some side of it there's still a connection to the rest of the company, with all the 'inferor' luggage that there might be. You're lucky if a manager is the shield that keeps that external drag at bay to alow his team to perform at their best. The psychological safety that the author mentions is analogous to the feeling of comfort. It can equally apply to healthy as well as to unhealthy teams, as long as the values are shared by the team members. We all have seen very stable yet underperforming teams, trying one or the other technique/practice to put another layer of make-up on a zombi face. It may sound pessimistic, but it seems that once a team settles in its low energy state it's next to impossible to reenergize it by introducing techniques and practices. Borrowing the analogy... how does one deal with zombies...figuratively speaking? Then, what if by now you are one of them? On the other hand, when team is still alive or new, then all this spirit must be nurtured. Techniques, experiments, practices. Most importantly, respect!
dpc_pw 6y ago
I don't buy almost any of it. The thing is - it's very hard to compare performance between projects and teams. What author considers "high-performance" might mean "environment I felt productive in" and so on. Don't get me wrong. It might all be good advice and work well, or it might not. Or might work in some contexts, but not in other. And it's all just an opinion.
hn_check 6y ago
I once had an occasional associate tell me how remarkable his team was. They had daily scrums, amazing communications, everyone loved the work and the organization, they felt good about their quality and pace, etc. He told me, with great enthusiasm, that this was the best group he'd ever worked with. Happenstance brought us together when another associate called on me to audit this firm as they were acquiring and incorporating it. Awkward, right, but I was sure it'd be a cakewalk given how great it had been described to me. It was anything but. A team of approximately 12-16 developers (plus a handful of QA, several BAs, etc) had, it turned out, spent years doing trivial refinements on a system that a passing "cowboy coder" (who they all derided at every chance) almost single-handedly made close to a decade earlier. He built a system and then moved on to greener pastures. This team had, from the history, at various points tried their own reinvention. Each was a failure. They "refactored" to whatever was the trend that year, so every layer had become a fragmented disaster of countless approaches, standards, etc. Their Jira history was almost cartoonish, with the most absolutely trivial change somehow turning into weeks of work. I had to listen in on some scrums and it was amazing how the culture had made them happy with long bullshitty diatribes about how every tool is crashy junk, aren't they heroic, etc. I think of that when I see tales like this. We have no idea how high functioning his team is, and many such teams live in an insular bubble where there is little competition and little perspective.
baron816 6y ago
Another point I'd like to suggest: The motivations of the individual, the team, and the company should all aligned. Individuals should be happy to help other team members, or members of other teams. Teams should be willing to give up under utilized resources if it means contributing to the goals of the company. The company and teams should support individual growth and reward individuals who help them reach their goals. That should all be obvious, but it's not uncommon for individuals to be in competition with each other, teams to hoard resources "just in case," and individuals and companies to have an adversarial relationship.
- JumpCrisscross 6y ago
  > motivations of the individual, the team, and the company should all aligned Expanding on this from the perspective of building and managing sales teams. Personality must be considered when building incentives. Sales teams can be paid on commission, paid on salary, or both. A great salesperson under one model can be terrible under the other. Commission-paid sales teams should not need motivating; their processes will focus on ensuring long-term decision making and avoiding risks to the firm. Salaried teams shouldn't need those processes to be as heavy, but will need ones to get balls rolling. Lifting systems from one model and applying them to the other will be disastrous. Unfortunately, a lot of naïve management involves this sort of tooling transport.
noizejoy 6y ago
What I’m missing the most in TFA and this discussion (a few hints notwithstanding) is the importance of demographics compared to process. Programming is very much a process thing, people much less so. Successful teams in programming (just like in sports and other human endeavours) seem to have the right mix of skills as well as of personalities. What the right mix is, varies by project - even within programming. In my own experience, even gender mix seemed correlated to team success - roughly 50/50 mixes seemed the best. And a distribution of leaders/followers, nerds/playboys/mothers/flirts/emos/rationals/heroes/pessimists etc. - depending on the project at hand. And team size matters - a lot (but that seems already better understood in programming circles).
guest2143 6y ago
Anyone have an example of taking a low functioning team to a high functioning one? Building trust, changing culture. It's one thing to just say "here's the ideal". And another to say if you're in a sub-optimal place, "just leave." But how to change a poor habit place into a good habit place. I don't think bad habits really go away, they get drowned out by the better habits. I think the same is true of teams. But, IMHE, improvement has been hard to come by. I'd love to hear your stories.
- bradlys 6y ago
  I presume most people here at still ICs, so I don’t think there is anything you can really do except get into a leadership position and change it yourself. The best thing I’ve done for psychological safety is by creating groups within the team that are willing to share feedback with each other. As long as there isn’t a bad manager involved or people who are incentivized to sabotage work, we do okay. But, ultimately, it’s unproductive and we all end up looking for new jobs in the end anyway. I’ll admit I haven’t had every manager in the world but it feels like the manager ultimately decides the psychological safety of the team in the end. If they want it to be unsafe, you can’t do anything about it.
modwest 6y ago
Hoo doggies I need management at work to read and internalize this.
rb808 6y ago
Its probably both cause and effect, but low turnover helps immensely. The joy of working on a project where the whole team has been there for 3-5 years and we had no new people to train was huge. Conversely I've worked on projects where a continual turnover of people means no one fully understands how to code works and no one really cares because they'll probably be leaving soon anyway.
29athrowaway 6y ago
Efficiency means different things to different people. An incomplete list of them (note that these are not mutually exclusive): a) finishing tasks quickly ("velocity") b) pushing more code c) maximizing the work not done d) reducing rework e) creating maintainable, reusable code f) being more productive than other team members g) authoring new projects / components Are each one of them the ultimate goal? Let's see: a) Customers do not buy kanban boards, they buy quality products. A board with finished tasks looks nice, but is your new code production ready? does the result actually make sense? b) Customers do not buy kSLOCs, they buy featured products. Who will be paying for the maintenance of the new lines of code? c) Neglecting tasks that increase your productivity leads to "maximizing the work done". d) Trying to anticipate future requirements can make the code base unnecessarily complex. Implementation is not a substitute for proper requirement analysis. e) Reusability should not come at the expense of maintainability. f) Individual productivity should not come at the cost of collective productivity. g) Before you start a project: can you solve that problem using an existing, robust solution within your budget? And by budget, remember that that internal projects are not free. They are paid with development time. Paying 10k for a license is cheaper than paying a full time developer. And actually, you may need more than one developer, for redundancy (bus factor), making your internal project even more expensive.
friendlybus 6y ago
This is a political piece. Casually mentioning words defined by feminism (microaggressions, stereotyping, ect) means you are going to have to deal with the politics the author brought in. The article reads like a laundry list of things the author wants to receive, rather than dealing with what people are capable of giving. It is fundamentally risk averse and takes the worst part of egalitarianism to bring the team down to a slow pace the author can tolerate and receive what he or she intends to receive. Egalitarian attitudes like the attempt buried in the "exp sharing" idea can be used as a great force for driving higher achievement. If my mate can do it, I can do it. I can try and equal a higher standard the team has achieved. The author does not do this and instead demands that high functioning individuals waste their time doing management's job of allocating work and spreading the challenge of work to people who won't have the opportunity to deploy the knowledge they gain from redistributed work. Overall this kind of language policing and redistributive workplace mechanisms is how bureaucracy that grinds to a halt, is formed. I would leave this company, I have spent years at school, I don't mean to go back to another micro-managed institution and run at the slowest workers pace. Downvotes without reply on a political post. Welcome to the gulag.
- dang 6y ago
  Please don't post ideological battle comments to HN: https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html. Also, please don't do this: > Downvotes without reply on a political post. Welcome to the gulag. ...it's also against the guidelines and guarantees further downvotes and flags.
  - friendlybus 6y ago
    With all due respect, the article brought up the political ideology. I would not have made any comments if the author did not include feminism, both in definition and in links to geekfeminism. -https://geekfeminism.wikia.org/wiki/Microaggressions https://geekfeminism.wikia.org/wiki/Microaggressions -https://geekfeminism.wikia.org/wiki/Stereotype_threat https://geekfeminism.wikia.org/wiki/Stereotype_threat -https://geekfeminism.wikia.org/wiki/Reducing_male_bias_in_hiring https://geekfeminism.wikia.org/wiki/Reducing_male_bias_in_hi... >...it's also against the guidelines and guarantees further downvotes and flags. I have earnt 750 karma almost entirely in productive comments, I know the rules. I have done this before and gotten productive replies. You can't allow politics in the written articles and then complain you get political replies. Just admit you chose sides and I'll leave voluntarily.
ojhughes 6y ago
Good hygiene goes beyond just code hygiene. Highly functioning teams take good care of themselves, shower regularly, rest well, exercise.
nunez 6y ago
I agree with Denise. High-performing teams are high-performing primarily because they communicate openly with each other, during good times and bad, and their leads are really good about keeping them away from political bullshit without sacrificing velocity. They also encourage learning and have the autonomy and authority to fix things when they are broken even if that means stopping a release. In cultures where mistakes are forbidden, features are currency, and development is just a step ladder into management, (I.e. a large swath of enterprises) instituting the foundations of high-performing teams is insanely hard to do. It usually takes an executive willing to put their career on the line to try and change things.

436 points by zbentley 6y ago

Very good article. There is a thing in leading teams, in having good team composition, structure and over all happiness and strong contribution that is analogous to what Spolsky calls the Development Abstraction Layer. (https://www.joelonsoftware.com/2006/04/11/the-development-abstraction-layer-2/ https://www.joelonsoftware.com/2006/04/11/the-development-ab...) You need to try to find at least one company, one opportunity and see it work well. It is a completely integrated system that permeates the entire organization, from the CEO and CTO, down to a recent hire. The way interviews are conducted is also impacted. Some departments are more stressful than others. Sales, Marketing are the obvious victims in most circumstances and are very competitive. But it is interesting to hear their yearning to adopt this approach.

vsskanth 6y ago

Working for a team like this with psychological safety does indeed sound magical, but I rarely encounter teams like this, big or small corps. I'm not saying they don't exist, just rare. With that being said, two questions arise: 1. What kinds of incentives, business area and market forces create or prevent such teams from forming (since I feel these teams are rare), and how does one ensure a pit of success here ? 2. Is it already hopeless when you inherit a team with low psychological safety or flat out incompetent team members ? Are there incremental steps to get there ?

kradroy 6y ago
I have some experience with these questions. 1. Management, and involvement of management in particular. When you're an individual contributor, it can often be motivating and validating to hear praise and interest from a manager, director, VP or beyond. 2. It's not hopeless. In that case there are two courses of action required a) engage the team and build an atmosphere of psychological safety; this is done by giving focused, time-relevant feedback, both positive and critical, on behavior in group settings (e.g. "That question you asked in stand-up was critical. I'm glad you brought it up.") b) push out (fire, transfer, etc) negative influencers and those who don't contribute, once enough time has passed since instituting team culture changes. 2.b might sound harsh, but in normal circumstances a group of people will reject and disassociate with a member who no longer shares their values. In a work setting a manager has to do this or they risk the productive and positive team members leaving.
momokoko 6y ago
I’ve found a pretty simple formula. 1. Team deeply cares about the product. Not just the tech. 2. Team deeply cares about each other and has things they deeply care about outside of work. 3. Team has a high level of skill and talent and teammates rarely have to ask for help(as opposed to suggestions / ideas). So in a way it’s hopeless if you don’t have all three. Some people simply do not have a lot of passion for life and work and some people just don’t have enough talent and skill. But sometimes they do and it’s the original culture they inherited that causes the problems. In that case you can fix things. With that said, we all play with the cards we are dealt and you can still achieve great things without a high functioning team.
- bradlys 6y ago
  Are you saying those are key elements to psychological safety? I’ve never found any of those correlated with psychological safety.
  - momokoko 6y ago
    1. When a team cares deeply about the product as opposed to just the tech, everyone’s goals tend to be more aligned and people tease things less personally because they realize the other person is saying or doing something to make the product better. As opposed to picking favorites or picking tech they want for their resume / career growth. 2. When a team cares deeply about each other there is less distrust and misinterpretation of statements. When people have things the care about outside of work they are less likely to get over emotional about a decision. 3. When there is a high level of skill all around, people are less likely to feel nervous about looking bad or covering up a deficiency. All of this results in greater trust and perspective which correlates quite heavily with psychological safety.
    - bradlys 6y ago
      In a perfect world where there were no managers - maybe this would be true? I can imagine this being more true in a flatter organization or in one where everyone has similar authority inside the company. But, in a more common place, I don't see this being sufficient. The effect a manager/skip-level-manager has on the psychological safety of an environment heavily outweighs any contributions an IC makes (or even a group of ICs). I'd like to add: High level of skill isn't sufficient to say someone is less likely to feel nervous about looking bad or trying to cover up a deficiency. It's entirely up to management and how they punish/reward you. If you are perceived to be high level but make a simple mistake that a lower level employee would make - certain kinds of management would punish you for it. So, you might be nervous because of how management treats you - not because you're bad in your abilities and lack some years of confidence thing. There are certain skills I have that are in the top 1%. You can bet your ass if someone is evaluating me - I get nervous. But if no one is evaluating or I don't even know they're evaluating - I'm not nervous. My point is: I don't think high of level skill is sufficient criteria to say you're less likely to be nervous... It's very environment dependent and not skill dependent.
itronitron 6y ago
Not hopeless. Teams with low psychological safety can recover after the toxic people leave. You still need a manager or team lead to show people the path but in my experience 90% of the people want to help their coworkers and be part of something valuable/bigger. It's important that the team be highly connected (in how they coordinate their work), if it's one person talking one on one with everyone else then that's not going to result in a high-functioning team. You also need excitement among at least some of the team members.
pugworthy 6y ago
It is rare, which is why we often have that great team/project that we miss so much because it was just right. You can interpret the Steve Jobs quote about A players hiring A players, and B's hiring C's (and so on) as a reflection of technical skill, but I think it's a lot more about personality and psychological safety than technical skill. A good team often seems to focus job interviews on the person, not the technology. Yes, make sure the person can do the job technically, but really focus on whether they'll get along and work well with the team. Make sure they are a good fit. That's A players hiring A players.

Traster 6y ago

>In this post, I’ll try to document the characteristics and habits of the highest-performing teams I’ve been on. One of the real weaknesses of studying high performing teams is this focus on the behaviours of high perfoming teams. So often you end up with horrible activities that are a disaster for teams that have this instituted. Feedback week sounds like a disaster in the making. I'm not doubting it worked for this person, but I think sometimes you need to back away from the examples. What you need to think about when creating a high performance team is understanding that the high performance enables other things. Retrospectives don't enable psychological safety, psychological safety is a pre-requisite for a retrospective to be useful. It's like winning the lottery and then writing about how you chose to spend the money as if that is going to help other people win the lottery.

wtracy 6y ago
This reminds me of the Extreme Programming "bubble" (for lack of a better word). Really awesome Practice A (skipping up-front requirements development, shorter QA cycles) is made possible by really tedious Practice B (pair programming, TDD). If you try to cherry pick the obvious shiny stuff while skipping the slow/expensive less-obvious things, you are doomed to fail. Getting back to the subject at hand: I think what would be much more helpful than case studies of existing successful teams would be case studies of teams that were successfully turned around. Not only does that quickly winnow down what factors actually have an impact, it provides more actionable advice in other ways. There are certain factors that are only helpful if you start with a magically perfect team from day one that may not help (or actually be harmful) when implemented with B players or a team with existing dysfunctions. (You are probably right about detailed retrospectives falling into this category.)
- jacques_chester 6y ago
  Denise's case studies are coming from time at Pivotal, which performed a lot of turnarounds by embedding client teams in order to demonstrate the possible world. I've also worked at Pivotal and I was allocated to several rescue missions in both Labs and R&D. A lot of the work was patiently modelling the possible and continuing to make small, incremental steps towards the better condition. From week to week the situation may appear to be impossible, but one day you look back and realise how much better things are than 4 weeks, 12 weeks, 6 months ago.

bryanrasmussen 6y ago

So like if I was on a team one time with Ken Iverson, John McCarthy, and Peter Norvig and the team did a lot of acid and masturbating at their desks whenever they found a really cool bug to fix I would write an article (and probably found a management movement) to have programmers take acid and masturbate at their desks. hence, stuff like this "Some teams go even further and require that the issue number is tracked in every commit." well, I was on a team that did this and a lot of other stuff listed here but as it happens it wasn't one of the most productive teams I've ever been on.

danans 6y ago
> hence, stuff like this "Some teams go even further and require that the issue number is tracked in every commit." well, I was on a team that did this and a lot of other stuff listed here but as it happens it wasn't one of the most productive teams I've ever been on. This shouldn't be interpreted so narrowly. In situations where you are adding small features for fixing bugs to an existing system, having a separate issue per commit really helps communicate the background and intent behind the commit, because a lot of problem solving takes place before any code is changed, and can be very helpful for people who have to change the code later on, or reviewers of the code just prior to commit. If however you are working on a new concept by rapid prototyping, or working on a single large feature comprised of multiple commits, it makes more sense to have a single issue that represents that effort, and all commits related to it point to the same issue. This minimizes issue management overhead while still maintaining the link between the commits and their motivating rationale. Either way, a link to the human conversation that gave rise to a commit or series of commits is very important for understanding the intent behind the code change.
telesilla 6y ago
In my experience, aspiring to this while allowing the odd outlier has been very productive. It means the team isn't off fixing random bugs they come across but are focused on what needs to be done.
- sgift 6y ago
  That you think the team doesn't know whether the "random bug" or something else is "what needs to be done" is a big red flag.

MattGaiser 6y ago

Feedback week seems like a way to introduce a tremendous amount of politics to the workplace. "Feedback week" is not an outcome I would leave to chance unless I trusted management to an extraordinary degree. Getting good feedback would become my priority for the week before and I would be forming partnerships with people to play up certain aspects, especially if management (the people who decide my paychecks) are going to be hearing it. Why would I do all this? It is very hard to shake a negative impression, so preventing one is imperative. Feedback week tells me to spend the week before not asking for help which may be hard to provide, investing in colleague lunches, sending them job postings and encouraging them to seek a promotion, withholding cool productivity improvements until just before feedback week (I have this cool new automation script), and planning my feedback with close team members. That seems like a worse outcome than having me actually doing work.

jacques_chester 6y ago
> "Feedback week" is not an outcome I would leave to chance unless I trusted management to an extraordinary degree. I worked for the same company as Denise and yes, I had that kind of trust in my management. I have received at times quite blunt feedback, but it has never to my knowledge put me at threat of losing my job. I have at other times been left feeling cynical, hurt or angry, but expressing those feelings has never put me at threat of losing my job. It's doable. It's just hard and takes a lot of time, a lot of patience and willingness to improve in small steps.
- z6 6y ago
  I would say losing your job is at the extreme end. There are many ways it could have impacted you without you even knowing. Obvious ones are missing out on promotions, getting a lower raise, bonus, etc. I think it's incredibly naive to think there would be no impact.
  - jacques_chester 6y ago
    I was involved in student politics and then grownup politics, so I feel qualified to exercise all due cynicism about people's motivations. Once I got over literally every other professional experience I'd ever had, Pivotal was the real deal.

michaelborromeo 6y ago

High functioning teams start with high functioning individuals. After that it’s up to the group to not waste effort, not go in the wrong direction too long, avoid toxic behavior, and otherwise stay healthy. But teams start with individual talent.

BeetleB 6y ago
> High functioning teams start with high functioning individuals. There's a spectrum between a team with no high functioning individuals and one with all high functioning. In my experience, only 1-3 people in the team need to be "high functioning". Also in my experience, if the whole team is high functioning, then the chances of dysfunction go up significantly. In my career, I've been in a bunch of teams that were full of high functioning folks. And not one of those teams acted as a team. The management almost always graded you based on your individual achievements and not on how you helped the team. As a result, every one of those teams had instances of individuals doing brilliant things that hurt the team effort, but would get rewarded for it. Everyone of those teams had the majority of team members working against each other to get their idea to the fore, due to the reward structures. In every one of those teams, when something went wrong, the focus was on finding out which individual(s) were responsible. I don't believe that what I saw will always be the case, but the correlation is high and I think it is the natural state unless actively guarded against. In other teams where not everyone is high functioning, the focus on working as a team was much greater, and much more successful. It wasn't "Who is responsible for snafu X?", but "How did we allow snafu X to occur?" But of course, a team with no high functioning individuals will be mediocre.
- michaelborromeo 6y ago
  Mythical man hour describes it this way too right? But yeah I think the incentive structure helps determine outcomes like the one you describe. Maybe a good way to handle having a team FULL of high functioning individuals is to break it up and have them each lead their own team eventually?
  - BeetleB 6y ago

ripvanwinkle 6y ago

I'd love to see an article on how to create psychological safety in the first place where non exists or where the opposite is true. From there all sorts of good habits can take root but without that things like feedback week can become bitterly political events. I suspect creating psychological safety boils down to things like the rewards and incentive system, org structure and transparency of decision making but I'd love to hear if anyone has first hand experience

PacifyFish 6y ago
Psychological safety is 10% job security and 90% how comfortable you feel with the people you work with. Simple to understand, hard to make happen - you need to hire well.
- ckdarby 6y ago
  >you need to hire well This! It is odd to write but the more time I spend in the industry the more I find myself thinking back to that statement, "You can't teach an old dog new tricks." The five dysfunctions of a team have been the hardest things to change in my opinion once habits form that prevent them. I ponder at times if this is truly why "hyper growth" startups tend to hire on average much younger candidates and our industry says that ageism is rampant.
  - joejerryronnie 6y ago
    I just passed on a recent candidate who was a perfect technical fit for an open position on my team (far better than the candidates I’m now considering). He did, however, come across as extremely arrogant and abrasive. I can work with a junior team member growing into a role but I can’t jeopardize the entire team dynamic based on one person’s inability to work well with others, regardless of how proficient they might be.
- koheripbal 6y ago
  And this is 50% not hiring insufferable assholes, and 50% not hiring fragile snowflakes. 90% of office conflicts I've encountered is between two individuals of these types.

blargmaster33 6y ago

I'm currently enjoying a front row seat of the destruction of a High-Functioning team I managed to build over the last year. I'd fascinating in a sad way how fast the wrong manager can destroy a software team. And it's all about High Psychological Safety.

deleted 6y ago

[deleted]

kevindeasis 6y ago

I've seen this exact information before, multiple times actually. It seems like it's just a rehash of the same generic advice What I'd like to see, is if you enforce this in a dysfunctional team, would that team still be dysfunctional? Are these habits things that come out organically from some high functioning team? Cause I bet if you enforce these kinds of habits to a dysfunctional team, that team would still be dysfunctional, but most likely better. Highly functional teams, would always make things happen, and if you join highly functional teams, you will be part of their culture and reinforce habits There are also, enjoyable teams. Teams that have an amazing culture. Those teams are great to be in, but have a different culture compared to highly functional teams

baron816 6y ago
Dysfunctional teams == 10X engineers: https://twitter.com/skirani/status/1149302828420067328?lang=en https://twitter.com/skirani/status/1149302828420067328?lang=...
pizlonator 6y ago
I don’t know if enforcing these things on a dysfunctional team would fix anything. It probably depends on the team. But stuff like redistribution of XP and active measures to create psychological safety are necessary components of a functional team. So, it stands to reason that if you want a dysfunctional team to become functional then the manager will have to make those two things happen. It may not be enough if there are more fundamental problems (like toxic team members, toxic upper management, or a toxic code base) so I’d say it’s a “necessary but not sufficient” sort of thing. I also suspect that this lists and others like it are not exhaustive. Probably the best teams have emergent dynamics that even very smart people don’t know how to describe or reproduce.
zoomablemind 6y ago
> What I'd like to see, is if you enforce this in a dysfunctional team, would that team still be dysfunctional? I was wondering the same. It seems that the 'good' team dynamics just happens, mostly due to a combination of factors. People, of course, are firstmost. Then the company organism is a big factor too. An isolated team might enjoy a feeling of superiority, yet at some side of it there's still a connection to the rest of the company, with all the 'inferor' luggage that there might be. You're lucky if a manager is the shield that keeps that external drag at bay to alow his team to perform at their best. The psychological safety that the author mentions is analogous to the feeling of comfort. It can equally apply to healthy as well as to unhealthy teams, as long as the values are shared by the team members. We all have seen very stable yet underperforming teams, trying one or the other technique/practice to put another layer of make-up on a zombi face. It may sound pessimistic, but it seems that once a team settles in its low energy state it's next to impossible to reenergize it by introducing techniques and practices. Borrowing the analogy... how does one deal with zombies...figuratively speaking? Then, what if by now you are one of them? On the other hand, when team is still alive or new, then all this spirit must be nurtured. Techniques, experiments, practices. Most importantly, respect!

dpc_pw 6y ago

I don't buy almost any of it. The thing is - it's very hard to compare performance between projects and teams. What author considers "high-performance" might mean "environment I felt productive in" and so on. Don't get me wrong. It might all be good advice and work well, or it might not. Or might work in some contexts, but not in other. And it's all just an opinion.

hn_check 6y ago

I once had an occasional associate tell me how remarkable his team was. They had daily scrums, amazing communications, everyone loved the work and the organization, they felt good about their quality and pace, etc. He told me, with great enthusiasm, that this was the best group he'd ever worked with. Happenstance brought us together when another associate called on me to audit this firm as they were acquiring and incorporating it. Awkward, right, but I was sure it'd be a cakewalk given how great it had been described to me. It was anything but. A team of approximately 12-16 developers (plus a handful of QA, several BAs, etc) had, it turned out, spent years doing trivial refinements on a system that a passing "cowboy coder" (who they all derided at every chance) almost single-handedly made close to a decade earlier. He built a system and then moved on to greener pastures. This team had, from the history, at various points tried their own reinvention. Each was a failure. They "refactored" to whatever was the trend that year, so every layer had become a fragmented disaster of countless approaches, standards, etc. Their Jira history was almost cartoonish, with the most absolutely trivial change somehow turning into weeks of work. I had to listen in on some scrums and it was amazing how the culture had made them happy with long bullshitty diatribes about how every tool is crashy junk, aren't they heroic, etc. I think of that when I see tales like this. We have no idea how high functioning his team is, and many such teams live in an insular bubble where there is little competition and little perspective.

baron816 6y ago

Another point I'd like to suggest: The motivations of the individual, the team, and the company should all aligned. Individuals should be happy to help other team members, or members of other teams. Teams should be willing to give up under utilized resources if it means contributing to the goals of the company. The company and teams should support individual growth and reward individuals who help them reach their goals. That should all be obvious, but it's not uncommon for individuals to be in competition with each other, teams to hoard resources "just in case," and individuals and companies to have an adversarial relationship.

JumpCrisscross 6y ago
> motivations of the individual, the team, and the company should all aligned Expanding on this from the perspective of building and managing sales teams. Personality must be considered when building incentives. Sales teams can be paid on commission, paid on salary, or both. A great salesperson under one model can be terrible under the other. Commission-paid sales teams should not need motivating; their processes will focus on ensuring long-term decision making and avoiding risks to the firm. Salaried teams shouldn't need those processes to be as heavy, but will need ones to get balls rolling. Lifting systems from one model and applying them to the other will be disastrous. Unfortunately, a lot of naïve management involves this sort of tooling transport.

noizejoy 6y ago

What I’m missing the most in TFA and this discussion (a few hints notwithstanding) is the importance of demographics compared to process. Programming is very much a process thing, people much less so. Successful teams in programming (just like in sports and other human endeavours) seem to have the right mix of skills as well as of personalities. What the right mix is, varies by project - even within programming. In my own experience, even gender mix seemed correlated to team success - roughly 50/50 mixes seemed the best. And a distribution of leaders/followers, nerds/playboys/mothers/flirts/emos/rationals/heroes/pessimists etc. - depending on the project at hand. And team size matters - a lot (but that seems already better understood in programming circles).

guest2143 6y ago

Anyone have an example of taking a low functioning team to a high functioning one? Building trust, changing culture. It's one thing to just say "here's the ideal". And another to say if you're in a sub-optimal place, "just leave." But how to change a poor habit place into a good habit place. I don't think bad habits really go away, they get drowned out by the better habits. I think the same is true of teams. But, IMHE, improvement has been hard to come by. I'd love to hear your stories.

bradlys 6y ago
I presume most people here at still ICs, so I don’t think there is anything you can really do except get into a leadership position and change it yourself. The best thing I’ve done for psychological safety is by creating groups within the team that are willing to share feedback with each other. As long as there isn’t a bad manager involved or people who are incentivized to sabotage work, we do okay. But, ultimately, it’s unproductive and we all end up looking for new jobs in the end anyway. I’ll admit I haven’t had every manager in the world but it feels like the manager ultimately decides the psychological safety of the team in the end. If they want it to be unsafe, you can’t do anything about it.

modwest 6y ago

Hoo doggies I need management at work to read and internalize this.

rb808 6y ago

Its probably both cause and effect, but low turnover helps immensely. The joy of working on a project where the whole team has been there for 3-5 years and we had no new people to train was huge. Conversely I've worked on projects where a continual turnover of people means no one fully understands how to code works and no one really cares because they'll probably be leaving soon anyway.

29athrowaway 6y ago

Efficiency means different things to different people. An incomplete list of them (note that these are not mutually exclusive): a) finishing tasks quickly ("velocity") b) pushing more code c) maximizing the work not done d) reducing rework e) creating maintainable, reusable code f) being more productive than other team members g) authoring new projects / components Are each one of them the ultimate goal? Let's see: a) Customers do not buy kanban boards, they buy quality products. A board with finished tasks looks nice, but is your new code production ready? does the result actually make sense? b) Customers do not buy kSLOCs, they buy featured products. Who will be paying for the maintenance of the new lines of code? c) Neglecting tasks that increase your productivity leads to "maximizing the work done". d) Trying to anticipate future requirements can make the code base unnecessarily complex. Implementation is not a substitute for proper requirement analysis. e) Reusability should not come at the expense of maintainability. f) Individual productivity should not come at the cost of collective productivity. g) Before you start a project: can you solve that problem using an existing, robust solution within your budget? And by budget, remember that that internal projects are not free. They are paid with development time. Paying 10k for a license is cheaper than paying a full time developer. And actually, you may need more than one developer, for redundancy (bus factor), making your internal project even more expensive.

friendlybus 6y ago

This is a political piece. Casually mentioning words defined by feminism (microaggressions, stereotyping, ect) means you are going to have to deal with the politics the author brought in. The article reads like a laundry list of things the author wants to receive, rather than dealing with what people are capable of giving. It is fundamentally risk averse and takes the worst part of egalitarianism to bring the team down to a slow pace the author can tolerate and receive what he or she intends to receive. Egalitarian attitudes like the attempt buried in the "exp sharing" idea can be used as a great force for driving higher achievement. If my mate can do it, I can do it. I can try and equal a higher standard the team has achieved. The author does not do this and instead demands that high functioning individuals waste their time doing management's job of allocating work and spreading the challenge of work to people who won't have the opportunity to deploy the knowledge they gain from redistributed work. Overall this kind of language policing and redistributive workplace mechanisms is how bureaucracy that grinds to a halt, is formed. I would leave this company, I have spent years at school, I don't mean to go back to another micro-managed institution and run at the slowest workers pace. Downvotes without reply on a political post. Welcome to the gulag.

dang 6y ago
Please don't post ideological battle comments to HN: https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html. Also, please don't do this: > Downvotes without reply on a political post. Welcome to the gulag. ...it's also against the guidelines and guarantees further downvotes and flags.
- friendlybus 6y ago
  With all due respect, the article brought up the political ideology. I would not have made any comments if the author did not include feminism, both in definition and in links to geekfeminism. -https://geekfeminism.wikia.org/wiki/Microaggressions https://geekfeminism.wikia.org/wiki/Microaggressions -https://geekfeminism.wikia.org/wiki/Stereotype_threat https://geekfeminism.wikia.org/wiki/Stereotype_threat -https://geekfeminism.wikia.org/wiki/Reducing_male_bias_in_hiring https://geekfeminism.wikia.org/wiki/Reducing_male_bias_in_hi... >...it's also against the guidelines and guarantees further downvotes and flags. I have earnt 750 karma almost entirely in productive comments, I know the rules. I have done this before and gotten productive replies. You can't allow politics in the written articles and then complain you get political replies. Just admit you chose sides and I'll leave voluntarily.

ojhughes 6y ago

Good hygiene goes beyond just code hygiene. Highly functioning teams take good care of themselves, shower regularly, rest well, exercise.

nunez 6y ago

I agree with Denise. High-performing teams are high-performing primarily because they communicate openly with each other, during good times and bad, and their leads are really good about keeping them away from political bullshit without sacrificing velocity. They also encourage learning and have the autonomy and authority to fix things when they are broken even if that means stopping a release. In cultures where mistakes are forbidden, features are currency, and development is just a step ladder into management, (I.e. a large swath of enterprises) instituting the foundations of high-performing teams is insanely hard to do. It usually takes an executive willing to put their career on the line to try and change things.