Gift Giving

I’ve talked about the gift of feedback before. How important it is, and how useful it is. One thing I didn’t talk about then though is what kind of feedback you give when. Gifts should match the occasion. You wouldn’t give a housewarming gift for a 75th anniversary, and feedback is just the same.

Let’s say you want your house painted, so you look around at newly painted houses and find that the ones you like have the same painter. You call the painter and start to discuss things. The painter puts a swatch on the side of the house for you to look at. You look at the swatch, tell the painter you don’t like that the edges of the swatch aren’t crisp and they should do a better job of edges and finishing things and head to work. You come back at the end of the day and see that your house is almost fully painted. The only thing left is the door and the window frames. The edges are perfect. Just what you want. But not the color. So you call the painter and tell them it’s 2 shades too dark and they need to redo it.

That doesn't make a lot of sense, does it? The wrong feedback at the wrong time. It’s understandable though. We want orderliness and predictability. We want to close out issues. So instead of opening a discussion on the things that are unclear we focus on things we can close out. But we should fight that urge and give the right feedback at the right time.

That’s the 1/50/90%feedback idea. When things are just starting out, when there’s 1% of the project done and most of the work is in the future, feedback is about the big things. Is the direction or vision correct? Are the right upstream and downstream dependencies identified and accounted for? Does this fit into the bigger picture you’re going for? In the house painting example, when looking at the swatch on the side of the house, the feedback should be about the color. How it fits in with your overall vision for the house. How it works with the landscaping and the surrounding neighborhood. Not if the edges are crisp.

Some time later, when things are well underway, say 50% done, feedback is about how it’s going and how well things are matching with expectations and vision. Are there any new learnings/understandings from doing the work that far that might cause a change in the plan? If so, have they been raised, answered, and incorporated? Again, back to the house painting, when one or two walls have the base color applied, does the color still work with the surroundings? When you look at it from farther away, from a perspective you couldn’t see with just a swatch, does it make the statement you want? Now might be the time to think about the trim color for the eaves and windows.

Finally, when the project is 90+% done, look at the external details. The fit and finish. It’s (mostly) too late to change the big details, but what are the smaller things that you can only see now in the full context that might need some adjustment. Back at the house, the painting is almost finished. You’re doing a walk-around with the painter. Now is the time to talk about the edges between the walls and windows. Look for paint splatters. What they call in the trade the punch list. The things that need to happen before it’s truly done.

And that applies to software just as well as it does to house painting. When you see a proposal or vision doc, that’s not the time to say there needs to be an api for X and it needs to include parameter Y, or write the exact error text if an invalid parameter is provided. Instead you should make sure the domains are properly separated, the use case for the X api is covered and that as a principle, error messages are provided and that they include enough context for the user to understand how to fix it.

At an interim review, make sure the domain boundaries still make sense as things have evolved. Make sure use cases are covered, or at least not precluded. Think about new requirements that might have come up, or changed to up and downstream dependencies that might impact things. How has the overall environment changed and what are the effects of that. It’s still not the time to correct the grammar on the error messages, but it is the time to make sure the principles are being followed and the info is there.

Finally, as the project is nearing completion, feedback gets very specific. Now is the time to check the grammar in the error messages. Make sure that it’s solving the problem completely, not leaving off some edge cases. Feedback about things that might make it easier to live with over the long term. And of course, if you do see a big problem, say something. It’s better to fix things late in the dev cycle than to put something out that makes things worse.

So continue to give the gift of feedback. Just make sure the gift matches the occasion