Skip to main content

Hi, I'm Mike! I'm a web nut and Drupal expert at Phase2.

I also do Drupal site audits and Drupal consulting on the side. Shoot me an email!

The Why's and How's of Jelling Teams

This post was originally published on the Phase2 blog.

Think back to your most successful project. The one that was on time and on budget with a happy client and work that everyone could be proud of. Chances are, that team worked really well together, right? Did the members of that team all have a lot of respect for each other? Did they all want to make each other look good? If the project was truly a success, I'd say it's pretty likely that all of those are true.

That team was jelling. A team like this can be a total game changer.

There are two key points to this, that we're going to dig into:

  • Jelled teams make projects successful, as opposed to successful projects making teams jell.
  • Jelling can't be forced, but it can easily be blocked, so removing the obstacles is the key.

But first, what is a jelling team? It’s one that motivates and empowers the people on it. It challenges them and improves them. A team that has reached that level is a heck of a lot more than a group of individual people who all happen to be working on the same project; the sum is greater than the parts.

What a jelling team can get you

Motivation

In the book Drive by Daniel Pink, he makes the case that the traditional view of motivation by carrots and sticks is absolutely misguided. True motivation should generally come intrinsically from the work itself. For this to happen, the work should ideally have 3 characteristics:

  1. Purpose: the sense that the work really means something worth caring about
  2. Mastery: the idea that doing the work will make you better in some meaningful way
  3. Autonomy: the freedom to do things the way that you think it should be done

1. Purpose

We can't all spend all of our time working on problems that we feel deeply passionate about. In the absence of finding purpose in the work, we can instead find purpose in our team. You'll feel driven to help the project succeed for the good of the team. You'll find motivation in the team you’re going to battle with, rather than what you're battling against.

2. Mastery

It's tempting to give each task to a person who already knows how to accomplish it, thus robbing everyone else of the opportunity to learn new things. People on a jelled team know what each other want to learn, and want to help each other learn those things. This means that tasks can be given to people who want to learn rather than people who already know how to do those things. We'll come back to this below (see "Education robbery").

3. Autonomy

This one should be somewhat obvious. People like feeling empowered to make decisions and solve problems and take educated risks. It's harder to self-motivate if your work is basically just doing exactly what someone else already told you to do. People on a jelled team (especially managers and tech leads) have the respect and trust for their team members needed to give each other the freedom to make their own technical decisions. This comes down to providing strategic direction rather than tactical direction (see "Defensive management").

Morale

It’s simple -- teams that are jelling tend to have happier people than teams that aren't.

Let's make up a totally ridiculous example to illustrate this. Say we have Project Firemuffin, in which a team of people are making a web app for a new muffin that can also start fires. We'll say that the client is on the difficult side, the deadline is extremely tight, and nobody on the team thinks that exploding muffins are a particularly exciting thing to be working on.

But, Team Firemuffin is jelling. They have a ton of respect for each other, they get energy and happiness from working together, and they all feel a sense of motivation to succeed as a team. They feel like the project is a fun challenge that they're all up against. They are happy despite the difficult project, just because of the team, and they'll do better work because of it. That's morale.

If that team hasn't bonded like this, then suddenly the project seems miserable. They can't stand the client, they don't care about the work, the deadlines go from a challenge to a death march in their minds, etc. They don't have the team morale that they could have if they was jelling, and their work will almost definitely suffer because of it.

Summary

These teams are made up of people who are motivated (because they are working on things that give them Purpose, Autonomy, and Mastery), and they find happiness in working together. With a group like that, it's hard not to succeed.

How to keep your team from jelling

A group of people working together will naturally bond like this -- if nothing stops them. Teams want to jell, and if they aren’t, then it’s because something is stopping that from happening. Our goal then is to remove all of the barriers that are making it difficult or impossible.

Time fragmentation

Putting team members on multiple teams, so that they're only on each project part time, is one of the easiest ways to prevent jelling. Each team has its own culture and process and deadlines and problems. It's not just the person's time that will be fragmented; it's also their attention, their motivation, and their commitment. It's really difficult to find purpose and drive from your team if you're on more than one team at a time.

Also, if some of the team members are only around part time and the other team members are full time, then you run the risk of the part timers being thought of as a 2nd class citizen, and not fully accepted as part of the team. A team where everyone isn't committed, motivated, and fully involved will always have trouble bonding.

Clique control

The idea here is that a jelling team may have a certain sense of eliteness. Even though "clique" is a dirty word, a little bit of friendly "man, do we rock or what?" can really provide a boost to morale and motivation. Try not to be too worried if your teammates are getting a little bit of an ego about the team they're on. It just means that they're confident in what they're doing, and they're proud to be on the team doing it.

You could even go a step further and make a team name or logo. From there you can branch t-shirts or slogans or whatever you want. Don't underestimate the feeling that comes along with being a part of an exclusive group; encourage it instead.

Phony deadlines

A "phony deadline" is just made up for the sake of having a deadline, without any real world meaning. If you say the project has to be done by April 3rd but that date is totally arbitrary, then April 3rd is a phony deadline.

The problem with phony deadlines is that they become an annoyance rather than a challenge. A tight deadline that actually has meaning behind it can be a exciting thing for a team to rally against. The deadline for a product site is October 3rd because the product will be released exactly a week afterwards? That's a real deadline. That's something that's worth working towards, because it matters. That can motivate the team.

If the deadline is October 3rd for no reason at all, however, it can actually be demotivating. It just comes across like they're being told to go the extra mile and rally against a date that doesn't actually matter at all. This is damaging to morale, and a team with bad morale is a team that isn't jelling.

Furthermore, tight deadlines in general can lead to quality reduction, which brings us to...

Quality reduction

If the team can't be proud of their work, then everything else in this post becomes somewhat irrelevant. Taking pride in our work is the root of all of this.

This is tricky though, because the level of quality required to satisfy most clients, managers, or end users is lower than the level of quality required to satisfy ourselves. Because of this, it can be tempting for managers and clients to ask for lower quality work because it can save time and money. After all, as long as it’s on time and on budget, most clients don't care if the code is well commented, or cleanly abstracted, or unit tested, or if it contains elegant solutions for obscure edge case bugs.

We've all been there, but this can be a huge hit for a team. Give a team the power to build something that they're proud of, and everything else here becomes a lot easier. Rob them of that, and it may save a bit of time here and there, but those savings will be sunk in the lost motivation and morale and overall ability of the team to come together.

Competition

By competition I mean things like calling specific people out or giving spot bonuses or awards for the most points closed in a week, etc. Pitting team members against each other goes against the goal of jelling the team. We want the team thinking as a team, rather than a collection of people who are working on the same project.

This may be a good time to point out that traditional "if-then" rewards (like spot bonuses) can in many cases actually damage motivation rather than improve it. According to the book Drive, these can put people in the mindset that the work is not rewarding or interesting on its own, which is why they're being given extrinsic rewards to keep them going. Focus on intrinsic motivation, and remember the 3 big pieces above: Purpose, Mastery, and Autonomy.

Education robbery

It's tempting to assign people the things they're already experts in. You don't have to worry about the ramp up time involved in learning something new, so you cut out some overhead.

It can come back to haunt you though, when people are tired of being pigeonholed on every project. It's a recipe for burnout if given enough time. Let people learn and make mistakes, and be there to support them along the way. It'll motivate them and make them happy, and a motivated and happy team is a jelling team.

It's also useful for different people to know how to do different things just for the sake of having a team with a diverse set of skills, so that no part of your project has a low bus factor. That way, if someone goes on vacation or leaves the project, then the hit to the team's knowledge will be minimal.

Defensive management

This one's for the people in the leadership positions. You've assembled your team, you've made it through discovery, and it's time to get to work. This means it's time to start to place trust in your people. Give them the Autonomy to do their work and be there for support when they need it.

One way to think of this is the difference between tactical versus strategic guidance. If we're building a building, then strategic guidance means saying, "Ok, put the building on this hill, make it 8 stories tall, and give it a fountain in the front." Tactical guidance is more like saying, "We're going to need 4 bulldozers and 8,000 tons of iron girders, and we'll need 2 concrete trucks to start pouring the foundation on Tuesday." 

Trusting in your people means telling them what needs to happen but not micromanaging. Sure, if they have questions then your feedback is welcome. But in general, a little trust goes a long way in helping the team feel autonomous, empowered, and able to jell.

Lack of closure

Everyone likes to see the fruits of their labors. If you spend a month building something, you want to see that thing go live for people to use it. You don't want it to be shipped off into the void, never to be seen again. It can be a slow and gradual motivation and morale killer for a team to constantly be working on things without ever getting closure about them.

This can sometimes be difficult. For example, if your team only has access to a development environment because the code will end up on a super secret company intranet, then it's really tough to get closure. Or maybe it's just a case where everything is going to be deployed all at once a year from now, making constant closure impossible. These are tough problems to solve.

They're worth solving though. Maybe you can set up milestones that can be deployed more often, or maybe you can have an "internal production-ish" site for deployments even if they can't go to actual production yet. Be creative. Try to think of some ways for people to see the end value of all their work.

Splitting up the team

The project is coming to an end -- what's next? Typically, those people would all be split up and sent to other separate projects, wherever they are needed, because it makes the most sense from a resourcing point of view.

Splitting up a jelled team so that they can all go start from scratch somewhere else is a huge blow. Keep those people together! If you roll that same group of people onto another project then they will have a HUGE head start. They will already know and respect each other and work well together, and you can shortcut months and months required to get a new team to start solidifying.

Why have we been ignoring this?

A jelled team can make a world of difference in the success of your project, yet we as an industry keep doing all of these things that prevent a team from being able to solidify. Why is that?

I think the reason is simple. If you see a smooth project where deadlines are being hit and the client is happy, then it's easy to assume that the team is happy. This can lead us to think of happy and motivated teams as the result of a successful project, rather than a cause of the project being successful. The opposite is true.

Teams like this make projects successful, rather than successful projects making teams like this. It’s time for us to realize that, and to encourage it. Remember that teams want to jell, and we just have to let them by removing anything standing in the way.