Effective feedback: Thirty Percent Vs Ninety Percent

When I was first getting started as an entrepreneur, co-founding a business with someone who I had relatively recently met, I’d consistently run into a challenge getting feedback.  I’d have built a prototype, have some ideas for what we could do with it, and take it to my cofounder to show it to her and ask her thoughts.  We’d almost inevitably get bogged down looking at and talking about details that had nothing to do with the prototype itself – this font isn’t right, why is this other part of the site interacting with it this way, etc.

This went on for quite a while, and was frustrating to both of us.  I’d just want some direction on the single item I was working on, and she wanted to clean up and polish all of the other things around it.  Alternatively, sometimes I’d have something that was just about ready to run and the conversation would veer into fundamental directional questions.  Until one day, we stumbled on the concept of thirty percent feedback vs ninety percent feedback, which I believe I first found on the 42 floors blog.

The basic idea is this – Whenever you’re asking for feedback, make clear if you’re closer to 30% finished or 90% finished.  The feedback you’ll get will be wildly different.

Thirty Percent Feedback

Thirty percent feedback is strategic, it is big picture… it answers the question ‘Am I heading the right direction?’  and because it is early enough that there is time to course correct, it has room for divergent thinking, opening up the problem domain and exploring radically different options.

Because it is early in the process, it glosses over fine details and polish, knowing those will be addressed later.  Thirty percent feedback is possibly the most difficult to ask for, because it involves putting yourself out there with work that you know is not ready, is not polished, but it is also often the most helpful feedback to get.  It can help you sidestep a lot of wasted effort, and give you truly powerful strategic insights.

Ninety Percent Feedback

Ninety percent feedback is more tactical, it is detail oriented, and it tries to catch every little issue so that nothing makes it out into production.  This is the time for closing things down, tweaking final copy, and making everything pixel perfect.

You Need Both

The place I think this is the most important is in dealing with stakeholders.  The most painful thing in the world is when you think you’re at 90% complete, you go to a stakeholder, and they’re giving you massive directional changes.  Suddenly you’re back at square one, and you’ve wasted a ton of time and energy polishing something that doesn’t end up getting used.  This is a natural consequence of skipping your 30 percent feedback checkin.

Almost as painful is going to someone for 30% feedback and having them get all caught up in the details, not able to step back and take a look at the bigger picture, and acting as if you’re delivering shoddy work.  Its not shoddy, its just only 30% finished!

So what I’ve learned to do is engage both – you engage all of your stakeholders early and often in the process, as soon as you have any sort of idea or direction, but you make clear the stage you’re at and what type of feedback you’re looking for.  That way, by the time you get to the 90% feedback not only do you have much more high quality work, but they’ve been coming along for the ride the whole time.


Enjoy this?  Want to read more like it?  Sign up for email updates by on ‘Email’ in the subscribe box at the top right of the page

Technical Leads

The skills that it takes to become a good engineer are not the same as what it takes to lead a team.

Let me tell you about a situation that I saw unfold before me recently. I’ve been consulting at Sony Electronics with a web software group there. The team lead was about to leave for a new position, and they had selected a successor, who I’ll call John. John is an excellent software engineer – he
regularly tackled challenging problems, was involved in architectural decisions, had demanding standards in code reviews, and was clearly the most senior full time engineer remaining on the team. Besides, except for me, and I was a part time consultant, no one else seemed even remotely ready.

John was interested in the new responsibility – it seemed like the next step in his career, not quite in management but starting to assume a leadership role – and while he was anxious about it he agreed to take it on. There were a few weeks remaining before the prior team lead was going to leave, so the plan was to transition him gradually, having him take on more and more responsibility over the next few weeks.

The challenges started almost immediately. Asked to lead a technical meeting to come up with a proposal, John faltered. He opened with a long rambling monologue that left noone in the room certain about what was trying to be accomplished. As he called for participation, there was first silence, then disjointed conversation. Eventually, his manager and myself spoke up to help guide the meeting and get it back on track. This would have been fine, had John been open to feedback about how to improve, but either due to defensiveness or due to a feeling that he had all of the skills he needed, he wouldn’t or couldn’t hear it.

The issues continued with additional meetings – when we met with the product owners to figure out details of the next release, John sat through the meeting saying very little. Questions about details, give and take about technical vs business tradeoffs, push back against irresponsible features, it all fell to other members of the room. When asked about it later he said that it was a ‘business’ meeting, and he wasn’t sure what to say.

The skills that it takes to become a good engineer are not the same as what it takes to lead a team.

This situation didn’t end well – after a few weeks of this, with the old team lead about to head out and the management feeling desperate, I was asked to co-lead the team with John. We worked together reasonably well, but it was always a little awkward and several months later he left the company for another position – purely technical – in the bay area.

With this experience freshly in mind, I’m now working to train the next team lead before I wrap up my time consulting with Sony. But it got me thinking about the skills that it takes to be an effective technical leader. They’re learnable, many of them are actually fairly concrete, but they’re not the same skills that it takes to become a good engineer.

I’ve learned them in a combination of being mentored, years of Toastmasters, and trial by fire as a startup CTO. But I wonder… where do we expect engineers to learn them? And from what I’ve seen, good team leads are even more rare than good engineers, so why aren’t we being more deliberate about training them?