Skip to content
Search
Generic filters
Exact matches only

It’s time to learn to unlearn: Six team behaviours that crush collaboration

It’s almost inevitable that we need to work with people in our day jobs. However, it can always feel a little risky to work with unfamiliar co-workers. We often hear inspiring stories about “high performance teams” and the benefits of team collaboration, but in reality, it’s rare to have smooth teamwork from the get-go. 

When I look back on some of my past projects, I feel grateful to have worked with so many talented people who inspired me in many different ways and taught me so much. But I’ve also had my fair share of working on more challenging projects where team collaboration is less than ideal or frictionless as it should be.

Based on my experience, I’ve summarized the key behavioural traits of team members which are barriers to successful teamwork. In doing so, I hope we can all strive for great team behaviours and unlearn some bad ones – as the saying goes, “if the cap fits, wear it”. Just as good behaviours create good teams, bad behaviours can crush collaboration. Here are the six most common behaviours which can inhibit great teamwork:
 

  • Not knowing how and when to prioritize
  • Complaining in the workplace
  • Having a “big mouth”
  • Unwilling to walk out of their comfort zone
  • Blaming others instead of finding solutions
  • Having a lack of responsibility
     

Prioritization is key

It comes as no surprise that team members who procrastinate and don’t contribute much will bring the team productivity down. However, though it may sound counterintuitive, the person who also tries to do everything is equally less efficient. These team members are always busy and have a huge backlog. When items in their backlog have some dependencies, this can make the backlog even bigger, leading to the team not functioning properly because of the overwhelming workload.

The truth is: if you think everything is important, that also means everything is NOT important. Not knowing how to prioritize tasks can have problems that are harmful for both the individual and the team they are in:

  • It can create an “information island”
  • Create too many concurrent work-in-progress tasks but none of which are complete
  • The individual becomes a bottleneck to the team

In one of the examples described in the Phoenix Project, the team member who was known for being a “superstar” was in fact the biggest bottleneck to the team. Given they hardly ever had any bandwidth, most of the work had to wait in a queue, and the wait time looked something like this:
 



A graph depicting the wait time versus how busy the resource is

A great team member should in some way follow the UNIX philosophy: do one thing and do it well. Nevertheless, without stopping them from being versatile, the point is: you should focus on a single task at a time and get it done. Interestingly, in a situation like this, even if the intention is good and the person has a lot of expertise, if you measured their productivity, you would be surprised to see it’s actually below average.
 

Stop complaining and be constructive

In one of my projects many years ago, when the product we had been working on was about to release, the team had a bug bash to collect potential defects in both accessibility and functional features. Then someone in the team found more than thirty “serious” issues which needed fixing without providing any solutions. By not being part of the solution, you can be part of the problem.
 



Bring me solutions not problems - A comic strip

Image by Scott Adams via dilbert.com

Raising a question – particularly when you don’t have to fix it yourself – is relatively easy, but it’s difficult to give the corresponding solution. Suggesting a straightforward solution may be easy, but giving multiple options with both advantages and disadvantages is even harder. If you really want to be a great team member, then do the hard thing by coming up with solutions where you can and help simplify the work others have to do.
 

Hands-on ability

“Talk is cheap, show me the code.” – Linus Torvalds

In my career, I have known many principal engineers who talk about high cohesion low couples or S.O.L.I.D, and can spend hours telling you different programming paradigms. So I was surprised to learn that many could barely write working code, or even compile code. Luckily it’s pretty easy to solve this problem. Firstly, you need to recognize that it is a problem and that there is a difference between “knowing” and “doing” (as depicted in this famous illustration). We all know that in reality writing FizzBuzz in TDD is very different from refactoring a legacy online shopping transaction system.
 



How to draw a horse

 

Image by Van Oktop via Tumblr

In most cases, it’s not the circles or the triangles we are missing – it’s the small details. The details that fill in the basic shapes that make a horse a horse; the details that make a world of difference between “knowing” and “doing”. So start doing more and talking less.

If you’re looking to polish your professional skills in coding, I find Code Kata is super useful. Essentially you deliberately practise on specific topics so that you can master it in your muscle memory.
 

Deadly comfort zone

Some people just don’t like change. I can understand that some of that could come from negative experiences from learning new technologies in the past, or just losing the desire to learn, or perhaps both. So you hear some people say, “why don’t we just use redux (only because I’ve been using it all the time)?”. In fact, this can also happen to people who used to be tech advocators.

In most cases, they don’t want to step out of their comfort zone. They think what they have mastered can last forever, and that’s the best practise for the problem they’re going to solve. But that’s not true, everything changes. Technology becomes outdated or even obsolete at a pace that is much faster than we think.
 



Group of logos

When I joined ThoughtWorks in Xi’an 8 years ago, Ruby on Rails was the mainstream in the office, Backbone+Jasmine was state-of-the-art back then. Two years later, some teams are drastically trying Angular 1.2, using bower as dependency management, PhantomJS is so advanced that most teams are not even considering it by default. Now where are those technologies? Today in frontend React+Redux and GraphQL are proven to be something that can simplify frontend development a lot, but who knows what the next breakthrough technology will be?

Nevertheless, I think as a developer it’s important to stay curious and hungry to learn. However, this doesn’t mean you have to pick up the new star framework or language that’s trending on Github for your next project, but you should spend some time each week to be aware of those changes (ThoughtWorks Tech Radar is a fantastic source).
 

Blame game

In a team with a clear division of tasks, frontend developers are responsible for the implementation of the interface while using data returned by the backend API. The backend team is responsible for interacting with downstream services while organizing and returning frontend the data. An extreme scenario is when the frontend and backend cooperate only through contract, with one end completely ignoring the other and regarding it as something of a black box.

Such isolation may lead to some progress as the frontend and backend are relatively independent and do not affect each other. However, this can also create huge problems for the whole team – the delayed value of delivery due to delayed integration, which then gives rise to the “blame game”. I have heard many complaints from frontend like, “this is a problem with the backend API” or “this problem is caused by the backend because it fails to handle the connect timeout”. In a nutshell, every problem becomes someone else’s issue.
 



People pointing one another - A comic strip

Image by Manuel Francisco via The Manila Times

The description “this is a problem with the backend API”, although it is a correct statement, should not be a conclusion. Instead, it should be the beginning of further exploration: the beginning of developing a more systematic end-to-end solution. Two groups of co-workers, physically separated, should face the problem together and figure out a solution that fits the current architecture.
 

Legacy codebase

Some people complain about the codebase they have to maintain, how bad the architecture design is, or how difficult it is to add anything new on top. If you challenge why they don’t take action on it they would tell you, “the code was designed that way” and that they cannot do anything about it. This kind of complaint also normally comes from someone who:

  • does not understand business logic well
  • does not know how a technique decision was made
  • has a lack of ability of refactoring
  • is missing the high-level automation tests

But the “legacy code” argument does not make a lot of sense because it tries to position the individual as the victim of a problem they cannot solve. The complaint makes it sound as though they could deliver better results if only they had been given a more ideal starting point. However, the fact is that the existing codes and architecture will become obsolete unless time, energy and dedication are made to improve them.

There is no such thing as a historical problem or legacy problem, there are just problems. Facing a problem is always the first step to solving it, which requires the same diligence and attitude whether you’re addressing an online defect or making a small change on the story you just signed off.  

Simply put, we can maintain a storyboard just as we do with tech debt, and maintain them regularly based on value and effort, and demolish them step by step just as we do with normal stories.
 



Idea triage matrix

Credit: Quest Technology Group

I have been working on many legacy projects, some of them for quite some time, while others started from scratch but were corrupted as more features were added on. One way I found works well is to treat the legacy code just as the code you wrote – set up an automation test as a safety net, refactor a bit (could be as small as renaming a variable or as big as deleting a whole module), but just make sure it’s getting better with every commit.
 

Summary

I’ve summarized here the many different behaviours that are harmful for team collaboration. I admit that I have also at times failed to prioritize work, complained in the workplace, and even feared change. But as I have mentioned, facing a problem rather than resisting it is the key to finding the solution, and this definitely needs courage in order to move forward. I hope that some of these suggestions can help people overcome certain challenges and make a team more effective and productive by prioritizing by value, improving hands-on skills, working to solve things rather than just pointing out problems, and collaborating instead of blaming.

error: Content is protected !!