Label

Once a team starts registering work one item at a time, the list reaches several hundred rows fast. Creating items is easy; finding them is not. When the CEO asks how many billing problems came up last quarter, the person answering has no option but to scroll the whole list, and the number they come back with is a guess that nobody can check.

Searching by title is the obvious first attempt, and it doesn't hold up. One person writes "payment," another writes "subscription," a third writes "card." Search all three and you still miss the one somebody filed as "billing." The structure asks the person searching to guess the word the person filing happened to choose, which makes an exact count impossible.

Folders run into a different wall. An item lives in exactly one folder, but a payment error that only happens on mobile belongs in the mobile folder and the payment folder equally. Pick one and the item vanishes from the other count, and the choice is usually made in a hurry by whoever filed it.

Labels solve both at once. The team fixes the vocabulary in advance and people pick from it rather than typing their own word, which removes the spelling drift; and an item can carry several labels, which lets one item sit in several categories the way it actually does.

Three actions cover all of it: attach, filter, count.

1. Attach. One item can carry several labels. A payment error on mobile gets both billing and mobile. This is where labels differ from workflow status or assignee, which hold one value each. An item cannot be in progress and done at the same time, but labels are allowed to overlap.
2. Filter. Turn on billing and the list narrows to those items; turn on billing and mobile together and only items carrying both remain. On a kanban board, where work sits in columns by stage, filtering by label shows which column that subject is piling up in.
3. Count. How many items carried the billing label last quarter, and how many of those are still open, comes back immediately — nineteen filed, four still open, say. The question that couldn't be answered at the start gets its answer here, and it gets the same answer no matter who runs the filter.

Keeping those three working means maintaining the list itself. Anyone can create a label at any time, so left alone the set grows. Once billing, payments, and payment all exist separately, counting by any one of them gives a wrong number.

• Prefix names with their category. Writing area/billing, area/mobile, type/bug keeps the list sorted and makes the groupings visible.
• Decide who creates new ones. Even if creation stays open to everyone, one person sweeps the list once a quarter and merges near-duplicates.
• Keep the total under about thirty. Past that, people stop reading the list, pick whatever sits near the top, and eventually attach nothing at all.

The same device appears in several tools under slightly different names.

Issue trackers are the most common home. An issue is the shared record unit for tasks, bugs, and requests, and labels record which area of the product it touches and what kind of work it is. Tag technical debt — cleanup deferred in order to move faster — and you can count how many days went into paying it down this quarter. That number is what turns a request for cleanup time into evidence rather than a feeling.

Customer support queues work the same way. Label every incoming ticket with its request type and a month later you know which kinds arrived most often. The top three or four lines of that list become the order of what gets fixed next.

Code repositories have them too. Each change request carries labels describing what kind of change it is, and release notes get assembled by grouping on those labels instead of reading through every merged change by hand.

Labels also serve as triggers for automation. An urgent label pings the on-call channel; a docs label links the item under its epic automatically. From that point a label is no longer only a category but a value that causes something to happen, which is why some teams restrict who can attach those.

"Can you put the billing label on this? I need to pull them all together at quarter end."

Not something needed right now — it's being tagged so it can be counted later.

"We're past forty labels. Let's clean the list up."

There are so many that nobody applies them consistently any more.

"That should be a status, not a label."

The value is one that an item should only ever hold one of, so it doesn't belong somewhere things stack.

Pagedeck uses only three families: which area (area/), what kind (type/), and where it came from (from/). Theo files a bug with area/billing and type/bug; Sofia writes up a request she heard from a customer and adds from/customer.

At the end of the quarter, Mia pulls everything tagged from/customer and counts how many actually shipped. Last quarter it was six out of twenty-three, a ratio nobody had a way to see before the tag existed. That one number changed the conversation in the next planning meeting. Instead of collecting more customer requests, the team started by deciding which of the ones already collected to drop.

It's easy to assume that more labels means better organization. Attaching one costs almost nothing, so tagging generously feels sensible. But a label earns its keep only if the filtered list means something. When every item is marked urgent, filtering on urgent returns the whole list, and the label carries no information at all. Asking how many items you expect to remain after filtering on a proposed label screens out most of them before they get created.

Using labels in place of priority or dates is the other common mistake. Some teams accumulate important, very important, and critical as separate labels, but those values are ordered and an item should hold exactly one, which is not how labels behave. Nothing stops both important and very important from landing on the same item, and at that moment nobody can say which one applies. Ordered values belong in a priority field, dates belong in the due date, and labels stay for categories that have no order — the area a thing touches, the kind of work it is, where it came from.