How our engineering team uses Polish Parties to maintain quality at pace

It’s fair to say that delivering software faster has never been more relevant. But in doing so, it’s easy to let your bar for quality slip.

Often, the guardrail to avoid this is to hire dedicated QA Engineers, whose sole job is to ensure your software works as it should and to spot any issues that arise. Seems sensible, right? Well, at incident.io, we take a different approach.

Instead of having QA engineers, we hire product engineers who care deeply about the quality of their work and take responsibility for ensuring that our product functions well.

Every product engineer is tasked with not only building the product but also paying close attention to the things that are broken or don't feel quite right; we’re not just identifying errors but also creating a product experience that feels world-class.

In the end, we’ve established a culture where everyone has an eye for detail, takes pride in their work, and is invested in the overall success of the product and the wider company.

So what’s the secret recipe that drives this culture? In a company that moves fast, you can’t delegate quality to a few individuals, it has to be everyone’s responsibility. Polish Parties are one of the tools that help us maintain our quality of work.

What's a Polish Party?

Polish Parties are meetings we run towards the end of a project, where we get feedback on our work from people who weren’t part of building it.

For these sessions, aside from the project team, we usually invite folks from the rest of the organization: from our engineering and product managers to our designer. If it’s a bigger project, we also like to invite engineers from other teams and stakeholders outside of the product team.

You've seen the same screens and gone through the same workflows so often that you might not notice a minor flaw or a user experience hiccup. And with all the context you’ve gained in building it, it’s easy to lose your ability to empathize with a first-time user.

By involving more people, both within and sometimes outside the team, we get fresh eyes on the product and valuable insights into how we can make it better.

These meetings also provide an explicit space where everyone feels comfortable pointing out the tiny things that may seem insignificant but could make our software even better.

However, nitpicking requires a lot of trust and the right approach. We’re all there to make the product better, not disparage everyone’s hard work. At incident.io, we call this attacking the idea, not the person, and it’s critical to avoid this to ensure Polish Parties remain healthy.

These minute details might be the difference between a good product and a great one, and we embrace them to make our software as good as it can be.

How do we make sure we run great Polish Parties?

Scheduling a calendar event is one thing, but running a successful Polish Party takes a bit of preparation.

Already identified a problem? Fix it beforehand!

The first step to running a great Polish Party is to make sure that the feedback you receive will be helpful.

For that to happen, you shouldn’t leave things you’re already unhappy with; if you think it’s a big problem, odds are so will others. When this happens, try to be proactive about fixing any known issues beforehand. Sometimes, that can mean delaying a bit and that’s totally fine.

This doesn’t mean everything has to be perfect; you don’t have to love what you built yet, but you also shouldn’t hate it.

Invite the right people

To run a Polish Party, you need people. But depending on the size of your project, you may want to have more or fewer people.

As I said earlier, typically, we’ll always invite the team the project is part of, including the engineering and product managers and designers; for smaller projects, that tends to be it.

In a larger project, we’re likely to invite engineers from other teams, as well as folks from other departments who we think might have a good pulse on what would delight customers.

Come prepared

If you’re the product engineer building a feature, the Polish Party starts before the calendar event. It doesn’t take much to be prepared, but spending 30 minutes beforehand can make the difference between feedback that is just fine and something productive.

Some things to think about ahead of time could be:

• What you want to demo
• Small details that you’re not quite sure about

When you plan your demo, don’t forget to consider edge cases that customers might reasonably run into and show what that looks like.

Common ones to look out for are upsell flows, which tell users about plan limits and incentivize upgrades, and first-time use, which is often about going through what the empty states look like.

Running the meeting

Assuming all of the prep work is done, running the Polish Party is the easy bit!

It’s a collaborative session where you’ll run through key flows and get feedback from everyone attending.

One thing you should always do at the beginning is to assign a notetaker who isn’t yourself. It’s really hard to effectively take notes, demo, and listen to feedback all at once. As a project member, your focus should be interacting with the other people at the Polish Party actively, not being a notetaker.

Speaking of interaction, it plays a critical role here.

These are not one-sided affairs where project members passively ingest feedback and go implement it after. Instead, it’s often worthwhile thinking about the feedback for a moment, and if you think it could be even better, have a quick chat in the meeting to agree on the best solution.

Sometimes, the feedback might not feel actionable, and that’s fine, too. In running a Polish Party, you should expect people not just to voice obvious problems but also to flag when something just feels off.

Those usually won’t be resolved live. Instead, we’ll often follow up with our designer afterward to figure out how we can make something feel less awkward.

Implementing feedback

After the Polish Party, we create tickets representing all of our action items. We like to create one ticket per ‘product surface,’ as it tends to be more efficient to do a chunk of work rather than have a bunch of small individual tickets like “change this word.”

When writing the tickets, we also like to be clear on which issues need to be addressed before release and which can be done immediately after as ”fast-follows.” This lets the team address the most critical feedback first and release it before everything is 100% polished while still ensuring it gets done.

Bonus: being a great participant

Polish Parties are effective because they pull in people outside the project. Because of this, it’s important to also be a great participant when you’re invited to one. Here’s some ways you can do that:

• Be familiar with the project. You don’t need to know the ins and outs but know enough about what the project is trying to solve so that you can give effective feedback
• Be to the point and succinct in your feedback, and always focus on the work, not the person behind it
• Sweat the details. Polish Parties exist because the project members might get used to the small hiccups, and they need you to say, “that feels weird to me”
• Close your laptop and pay attention. You can’t pick up on the details if you’re on Slack or checking emails at the same time!

Lastly, remember that Polish Parties are about your opinion, not objective truth. You don’t have to be correct, and subjective feedback can be beneficial. If you find something confusing, even if you don’t know how to solve it, it’s likely at least one customer will, too.

Polish Parties: they’re all about trust

It’s fair to say that Polish Parties have played a massive role in defining the product you see today. But there’s one very important caveat that I have to leave you with.

So if you’re unsure if this is the case for you, take some time to diagnose the issue before adding Polish Parties to your workflow.

It’s better to iron these things out beforehand to better your chances of a productive working session.