Buy My Book, "The Manager's Path," Available March 2017!

Wednesday, March 28, 2012

Yes, and...

I have a terrible habit. When confronted with a new idea, any idea, my knee-jerk instinct is to find its flaws. Or, to put it more succinctly, I'm a "no, wait!" kind of person. You want to add a new feature into my library? No, wait! That won't maintain API backwards-compatibility! No, wait! No one but you really needs that, why should we put it in a library used by everyone? No, wait! The work that will take us to review overwhelms it's worth as a new feature.

There is a well-trod school of thought that says to maintain creative collaboration, anytime you want to say "no, wait!", "no, but" or even just "but", you should instead start the conversation with "Yes, and". Want to add a new feature into my library? Yes, and we will have to think about how to add it without breaking API backwards-compatibility. Yes, and we should see what other community members think about the usefulness of the feature. Yes, and we'll have to evaluate the work that it will take to correctly implement and review.

"Yes, and" is a great baby step on the path to thought leadership and productive collaboration. But let's face it, it's easy to get a bit snarky with our yeses. Yes, and six months later, we'll have another release. Yes, and you can be on hand to fix the bugs that come in. Yes, and why don't we rewrite the whole thing in Scala while we're at it? (Watch Peggy struggle with this on Mad Men[16:50], when Megan shows her work)

So how do you really take "yes, and" to heart? My boss, who is a natural at this sort of thing, taught me one of his favorite tactics. It's not just saying yes. When a new idea is presented, find at least one positive thing to say about it, and praise that quality first.
 "That is an interesting idea. People using our service to do complex state maintenance could really use this feature, it would save them having to write a lot of code themselves."
The goal of this exercise is not only to keep the flow of positive collaboration going. It is also to force yourself to acknowledge the problem that the idea is trying to solve. You may not think the problem is worth solving, but this is something that your collaborator wants to explore, perhaps because it is causing them pain, perhaps because they have a different set of priorities than you, perhaps because they're simply trying to contribute to the discussion.

I will admit that despite knowing this is the right thing to do, I am absolutely terrible at following this advice in person. My knee-jerk nerd comes out and she is very into scoring points by pointing out flaws. Among the tech community, I'm hardly unique. Read the comments on almost any Hacker News thread if you don't believe me. And yet, the easiest place to start with this is online. You have time to think before you hit send on that email, submit on that comment, post on that tweet. Why not take the time to acknowledge the idea fully before pointing out its downsides? Just because you didn't think of it doesn't mean you lose by making it better.

3 comments:

  1. I do it very often..after starting with the negative comment I feel bad that I snubbed an idea while being formed..i try not to do thatm but as you say the instinctive reaction just pop out :D

    ReplyDelete
  2. This post reminds me of something Tina Fey writes about in "Bossy Pants" (a book that's nearly 40% funny). Shes write about "The Rules of Improvisation That Will Change Your Life and Reduce Belly Fat." I think these rules work in general and are similar to the tips you listed, namely:

    1. The first rule of improvisation is AGREE. Always AGREE and SAY YES. This is about achkowledging the other person's creation or improvisation in the original context.
    2. Not only say yes, but YES, AND. This is the second rule. To keep a good brainstorm session going you must not only acknowledge the other person's idea but add to it, keep the spit ball growing.
    3. Third rule, MAKE STATEMENTS. As in don't always ask questions, get out there a little bit, be brave, say what you feel.
    4. Forth, THERE ARE NO MISTAKES only opportunities. Thinking like this makes 3 easy.

    My 5th is:

    5. Be tough. Criticism is a fact of life. Life aint't lollipops and leprechauns. Learn how to take criticism. Or in Software Engineering parlance, your code sucks, fix it.

    ReplyDelete
  3. I think "Accept, and build" is a better provocation than "Yes, and".

    ReplyDelete

Note: Only a member of this blog may post a comment.