Dream Teammate

Notes on building teams that last

Next step

Bring us the team story you keep telling at the end of a shift

Every setting on this page started as a tip from someone who worked there. If you run a workshop, a kitchen, a studio, a club, a small production company, or a cooperative, and your crew solved something worth writing down, send it over. We read everything, and we answer.

What helps us most

  • The trade and the city or town
  • The problem your team actually faced
  • Who disagreed, and how it got settled

Not sure it fits? Start with a short note and we will tell you honestly. You can also read how a full story comes together on our home page.

Why readers stay

What you actually get out of these pages

Every setting we cover has its own way of handling trust, handoffs, and the awkward conversations nobody puts in a job description. Here is what that reporting gives you, whether you run a crew or are trying to join one.

Dream Teammate use cases

Long interviews, not summaries

A foreman and two apprentices talk through who signs off on a finished piece, and where that argument actually started. You hear the whole exchange, not the tidy version.

Project diaries as they unfold

A kitchen rebuilds its shift schedule after a menu change. We follow the first two weeks, including the nights it clearly did not work.

Three trades, one problem

Our fixed column puts the same concrete crisis in front of three people from the same field. They rarely agree, and the disagreement is the useful part.

Columns from both sides of hiring

People who bring others onto a team write next to people looking for a first job. Same situation, two very different accounts of it.

Cooperatives and small crews

How members vote on sharing surplus, and what a neighborhood club learns the first time it pays one person to coordinate the rest.

Practical guides for Caribbean projects

Shorter pieces for tourism and food teams, written for readers who need something they can apply on the next shift rather than next quarter.

Curious how we choose what to report? Read our editorial approach or send us a team story.

Visual highlights

The rooms where a team actually gets tested

Six settings keep coming back in our reporting. Each one has its own way of handling trust, handoffs, and the moment two people disagree about what finished work looks like. These are the frames we keep returning to.

Dream Teammate use cases

Workshops

Who signs off on the finished piece

A foreman and two apprentices negotiate the last ten minutes of every job. The argument is rarely about skill; it is about who gets to say the work is done.

Kitchens

Rebuilding a shift after the menu changes

A head chef and the prep team redraw the schedule when a dish is swapped out. Someone loses their preferred station, and the shift has to keep running that same night.

Design studios

Three freelancers, one shared byline

Shared work means shared names, and the order matters more than anyone admits. We sit in on the conversation about who is listed first.

Neighborhood clubs

Rotating duties when attendance drops

Volunteers carry the club until they stop showing up. The board then has to decide what gets cut and who takes over the tasks nobody wants.

Small production companies

Agreeing on realistic shoot days

A producer and the crew argue over how many setups fit into a day. The estimate on paper and the estimate on set are two different numbers.

Cooperatives

Voting on how surplus gets shared

Members decide together how shared resources are allocated at the end of the year. The vote is calm; the months before it are not.

Clarifications

How we read these cases

A use case is a situation, not a promise. What follows explains the terms we use across this page so nothing gets stretched further than the reporting allows.

Setting versus sector

A workshop, a kitchen, or a club is a setting: a place with its own routine and vocabulary. It is not a stand-in for an entire industry. Two kitchens can share a stove and disagree on everything else.

Reported, not invented

Every case on this page comes from people who were in the room when the problem happened. Where a detail could not be confirmed, we say so in the piece instead of filling the gap.

One problem, one account

Each case describes a single concrete problem and how a team handled it. It is not a template to copy. A solution that worked on a Tuesday shift may fail on a Saturday, and we leave that tension in.

Names and details

Some contributors ask to be identified by first name only, or to have a workplace left unnamed. We honor that. It does not change the facts of the case, only how much of it we print.

Editions and language

Cases are published in the main edition and, where relevant, adapted for the Caribbean edition. The adaptation shortens the piece and adjusts context; it does not change what the team actually did.

What a case is not

It is not advice, a ranking, or an endorsement of any method. We document what happened, including the parts the team would rather have handled differently.

Cookie settings

We use a small site preference to remember your cookie choice and keep the experience consistent. You can accept, reject, or review the settings before continuing.