How to Handle Competitive and Blame Culture Within Team

Question

Context: This is a software development team within a small e-commerce company. I am acting team lead whilst the current team lead is handing over to me and preparing for retirement. I have been in the team for nearly a year.

Within my team at work there has become an issue with colleague cohesion. There seems to be such a jostling for position amongst the junior to mid level developers that I feel it is starting to harm team moral.

Some examples, should a team member be off sick, the following days or weeks I notice a couple of team members like to keep pointing it out unnecessarily.

"Oh so yeah I fixed that bug when Bob was off sick last week"

or

"Well I couldn't get much done yesterday as Bob was sick so I had to cover support"

If feels as though, contextually, that they are subconsciously trying to push Bob down the pecking order by regularly bring it up that he was off. This happens with other team members also.

In addition to this, there is a moderate competitive edge to getting work done which spills over into blaming when team members will be working on the same feature. There is often talk about "beating" others when it comes to getting work done, and often in their rush to do things there becomes a reduction in quality and introduction of bugs.

This culminates in some team members becoming profoundly disheartened or defeated when another team member comes up with a better idea or solution to an issue.

I feel that this one-upmanship within the team is causing a lot of issues, including design/style arguments in meetings and code reviews, and the aforementioned sulky responses from team members when others' solutions or ideas are selected and the priority of speed sacrificing quality. The main feeling I want to achieve is that we are a team and working together, not against each other.

How can I encourage my team to relax and quit the competition and blame culture? Or am I looking at this from the wrong perspective?

Answer 1

1. Look at incentives How are bonuses decided? Pay raises? Promotions? In the absence of clarity that it is not a competitive process (and you need a heck of a lot of resources to make it not a competitive process), it is going to be assumed to be a competitive process. What is the fast track to a promotion or raise in your company (and there is one even if it is out the door to a competitor with a solid resume)? Is there any scarce resource that not all developers will get and that process is defined by work success? Congrats, you have created a competitive process.

2. Look at weight pulling. The ideas of "team responsibility" and "cooperation" wear very thin when the benefit goes one way. Was Bob just sick that day or is Bob also a relative under contributor?

3. Consider resume building. I am not sure how you do your project management, but some kinds of project management mean that developers don't get final responsibility for any part of the project. In the absence of a large resume line worthy chunk for them to be responsible for, they are left with any competitive metrics from their co-workers. How can they build their resumes without saying things like "highest reliability level of team of 10 developers when completing sprint goals"?

4. Look at open internal jobs. Is there an open senior position perhaps? Casting competitors as unreliable is a time honoured way of being more competitive for those jobs.

5. Consider how they came to be at the company. In America (and somewhat Canada), one gets a spot in the top high schools by successfully competing with other people and winning. One gets a spot in university by competing and winning. One gets internships by competing and winning. One can get hired based on the awards and achievements competing and winning give you to put on your resume. But then many companies shift to the amortized responsibility of "team play" despite having hired people because they succeeded in beating other people. I bet that your company uses a competitive hiring process seeking the "best who applies." How does one get in that position with the evidence to prove it? Beating other people.

relax and quit the competition and blame culture

It has to stop being beneficial to employees to be that way. But the problem is, in only the most perfectly balanced environments is that true without the behavior either continuing or top people seeking to leave. Assuming you are American/Canadian, your employees have spent their lives using competitive processes to win, so high sensitivity to incentives is a long embedded behavior. You basically need to rebalance the incentives.

Answer 2

The best way to find out why they are competitive is to actually talk to them. I think it is better if you do it in two steps:

1. Have a team meeting with everybody. Tell them what you observed, and that you are unhappy with the situation. Also admit to them that you do not understand why these things happen, and that there might be a good reason for it. Let them explain whatever they want / need, BEFORE you try to fix anything. Based on the feedback, you might want to try asking them to find a solution which works both for them and for you.
2. If step 1 fails (no feedback, or unusable feedback), then organize F2F meetings with each one of them. In this way, they will be released from the pressure of being judged by their colleagues.

The ground rules:

• make it clear from the beginning that the discussion will not be taken into consideration for job evaluations. It will be as if it did not happen;
• get as much information as possible BEFORE you start fixing anything;
• personally, you cannot fix anything; if the team does not fix their issues, no other effort will help; forcing things will result in people leaving the boat;
• the issue might take time to get solved, even if the process starts immediately;

A good read in your case is to read more about teams and teams development.

The rules of feedback are essential also.

---

@Meg made a very useful comment:

If anyone came to the workplace SE with the question, "My boss asked for a meeting and said that it wouldn't be taken into consideration for later evaluations, can I actually be candid?" I would wager that most of the top answers would be along the lines of -ITS A TRAP-, so don't be surprised if team members are hesitant to give feedback.

That is very true, that a relevant number of managers promise one thing and do another. However, some of them are not evil. How do we know which manager is evil and which one is not? Only experience will tell. And yes, I had the experience when managers said that the feedback was more like a team-building / training session, only to find out that all the information collected appeared on the personal evaluations at the end of the year.

If a manager asks for feedback without specifying the purpose of the asking, then there is a good chance that the feedback shall be used during evaluation. But the test comes when he promises not to use the feedback. If the indeed keeps his promise, then you know you can build trust with that manager.

Of course, it is always a double-edged sword. It is always the question of who was the first, the chicken or the egg. But somebody must take a leap of faith to try to make the world better.

Again of course, as a team member, do not spill out everything from the beginning . But if the manager keeps being the nice guy, you can more and more open, for the mutual benefit.

Answer 3

Since they seem to be fighting over speed, why not take that away from them altogether? It can be done relatively easily - meet at the beginning of a work period, say Monday, and agree on work to be delivered for that work period, and review progress at the end of it. It can be a week, can be two weeks, dealer choice.

Then during standups focus on the very simple format of "what have I done", "what will I do today", "are there any blockers", cutting short any chitchat/blame games, etc. If there is an actual issue to discuss, take it after standup with just the involved parties in some private space.

If the amount of work for any word period is fixed then there is no reason to rush it, instead, there is an incentive to assure quality of your product so it is complete and ready for handover, without having to find more time to then bug-fix it. That should still satisfy their need to compete, but less on the "rush to deliver" side.

Answer 4

Regarding the issue of pointing out other peoples' absences: Because you are the team lead, you are the one that your subordinates have to answer to. If their work is late, then (so they believe) you will hold that against them and say they are underperforming. Therefore, there is a need for accountability in the sense that you need to know why they are not getting their work done. This is not everyone blaming "Bob", this is something that happens; Bob is sick, so work depending on Bob gets delayed, so projects and tasks are late, so the person responsible for keeping those tasks on schedule (i.e. you) get upset at those who were supposed to complete these tasks, without knowing that the tasks were delayed not because the person performing them was undercontributing, but because Bob was away and the task depended on Bob.

I don't think there is a reasonable way to resolve this issue. It is an important part of Agile methodology that when goals are not met, there is a retrospective and a conclusion is come to about why those goals were not met; if the conclusion is "Bob was an essential part of this task and Bob took a week off", then the conclusion is the conclusion, whether or not it sounds like Bob is being "blamed" or not. This can be taken as a lesson to the one who schedules tasks (presumably you): Have your employees give you advance notice when they take extended vacation, and don't (or try not to) schedule tasks dependent on those employees when they are away. Then you won't have the blame issue arising because there is nobody to blame.

(A better solution would be to encourage information sharing across the team to reduce your team's "Bus factor", but that's an ideal and not practical in many environments)

Regarding the competitiveness of the team, what is the KPI measurement your team works under? Is it number of tickets cleared? Number of agile points completed? Number of bugs introduced (minimize)? Something else? You should be clear with your team regarding what they should be optimizing their work for. It sounds like the previous lead of this team maximized "number of tickets completed", which leads to code being written fast and loose, standards not followed, bugs introduced, code merged without review, and so on. Most of the problems you describe could be explained this way. My suggestion would be to turn that on its head: It's more important for tickets to be done right than to be done fast. Make code review first and foremost priority, and making sure all code is up to standard before it gets merged and deployed. Incentives therefore get optimized on number of bugs found after the fact; if a bug is found in a piece of code, both the developer and the reviewer get negatively impacted (in whatever way you see fit as a team lead). As long as the work is getting done then it can be slower to be done, but it has to be done right.

In this case, at least if your subordinates are competitive with one another, their competitiveness is aligned with the business: rather than getting any code out even if it's bad code, the competitiveness will be aligned on who can write the best code, and that's more or less the end goal.

Answer 5

1. Talk openly about that you have observed this issue in a meeting with everybody present, and without fingerpointing just say that you want this to change and you will apply some concrete measures to achieve a more cooperative a productive team work this is a clean slate. Nobody gets judged for anything what has happened until now.
2. Try to encourage and reward the desired behaviour: How to reward? Regular and tight feedback loops: “Hey, I noticed you helped and supported Bob in achieving his task: good work!”, “Cool how you accepted your collegues critique and implemented the changes they suggested: it shows professionalism and that you care more about the code than about your signature in the code - that’s the way to go”
3. Make them understand that the individual success of each member is tightly coupled to the success wholen project/team - hence you do a good work if you contribute such that the team performs in the best possible way (not a single person compared with the other team members). Having a bad and hostile atmosphere within the team clearly is poison and any behaviour that nurishes this should be strictly avoided. To achieve this, it is the best if conflicts between member are talked openly and discussed right away and some compromise is achieved where all the involved parties chip in. If this is not possible (which I hope is not the case, because that would be a really bad atmosphere) you would even need to consider letting someone go who is not willing to cooperate, even if he is a badass coder. But it is important that everybody understands that when doesn’t feel well with respect to some other member they should speak out such that some kind of action can be taken - extinguish fires asap! Also making other team members look bad in the slightest way will not make you look better in any way but only make you appear less of a good team player. If there is an issue: adress it directly.
4. Make ‘being a good team worker’ one of the traits that gets evaluated for further career development It is easier to mesaure than you might think: ask the others how much they like to work with subject A from 1 to 10 or something. Do this for every member. But notice that I said one of the traits- of course a lot of other things should be evaluated too. Still having this as one of the things will make them more willing to do well in this category.
5. Make them have feedback talks (pairwise) between each other from time to time everybody should tell the others what they did well and where they felt they could improve and maybe even something they felt bothered with that hopefully can be changes - you should in the end get the filled out forms.
6. To let the ‘new era’ begin you might even do some kind of ‘team building’ event In our company we did one event where we had to build a tower with Spagetti and marashmellows but only discussing first without touching the stuff and then build without talking (or something along those lines). But it would be good if it was at least a whole afternoon of these kind of things and maybe even do some cooking for lunch together first. Just as a rough idea...

Point 4 and partially also 5 will give you more insight into the relations about team members and be able to see potentially critical relations and adress things early.

Answer 6

As a team lead you must incentivize the behavior you wish to see, to the extent that you can.

Try and look at these issues from the perspective of the team. You mention, for instance, that they are competing for speed at the cost of quality. Start asking why. Do you have deliverable dates for units of work? Are there quality checks in place? Who is responsible for fixing the bugs introduced in this way? In short, why are they less concerned about quality and what can you do to shift the balance?

In a more general sense, how do you incentivize teamwork? Broadly speaking, you should look to evaluate the work as a whole and decouple it from the individual contributors. Make it clear that you're not interested in who did what, or that x didn't finish something because he or she was waiting on y, or that one person finished something more quickly than another. Setting clear goals to measure performance/progress should help to shift the focus away from one another.

In doing this, your team will have to confront the fact that their individual contributions are only as good as what they bring to the larger goal. They will ultimately be judged on how they sink or swim together, and learn to rely on one another if they wish to succeed.

Answer 7

Id suggest finding out how things got so bad in the first place. Where does this need to assign blame come from?

It could have come from the previous manager (who is leaving) or it could have come from one or two members of the team who came in the door and started stirring shit.

Since you've been there nearly a year, if you don't have an idea who the toxic teammates are, it was probably your old manager who encouraged this behavior.

That's pretty great, because all you have to do is stop encouraging this behavior.

when someone says something like

"Well I couldn't get much done yesterday as Bob was sick so I had to cover support"

You can respond by saying:

I don't care

When they blame each other in emails and take "subtle" digs at each other, call it out with a quick "I don't care". You don't have to write an essay on how it's toxic to the team or any of the rest, just make it known, often, that management no longer cares about the petty bullshit.