<aside> 🧠 The concept of 30% feedback was introduced at Griffin by @Maria Campbell and comes originally from this post on Jason Freedman's blog.


Most of us are only comfortable sharing our work once it's at least 90% done. We do this because we're worried that if we share our work before then that people will be harsher with their criticism (and because we want to make a good impression!).

The downside to sharing work that's at least 90% complete is that it's very easy to have invested a ton of time building on the wrong foundations, to have misunderstood one of the core requirements or just to have worked on the wrong thing entirely. This is a huge waste of effort, and having to throw away all of that work can be horribly disheartening! Even if only subtle changes are required, implementing them at the 90% point involves way more work than doing so at an earlier point in time.

The way around this is to share work that's much earlier in its development - maybe only 30% complete - but to make sure that the person who's receiving it is clear that this is 30% done rather than 90% done.

Setting expectations

In practice, doing this well starts with you telling the reviewer how complete something is at the time you share it. Is it 10% complete? 30% complete? 90% complete?

If it's only 10% complete, you're probably just looking at a series of bullet points or even just a few sentences describing the plan. As a reviewer, you want to focus on whether the thing that is being described is worth doing relative to other things the person could be working on instead (or worth doing at all!).

If it's 30% complete, you may be looking at a more detailed outline or potentially some draft chunks of the final work. At this stage there are likely to be tons of tiny things that are wrong, but as a reviewer you should focus on the broader agenda. Does this look like a fruitful avenue for further exploration? Is it heading in the right direction? Has anything major been forgotten?

If it's 90% complete, most of the usual feedback for how to review work applies so there's no point in repeating it here - at this point you get into things like phrasing, polish, and the rest of detailed review.

Making this work at Griffin

Sharing rough drafts of your work is uncomfortable. It goes against how we've been taught to show our work in our best light. But sharing rough, early drafts of your work is actually the most efficient way to make your work better - it's always easier to tweak direction at the beginning than at the end.

Note that not all of our stakeholders are appropriate for sharing rough work with. For instance, we try to only bring things to the Board or our regulators when they are complete. Even when dealing with investors, not everyone has the stomach for seeing work that's only at 30% done. But internally we should be comfortable that our colleagues will be understanding and constructive when we share early drafts of what we're up to.