Building Aggressively Helpful Teams

I've always said that software development is a team sport. I believe in building teams around that. And I recently discovered a simple two part trick that makes each team member believe it too.

There are little things that happen all the time that discourage individuals from working like a team. Pushing them to be a working group of individuals that all happen to be doing a similar activity, rather than a team that actually influences each other.

There are things you can do as a manager to encourage teams to work as actual teams, like not assigning explicit units of work to individuals. Instead assign tasks to teams. Then allow them to self direct and accomplish the goal in the best way they see possible, because they're closest to the ground.

But you've got an uphill battle ahead. New team members often bring a lot of baggage from previous organizations. So even if you really mean it, that software is in fact a team sport, you'll face skepticism.

Even if you do everything you can, in both actions and words, to prove it over months, you'll still face subconscious defensive efforts to make sure, just in case it was a trap or a long con, that individuals members are still proving themselves as individuals, rather than as a team.

Part One: Just Ask

But recently I discovered a simple change that gets folks to buy in.

Now, in the shoes of someone on the team, when you finish up the current piece of work, and you're headed back to the kanban board (or backlog, or whatever you call your prioritized work pile) you look at the top piece, and if someone else is working it, rather than immediately proceeding to the next one, make it a habit of asking the individual working on it if you can help.

This is part one. It's as simple as:

Hey, do you need a pair on implementing that user story?

Part Two: Publicly Reframing Implications

Now, as a member of the team, when you look at that top item, you may think:

That one looks like it's probably easy, and whoever is already on it is a competent software engineer. They don't need my help.

Stop.

Instead, ask yourself:

Is this one so simple that it would be actively harmful for me to work with them on this one?

Let the team know publicly that this is the explicit question that everyone is asking before they ask if you could use a pair.

This reframe is useful because otherwise you will have the tendency to skip over it. and go to the next unclaimed item.

If you let the team know that this question is your operating principle, you also avoid the other problem, which is that without it "Do you need a pair?" can be heard as:

Are you so intellectually weak/incapable of solving this that I have to step in and carry you?

And nobody wants to look like they're not capable.

They don't want to get fired.

So if you ask "Do you need a pair?" unless you team has established a lot of psychological safety already you may get back "Nah, I'm fine", unless they're already so in over their head that they know they have no other alternatives but to get help.

Knowing that team members are explicitly asking themselves:

Is this one so simple that it would be actively harmful for me to work with them on this one?

Before asking you, and still asking you if you need a pair, gives you the freedom to say, yeah, it really is so simple, in the event that you're doing something that wouldn't be a value add to pair on (why you're doing this work becomes another issue I'd want to address, but that's for another article), but if you feel any sort of safety with your team, and it's anything more complicated than changing a single button's color, you have more leeway to reply, you know what, this isn't completely trivial, yeah I could use a hand.

And then you get to experience the almost magical benefits of pairing in your organization.

Go Build Aggressively Helpful Teams

This was described to me as a trick that made our team feel aggressively helpful, by one of it's members, a very welcome change compared to previous organizations.

So hopefully you can steal this trick and build aggressively helpful teams too.

If you've got any other tricks you use to build aggressively helpful teams, I'd love to hear about them! Fediverse (@brittonjb@hachyderm.io), or via email (brittonbroderick@gmail.com).