Meetings are meant to be decisive. They should not get in the way of getting things done.

Everyone at Papercup can expect a monthly one-to-one and showcase, a weekly engineering team check-in, and a 10-minute daily stand-up to make sure everyone’s on the same page. That’s it!

We don’t believe in delaying decisions just because they’re difficult, nor do we want to spend too much time getting everyone up to speed at every meeting. So we ask everyone to show up to meetings well informed and prepared, in order to keep the meetings themselves short.

As engineers, it’s important that we have uninterrupted blocks of flow.

Aside from a weekly sprint-planning and all-hands meeting, we do our best to avoid regular, mandatory meetings. As a company, we have a short (<5-minute) stand-up every morning at 10am but the way we stay in tune with what everyone is working on is through our demos once every other week. Instead of meeting to tell everyone what we’re currently working on, we spend time showing up what we’ve built. Engineers demo their new features, ops showcase their new models, and our provider interaction team shares the new scripts they’ve written. (Show and tell is still exciting as it was when we were younger!) It’s natural to go into a meeting-heavy state, so we are constantly fighting against that and making sure that engineers have the schedules they need to work effectively.

We have two regularly scheduled meetings every month. That’s it.

Our all hands meeting takes place once every 2 weeks. All other meetings are intentionally done ad-hoc. In general, we prefer communicating in Slack and in person. We default to asynchronous communication in Slack or Github issue as a first step. When meetings need to happen we keep them small to the key decision makers and strive to make decisions in the room (not necessarily by consensus, but more often via disagree and commit).

You won’t be stuck in meetings. You’ll be shipping.

We have 3 all-hands stand-up meetings every week, which usually take 20 minutes, but can last up to an hour if an interesting discussion arises. We have weekly sprint planning which take about an hour. Some teams have an additional short stand-up, but each team determines their own process. It’s a great place to work if you enjoy being productive.

Nearly all employees are remote. We have an office in SF, but only one employee is there every day. Our team is scattered across the continental US in SFO, SEA, SLC, NYC, PHL, etc. We communicate through our own messaging platform - Signal - and through video calls and Google hangouts.

We are firm believers in Deep Work.

In order to perform cognitively complex tasks, we believe you need a distraction-free environment. Our engineering and product managers carry the burden of extraneous or tangential meetings, so that you can focus on your craft. Meetings have a clear agenda, and result in clearly owned action items.

Engineering teams have the freedom to independently adopt their own practices. It's up to you and your teammates to decide the environment you want. If you enjoy pair programming, let us know. If you like having more structure - daily standups, retrospectives, sprints, etc., try it out with your team.

By default, we avoid meetings and only schedule them if they’re really necessary.

Having technical founders, our culture of light meetings started from the very beginning. We try to schedule all regularly meetings on Monday and Tuesday to get them out of the way, and we encourage people to leave meetings if they feel like they’re not contributing or getting anything out of them. No one takes offense. In addition to our all-hands every Monday, engineers also have a 1-on-1 with their manager once every other week.

Generally, we prefer asynchronous communication and protecting long blocks of uninterrupted working time for engineers. We encourage folks to turn off Slack notifications when they want to get in the zone. Generally speaking, you shouldn’t Slack someone unless it requires immediate attention, and even then, an ad-hoc meeting is better if something needs to be addressed right away. As far as bug reports and new feature requests, we view PMs as a buffer between users and engineers.

If you often question the number and length of meetings that you attend, you’re not alone!