How to ask for feedback without creating chaos

One of the core engineering beliefs at Pusher is that everyone should have an equal chance to raise issues and propose solutions to fix them. Proposals can tackle a broad range of problems — from naming, through feature suggestions, to implementation details.

While anyone can suggest changes, the final decision always belongs to the owner of the subject of the proposal. Typically, it’s the responsibility of engineering teams. They can either accept the suggestion and turn it into an action item, or reject it.

Teams can reject proposals for various reasons. Sometimes the solution is incorrect or causes other problems. Sometimes the problem is vague or irrelevant. Even senior engineers sometimes struggle with writing proposals.

To improve the chances of ratifying the proposal and to save ourselves time, we ask others for feedback. Reviewing proposals might seem straightforward, but sometimes it can have negative impact on your team, especially if you lack confidence in the problematic area.

During my time as a platform lead at Pusher, I developed a set of guidelines that help me propose and introduce changes without causing confusion in the team.

Avoid broadcasting chaos

Broadcasting is a way to distribute information from one to many members of a group. If you want to share something important with your team, you can send them an e-mail, write a post on your internal blog or drop a note on Slack. It’s a simple, but very powerful tool.

Like most tools and processes, unfortunately, broadcasting has pitfalls. It can easily turn small proposals into chaotic discussions.

Chaos emerges from controversial ideas. They can be caused by lack of context, misunderstanding between the proposer and reviewers or just a human error. It happens to everyone occasionally.

People start discussions when they see controversy. Those conversations can become problematic for two main reasons:

1) Too many people involved

You don’t need a big company to start a large discussion. I’ve been part of unproductive conversations with fewer than 10 participants.

First problem I’ve noticed with large groups is conversations splitting into parallel threads. Boundaries between discussed subjects might not be clear for participants, causing people to bounce between topics, trying to make sense of the whole discussion. To get the conversation back on track, it must be moderated and big groups are hard to control.

Large groups are also inefficient in the worst case scenario when the idea is clearly wrong. Asking everyone for feedback on a flawed proposal is a massive waste of time. I’ve been wrong several times and I will certainly make mistakes in the future. Minimising the cost of misunderstandings is important to efficient management and leadership.

2) Using the wrong medium to communicate

Companies, especially in the tech sector, use plenty of communication channels. Meetings, presentations, e-mails, Slack, the list is long. Choosing the right medium for discussion can be tricky.

In my experience, the easier it is to join a conversation, the more chaotic it gets. Slack works great in lots of situations, but I found it really treacherous when asking for feedback. Discussions in large, public channels tend to be particularly unproductive.

Beware of quiet misalignment

Some discussions dodge the chaos, but they might still cause problems. For many reasons, your teammates might not object to your proposal even if it’s wrong. Maybe they (still) trust you, maybe they are afraid to speak up.

One such proposal might not cause much damage, but persistent lack of feedback is a real danger in the long term. You need to create an environment that makes people comfortable discussing issues.

How to control the feedback flow

There is a way to verify proposals in a gradual way, reducing the confusion in your team. This process has three pillars:

1. start with small, private groups
2. start with highly credible people
3. remember diversity

1) Start small

To avoid complex communication patterns, the initial feedback group should have few members. In my experience, a good number is between 3 and 5 people. Usually, discussions in such groups are productive. In case people go off track, it’s still possible to moderate the conversation.

Another option is splitting the discussion into a bunch of small, independent groups. That includes one-to-one meetings or sending blind carbon copy e-mails. Controversial proposals are best dealt with privately first. People with quiet personalities tend to be more open in private discussions too.

2) The importance of credibility

Even in small groups, if you pick random people, you will probably not get good feedback. You need a group you can believe to raise useful suggestions.

Where does credibility come from? I always look for two main factors:

1. expertise in the area
2. honesty

People with more knowledge about the discussed subject are more likely to understand the context and implications of the decision. However, they need to be open to raise issues, otherwise their expertise is not really useful.

3) Diverse thinking

Minimising the time to agree has a bad side-effect of creating echo chambers. Decisions driven by short term efficiency might turn into huge liabilities in the long term. Taking many perspectives in the decision-making process helps break down silos and make more informed decisions.

Seek people outside the core decision group. If it’s your team proposing the change, ask a member of a different team for their opinion. If you’re working in a special interest group, bring a non-member into the discussion. Often, they will question basic assumptions behind the proposal, uncovering problems missed by the rest of the group.

If your decision affects other teams, it’s important to ask someone who will have to adjust to the change. We try to structure dependencies between Pusher’s engineering teams as customer-provider relationships. For example, product teams are customers to the platform team, which provides shared infrastructure for them. Before investing time to solve a problem for a customer, we ask them for their feedback.

Summary

We use the guidelines outlined above in our company to improve the process of proposing changes to our systems. By discussing ideas with smaller groups first, we can smooth out the rough edges of proposals before exposing them to larger audiences. Reducing the amount of noise helps us make better decisions and maintain morale not only in teams, but also across the whole company.