Habits of High-Functioning Teams
deniseyu.io
deniseyu.io
"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.
So if you're a manager: do your damnedest to build trust.
If you don't have that trust, it will be hard to pull off any of these activities. Even around things like spreading work and knowledge around - distrust is how you get people hoarding knowledge for perceived job security; or bitterness about being asked to do something they aren't the best at (feeling like you're setting them up to fail instead of trying to up their skills).
It should be your primary job all the time in feedback based organizations.
If it is management feedback, isn't that just most jobs?
Like what? Also, what is your actual job?
When I have had peer reviews within organizations (my current one does not do this), I usually convince other team members to let me write my own to save them the time or ask them to help me craft my review of them (and they usually reciprocate). Most of the time they let me write both and just approve their own.
I end up spending my time crafting my own narrative instead of working as well as giving them a convincing one in exchange.
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.
Once I got over literally every other professional experience I'd ever had, Pivotal was the real deal.
That's impressive. Would you consider yourself the trusting type?
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.
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.)
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...."
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.
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!
So, banks are understandably the epitome of risk-averse. Why make changes to the current system, when (1) the current system works, (2) almost nobody fully understands how or why the whole system works and (3) it generates revenue that’s 1000x the salaries of the engineers employed to keep it running?
It’s not an environment where the dividends of innovation are typically worth the risk: besides, from the bank’s corporate perspective, there’s a whole startup industry (fintech) that exists to do the innovating “for you”.
In short, it’s a division of labor, but it’s not a very transparent one to the unannointed, and it’s very frustrating to be on the “wrong side”. Superficially, they have tons of money: think about all the interesting problems they could solve with that money!! But of course, nothing is that simple.
Editing to add that this did fit one thing I concluded (before learning economists found it to be obvious): diffuse risks almost never get handled. Only sharp, tangible risks really get thought about.
"We had an outage" can lead to someone getting sacked, so fear prevails. But "we slowly strangle ourselves to death and then get eaten by a nimble upstart" is nobody's risk. It's invisible and immeasurable.
I don't think small-team agile is particularly immune to this problem. It just tends to have a smaller surface area for diffuse global risks.
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.
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)
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.
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.
- 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.
Having said that, if you are not doing the 12 practices, then you are not doing XP. You are doing something else. It's totally fine to do something else, but it is not XP. It may have been inspired by XP. That's also really great. But it is not XP.
This is important because people talk about their experiences with XP and it is difficult to determine if their success (or lack thereof) is actually due to XP, or other factors. Do the 12 practices actually generate a method? Does it happen all the time? Is there something you have to do to get it to generate the method? Is the method always the same? There are many, many question.
For most people, those questions are boring because they are not actually interested in XP. They are interested in being successful on the projects. This is a very understandable position to be in! However, it is frustrating for people who are interested in XP ;-)
This is true with everything in life that you seek to do well: cooking, dancing, etc.
> Really awesome Practice A (skipping up-front requirements development, shorter QA cycles) is made possible by really tedious Practice B (pair programming, TDD).
A big nit: you don't exactly "skip up-front requirements development".
First, the appetizer:
One of the things you actively seek to avoid in an XP team is blocking: having people sitting around, doing nothing, because they are waiting for other teams/roles to hand them something.
Another thing you want to avoid is building things that are not needed, wanted, or required by either you or your customers.
Finally, customers are going to change their minds, and you can come to them with one of two answers, either, "we can't do that, it's not in the plan"; or, "sure, we can change direction".
Now, the meaty goodness:
You absolutely do market research, and probably have designers doing various types of prototype testing with Real Live Users (Or At Least Their Proxies) before you kick off any serious engineering work.
This will yield a pile of low-fidelity prototypes, assumptions to validate, and a tentative roadmap upon which your whole team (Product, Design, and Engineering) can begin execution.
You absolutely should have plans that stretch into the future, but the farther out those plans go, the lower their fidelity should be, because you are almost certain to change those plans as you build, experiment, and learn.
There is actually a type of orgnaisation that does not change their mind. They have a vague idea upfront what they want. They ask for a plan and an estimate. They never actually think about what they want in detail. When the thing is delivered, if nothing goes wrong, nobody looks at it or thinks about it. If anything goes wrong, then they say, "You didn't deliver what I asked for" (a vague idea that doesn't break things ;-) ).
The biggest problem I've had with some groups is convincing them that changing their minds is actually crucial to the success of the project. It's funny because you'll have a whole bunch of other people who are trying to cover their asses by getting management to sign off on the plan, etc, etc. But I'm coming in and saying, "I want you to change your mind" because then they have to have a mind in the first place. It's surprisingly challenging. I find that if I don't succeed in that, then it's pretty difficult to succeed with an XP team.
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.
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.
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 ?
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.
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.
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.
It's to the point where referencing team is kinda meaningless. It gives a sense that it's a group effort when it's usually bottle-necked by the manager more than anything else. Yes, group effort in the end but if the manager ain't going along (which is usually the problem) then it's a non-starter.
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.
I really want to say that...
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.
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.
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.
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
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.
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.
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.
90% of office conflicts I've encountered is between two individuals of these types.
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.
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
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.
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.
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.
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.
https://www.nytimes.com/2004/04/13/science/no-time-for-bulli...
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.
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.
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.
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.
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.
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.
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.
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.
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.
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).
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.
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?
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.
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.
Is that true though? I can think of plenty of counter examples where lots of quality work has been done in very toxic environments.
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.
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.
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.
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.
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
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.
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!
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.
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.
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.
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.
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.
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).