HACKER Q&A
📣 manibaur

Is anyone frustrated abt the disjointed state of software project mgmt?


I've worked at software companies big and small for about a decade and the one common theme I see is they all can do a better job organizing information about the software they build and maintain.

Things like architecture diagrams (high/low level diagrams, UML diagrams etc.), UI flowcharts, documentation, metrics etc. are all scattered across various tools that all do that one thing very well. E.g. metrics are in Splunk, documents are probably in Confluence/G-Docs etc.

But it's hard to know how they all tie together unless you have it "hardcoded" in your head. E.g. you must know which dashboard in Splunk surfaces the metrics you're looking for, you must also know which document/runbook in Confluence has the relevant information on how to act on those metrics. And more often than not this documented information, if it exists at all, drifts from reality.

Worse yet, the need for this "hardcoded" information is precisely what makes onboarding new hires hard; it's my least favorite part of joining a new team.

At one of my previous employers, we created a "team page" on the internal wiki that aggregated the team members' directory links, listed the services we owned, included some basic documentation and embedded metrics via iframes. But even that didn't meet our needs fully.

Wondering what the HN community feels about this problem (is it even a problem?) and if someone's using a tool that solves this for them at some level.


  👤 ethanbond Accepted Answer ✓
Disclaimer that I’m in the current YC batch with a company trying to solve exactly this (resync.ai has a contact button if you’d like to learn more).

I think this is a real and very substantial problem on a bunch of different levels.

For ICs, they spend a bunch of time finding scattered resources which usually involves pinging each other on Slack “what’s the latest on X” or “where can I find Y.” This incurs continuous cost on the team’s attention.

For PMs, if they’re good they’re in all the different convos and tools and they become the “reducer” for the rapidly changing team state. But this duty takes away from the more strategic/future-looking work that a PM should be doing.

For director++ people, what we’ve learned over the last few months is that they don’t know what their org is working on either. In easy-money times you just keep hiring through the inefficiency but now companies are starting to take account of what their org is actually working on and we’ve heard some real horror stories about these efforts (e.g. discovering you have many more large eng projects ongoing than you have engineers).

The underlying fact that makes a solution difficult for each party is that no one views maintaining this truth as their job, or if they do, they do it in the cheapest way available (see the PM who just sits in every single meeting, watches every Slack thread, every file’s comments) which tends to just move the problem.

The key thing to solve is how do you make curation and updating of “shared truth” and its associated resources a natural byproduct of doing the work you’re already doing. You’ve got to figure out a way to connect the substance layer of the work (various documents, chats, mockups, issues) with the ”meta” layer of the work (indices, decision logs, status reports, etc) with close to zero work from IC level people.

We’ve found this problem emerges around 30 headcount, gets super painful around 100, and continues to just get worse from there.