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.
There's a high level of distrust in this comment, both of peers and of managers, which I think misses an underlying thing: teams without this level of distrust of each other and of management have a lot of advantages.
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).
I just don't trust people in general...it has nothing to do with the team. I've been stabbed in the back too many times for trusting people to do the right thing.
Hopefully, it is made clear to you that the team operates as a high-trust cooperative and you can self-select out of that environment since you find it undesirable. You and this style of team are incompatible.
This makes little sense in context. Whether or not someone finds something desirable doesn't matter if their experience is that it doesn't happen in practise. It's hard to unlearn painful lessons in trust.
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.
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.
> "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.
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.
>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.
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.)
> 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...."
This is unfortunately common in management. Ideas are easy and exciting; execution is difficult and requires sacrifice & discipline. Human beings love to enjoy the benefits of thinking pretty thoughts without the actual cost of action.
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.
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.
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!
At huge financial institutions, software improvements do not usually improve revenue. At the very best, if you’re lucky, they might (although not provably) improve the derivative of revenue or cut some costs. And at most banks, revenue projections are fragile and magical, making revenue’s derivatives are volatile and doubly magical. In that context, try explaining to a non-technical director and his or her director, why the system “needs” fixing, when it generated consistent profits for the last decade, and why the risks of instability are worth it.
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.
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.
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)
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.
> 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.
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
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.
The 12 practices of XP are not XP any more than a finger is not the thing that it is pointing to. XP is intended to be a minimal set of practices that generate a method. Rather than specify a method (which will dependent upon circumstances), XP specifies a set of practices which will hopefully help you discover the method.
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 ;-)
> If you try to cherry pick the obvious shiny stuff while skipping the slow/expensive less-obvious things, you are doomed to fail.
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.
> Finally, customers are going to change their minds
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.
> 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.
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 Ifelt 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.
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 ?
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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
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.
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.
>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.
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.
> 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.
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
> 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.
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).
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.
Sometimes it just takes "a terrible outbreak of tuberculosis selectively killing off the biggest, nastiest and most despotic males, setting the stage for a social and behavioral transformation unlike any seen in this notoriously truculent primate."
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.
> 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.
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.
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.
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.
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.
> 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.
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.
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.
> 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.
> 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).
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.
> 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.
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.
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.
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.
> 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.
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.
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
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.
> 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!
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.
>> 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.
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 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.
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.
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).
With all due respect, the article brought up the political ideology. I would not have made any comments if the author did not include feminism, both in definition and in links to geekfeminism.
>...it's also against the guidelines and guarantees further downvotes and flags.
I have earnt 750 karma almost entirely in productive comments, I know the rules. I have done this before and gotten productive replies. You can't allow politics in the written articles and then complain you get political replies.
Just admit you chose sides and I'll leave voluntarily.
I'll take your point about the article (I haven't looked), but it's a matter of degree. Your comment took the thread further into ideological battle. That's what we care about—i.e. that's what we care about not happening here.
https://news.ycombinator.com/item?id=22706608 ("Furthermore, the moderators definitely have a personal libertarian bent that regularly seeps into selective moderation. I routinely see someone declare an interesting political assertion and then any replies to it that disagree with the principle are shut down as being political, but the parent post is ignored.")
There are many more links where those came from, but I try to contain myself.
Why do the opposing sides each think HN is strongly biased in favor of the other side? They can't both be right, and the odds that only one is right are also basically zero, since the comments are so interchangeable—if you flip the ideological bit, you can't tell them apart. Since the site is the same for everybody, this is clearly some kind of cognitive bias. I believe that it's that we're primed to notice the things we dislike and disagree with, and we weight those much more heavily (https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...). That would explain not only the direction in which people perceive bias (they always perceive it as going against their side) but also the intensity (people perceive the degree of bias in proportion to the intensity of their own ideological commitment).
Again, if you have a question that I haven't answered, take a look at those past explanations and if you still feel that way, please let me know what the question is.
"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.