TBM 404: Should Teams Use the Same Tracker?

Do you think it is a reasonable expectation to know what every team in the company is working on, and to ask them to use the same system for tracking work?

Good question. I’ll give you my perspective, and I’m curious to hear how others see it.

I think it is perfectly reasonable to know why each team exists, how they fit into the value chain, the customers they serve, the systems they own, what they have released recently, the metrics they hope to move and how those metrics connect to what matters, and a high-level sense of their current priorities and goals.

I do not expect overly precise information. A discussion of priorities will usually involve a rough estimate of where time and capacity are going, but it can be as broad as 50 percent on X, 30 percent on Y, and 20 percent on Z.

We are not filling out a ledger. We are painting in broad strokes.

I also think it is reasonable to ask teams to publish their near-term release calendars in a format that other partners can easily consume, instead of forcing everyone to shuffle through countless variations of the same deck. If there is one thing that should be consistent, it is communication across critical org boundaries like product and marketing. I would trade a roadmap on papyrus for a good release calendar API any day.

Finally, I think it is reasonable for anyone to see what was actually deployed, and when. Yes, this sometimes requires translation for non-technical audiences, but it is probably the most concrete system of record that exists, alongside product analytics showing actual usage. These are the changes that actually hit production and that customers interacted with.

The challenge is that without the things I mentioned earlier, which are admittedly difficult and require psychological safety, the only thing anyone has to latch onto is “the work.” What epics have they finished? What initiatives are they working on? When trust and confidence drop, leaders impose more oversight, ask for more details, and are more likely to manage through proxies.

This kicks off a wicked cycle:

Have you ever noticed how the “dream team” at any moment is often given a reprieve from the tracking requirements the rest of the org has to follow? They are making money. Yay. Do not mess with a good thing.

For the rest of the organization, low confidence leads to productivity-killing scrutiny and calls for non-value-add consistency. And as we have all learned, when trust is low, there is almost always a way to circumvent increased scrutiny.

The big exception, of course, is work that spans multiple groups. This is where it really pays to have a common language, common systems, common interfaces, and common rituals, especially if this type of work exceeds a critical threshold. When 30 to 40 percent or more of work in a company spans boundaries, you are effectively one big team, whether you like it or not. One big team will usually benefit from consistency, at least until you can fix the underlying issues and restore independence.

In other words, you may need to scaffold things temporarily until you untangle things. But don’t get too used to it!

So in general, I think most companies could treat work objects like epics, initiatives, and stories as largely throwaway, provided they can share the important context in other ways and meet whatever governance demands they face.

Use goals, value models, charters, and problem-based roadmaps as the main interface.

Let teams use whatever tools they want, as long as they check the other boxes.