[HN Gopher] Habits of High-Functioning Teams
___________________________________________________________________
Habits of High-Functioning Teams
Author : zbentley
Score : 260 points
Date : 2020-05-24 12:11 UTC (10 hours ago)
(HTM) web link (deniseyu.io)
(TXT) w3m dump (deniseyu.io)
| ripvanwinkle wrote:
| 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
| MattGaiser wrote:
| > 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
|
| I've never been in management but I am someone who modifies my
| interactions with people very easily and is very conscious of
| what harm could come to me based on my various actions. I am
| also good at spotting squirming people.
|
| Consider what you would do if you personally owned the company,
| i.e. you can't be fired and everyone must get along with you.
| What issues would you report? What opinions would you
| challenge? What ideas would you propose? How uncertain would
| you be willing to be in a discussion? Would you cut corners on
| the code to make sure that everything in the sprint gets
| finished by the end of the two weeks?
|
| Compare that list to what you actually do. For example, most
| people challenge very rarely but I can confirm from the Slack
| conversations which parallel the meeting that many want to do
| that (myself included). I've been in plenty of meetings where
| most agree that something is pointless or even harmful and we
| leave the meeting to go implement it. Why? The person speaking
| is the manager. Our concern is only expressed in chatting on
| the Slack in private during the meeting. That is why UnderCover
| Boss is so good at finding issues management knows nothing
| about.
|
| The difference is the psychological safety deficit. Ask
| yourself what exactly causes that difference. Why specifically
| do you challenge far less than you would like to? That is what
| you must fix.
|
| The problem is that the people who know this information are
| often lacking in the power to yield change and extracting
| feedback on this in an environment with low psychological
| safety faces the same problems as extracting any other feedback
| (which is why you wanted to solve the problem in the first
| place).
|
| I would not believe that it could be done without replacing
| >50% of team members and having them trust from the start.
| ripvanwinkle wrote:
| I suspect that an incentive system that is heavily biased
| towards collective success would make a big difference.
|
| The more we are vested in each other's success the more we
| are likely to want to bring out the best in each other and
| from there we might begin to get psychological safety and
| other goodness
| MattGaiser wrote:
| > I posit that an incentive system that is heavily biased
| towards collective success would make a big difference.
|
| There needs to be enough individual benefit (or the team
| must be small enough) that individual efforts can move the
| needle. But yes I agree. One of the biggest challenges for
| companies is that the average employee has no reason to
| care whether their project succeeds.
| iateanapple wrote:
| > Why specifically do you challenge far less than you would
| like to?
|
| Because if you push in another direction then you have to own
| the new direction.
|
| That is a lot of responsibility to take on - and in many
| organizations it comes with no reward and serious potential
| downside.
| MattGaiser wrote:
| > serious potential downside
|
| See? Found your problem. The downside must be eliminated.
| iateanapple wrote:
| > See? Found your problem. The downside must be
| eliminated.
|
| How?
|
| I've been successfully able to push for devs to be
| rewarded better - but I've never been able to eliminate
| the downside of a poor idea/execution.
| PacifyFish wrote:
| 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 wrote:
| >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.
| DanBC wrote:
| Changing the culture of an organisation is really difficult.
| Ideally you'd need support from senior leaders as well as front
| line staff. Without both of those it's going to be next to
| impossible.
|
| I like these (although some of them use lots of business
| jargon).
|
| https://www.health.org.uk/sites/default/files/HowCanLeadersI...
|
| If you like video you can try this by Professor Amy Edmundson
| from Harvard (it's a bit clunky because it's an online
| conference): https://youtu.be/rhVXwdzdPcc?t=880
|
| You're right that there's a lot of content about the benefits
| of psychological safety, and how nice it is to have it, but not
| nearly enough about how to create it if you're stuck in an org
| that's reluctant.
| ramraj07 wrote:
| My current team is repeatedly cited as one of the most fun and
| open teams in the org by many (both from inside and sidelines),
| and I can suggest some things that seem to work:
|
| 1. Psychological safety and honesty is subtle and contagious -
| if one person opens up and always makes a point in identifying
| their own mistakes (perhaps going out of the way at times)
| others feel empowered to do so as well. This ideally needs to
| be done by the senior most members of the team to start.
|
| 2. Make it a point to never (even subtly) blame individuals in
| even the slightest of public settings for any mistakes. Use
| 1-1s to do that and encourage the same throughout the team
|
| 3. Safety is contagious but the opposite is true as well - bad
| influences in the form of PMs out of sync with team culture
| should be avoided as quickly as possible.
|
| 4. Everyone should always feel like the team has their back in
| any external surface (either their managers, the customer
| success team, the product management team, etc) - any slight or
| suggestion that an individual might not have done something
| optimally should be backed by honest support from the remainder
| of the team. Not lying or defending bad actions but just
| assuring that the team will work together to rectify any
| problem.
|
| 5. Make it a point to publicly acknowledge any good
| contribution by any team member.
|
| 6. In any public channel even within the team, all engineers
| are treated as if they are equally senior.
|
| 7. Display and inspire a sense of responsibility towards the
| product, not because you owe it to your company, but you owe it
| to the customers, to your teammates, and other teams in the org
| that will have to make up for any mistakes we do. Again not by
| working overtime (not more than once or twice of course).
|
| 8. Fully acknowledge that no one should work "too hard" (read:
| more than 9-5 on most days). If one engineer does because they
| have no life, make sure everyone knows that's not anyone else's
| problem (and make sure that this extra-work engineer doesn't
| cause trouble via bad code or unrealistic expectations).
|
| 9. Be brutally honest to each other in 1-1s, and try to use the
| same techniques as above to do so.
|
| 10. Never hold back feedback from each other that you feel
| obligated to give in peer reviews eventually anyway. Give it to
| them (privately) as soon as possible.
| baron816 wrote:
| 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 wrote:
| > _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 naive management
| involves this sort of tooling transport.
| blargmaster33 wrote:
| 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.
| noizejoy wrote:
| 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).
| troughway wrote:
| 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-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.
| modwest wrote:
| Hoo doggies I need management at work to read and internalize
| this.
| bryanrasmussen wrote:
| 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 wrote:
| > 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 wrote:
| 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 wrote:
| 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.
| telesilla wrote:
| Right, I don't think I meant it quite like I may have put
| it, more that I've seen commits by juniors have multiple
| unrelated fixes, instead of documenting said issues and
| being unable to track them.
| [deleted]
| kevindeasis wrote:
| 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
| pizlonator wrote:
| 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 wrote:
| > 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!
| andrewingram wrote:
| It's been mentioned on Hacker News a few times, but the book
| "Turn The Ship Around" is essentially about this very
| question. It's about a different kind of organisation (a
| military submarine), but I differently recognised a lot of
| the same dysfunctions and failed attempts at fixing things
| that I've seen whilst working in numerous tech companies.
|
| The answer seems to be that, yes, you really can turn a
| dysfunctional team into a high performing one (literally
| worst to best in the case of the book), and in much less time
| than you'd have thought (most of the changes happen within 45
| days of the author taking command). My main takeaway from the
| book has not been new ideas about what good looks or feels
| like, but tools about how to fix it if it's broken. Highly
| recommended.
| icelancer wrote:
| >> What I'd like to see, is if you enforce this in a
| dysfunctional team, would that team still be dysfunctional?
|
| Yes. All these articles start with an average or better
| workforce in terms of talent and innate productivity/passion.
| If you have 80% crap for whatever reason, the only way out is
| replacing them. Or leaving.
| baron816 wrote:
| Dysfunctional teams == 10X engineers:
| https://twitter.com/skirani/status/1149302828420067328?lang=...
| vsskanth wrote:
| 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 ?
| momokoko wrote:
| 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.
| spyspy wrote:
| This is absolutely spot on. In fact these are the exact 3
| points I came up with when I've thought about "high
| performing teams". If you don't have a team that thoroughly
| enjoys what they're building and each other you have nothing.
| Skill is tertiary but important. At least one person needs to
| know what they're doing. Even if the other 5 just graduated
| middle school, if they're eager to learn and willing to
| listen things will be copacetic.
| bradlys wrote:
| Are you saying those are key elements to psychological
| safety? I've never found any of those correlated with
| psychological safety.
| momokoko wrote:
| 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 wrote:
| 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.
| spyspy wrote:
| You seem to be mistaking a manager as not part of "the
| team". If you have a direct supervisor who over-
| admonishes engineers for their mistakes they violate
| point #2 more blatantly than any engineer could.
| bradlys wrote:
| I think they should be categorized differently. As I
| said, "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)."
| The influence they have on psychological safety is so
| much more important than the rest of the team. To the
| point that it doesn't even matter at all what the team
| does if the manager isn't going along with it.
| pugworthy wrote:
| 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.
| kradroy wrote:
| 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.
| itronitron wrote:
| 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.
| MattGaiser wrote:
| 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 wrote:
| > _" 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.
| MattGaiser wrote:
| > I had that kind of trust in my management.
|
| That's impressive. Would you consider yourself the trusting
| type?
| jacques_chester wrote:
| It depends on the situation.
| z6 wrote:
| 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 wrote:
| 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.
| iateanapple wrote:
| > Getting good feedback would become my priority for the week
| before
|
| It should be your primary job all the time in feedback based
| organizations.
| MattGaiser wrote:
| If it is peer feedback I then spend a ton of time doing
| things not related to my actual job.
|
| If it is management feedback, isn't that just most jobs?
| ncphillips wrote:
| The article states that teams with high psychological safety
| have success with feedback weeks, it does not say that feedback
| week results in high psychological safety.
| dpc_pw wrote:
| 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 wrote:
| 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.
| Traster wrote:
| >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.
| jacques_chester wrote:
| > _psychological safety is a pre-requisite for a retrospective
| to be useful_
|
| The first heading in the article is "High Psychological
| Safety". I didn't see any claims of directional causality.
|
| > _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._
|
| She notes that she's also worked in non-lottery conditions.
|
| A big part of discussing these experiences is to show that they
| _can_ exist and that when they do, there are a number of
| beneficial outcomes for folks who are involved. I 've worked at
| the same company she's writing about and my experiences gel
| with hers.
|
| The lottery-winning incident was being hired. After that it was
| all due to sustained, deliberate efforts by many individuals
| over a long time frame. Investing time and effort into being a
| safer, kinder, more humane workplace isn't buying a lottery
| ticket. It's _investing_ time and effort. You divert some of
| today 's time and effort to make it happen.
| wtracy wrote:
| 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 wrote:
| 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.
| twic wrote:
| I spent about thirty or forty years of my life working with
| enterprise clients in Pivotal Labs, which i think lasted
| two and a half calendar years. A year or so of that was
| leading engagements with one particular enormous and highly
| dysfunctional retail bank. Every week, we tried to
| demonstrate that a better world was possible, and every
| week, they remained resolutely stuck in their world of
| suffering and not delivering software.
|
| Some time after i left, i asked after that client.
| Apparently their organisation is agile, the projects
| shipped successfully, and they're really happy.
|
| I have no idea how that happened.
|
| I'd love to think that i was making a difference and just
| not seeing it because i was stuck at the coalface, but it's
| probably just that people much better than me got involved
| after i left!
| jacques_chester wrote:
| Ah yes, the banks. By _far_ our hardest clients. I think
| we took on too many bank engagements.
| dajohnson89 wrote:
| what about banks make them so difficult to work with?
| jacques_chester wrote:
| It's a mix of things. The biggest is that they're just
| enormous, so nearly every engagement is pretty much from
| scratch. As in: single departments of single divisions
| could dwarf us in headcount and revenue. It can be
| dispiriting for Labs consultants and I know people who
| quit because of it.
|
| A lot of the time you hit what I call "veto culture". You
| are forever running into groups, committees, boards,
| bureaus, offices of the whatever etc etc who have the
| power to gate some change. Those folks almost always say
| "no". The logic is simple: if they say "yes", and
| something goes wrong, and they are blamed for it, then
| they might lose their job or at least risk a bonus or
| promotion. But if they say "no", there's no risk to them.
|
| In practice it drives everything productive underground.
| We often relied on discovering the nomenklatura who
| actually _did_ things as we went. The parallels to the
| USSR 's experiences (as I understand them) were
| fascinating.
|
| It's important to note that I don't see any of this as
| being a deliberate outcome. In general folks don't wake
| up and ask "how can I make my company less productive and
| pleasant today?". People do what makes sense to them,
| based on their experiences. But I have seen how culture
| can drift into a bad place that's hard to dig out. Big
| banks seem to have even more of this than regular
| megacorps.
|
| I know some folks who worked in the Federal sector had
| some similar experiences, but overall it seems like a lot
| of the time it seemed more manageable due to different
| incentives. In fact a lot of the compliance / standards
| folks were often thrilled that someone _wanted_ to talk
| to them.
| thebigbank wrote:
| This is very true. I work for a big bank and purposely
| overestimate any work because: 1) the veto culture; and
| 2) it allows me time to do work not counted in the
| "sprint".
|
| The actual amount of development I do is between 20-30%.
| The rest is taken up by "agile ceremonies" and convincing
| multiple layers of veto holders not to veto.
|
| Often times I'll spend 2-3 days developing a prototype
| and then 2-3 months convincing people its a decent idea.
|
| (I put "sprint" and "agile ceremonies" in quotes because
| its waterfall presented as agile)
| urbanetrellis wrote:
| As someone who got to embed with a mixed client/Pivotal
| team, this was a great experience for me. I had never seen
| pairing or TDD done in a disciplined and thoughtful way, or
| participated on a team that was "Agile" in more than just
| name and appearance. We certainly had plenty of room to
| keep improving, but by the end of my time on the project we
| were deploying a high-quality product on an ongoing basis,
| making good design choices, and delivering substantial
| value for the users every few weeks. It felt great and I'm
| sorry to say I haven't gotten to experience it again since.
| karatestomp wrote:
| > Really awesome Practice A (skipping up-front requirements
| development, shorter QA cycles) is made possible by really
| tedious Practice B (pair programming, TDD).
|
| School/district administrators do the same thing. "Hey I just
| read [popular education book about some system] and got the
| district to pay for me to go to a conference about it and it
| seems great! We're doing that now. Oh but not that part. Or
| that other one. Those make me uncomfortable." [two years
| pass] "Huh, weird, none of this is working for us, guess the
| book sucks. Hey, I just read this other book...."
| hinkley wrote:
| XP (and most Agile Manifesto children) proscribes a bunch of
| onerous activities in favor of a set of less onerous
| activities, but people aren't looking for discipline, they're
| looking for ways to avoid pain.
|
| While discussing the failings of XP as practiced, someone put
| it this way:
|
| You are effectively telling people that if they eat their
| vegetables they can have dessert, and what happens is people
| eat their dessert and don't want to eat their vegetables.
| mpweiher wrote:
| > with B players or a team with existing dysfunctions.
|
| Hmm...I got handed a team of C players. By focusing on the
| technical aspects of XP such as simple code, test first,
| quick turnaround (work on master, check in when green) the
| team was outperforming the "star" team(s) after about a year
| or two.
|
| We paired only on a need basis, but I wouldn't say that we
| failed.
| dionian wrote:
| I agree with you and i also see the flip side of this: people
| who think you need to do 100% of XP techniques to be 100% XP.
| Whereas XP is supposed to be about doing what's right for the
| situation
| urbanetrellis wrote:
| I would argue it's doing what's right for the situation but
| with a few top level goals that should constantly be in
| view.
|
| - Simplicity: you should be creating simple designs /
| solutions
|
| - Feedback: you should be getting continuous feedback as to
| whether what you're doing is working and self-correcting
|
| - Courage/Communication/Respect: you should be fostering a
| collaborative environment where people feel free to tell
| the truth and feel they're respected as people and
| professionals
|
| The practices (pairing, TDD, etc.) are just a way of
| getting to those goals. You can follow any other
| disciplines you want, but if the end result doesn't look
| like what I just described (or if it isn't the explicit
| goal of your activities) then I don't think you're doing
| XP.
| guest2143 wrote:
| 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 wrote:
| 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.
| michaelborromeo wrote:
| 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 wrote:
| > 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 wrote:
| 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 wrote:
| > But yeah I think the incentive structure helps determine
| outcomes like the one you describe.
|
| Yes - most of the behavior likely is due to the incentive
| structure. My point was that such incentive structures seem
| strongly correlated to teams/orgs with very talented
| people. At least in my discipline, I attribute it to the
| incentives in academics/universities, which is where most
| of such folks come from.
| zbentley wrote:
| I'm not sure "high functioning" is the right term when
| discussing individuals rather than teams. I suggest using
| "leaders" or "mentors", since "high functioning" as in
| personal contribution productivity is, as you pointed out,
| often a toxic thing to optimize for.
|
| Consider this: a team with one insanely productive
| contributor and three new/less-than-productive folks is
| tasked with a bunch of projects. As expected, the productive
| person does most of the work. The others might learn a bit by
| example, or not. Productive person moves on/gets bored/gets
| significant non-work commitments/burns out/gets hit by a bus.
| The team is no longer productive or functional.
|
| Then consider this: a team with one person with a talent for
| teaching and leadership, and three new/less-than-productive
| folks is tasked with a bunch of projects. At first, they
| aren't that high-functioning as a team. The teacher/leader
| spends a lot of their time mentoring, going over the basics,
| reviewing, and planning. Over time, they get more productive.
| If the mentor/leader leaves the mentorship/leadership role,
| at worst they leave a high-performing team behind. At best
| they leave a high-performing team of people who are
| additionally prepared to assume a mentorship/leadership role
| in the future.
|
| Depending on how "10x" (ugh) the developer in the first
| scenario is, the team in the second example might never reach
| their productivity. But I think it's pretty obvious that
| organizations are benefited more by second-example-type
| teams.
| iateanapple wrote:
| > Then consider this: a team with one person with a talent
| for teaching and leadership, and three new/less-than-
| productive folks
|
| In practice it is more complex - people with a talent for
| teaching and leadership _and_ are experts are incredibly
| rare.
|
| What we often end up with is a mediocre dev taking on the
| teaching role and helping build a mediocre team.
| BeetleB wrote:
| > In practice it is more complex - people with a talent
| for teaching and leadership and are experts are
| incredibly rare.
|
| Not in my experience. While there are obviously fewer
| people who have both traits, they're not at all rare. In
| practice, what I see is that such people shift away from
| teaching/mentoring as it takes time/effort that their
| manager does not reward.
|
| If you want talented people who mentor well, make sure
| such mentoring is rewarded.
| iateanapple wrote:
| > what I see is that such people shift away from
| teaching/mentoring as it takes time/effort that their
| manager does not reward
|
| I don't think it's that simple. I work with tons of
| talented engineers who put a huge amount of effort into
| tasks that management doesn't care about - like
| refactoring our codebase.
|
| In contrast everywhere I have worked management has cared
| about being able to level up new developers and under
| performers (assuming it's a skill deficit).
| iateanapple wrote:
| To add to this one of the most soul crushing tasks I've
| had to do is to manage out good people who are under
| performing.
|
| If I could say "BeetleB, I'm pairing you with Joe for the
| next 6 months - I don't care if your output halves but I
| need you to bring him up to speed or we have to let him
| go" and you could train him up - well you would be worth
| your weight in gold.
| zbentley wrote:
| Well, there are teachers and there are teachers.
|
| More specifically, some folks like to teach because it
| makes them feel like an expert when they're not. That's
| bad.
|
| Some folks like to teach because it helps them learn-by-
| teaching and helps their pupils learn-by-questioning (and
| learn by questioning and receiving an honest "no idea/I
| might be wrong!").
|
| The quantity that's in short supply is not expertise.
| It's humility.
| zbentley wrote:
| That depends on how you define talent.
|
| Is "talent" some immutable, innate, static thing? If so, no:
| teams that do well don't have to start with individual talent.
|
| Does "talent" encompass the ability to learn and grow and
| change what you're best at/what you enjoy? If so, then sure,
| having members with the ability to do those things is important
| to a team's success. But that's not what most people think of
| when you say "talent".
|
| In a good environment, a team of novices can grow and learn to
| produce great things--even without the presence of
| talented/experienced/whatever mentors/leaders. In an unhealthy
| environment, not only are the novices doomed to failure/making
| things worse, but so are experienced folks. Determining what
| constitutes a good environment (and how to foster one) is
| important--that's what I think the article is saying.
| iateanapple wrote:
| > In an unhealthy environment, not only are the novices
| doomed to failure/making things worse, but so are experienced
| folks.
|
| Is that true though? I can think of plenty of counter
| examples where lots of quality work has been done in very
| toxic environments.
| zbentley wrote:
| So can I. But I don't think I'd call those
| environments/teams high-functioning.
|
| This is roughly the same reason that LoC or features
| delivered/day are bullshit metrics. They can be skewed by a
| tiny minority of people doing most of the work. When that
| is the case, you don't have a high-functioning team or
| organization; you have a few massive liabilities tipping
| the scales.
|
| Edit: what I mean is that experienced folks in those
| environments are "doomed" in a different way than novices.
| Novices won't gain new skills. Experienced folks will
| instead feel unappreciated and burn out, or feel over-
| appreciated and succumb to narcissism. Both outcomes happen
| at the expense of the team.
| watwut wrote:
| High functioning team can have juniors in them, can have
| inexperienced people in them and can have people with range of
| knowledge and skills.
___________________________________________________________________
(page generated 2020-05-24 23:00 UTC)