I am trying to validate a problem I keep seeing at bunch of mid-size companies that run on Slack, Jira, Asana, Confluence, Google Docs, often Figma, email, ...
The pain isn’t search. Tools like Glean are good overlays for discovery.
The pain is drift: decisions or clarifications made in one place don’t get reflected in the others, so truth diverges and teams lose time reconciling.
So what I’ve observed:
* A Slack thread (or Confluence comment) clarifies a requirement, the Jira acceptance criteria and the spec never change
* A PM updates Confluence, but x-functional issues (DA, Eng, Design) under the same Epic still reflect the old requirements
* Decisions happen across multiple Slack or Teams threads (including DMs) and aren’t visible to those who need to know between threads
* “What’s the latest?” becomes a recurring standup agenda item, and PMs have to route information based on internal knowledge and changes
* Service Now incidents convert/escalated into Jira tickets without and become disconnected since then
I’m trying to gauge how widespread the "keep sources semantically in sync" problem is, and to collect adjacent challenges we should consider if we tackle it.
3 questions for HN:
1. Do you see this drift in your company, team? Where is it worst?
2. What’s your current process? E.g., manual doc comments, weekly readouts, pinning Slack messages, internal scripts, ...?
3. If you’ve tried to fix it, what failed or worked?
If this is a real pain for you, resonates with you, would you be open to a short call as a potential design partner? I’ve built a prototype and want to sanity-check problem scope and success criteria, not pitch a solution yet.
Promise: I’ll summarize takeaways back to the thread.
DM or email me. Thanks!
BobbyTables2•2mo ago
white•2mo ago
The problem doesn't disappear though, but shifts to other people. Unless you have seen it differently - can you tell me more?
BobbyTables2•2mo ago
The architects didnt understand the code. The developers didnt understand how it would be used, and the managers didnt understand either. The executives understood none of this, nor appreciated what was involved, but focused on what sounded flashy.
A “tiger team” of exceptional people (who understood everything) was formed, tried valiantly, and managed to make progress even possible… But even Superman cannot boil the ocean.
The problem wasn’t even technology or management — just too many people who didn’t understand what the were building or how it would be used. This included both the technical side as well as the “use case” side. They also had no comprehension of how their component interacted with the rest of the system.
I’ve all seen small teams of 10-20 do amazing things because they all understand the goal. They may have different ideas but can quickly arrive at a final design and make it happen.