✨ The 20% Rule - The Power Of Early Feedback

Issue No. 28

This topic often comes up in my coaching sessions with team members and is a type of culture I try to encourage.

💬 In this issue, I cover:

• ✨ The 20% Rule - The Power Of Early Feedback
  • 📜 A Request For Comment Process Gone Wrong
  • ⚠️ It's A Trap We Fall Into
    • 🛠️ Common Traps in Software Development
    • 🌍 Real-Life Examples
  • 💡 The Solution: Share Early, Iterate Often
  • 📏 The 20% Rule: Share When It Hurts
    • 🔄 Iterate Through Feedback to Improve Quality
  • 📊 Why Share Early? Let's Visualise The Difference
    • 🌟 The Benefits of Early Sharing
  • 🚀 Yes, This Is How Agile Works!
  • 🔋 Beat Burnout By Following The 20% Rule
    • 📈 The Problem of Collaborative Overload
    • 🧠 Beating Burnout: It's Not Just Our Organisation's Responsibility, We Need to Step Up
    • 🛡️ Best Practices to Avoid Burnout
  • 🏃 Ready to Take Action?
• 🔦 Highlight of the Week - Failure

✨ The 20% Rule - The Power Of Early Feedback

Or the huge waste of avoiding feedback until we think our work is good enough to share.

📜 A Request For Comment Process Gone Wrong

Storytime!

I've worked in a few companies with a Request for Comment (RFC) process to introduce changes.

The RFC process is a structured way to propose changes or new ideas in a company. It involves writing a detailed document that explains the change, why it's needed, and its possible effects. This document is then shared with colleagues for their comments and feedback. The goal is to get different views and ideas early on, which can help improve the idea and fix problems before it is put into action.

I thought I had a "brilliant" idea for a process change, so I spent hours writing a detailed RFC proposal to share with the company.

As a newsletter subscriber, you know I can sometimes be "a bit verbose"!

So, the RFC can end up being quite long, especially with my perfectionist tendencies.

You can imagine my disappointment when I finally shared my RFC; my "brilliant" idea fell flat as people poked holes in it.

• Some of the criticisms felt invalid.
• Some feedback was valid but required significant rework because I missed important things.

My colleagues approached my work from different worldviews and angles, whereas my RFC was written from my perspective.

My emotions crashed to a low.

I then faced a significant amount of rework to reach some level of agreement and convey my big idea successfully.

And getting to that agreement took forever! It was incredibly frustrating!

I tried to visualise this in the diagram below, which shows my emotional journey alongside actual progress towards a finished product.

In some similar situations, I've not even reached the happy ending of getting to an agreement and done! My idea and all the work I did ended up in the bin!

Have you experienced this roller coaster of emotions yourself?

I think we've all been there!

⚠️ It's A Trap We Fall Into

Writing extensive documentation or specifications without peer review is a trap we can all fall into; it can result in misunderstandings and misaligned expectations.

🛠️ Common Traps in Software Development

Sadly, we can fall into this trap all the time when we are building software products.

Here are some examples of the times I've fallen into this trap:

• Building a feature without enough user research led to a product that didn't meet user needs.
  • More generally, designing a user interface in isolation without early user feedback led to poor usability and user experience.
• Launching a marketing campaign without A/B testing led to ineffective messaging and a wasted budget.
• Frontend and backend teams work separately and only integrate at the end, causing significant rework and integration issues.
• Implementing a new technology stack without consulting the team led to compatibility and maintenance challenges.
• Planning a project timeline without stakeholder consultation led to unrealistic deadlines and resource allocation issues.
• Rolling out a company-wide policy change without gathering employee input resulted in low adoption and resistance.

🌍 Real-Life Examples

This is not just limited to building software products; we can fall into this trap in our relationships and communities.

For example, planning a family holiday without considering everyone's preferences can result in dissatisfaction and conflict.

Or organising a community event without seeking input from the people who live there, resulting in low attendance and engagement.

Life and collaborating with people are hard!

So... What is the solution?

💡 The Solution: Share Early, Iterate Often

Always share your work as early as possible and work as much as possible in the open with small iterations so you get feedback as often as possible.

So easy to say.

It sounds so obvious; you know this already.

And yet, it is so hard to do in real life!

If you think hard, you might be making this mistake in a project you are working on right now!

The key is to make your work observable to others and iterate through feedback.

Empower yourself and your team by sharing your work early. Trust in your abilities and those of your colleagues, and use rapid iteration to drive the project forward.

This is one of the bits of advice I find myself giving to others and reminding myself all the time!

In part, I'm writing this article as a reminder to myself!

📏 The 20% Rule: Share When It Hurts

My teammates will have heard me give this advice frequently: "Share your work at 20% done, not 80% done".

It's a good rule of thumb.

The idea is to make your work visible and share it early, even when it's just 20% complete, rather than waiting until it's fully polished. This allows others to provide input and suggestions, leading to better results through collaboration and diverse perspectives. It's about embracing the iterative and collaborative nature of knowledge work.

There is no formalised 'rule' percentage; the general principle is to share drafts and unfinished work much earlier than we traditionally have to improve quality through collaboration. The exact percentage is less important than developing the habit of increased transparency and 'narrating your work'.

A good guideline is that sharing your early drafts for feedback should feel painful.

The 20% rule means making your work more observable to others, explaining your thought process and decisions, and inviting feedback and suggestions. This practice helps build connections and trust within teams, leading to better results through collaboration and diverse perspectives.

By sharing early, you empower yourself and your team to take ownership of the project. Trust in the collective wisdom of your colleagues to enhance the work and drive it forward.

🔄 Iterate Through Feedback to Improve Quality

One of the key benefits of sharing your work early is the opportunity to iterate and improve based on feedback.

When you share a rough draft or prototype, you invite others to provide their perspectives and insights. This feedback can help you identify areas that need clarification, spot potential issues, and generate new ideas to enhance your work.

By embracing an iterative approach, you can progressively refine your work, making it stronger and more effective with each cycle of feedback and revision.

Remember, the goal is not perfection from the start but continuous improvement through collaboration and iteration.

📊 Why Share Early? Let's Visualise The Difference

There are real benefits to this approach. To illustrate this, check out this diagram of my progress and emotions on my RFC if I had followed this advice:

While this is a theoretical "reimagining" of the scenario I lived in previously, I think this reflects the difference when you get early feedback and work in small iterations.

You can see that we got to an acceptable solution in less time overall. My emotional state fluctuated somewhat, but I avoided the much lower lows and ended up in a higher state.

Different mindset, different approach, different outcome.

🌟 The Benefits of Early Sharing

Some key benefits of this approach include the following:

• Getting valuable feedback and new perspectives early on
• Building connections and relationships through the sharing process
• Increasing transparency and trust within teams
• Accelerating learning by making thinking processes visible

This rule works for everything, from a proposal document to an org change!

And it should be no surprise that this is a foundational principle of Agile!

🚀 Yes, This Is How Agile Works!

Agile emphasises iterative development, continuous feedback, and collaboration.

Agile aligns perfectly with the 20% rule of sharing work early and working in small iterations.

Just as Agile teams deliver small, incremental updates to gather feedback and make improvements, the approach of making your work visible and seeking early input fosters a similar environment of continuous improvement.

Both Agile and this "20% rule" aim to enhance quality, adaptability, and team cohesion by leveraging diverse perspectives and iterative progress.

🔋 Beat Burnout By Following The 20% Rule

Suppose we repeatedly avoid feedback until late in the process of making things. In that case, the emotional roller coaster could contribute to burnout.

By sharing early and often, you can reduce stress and avoid burnout. Empower yourself to seek feedback and make improvements continuously. This approach not only enhances the quality of your work but also fosters a healthier, more sustainable work environment.

📈 The Problem of Collaborative Overload

I came across a great article called "Collaboration Without Burnout" some time ago.

As organisations become more global, adopt matrixed structures, offer increasingly complex products and services, and enable 24/7 communication, they are requiring employees to collaborate with more internal colleagues and external contacts than ever before. According to research from Connected Commons, most managers now spend 85% or more of their work time on email, in meetings, and on the phone, and the demand for such activities has jumped by 50% over the past decade. Companies benefit, of course: Faster innovation and more-seamless client service are two by-products of greater collaboration. But along with all this comes significantly less time for focused individual work, careful reflection, and sound decision making. A 2016 HBR article coauthored by one of us dubbed this destructive phenomenon collaborative overload and suggested ways that organisations might combat it.

🧠 Beating Burnout: It's Not Just Our Organisation's Responsibility, We Need to Step Up

While organisations can and should do something about this, we as individuals are also responsible for some of this.

Not surprisingly, we found that always-on work cultures, encroaching technology, demanding bosses, difficult clients, and inefficient coworkers were a big part of the problem, and most of those challenges do require organisational solutions. But we discovered in many cases that external time sinks were matched by another enemy: individuals' own mindsets and habits. Fortunately, people can overcome those obstacles themselves, right away, with some strategic self-management. Much overload is driven by your desire to maintain a reputation as helpful.

And our organisation might not do enough, so we each need to take action and adjust our behaviour to protect ourselves.

The recent explosion in the volume and diversity of collaborative demands is a reality that's here to stay. Unfortunately, the invisible nature of these demands means that few organisations are managing collaborative activity strategically. So it falls to you, the individual, to fight overload and reclaim your collaborative time.

🛡️ Best Practices to Avoid Burnout

We can implement three broad categories of best practices related to our beliefs, network and behaviour.

We uncovered best practices in three broad categories: beliefs (understanding why we take on too much); role, schedule, and network (eliminating unnecessary collaboration to make time for work that is aligned with professional aspirations and personal values); and behavior (ensuring that necessary or desired collaborative work is as productive as possible). Not all our recommendations will suit everyone: People's needs differ by personality, hierarchical level, and work context. But we found that when the people we studied took action on just four or five of them, they were able to claw back 18% to 24% of their collaborative time.

I highly recommend reading the whole article.

What I found interesting was that what I'm recommending in this essay is also one of the behaviours they recommended to help people avoid burnout (emphasis mine):

Ellen, for example, decided to engage stakeholders in collaborative work early to save time later in the process. "I used to dot every i and cross every t before approaching others," she says. "But I've learned that if I get a plan partially developed and then bring in my team, my boss, even my clients, they get invested and help me spot flaws, and I avoid tons of downstream work to fix things or convince people."

🏃 Ready to Take Action?

Think of all the projects you are working on right now.

Go ahead and write out a list of all of them...

Or bring up your to-do list...

When was the last time you got feedback on them?

Have you validated your assumptions with real users?

Circle or star the projects where you need to take action.

Go for it. Take that action!

Writing this article made me face a project I have been tinkering with without any user validation! I'm now off to figure out how to validate my hypothesis before I do more work!

Thanks for being a reader. It helps keep me honest!

💬 If you had some thoughts while reading this, I would love to hear them in the comments.

🔦 Highlight of the Week - Failure

I needed this reminder about failure (from the Farnam Street newsletter on the 11th of Feb 2024).

Maybe you need a reminder as well?

Go easy on yourself... but not so easy that you aren't in the arena!