High performing teams develop habits that make working together easier. Much like professional sports teams that practice the same drills and situations over and over such that they do not have to stop and decide how to respond each time. They know their role, what their teammates will do and what happens next. We want the same predictability in how we work together.

Developing and agreeing on these work habits are especially important with distributed teams - which is now the norm. This playbook covers practical details within the broader idea behind Systems Create Freedom.

The goal is not more process. It is to reduce the number of things we have to manage in our heads so we do not wonder who owns something, whether a request was received, what came out of a meeting, where a decision was recorded or what happens next.

These are not meant to be rigid rules for every situation. They are the foundation that team members can rely on from one another.

<TLDR>

• As a world-class hospitality company we:

• Are enthusiastic. It is actually part of the job.
• Practice empathy at every level, what is good for people is also good for this business

• E.g. Eric just woke up and is being blindsided with paradigm-shifting concepts and questions
• E.g. Dan wakes up to a dozen emails and dozens of text messages with no indication of priority, hijacking his morning (or backlogging inbox, or missing something)
• E.g. Roxanne and Anna have been doing critical work in a foreign language all day
• E.g. A guest is jet lagged, nervous, or hungry
• E.g. A family is at its wit’s end with each other from a complex travel day and needs space or levity
• E.g. A contractor/team member arrives to conditions other than expected, needs an opportunity reset expectations

• Listen openly and actively work to understand people's experience and perspective. Avoid defensiveness, No waiting to talk. No monologuing. 
• Drive a culture of trust, support and accountability (the latter does not exist without the former)
• Understand that not everything valuable looks efficient

• Ideating and flexing creative muscles, even when there is work to do, is important and can help lead to greatness. It cannot replace completing tasks, but cannot be eliminated altogether.

• It’s okay to say I am not in a place to brainstorm, but it is counter productive to put out someone else's fire

• Projects & Tasks

• Big Rocks

• Organize and align priorities in a constructive and focused manner, while leaving room for the adaptive nature of hospitality and farming
• Have clear outcomes and benchmarks, when appropriate

• All Rocks have a short overview that describes what success/completion looks like and how progress can be measured and communicated.  

• When appropriate: Leadership team buy-in on this description & quantifiable / funnel based (not a requirement, only if appropriate)

• Single owner that intimately knows project details even if someone else is doing the work.
• Updates shared in BLUF format
• Works proactively and raises risks before they become issues
• Be deliberate w/ sprints and rest/maintenance period to optimize performance and avoid burnout.  There will always be a never-ending list of things to do.

• Meetings

• The meeting owner takes a beat to prepare for meetings
• Agenda sent on a consistent schedule with topics, owners and labeled outcomes (Decision Needed, Proposal, Brainstorm, Alignment, Problem Solve, Review w/Feedback or Plan w/Commit

• Task owners are typically responsible for capturing their required outcomes outside of meeting notes (unless otherwise specified)

• The owner runs a tight meeting, calls out off topic discussion to move to the parking lot - discuss if time permits.
• Meeting notes aren’t enough - tasks created or updated, owners and dates clarified and notified, and decisions reflected in the playbooks, plans or other tools where the work actually lives.

• Collaboration

• Set aggressive goals, make credible commitments
• Take the next step whenever possible
• Share and recognize small wins along the way
• Writing things down gives team members context and keeps us from having to reconstruct the thinking later from conversations, email threads or memory.

Project Ownership

Owning a project means proactively driving it to completion. The owner needs to understand the details, monitor progress, follow up with the people involved and keep the work moving.

That remains true when someone else is doing most of the work. A contractor, vendor or another team member may be responsible for a particular piece, but the project owner still needs to understand what is happening, review important work, follow up when needed and anticipate where something could get stuck. The owner does not need to do every part of the work, but someone should understand the whole, keep the relevant information current and be responsible for getting the outcome to a conclusion.

Clear ownership creates autonomy. If we agree on the outcome and know who owns it, that person has the freedom to determine the work required and pull in the people or resources they need.

Ownership ends when the work is complete, clearly handed off or deliberately stopped.

Outcome Focus

Before starting work, we should be clear about the outcome we are trying to create. Completing a task is not the same as producing a result. A useful question is what should be different when this work is done.

When the outcome can be measured, use the fewest useful measures and track them over time. The point is not to create more reporting. It is to know whether the work is producing the result we intended and to notice early when it is not.

Outcomes often change as the project progresses and we learn more. When this happens the owner updates the stakeholders proactively with the why and what the new goals are.

Shrinking the Gaps

Being small gives teams the ability to move quickly. A simple way to increase the pace and momentum of working together comes from reducing time gaps between steps. Send the document when it is ready instead of waiting for the next meeting. Make the call when you are thinking about it. Respond to the vendor to keep things moving. Update the plan as decisions are made.

Pay attention to the cost of creating work around the work. Often it’s faster to handle something than to write a task, assign it, pick it up later, refresh on the context and then do it. None of these actions is especially significant on its own, but together they keep work moving. If the action takes less then <3 minutes, do it now.

Not all tasks can be done this way, we’d never get any deep work done. It’s a balancing act of understanding what can be done efficiently in the moment - and what needs to be scheduled and focused on.

Having team members in different time zones adds complexity, but it also offers an opportunity for momentum. Work can be handed off at the end of one person's day so someone in another time zone can pick it up.

Tasks

A task should have a clear owner and a next step. When timing matters, it should also have a date. When the work changes, the task should change with it, and when ownership changes, that should be clear.

When a discussion resolves an issue, we should decide what happens next before moving on. Tasks that sit without a next step or date tend to turn into reminders of old conversations. Weeks later, someone has to rediscover the context and decide whether the task still matters.

We also do not need to create active tasks for everything we may want to do someday. There will always be more ideas than we have time to pursue. If nobody has time to work on something yet, it can stay on a future list until we are ready to act on it.

Commitments

We want a high say/do ratio. That means being careful about what we commit to and then doing what we said we would do.

For a small team, missed commitments have a larger effect than they might appear to. Other work may depend on them. Someone else may need to follow up, rearrange their work, reschedule a decision or solve something at the last minute.

If it looks like a commitment or due date may slip, let the team know before it is missed. An early heads-up gives other people time to help, adjust dependent work, change the plan or find another path while there are still good options. If a due date is no longer realistic, update it and explain what changed. If another task depends on it, talk to that owner rather than letting the delay surface later.

The goal is to surface problems while there is still time to do something about them, not after they have already become problems. Predictability makes it easier for everyone else to plan their work.

Working Ahead

We think beyond the immediate task and ask ourselves what could delay the work, what will others need from us, what decisions are needed, what information is missing, what is likely to become urgent if we get delayed and what we can prepare now that will make the next step easier.

This becomes especially important when outside people are doing work for us. We can trust someone to do their job while still understanding the details, checking important work and helping remove obstacles before they become problems. The same habit applies to guests. If we know a family is arriving after a long overnight flight, for example, we should be thinking about food, room readiness, luggage and what they will need before they reach the gate, not after.

Team Collaboration

Taking the Next Step

Whenever possible we take the next useful step rather than simply passing information along. This builds momentum. If research answers a question, turn the answer into a recommendation. If we make a decision, update the plan. If we learn something that belongs in a playbook, add it. If we identify something a guest will need to know, put it in the guest guide. If we see an error and know the answer, we fix it and share the update instead of only pointing it out.

Comments, questions and feedback are useful, but they often leave the next piece of work for someone else. When we can reasonably move the work forward ourselves, we should.

Small Wins & Sharing Progress

Large projects can make progress hard to see. A lot may be happening even when nothing feels completely finished. The Harvard Business Review article The Power of Small Wins helped put a name to this: small, meaningful advances create momentum, reinforce progress, and give the team something to build on.

Small wins are meaningful milestones on the way to something bigger. They help us recognize what has moved forward, celebrate progress along the way, and keep everyone connected to the larger goal.

The important distinction is that a small win represents movement toward an outcome, not simply time or effort spent.

For example, “work on journalist outreach targets” describes an activity. “Send the first ten personalized introductions” describes progress. Ten journalists have now been contacted, responses can begin, and the project has moved forward.

Thinking in terms of small wins helps us:

• make progress visible
• create clear ownership and a shared definition of “done”
• keep attention on the work that matters most
• build momentum as larger projects move forward
• recognize and celebrate meaningful progress along the way

The goal is not to divide work into tiny tasks so we have more boxes to check. It is to identify the meaningful milestones that move the outcome forward and pause and celebrate for a moment when we complete one.

Answering Questions About Work

A long explanation before the answer creates work for the person asking. Give the conclusion first, then the few facts that matter.  This is also known as BLUF - bottom line up front.

If the answer can be yes, no, a number, a date, a recommendation or "I don't know yet," start there. Add context if asked after the answer - we often overestimate how much explanation is wanted.

Documenting the Work

Ideas and discussion are useful when we are brainstorming or solving a difficult problem. Most of the time, though, work is easier to build on and use when it takes a concrete form. That might be a document, spreadsheet, recommendation, budget, plan, mockup, piece of code, training material or an update to an existing playbook. It does not need to be elaborate, often a short written recommendation with some background information is enough.

If a decision changes the plan, update the plan. If the budget changes, update the budget. If we learn something that should affect how we operate, update the playbook. If a meeting changes a task, update the task. Email, messages and comments are useful for communication, but they are not a good permanent record of a project. Writing things down makes it easier for other people to react to the same information and keeps us from having to reconstruct the thinking later from conversations, email threads or memory. A useful test is whether someone joining the project later could understand its current state without reconstructing how we got there.

This is an example of taking the next step.

One Source of Truth

Writing things down only works if people know where to find the current version. One source of truth does not mean one software application for the entire company. It means having an authoritative home for each important type of information.

Guest information belongs in the guest record. Maintenance work belongs in the system where maintenance is managed. A finalized operating standard belongs in the playbook. A project task belongs in the project system. A booking belongs in the property management system. Once we decide where something belongs, we should keep the current information there.

Otherwise the team pays a search tax. Did we ever decide this? Who was handling that? Where is the latest version? Was that in email or messages? Did someone already tell the guest? Each of those questions is a small piece of friction we can avoid.

Showing the Work

When we make a recommendation, especially one that asks the team to spend money, invest meaningful time or change direction, we include enough context for someone else to understand why. The person making the recommendation is closest to the work. They have had the conversations, seen the numbers, compared options and accumulated context over time. Other people have not, or may only vaguely remember the earlier discussion.

Showing the work does not mean documenting every step. It means sharing a summary of the facts, conversations, tradeoffs or findings that materially support the recommendation. If we recommend adding an employee, for example, include the rationale, the budget impact - and explain why it works, compensation data, etc. That gives the team something concrete to evaluate rather than asking them to react only to the conclusion.

This is especially useful when the recommendation requires money, meaningful time, a change in plan or a decision that will be hard to reverse. A good recommendation should make it possible for someone who was not close to the work to understand the conclusion and challenge it intelligently.

Meetings

Meetings have a simple agenda or list of topics in advance. The meeting owner reviews prior meeting notes and shares the agenda and materials at least a day in advance (especially when teams are across time zones) so people have time to review and prepare.

It helps to label agenda items by what is needed from the topic rather than simply by subject. Depending on the meeting, that may be Decision Needed, Proposal, Brainstorm, Alignment, Problem Solve, Review / Feedback or Plan / Commit. Pure updates or FYIs generally happen outside the meeting.

We try to reserve meeting time for work that benefits from being live: decisions with real tradeoffs, disagreements that need to be worked through, ambiguity that requires back-and-forth, brainstorming and alignment. Status updates and one-way information sharing generally belong in writing. If the outcome would be the same without the live conversation, we probably do not need a meeting for it.

During the meeting, the meeting owner or a delegate captures decisions, open questions and commitments. We also try to notice when a progress or planning meeting turns into a problem-solving session. Sometimes that discussion is worth having immediately. Other times it is better to identify the issue, decide who needs to be involved and handle it separately.

When a discussion takes a life of its own, a few questions are often useful: Are we drifting? Are we ready to decide? Who owns this? What's the next step? Are we reopening something without new information? What is needed to unblock this?

A meeting is not finished when the group leaves. Decisions need to be recorded, tasks created or updated, owners and dates clarified, and changes reflected in the playbooks, plans or other tools where the work actually lives. Let the group know when they will see those updates. Otherwise the result of the meeting depends on what each person remembers. Doing this predictably builds trust and keeps things from falling through the cracks.

Acknowledging Requests

When someone sends a request, question or handoff that needs attention, we acknowledge it. The answer does not always need to come immediately. A quick response that confirms it was seen and says when it will be handled is often enough.

Without that acknowledgement, the sender has to wonder whether it was received. That leads to searching, following up, mentioning it in a meeting or trying another channel. We will all miss things occasionally, but people should not normally have to follow up just to find out whether we saw something.

Keep a Future Idea Parking Lot

There will always be more ideas than we have time to pursue. We capture ideas in a “future” list that prevents every idea from becoming current work.

Brainstorming has a place, and so does deeper problem solving, but much of the time the most useful thing we can do is stay focused and finish what is already underway.

When these habits are working, the team spends less time managing the work and more time doing it. We know what we own, what happens next and what we can expect from each other.

Retrospectives

When something important misses a deadline, goes wrong or produces a result we did not expect, along with early notification to the team - we should take a short retrospective. The goal is not to assign blame or create a process around every mistake. It is to understand what happened, what we learned and whether anything should change.

A useful retrospective ends with action. If the lesson changes a plan, process, standard or assumption, update the place where that change belongs. Otherwise the lesson remains a conversation and the same problem is easier to repeat.