Method

TFW has one principle: define the topic first, then make the tools reflect that topic consistently. The six steps below apply that principle. Do them in order when you set up a new topic. Use them as a checklist when you review an existing one.

1. Choose the topic.
2. Use the most specific valid topic.
3. Align tool naming across surfaces.
4. Keep hierarchies shallow.
5. Separate conversation from the source of truth.
6. Define participants, access, and maintainers.

Step 1: Choose the topic

Why. Every later decision depends on the topic: the names, the surfaces, the access, and who is accountable. If the topic is unclear, each tool will develop its own structure, and the tools will stop matching each other.

How.

• Identify the venture: the business, organization, client engagement, household, or person the work serves.
• Identify the unit: the functional area of accountability, such as operations, finance, or marketing.
• The topic is that venture combined with that unit. See Topic in the model.
• Check the registry of existing topics. If the topic already exists, use it. Do not create a second topic for the same venture and unit.
• Do not create a new topic only because a piece of work is large, long, or involves several teams. Large work is still work inside a topic.

Step 2: Use the most specific valid topic

Why. Work filed in a broad, general place is hard to find and hard to own. Work filed in the most specific place that is still correct has one clear location.

How.

• Put each piece of work in the most specific valid topic. If work belongs to the operations of one venture, file it in that topic, not in a general topic for the whole venture.
• Give the topic a canonical name made of the venture name and the unit name, for example “Example Co Operations”.
• Give the topic a topic code, for example EXOP. Use the code in every surface name.
• If you cannot match work to exactly one topic, record a registry gap and ask the owner. Do not guess a code or invent a topic.

Step 3: Align tool naming across surfaces

Why. One real thing should not have five slightly different names in five tools. When every surface carries the same code and name, a person or an agent can search for the code and find every surface of the topic.

How.

• Create at most one surface per tool class for the topic. Chat is the exception: it has a chat channel for people and an automated channel for software.
• Use the topic code and the canonical name in each surface name. The tool classes section gives the naming pattern for each class.
• When a tool forces a different name, record it as an alias of the topic. An alias does not create a new topic.
• Keep a topic profile that links to every surface of the topic.

Step 4: Keep hierarchies shallow

Why. Deep folder trees and deeply nested pages are hard to browse, hard to maintain, and hard for automation to read. Most items should be reachable in two or three steps from the top of the surface.

How.

• Let the topic be the top level in each tool. Do not add extra levels above it for grouping.
• Inside a surface, organize by stable subject and lifecycle, not by a temporary task breakdown.
• Before you add a level, check that it helps someone find or review something. If it does not, leave it out.
• Prefer links between surfaces over copies of the same content in several places.

Step 5: Separate conversation from the source of truth

Why. Chat, email, and meetings are good for discussion and coordination. They are poor at keeping decisions, requirements, and procedures findable later. When the only record of a decision is a chat thread, the decision is hard to find after newer messages replace it.

How.

• Decide which tool class is the source of truth for each kind of information. See information placement.
• When a conversation produces a decision, a commitment, a requirement, or a procedure, write it to the source of truth first.
• Then post a short link to that record back in the conversation.
• Link to the source of truth from other places. Do not keep copies, because copies go out of date.

The table below shows the difference.

Step 6: Define participants, access, and maintainers

Why. Every topic carries expectations about who is involved, who can see what, and who keeps each surface correct. If access is granted tool by tool, the tools stop matching each other, and people end up with access to some surfaces of a topic but not others.

How.

• Name the owner of the topic: the one person accountable for it.
• List the participants: contributors, viewers, external participants, and automations.
• Define one access boundary for the topic and apply it to every surface. The simplest way is one group per topic that each tool uses for permissions.
• Record each deliberate exception to the access boundary. Do not grant access only because a person happens to be in one channel.
• Name a maintainer for each surface. The maintainer keeps the name, structure, description, and permissions correct.

The short version

Choose the topic. Name it clearly. Make the tools align to it. Then the structure of the tools shows where things are, and people do not have to remember it.