A long time ago, when I was employed at a software company, I participated in an all-engineering offsite meeting in which we attempted to figure out what we needed to do to improve.

First exercise: we went around the room, round-robin style, and everyone contributed an idea.

A Tester said the Developers should write better Specifications.

A Developer said Marketing should give them Better Requirements.

Another Tester said the Developers should be doing More Unit Testing. (Yes, I was in that group, but it wasn’t me, I swear…OK, maybe it was.)

Someone else said the Managers should do Better Planning.

I knew things were really getting silly when someone said that what was really needed was Better Health Coverage and someone else said Bigger Cubicles. The intent of the meeting was to figure out how we could improve, not to have a two day whine festival.

But what struck me was that no one suggested something that could be accomplished by their own group. No one ever said, “I’d really like to do better at my own work by…” Every single idea was an idea that Someone Else would have to implement. At the end of two days I felt completely demoralized. We had a long to do list, much of it Action Items for management, and nothing that seemed likely to actually happen. Indeed, six months after the meeting, nothing had changed.

Since then, I’ve had the opportunity to lead similar offsite meetings. Whenever I lead such a meeting, I remember how creating a long To Do List for Other People didn’t work well, nor did hosting a Whine Festival.

Fortunately, I’ve discovered a way to avoid the Other People’s To Do List trap.

I ask participants to focus on what they can do. Not what they want someone else to do, but what they, themselves can do. And then I teach them the We Reframe.

The We Reframe involves transforming “They” statements like “They don’t give us documentation” into “We” statements like “We don’t have the information we need to do our jobs effectively”.

The transformation is straightforward. You change the sentence from what someone else isn’t doing to the effect it has on you. Some more examples:

“They aren’t doing unit testing” becomes “We’re getting software that is not stable enough to test.”

“They don’t give us clear requirements” becomes “We don’t know what we’re supposed to build.”

“They aren’t planning” becomes “We feel pulled in too many directions at once.”

This seems like a subtle difference. But reframing the problem in terms of the effect it has on you allows you to own the solution. It frees you from trying to figure out what someone else should do differently and allows you to focus on how you can adapt to the situation.

If we’re getting software that isn’t stable enough to test, what can we do about it? We could reject it. We could provide a set of minimum acceptance tests to the developers. We could integrate our test efforts with the developers’ test efforts, eliminating the handoff that isn’t working. There are a number of things we could do. But if we define the problem as “They aren’t doing unit testing,” there’s very little we can do. We can’t force them to write unit tests. Even if we could, we can’t force them to write good ones that prevent the problem we’re actually experiencing.

The reframe worked well at helping the teams I facilitated come up with an actionable list. And I discovered another profound result of the We Reframe that I hadn’t expected.

By focusing on things they can control directly, participants discovered that they have more power to solve their own problems than they originally thought.

The result is more than a list of things they can start doing immediately. It’s a general change in attitude.

So the next time you feel frustrated because They aren’t doing something, try the We Reframe to see how many things you can do without any help at all from Them.

Oh, and by the way: They are likely to notice when you change how you work, and that might lead Them to consider changing too. It’s worth a shot.