I spent this past weekend at a case study competition called UW Apprentice, which was unique among events I’ve attended in two ways. One is that the cases were fresh from real startups that came in and explained the challenge they were experiencing, and who were all set to act on the best advice. The other was that you gave and received feedback with each of your teammates after each cases, and so you could review it all immediately. In theory, this could let you update your behaviour for the next case to be a more valuable team member, although I think in practice the schedule was too rushed for much reflection to occur.
Anyway, I noticed something interesting while filling out the “needs improvement” section at one point. The team member I was giving feedback to didn’t have any obvious shortcomings, and I found myself at a bit of a loss for what to say. Obviously they weren’t perfect, but they were totally generally “good” across the board. I wrote something general that was related to my sense of why we hadn’t won that round.
Today, I thought of this again when I was doing the final edits on a peer letter of recommendation for a fellowship program my friend was applying to. I had written last week in the draft: “It’s hard for me to think of a really good suggestion for an area of improvement for Tessa—” …today I added “—I’ve noticed it’s much easier to recommend bugfixes than features, for people.”
In this blog post, I figured I’d reflect a bit more on…
It might be kind of rough, and I might find future!me disagreeing with current!me about this pretty soon, in which case I may edit it.
Is it just the difference between negative and positive feedback? Nope. Negative feedback has the structure of “that thing you did—don’t do that [as often]”, while positive feedback has the structure of “that thing you did—keep doing it [and maybe do it more]”. The bug report / feature suggestion thing is more subtle.
» read the rest of this entry »
