After I published test && commit || revert, I got a variety of responses on Twitter and on Hacker News. The Twitter comments were mostly of the form, “I’ll try it and post how it goes.” Many of the Hacker News comments were objections–“This won’t work because…” I was reminded of a habit: turn objections into goals.

(My inspiration for this technique came from Dale Emery and his “Resistance as a Resource”.)

I turn objections into goals when an idea provokes resistance. My natural tendency is to argue or get angry. If I can insert a little logic between seeing the resistance and reacting, though, I can offer a more productive response.

But First..

Before deciding to engage with an objection, I need to decide what I think is meant by the objection. Sometimes objections mean just what they say–this won’t work because of that. And they are right. Sometimes objections mean rejection–I’m not ready to even think about this idea now. Those objections aren’t worth responding to at the level they are posed.

If I read an objection as engagement–interesting, tell me more, I’m worried about this–then engaging back has some upside.

“Can’t X because Y” -> “Can X when not Y”

The first step in objections as goals is to invert the statement, make it positive. “I can’t make changes in small steps because sometimes I have to change a hundred files,” becomes, “I can make changes in small steps when I can change one file at a time,” or, “I can make changes in small steps when a single change can modify a hundred files.”

This transformation is not logically sound. There may be other reasons I can’t make changes in small steps. It’s okay. We aren’t pursuing certainty here. We are trying to help people through the barriers to their own learning.

Sometimes this transformation is all that’s needed. The other party is saying, “I don’t want to try and fail.” We respond with, “So maybe trying isn’t so bad.” Away they go, ready to try. That’s all the good we can do for today.

There may be juice in the lemon for us, though. A little more work uncovers it.

“When not Y then X”

Objections can contain information we didn’t have or that we weren’t prioritizing. The second transformation transforms this information into something we can use.

From the example above, we go from, “I can make changes in small steps when a single change can modify a hundred files,” to, “When I can modify a hundred files with a single change then I can make changes in small steps.” Oh. Okay. That’s a thing I might do.

Examples

Here are some worked examples from the comments on test && commit || revert.

  • I can’t use TCR because nobody will write tests. I can use TCR when people write tests. People writing tests lets me use TCR.

Conclusion

The first time you turn objections into goals is likely to feel awkward. I’ve been practicing for ten-ish years and at some point it just became automatic. Someone has to object pretty hard and personally and I have to be off my game for me to drop into defensiveness in response to an objection. It still happens, but more often I offer help and learn something in the process.

Any objections?

Kent is a long-time programmer who also sings, plays guitar, plays poker, and makes cheese. He works at Gusto, the small business people platform.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store