
Habits of High-Functioning Teams - zbentley
https://deniseyu.io/2020/05/23/habits-of-high-performing-teams.html
======
MattGaiser
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
> _" 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
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
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.

------
Traster
>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
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
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
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
Ah yes, the banks. By _far_ our hardest clients. I think we took on too many
bank engagements.

~~~
dajohnson89
what about banks make them so difficult to work with?

~~~
jacques_chester
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
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)

------
dpc_pw
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.

------
vsskanth
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
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.

~~~
bob33212
There is enormous business pressure to ignore everything you just said.

If upper management wants the team to work on a project that the team feels is
a waste of time the only fix is to tell management to find another project for
the team. And that doesn't go over well with management very often.

~~~
ncphillips
If management is pushing a project it is their Responsibility to clearly
articulate why a project is being taken on. If the team thinks it’s a waste of
time then management has failed to communicate the companies objectives and
how the project relates. If the people closest to the project don’t understand
why it’s worth doing that’s a huge red flag and they should reconsider the
project entirely.

------
ripvanwinkle
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
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
>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
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.

------
bryanrasmussen
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.

~~~
telesilla
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
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
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.

------
rb808
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.

------
troughway
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...](https://www.joelonsoftware.com/2006/04/11/the-development-abstraction-
layer-2/))

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.

------
michaelborromeo
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
> 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.

~~~
zbentley
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
> 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
> 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
> 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
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.

------
baron816
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
> _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.

------
29athrowaway
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.

------
kevindeasis
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

~~~
zoomablemind
> 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
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.

------
guest2143
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
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.

------
nunez
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.

------
noizejoy
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).

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

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

