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

Moving From Overwhelm to Breakthrough

Not long ago, I had a meeting with my boss, who also happens to be one of my mentors, and after some other discussion asked him one of my favorite open-ended questions:

What should I be thinking about that I’m not yet?

After a few moments of thought, he started drawing a diagram that I’ve roughly recreated below:

work and impact

He highlighted that I, and many of our team, are operating in the middle area on this graph.  We’re working hard, we’re efficient, and we’re getting a lot done.  We feel like we’re just barely keeping up, but we are keeping up and we’re making serious progress.  He also pointed out that some of our team members who’ve struggled, and sometimes left, got stuck in the left hand side of the graph, feeling like they were pouring work in and never able to get ahead.

Then he challenged me.

I want you to figure out how to get you and everyone on your team over into the right side of this graph.

Moving from Holding On to Breaking Through

Operating on the right side of the graph means getting more impact for less effort.  It means optimizing not just for efficiency but for effectiveness.  It means rethinking goals and tasks to create radically different strategies.  Lets take a look at what this can mean in different areas.

Breakthroughs in Software Engineering

Breaking through in engineering means finding ways of overcoming the ‘Not Invented Here’ syndrome and leveraging existing tools and libraries.  It means boiling things down to the root of the problem and creating radically less code to solve the same number of problems.  It means learning and using the most efficient frameworks and investing time and energy in your tooling.  It means automating your tests, streamlining your deploys, and biasing every project towards creating something that can be reused and repurposed.

Breakthroughs in Customer Support

Breaking through in customer support means finding ways to move from the 1 plus 1 plus 1 model of supporting customers to a leveraged and scalable one.  It means taking problems that come up over and over again and writing documentation that clearly resolves them.  It means taking a set of individual customers and creating a place where they can converse, create community, and help solve each others problems.

Breakthroughs in Marketing

Breaking through in marketing means turning your best customers into your best evangelists. It means empowering others to write your content, spread your message, and bring new people into the fold.  It means finding creative ways to connect and reuse your content and materials across multiple mediums and locations.  It is creating self-perpetuating material that engage people, causing them to interact and create new material that further engages people and spins up the marketing flywheel.

Breakthroughs in Management

Breaking through in management is successfully engaging in this exercise with each of your team members.  It is moving away from making sure tasks get done and moving towards reimagining productivity and effectiveness.  Away from keeping checklists and towards teaching and mentoring.  In essence, away from management and towards leadership of empowered team members that self-manage.

Where else can we break through?

As I’m mulling on this more and more, I find myself wondering how I can apply this perspective to other parts of my life.  What does breakthrough parenting look like?  I live my parenting life somewhere between the left and middle of this spectrum, more often on the left.  What does breakthrough fitness look like?  Breakthrough relationships?

Leave me a comment, I’d love to engage on these ideas.

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?