How we run fully-remote at SUFFIX: the three systems that actually matter

Why most remote setups fail (and how ours started)

Most remote-work setups we see fail for the same three reasons. Tool sprawl fragments context across five different apps. Status reporting is ambiguous enough that nobody actually knows what's blocked. And meetings replicate the office pattern (too many, too long, too much status theater) instead of using async well.

We went fully remote earlier than most organizations in our market. Our neighborhood happened to be an early hotspot during the COVID-19 outbreak, and our team shifted to 100% Work from Home before it was a choice. What started as a forced adjustment became the permanent operating model, because once we figured out the three systems below, the cost of going back to an office outweighed the benefit.

This article covers the internal team side: how we coordinate work between ourselves. A separate article covers how we run client-facing operations remotely.

System 1: One tool for communication, not six

Most remote teams we meet run on a stack of four to six tools: one for chat, one for project tracking, one for docs, one for meeting notes, one for file storage, one for calendar. Each tool is fine in isolation. The problem is that a single conversation often spans three of them, and after a week nobody can find where the decision was made.

We run the bulk of our internal communication through Basecamp. Over the years we've tried Slack, Teamwork, and other mainstream options. Basecamp won because it consolidates the things a remote team actually needs:

- Direct chat and group chat
- Separated workspaces per team and per project (we have four internal teams: coordination, marketing, design, and development, across multiple active projects)
- Message boards for decisions and context that need to live longer than a chat thread
- Scheduling for meetings and deadlines

The specific tool matters less than the consolidation principle. Notion, Slack with structured workspaces, or ClickUp can support the same pattern if set up deliberately. What matters is that the team isn't jumping between tools to reconstruct a conversation, and that context doesn't die when a chat scrolls out of the window.

Rule of thumb we use: if a new teammate needs to check three different tools to understand what's happening on a project, the communication setup is fragmenting. Fix that before fixing anything else.

System 2: The daily status format

The purpose of daily status is simple: make it unambiguous what each person is working on, whether it's done, and whether they're blocked. We use two short messages per day in Basecamp: one at the start, one at the end.

Start of day
Work from home DD/MM/YY
Project
- Task

Example:
Work from home 16/03/26
SUFFIX
- Design Landing Page

End of day
Same format, with a status tag prepended to each task:
Work from home 16/03/26
SUFFIX
[Struck] Design Landing Page

Three possible statuses:
[Done] The task is finished.
[In-Progress] The task is underway, carrying over to the next day.
[Struck] The task is blocked. Someone needs to unblock it.

When a teammate posts [Struck], it triggers a predictable response: someone from the team jumps in via chat or an @‌mention to help resolve the blocker. That's not a policy. It's how the team has been trained to read the status.

Why status codes, not percentages

Early on, we tried percentage-based progress reporting. It didn't work, for two reasons.

First, percentages are subjective. "80% done" in one person's head means "almost finished, probably today." In another person's head it means "the hard 20% is still ahead of me, maybe another three days." Two teammates reporting the same number describe different realities.

Second, percentages don't encode an expected response. "80% done" gives the reader nothing to do.
[Struck] does: help.
[In-Progress] also does: don't interrupt, expect it to continue tomorrow.
[Done]: check it off.

The status system works because each code tells the team not just where the work is, but what to do about it. The three statuses cover the three decisions the team actually needs to make. Anything more complex gets subjective again.

System 3: Weekly team-based meetings, not project-based

Every week, each internal team runs a single 45 to 60 minute meeting on Google Meet, cameras on. The schedule in 2026:

- Monday: Coordination team
- Tuesday: Digital Product team
- Wednesday: Digital Marketing team

The content is project updates from everyone on the team, plus problems surfaced during the week and proposed solutions. Anything worth remembering gets written into the company WIKI so future teammates can reference it.

The non-obvious choice here is that meetings are organized by team (discipline), not by project.

Most organizations default to project-based meetings: the marketing project meets on Tuesday, the e-commerce project meets on Wednesday, and so on. That format is natural because projects have deadlines and stakeholders, and meetings are how you update those stakeholders. But it optimizes the wrong thing. Project-based meetings produce status theater: each person explains to the project manager what they did, and leaves without learning anything that will make them better at their job.

Team-based meetings optimize for skill transfer across projects. When the design team meets, designers from four different projects share what they ran into that week. The designer working on a landing page hears how the designer working on a mobile app handled a similar interaction problem two projects ago. Over a year, that pattern compounds into a team that's substantially better at its craft, because the knowledge isn't locked inside individual projects.

Project coordination still happens. It just doesn't happen in the weekly meeting. It happens async in Basecamp, in short project-specific syncs when needed, and in written handoffs.

The WIKI: external memory for the team

Weekly meetings surface insights. The WIKI captures them. The pattern is simple: when a problem gets solved in a team meeting, whoever solved it writes up the approach in the WIKI that week. Future teammates search the WIKI before asking the team, and the same problem doesn't burn two people's attention twice.

We use a structured internal knowledge base. Notion, Confluence, Coda, or Dropbox Paper can all serve the same function, as long as search works and the team has the habit of writing things down.

The underlying argument: without an external memory, knowledge lives in individual people's heads. When those people are off sick, on vacation, or eventually move on, the knowledge goes with them. For a remote team especially (where you can't overhear colleagues solving problems), the WIKI is how the organization actually retains what it learns.

A tactical note: writing into the WIKI should be part of the workflow, not a separate "documentation project" that happens at quarter-end. The insight is fresh when the work is fresh. Writing it down later usually doesn't happen.

Leave management still matters in remote

Even with no physical office to walk into, the team still needs to know who's available. We use Calamari to manage leave requests (vacation, sick days, vaccination days, personal time). Common alternatives include BambooHR, Rippling, and other HR platforms that cover the same use case.

The point isn't the tool. It's that availability information needs to be visible. When you can't see someone at a desk, an updated leave calendar is the proxy. Without it, people either assume a teammate is available (and get frustrated when they don't respond) or assume they're not (and wait unnecessarily).

What remote teams usually get wrong

From what we see across our client work and our own experience, remote teams tend to fail in one of two directions.

Office workflow over video: The team runs too many meetings, schedules them back-to-back, and expects synchronous response throughout the day. This replicates the worst parts of office life (constant interruption, meeting fatigue) without the upside (hallway conversations, shared physical context). A calendar full of recurring meetings isn't a remote-work strategy. It's an office with cameras.

Structure abandonment: The opposite failure mode. The team drops all process, assumes Slack will handle everything, and ends up with important decisions buried in chat, no accountability, and nobody sure what anyone is working on. Status updates disappear. Meetings stop happening. Then six weeks later, a deadline slips and nobody saw it coming.

The middle path is async-first communication with documented workflow, minimal but scheduled meetings, and clear status rituals. Remote work done well is more structured than office work, not less. The structure is what replaces the ambient information an office provides.

The core takeaway

Remote work becomes effective when the team shares a workflow everyone understands, not just when the team has good tools. The tools support the workflow. The workflow does the actual work.

Most of what makes coordination possible (who's working on what, who's stuck, what decisions got made) can be handled well through digital tools and platforms. The one thing that can't is transparent team culture: people surfacing problems honestly, asking for help without friction, writing things down for the next person. That has to be built deliberately, and it holds up even when the tools change.