How to Write a "How We Work" Guide (Free Template)

You've seen it happen. A new hire joins, brings their habits from the last job, and starts booking 30-minute syncs for things that could've been a Slack message. Nobody corrects them, because your company never wrote down what "normal" looks like.

A "how we work" guide is a document that sets your operating norms: how you run meetings, how tasks get assigned, how people communicate, and how decisions get made. Not an employee handbook. Not a policy document. It's the answer to the question every new hire silently asks on day one: "How do things actually work here?"

This post covers what belongs in one, why most companies skip the most important section, and how to get it done. The free template is at the bottom.

The Free "How We Work" Template

If you're here for the template, here it is.

[Download the free "How We Work" template]

It covers all six core sections: task clarity, calendar norms, meeting standards, communication defaults, feedback culture, and urgent request handling. Placeholder text throughout, so you can adapt it in under an hour.

The rest of this post explains what goes in each section and why it matters.

Why Not Having One Is Expensive

Writing a "how we work" guide feels like overhead. You're busy. The team is smart. They'll figure it out.

Here's what happens when they do: everyone defaults to the norms from their last job. Some of those norms involve booking meetings for everything. Others involve never saying no to a calendar invite. Without a written standard, every person brings a different operating system, and those systems collide.

The result is meeting overload that no one explicitly chose. At 150+ person companies, the average knowledge worker spends 15–25 hours per week in meetings. A large share of those meetings exist because no one ever said meetings were optional.

A "how we work" guide doesn't fix all of that. But it sets the default. Defaults matter more than rules.

What to Include

The best guides are short, opinionated, and practical. They don't cover everything. They cover the things that, if misaligned, create the most friction.

1. Task clarity: three questions before you start

Before anyone works on a task, or assigns one, three questions should have answers: What is the value of this task? What does "done" look like? Who owns it?

These sound obvious. They rarely get asked. The result is work that gets finished but not useful, or useful but not finished. Writing this norm down signals: we don't start things we don't understand.

2. Calendar and availability norms

How people manage their calendars is a proxy for how they treat other people's time. Set explicit expectations: accept or decline invites promptly, block focus time, mark absences with dates, build 10–15 minute buffers between meetings.

On rescheduling: once is fine, twice is worth questioning, three times is not acceptable. Writing this down prevents the slow drift toward calendars that are permanently negotiable.

3. When to meet, and when not to

This is the most important section in the guide and the one most companies skip.

Meetings are for decisions that need live discussion and alignment that requires back-and-forth. They are not for status updates, information delivery, or announcements that could be written down.

If your guide has one sentence, make it this: "Before scheduling a meeting, ask whether this could be an async message or a shared document instead."

When you do meet: every meeting needs an agenda sent in advance and someone responsible for keeping it on track. Every meeting ends with an action, an owner, and a due date. Without those, a meeting is just a conversation with a calendar block.

4. Communication defaults

How fast should people respond to Slack? What's the difference between "urgent" and "I just thought of this"? Who gets looped in on what?

Most communication friction comes from mismatched expectations, not bad intentions. Write down your defaults (response times, channels, escalation paths) and that friction disappears before it starts.

One norm worth stating explicitly: the speaker owns clarity. If a message is misunderstood, the default is that it wasn't communicated clearly enough, not that the reader wasn't paying attention. That shift alone changes how people write messages and how teams handle misalignment.

5. How to give feedback

Feedback without a direction is a complaint. Useful feedback names the problem, explains why it's a problem, and suggests what to do differently, even if the suggestion is rough.

One principle worth including: assume good intent. When something goes wrong, start from the assumption that someone made an error, not a deliberate choice to fail. It's not naive. It's a practical default that keeps feedback conversations productive instead of defensive.

6. How to raise urgent requests

Every ASAP request disrupts someone's plan. That's sometimes necessary. But it comes with a responsibility: explain why it's urgent and acknowledge the disruption, even if the urgency wasn't your fault.

This one norm, apologizing when you ask for urgent work, has an outsized effect on how a team treats each other's time. It signals: I know this is a cost. I'm not pretending otherwise.

The Section Most Companies Forget: Goals

A surprising amount of meeting time goes to work that's unclear, misaligned, or has drifted from its original purpose. A shared format for writing goals prevents much of this.

A useful starting point: "I will [objective] as measured by [key results]." The objective is directional. The key results are specific enough that anyone can tell whether they've been achieved.

"Improve meeting culture" is not a key result. "Reduce average meeting hours per person from 18 to 12 per week by end of quarter" is.

How Spry Helps You See If It's Working

A "how we work" guide sets the intention. Spry shows you whether the team is living it.

Once you've written your norms (meetings only when necessary, focus time protected, clear task ownership), Spry's calendar analytics show what's happening across your team: how many hours are going to meetings, which recurring meetings carry the highest cost, where deep work is getting fragmented. Week over week.

The guide gives people a direction. Spry gives managers the data to see if the team is moving in it.

[See your team's meeting load → Request access to Spry]

FAQs

How long should a "how we work" guide be?

Short enough to read in one sitting: five to eight pages at most. The goal is to set defaults, not document every edge case. If it's longer, it won't get read. Cover the norms that, if misaligned, create the most friction and leave the rest for team-specific documentation.

Who should own the "how we work" guide?

Typically the COO, Head of People, or a founder: whoever is responsible for how the company runs day to day. Assign one owner and a review schedule; once or twice a year is enough for most teams. Ownership matters because the guide needs to update when norms change.

Should the guide be the same for every team?

The core should be consistent: meeting norms, communication defaults, task clarity. Team-specific norms (engineering deployment standards, design review processes) live in separate documents that link to the core guide. Keep the "how we work" guide as the shared foundation, not a catch-all for every team's working preferences.

What's the difference between a "how we work" guide and an employee handbook?

A handbook covers policies: benefits, leave, conduct, legal requirements. A "how we work" guide covers operating norms: how decisions get made, how meetings run, how people communicate. Both matter; neither replaces the other. The handbook is for HR. The guide is for day-to-day collaboration.