Building a “No Asshole” project team

Have you ever worked in a high-performance team? A team that really “clicked”? A team which was harmonious, complementary and truly greater than the sum of its parts.

No Asshole project team

No Asshole project team

Have you ever worked in a real “self-organising team”? A team that could quickly and respectfully work out for itself what would happen in some situation.

It’s a wonderful feeling to have had this experience. Anecdotally, and from personal experience, this type of team is very rare.  I’ve been on more than 50 project teams and have been a part of only 1 or 2 high-performance teams.

“Individual commitment to a group effort – that is what makes a team work, a company work, a society work, a civilization work.”  Vincent “Vince” Lombardi (1913-1970), coach of 2 Super Bowl Championships and 6 NFL Champions 

How do such amazing teams happen? Was it planned or accidental?  Accidental teams can happen, but the members typically have positive and successful experiences from previous teams.  To have a planned outcome requires a level of emotional maturity and security in each person’s sense of self. This can enable that creation to occur without damaging individual psyches.

Why do we see so many bad teams?

Why do we see so few examples of high-performance teams?  What common behavioural issues are preventing the teaming effect from taking place? What behaviours are present in good teams?

I’m not referring to anti-social behaviour like bullying, intimidation or prejudice (all covered in Robert Sutton’s “The No Asshole Rule”). I’m referring to more common types of subtle anti-teaming behaviour: small thoughts or deeds that generate frustration or mistrust, and prevent the team from reaching its full potential.

For example, on one of my projects a few years ago, one team member was always late to meetings. It sounds silly, but we’re not talking about a few minutes, but habitually late by half the meeting.  Even though this person was the Product Manager and a key decision maker, we could have endured this annoyance.

The problem was that the Product Manager insisted on being brought up to speed on what had occurred in the meeting prior to their arrival.  Not only did they ask, but they insisted on this happening.  The choices were agree relatively gracefully and take the hit, or have an argument in front of the entire project team. Instead of it being the Product Manager who was inconsiderate, then it appeared that the project manager was the problem and uncooperative element.

I call such actions “Project Asshole” behaviours.

“It doesn’t take much to be a Project Asshole but it can have a big impact!” – Adam Russell   

How to identify “Project Asshole” behaviours

“Project Asshole” behaviours are acts, words or attitudes that create tension or frustration. They relentlessly chip away at the development of trust, common work ethic and the inter-personal bonding required to form a high-performance team.   These behaviours generate negative emotions and friction, but it’s usually not enough to trigger a private chat with the team-leader or an escalation to the person’s manager.

Are any of your team members displaying the behaviours listed below?

  • Showing little respect for individuals or teams in the context of group discussions: interrupting speakers before they have finished, or responding to propositions with ridicule or sarcasm.
  • Agreeing to something at a meeting, and then doing whatever they originally planned, or something else entirely
  • Regularly intimating that they are not happy about the project or their role; treating the project team as merely a very short-term activity.
  • Always taking advantage of opportunities to be absent: sick on Fridays or Mondays, or taking a holiday “sandwich day”; “special assignments” from boss etc. Not advising of upcoming holidays.
  • Assigning an action to someone else just before a review meeting so they can say “I’m waiting on so-and-so”. Saying “I’m trying to contact so-and-so” when they’ve only sent 1 email, or stopped by the desk at lunchtime.
  • Insisting on a particular process, document, or technique regardless of whether it’s appropriate or actually adds value to the project.
  • Keeping religiously to a fixed work schedule even stopping mid-task to go home at the designated time, rather than complete the job at hand, especially when other team members are working long and irregular hours.
  • Giving feedback on documents at signoff meetings instead of providing it in advance so that it can be incorporated into the final document, because “I’m so busy”.
  • Treating project or other meetings as the “quality time” for the project, by reading the material to be discussed or workshopped, or by catching up on reading or emails.
  • Not reading or responding to actions assigned in meetings until the next meeting. Claiming that they didn’t know they had been given a task.
  • Bringing past disputes with other teams into the current project, perhaps by making negative comments or proposing pathways that circumvent or undermine a particular system or team.
  • Not reviewing and approving key documents without numerous follow-ups.
  • Not executing actions or tasks unless repeatedly prompted to.
  • Artificially prioritizing the needs of existing systems or organizations over project needs.

I would be enormously surprised if you have not experienced some of the above behaviours. And this is only a very short and incomplete list.

Removing “Project Asshole” behaviours: set clear expectations

There are many factors that generate “Project Asshole” behaviours.  As I outline in Project Action Principle #4 of the 5 Project Action Principles, a project manager’s role is to identify and eliminate anti-teaming factors.  A fundamental step is to provide clear guidelines of your expectations.

I have talked to managers who are puzzled as to why team members are (or are not) doing something that we desire or need.  Often, they have merely failed to set expectations, or to provide specific details or examples of the type of behaviour for which they want.

This expectation-setting amongst teams is often implemented using a team charter or team agreement.

So I have developed a Charter for a “No Asshole” project team, consisting of 9 clauses.  Together, commitment to the Charter spells out what is implied and expected when a person signs up to participate in the team.

If team behaviour is defined clearly and we set high expectations, I’m convinced that we will see a positive response from individuals to construct a high-performing team.

“Finding and removing Project Asshole behaviours should be a top priority of any project manager!” Adam Russell   

The “No Assholes” Project Team Charter

This Charter will guide the engagement between various members of the project team.   Each clause illustrates the behaviours that we want people to adopt in order to promote a harmonious, productive and successful team to achieve its goals.

Hence our level of acceptance for the measurement scales of “Asshole” behaviour should be more sensitive because mutually-supportive, productive and proactive relationships are a minimum enabler to the team achieving project related outcomes.

The clauses contain a statement based on the principles that guide a team member to commit to the desired behaviour. When all these statements (written in the first person) are put together, we create a Charter for a “No Asshole” project team and form a contract that an individual commits to.

By explicitly reading and agreeing to these principles, team members will be guided to the kind of behaviour that they should exhibit and expect from others.

Commitment explicitly and publicly is one option (my preference), or it can be private and personal.

The Charter

The “No Assholes” Project Team Charter implements the Nine Teaming Principles as positive assertions in a number of clauses that demonstrate commitment to the positive behaviours and attitudes that generate high-performance teams.

The Charter can be used in multiple ways:

  1. a Poster or Posters that espouse the values of the clauses of the charter
  2. a Project Team signup form that is individually signed by each member of the team
  3. a Blow-up version of the charter that everyone signs in a signup ceremony.

You can see a short version of a Project Team Charter signup form The “No Assholes” Project Team Charter

Introducing the Charter to your project

By design, this Charter is intended to be physically signed by each team member and displayed in the project team environment.

You may find resistance to physical signatures in your environment, so alternatives could be to simply distribute it, or to hold a meeting to run through it and discuss objections.

However, if you can create a situation where it is signed by all team members, then you have triggered something very powerful.

In any case, the discussions that you will have to get people to commit to the Charter will tell you a lot about the individuals, and give you areas to work on with specific individuals and sub-groups.

Next Steps

The “No Assholes” Project Team Charter will help set clear expectations about the behaviours that are required in a principle-based project execution environment. You can use it as the initial introduction to, or a reinforcement of, the principle-based project management approach. It can be useful in Agile environments because, at their core, the most important attributes of Agile approaches are principle-based, not process-based.

We’d love to read your comments, so please use the area below the article to provide your feedback.

If you like this article, perhaps you’d like to be notified when there are more.

Subscribe to the AdamOnProjects Mailing List!