Show HN: Haystack – Visibility into How Software Teams Works
usehaystack.io
usehaystack.io
And perhaps stuff like this should have on-site capability for enterprises that don't use github, gitlab and such?
True. We'll add better images and case-study to avoid the confusion.
> And perhaps stuff like this should have on-site capability for enterprises that don't use github, gitlab and such?
I'm assuming you are talking about GitHub Enterprise, Gitlab Self-Managed and Bitbucket Server. We currently have support for Bitbucket Server and working on the rest.
A tech selection from Googling 'haystack'
What people on the internet are recommending is as long as the brand names would not be confusing it would be fine. The term "confusing" seems to be the tricky part. A trademark attorney would probably clarify it for us.
Generally any well intentioned person who worked on an idea like this would be delighted to share what their product does specifically and clearly - unashamed screenshots of interesting visualizations (maybe half cooked), telling descriptions of specific numbers being crunched and their utility as predictive indicators of project success, verified with statistical certainty.
Sadly this kind of naive, honest approach is very regularly usurped by the machiavellian machinery of the professional art of convincing others to buy things, which is narrative focused and story driven with very little concrete substance.
Not blaming the author here, I understand the motivations at work and sympathize with them, but still sometimes find myself dumbfounded by the results.
The ebook has additional content such as
- Mitigate Bus Factor
- Protecting Deep Work
- Avoiding Engineer Burnout
and explains each problem in detail.
Please tell people upfront what happens when they "sign up", as right now you're employing dark UX patterns just to collect emails.
Could you provide an example of actionable insight you provide when you have detected that a team is taking on too much concurrent work?
We get 6 months weekly average pull request throughput of each team. We call this the "Baseline Throghput". If a team has more (or less in some cases) pull requests open than the baseline, we consider that a "too many".
Too many Open Pull Requests can signal taking on too much work, scope creep, change in priorities and unexpected issues/bugs coming into the sprint. It’s good to keep an eye out of the number of Open Pull Requests since it’s a great indicator of the team’s current workload.
Your web site shows me diddly squat. Do you actually _have_ a product? Where's the video walkthrough, or at the very least, some screen shots?
If your product were genuinely useful / insightful (which is very hard to do in this space) then we might buy it. For 400 seats. But it looks like vapourware to me right now. Come back when you actually have something to show the community.
I'm pretty surprised that the price goes up per engineer as the team grows larger, especially as you're getting serious economies of scale -- all the math and stats is as easy to perform on 400 engineers as it is on 4, once you've got the system in place.
(This is just a guess, I have no connection to haystack)
If not it seems like a horrible product for engineers.
As long as the team has a visibility problem Haystack should be beneficial.
We have organizations prefering to use the stats more privately and only mention the necessary stats to engineers. We also have organization using our product in their daily standups. It depends on how the team choses to use it. We have seen both styles work well.