At Snap, we believe that kindness is at the heart of engineering: we place a high value on integrity, craftsmanship, and collaboration in all of our work. We also recognize that kindness without courage is not always enough: successful companies should foster healthy internal debate, driving positive change.
At the same time, throughout our careers, many of us have learned that the line between debate and conflict can be thin - and that disagreements that are allowed to fester may frustrate teams and get in the way of getting stuff done. To that effect, based on our experiences in the tech industry, we wanted to share a set of simple, time-tested strategies to help folks give productive feedback and make good engineering decisions in complex work environments.
When we see another person doing something inexplicable, we all sometimes fall back to what feels like the simplest explanation: that they don’t know what we know. But especially in a professional setting, this is often the wrong conclusion to reach.
At Snap, we want to celebrate different perspectives, but we want to harness such differences to build better products, not to divide teams. And so, when disagreements arise, we encourage folks to assume the best intentions of others, and to make sure we all have a full picture of each participant’s thought process and goals.
In our experience, perhaps the most practical tool at our disposal is deliberation: before challenging a decision, it pays to seek out all the facts in an open-minded and non-confrontational way. It’s good to dig up design docs to understand the project’s motivation and priorities, and get a solid sense of the alternatives considered before the team committed to a particular approach. Explicit critiques and hard-hitting questions are best reserved for later; even if they remain valid, this lets us fine-tune our thesis along the way.
When giving critical feedback, we believe it’s crucial to find a venue where both sides of the conversation can speak freely, and where everybody can think through their responses, discuss alternatives, and dive into the technical details of the matter at hand.
In this sense, it’s best for pointed conversations to happen in smaller forums. Lively discussions in large forums are common in the tech industry, but need to be approached with special care: in a very public setting, you might have had a chance to think through your argument and present it in the best possible way; the person who has to respond is not necessarily afforded the same courtesy.
On the other extreme, we feel it is seldom healthy to air frustrations when the other side is not in the room; fairness aside, it just doesn’t get much done. When faced with profound and important disagreements, it’s incumbent upon us to find a way to resolve them swiftly; and for minor annoyances, sometimes it is best to just move on.
When a loaded question appears to attack our integrity or casts doubt on our competence, we are likely to react viscerally and defensively - and are much less likely to give due consideration to the merits of the other person’s views.
To avoid putting others in this position, the oft-repeated tip is to make sure we are criticizing ideas, not personalities; in other words, we should never open with “I can’t believe you thought this is a good plan!”. At Snap, we try to take this principle one step further, with what I informally call the “Jeopardy!” rule: trying to phrase your feedback in the form of a question that prompts the other person to independently work through the considerations that are on your mind. Instead of exclaiming “but X is going to completely break your design!”, it almost always pays to start with “do we need to worry about X?”.
In some settings, it is OK to be more blunt; but especially if you’re in a senior role, remember that your off-the-cuff remarks carry a lot of weight - and have a lot of subtext - in the eyes of your team.
On some level, opinions are cheap; every person has one. What matters is the ability to turn these opinions into action - and to ship top-notch products to the world.
For this reason, we found it best to avoid the role of an armchair critic: it is not worthwhile to be the person who simply shoots down ideas without offering alternatives. As a corollary: most critiques should include a proposal for how to accomplish our shared goals in a better way.
The proposal we come up with as a part of this thought exercise does not have to be brilliant; going through that step is beneficial simply because it levels the playing field: it allows the other team to poke holes in your design. This sets the stage for collaboratively iterating on the proposal until the right solution emerges - and until everybody is excited about giving it a try.
Just like any other company, we sometimes deal with big, fundamental disagreements that need to be settled for the good of our business. That said, across the tech industry, we also often get passionate about far less significant things, where one outcome may be a bit better than the other - but ultimately, there are no dire consequences either way.
In such situations, protracted, unending arguments impose a very real tax on our teams. They waste a ton of time and affect the well-being of participants, especially in situations where a single person or a small group of people is on the receiving end of a debate where countless other engineers chip in over and over again.
To build healthy organizations at Snap, we encourage folks to zero in on the problems that truly matter and resolve them swiftly; but we think it’s equally important to know when to let go and move on. Once again, this rule is particularly important for senior folks: we want you to bring your knowledge and wisdom to the job, but you have to leave breathing room for more junior folks to experiment, learn from personal experiences, and grow.
Important disagreements need to be talked through in person first, but when no progress can be made, escalations are the right way to go. When done correctly, escalations are a collaborative tool for highlighting risks to the higher-ups, and for making strategic decisions - such as providing additional funding for neglected projects, or giving up some revenue to do what’s right for the Internet.
The secret of successful escalations is to sit together with the other team and work on a joint problem statement: there must be a broad agreement between you and the product team on the underlying facts, the problem in question, and the potential paths forward. A good escalation captures all that in a concise and accessible way.
Conversely, adversarial escalations - where each team works in isolation to present a vastly different take on the underlying facts and effectively discredit the other - are unlikely to lead to making the right call.
When suggesting paths forward, we like to remind folks to think big: asking to cancel a project or to sign off on a risk is seldom the right approach. Perhaps the solution is to allocate or shift resources; to resolve a policy question; or to commit to a long-term fix that will replace a temporary workaround.
Snap operates in a fast-paced environment. As we navigate ambiguity, we need to be able to take chances boldly and in a principled way. To avoid decision paralysis, we must settle debates quickly - and once a decision is made, we generally need to set personal opinions aside and commit to getting things done as a team. This means not just agreeing to not complain - but treating the path we’ve chosen as your own, and investing in making it successful.
In some cases, our bets will pay off; other times, we will make mistakes. It is important to learn from them - but it is also important to remember that hindsight is always 20/20. It is not constructive to deliver persistent, low-key critiques of other people’s work, to constantly undermine or revisit settled decisions, or to belittle people for believing in ideas that ultimately did not pan out. The only result of such an approach is a company that never takes any risks.
Learn more about Snap engineering values