Wow this is really smart. Extrapolating "developer happiness" is a great idea.
Launch HN: Okay (YC W20) – Analytics for engineering teams
21–30 of 36 posts
Re: Launch HN: Okay (YC W20) – Analytics for engineering teams
#22What is the point of having a webpage called "Pricing", which has practically no information about pricing? (Rhetorical question)
I need to make sure that startups say something about this when they're launching. It came up yesterday too: https://news.ycombinator.com/item?id=27447214.
Re: Launch HN: Okay (YC W20) – Analytics for engineering teams
#23Earlier quoted context omitted.
Sure. And having absolutely no relevant info on that page is a great way to certainly disrupt a potential customer's journey one step later. :-)
It's a filter in the sales funnel, often intentionally. "Contact us for pricing" tells everyone what they need to know – either you have a big budget and are not price sensitive, or you're self service and this product isn't for you. Pricing is hard, it makes total sense to just not publish prices early on.
I'm well aware of this practice and have no objection to it, in general. However, unless a company provides enough relevant information (e.g., feature breakdown per tier, other details) on the pricing page, IMO it could be better implemented as a button, link, one-liner or other compact visual element located on the home page, without wasting time and effort on repeating - and maintaining - essentially the same marketing copy on a separate page (as is the case here).
Re: Launch HN: Okay (YC W20) – Analytics for engineering teams
#24Wow this is really smart. Extrapolating "developer happiness" is a great idea.
Based on sources of mine and what you can find online, tracking developer sentiment is the next thing and github and gitlab are looking into it. I also know of a startup that is working on this. This is obvoiusly a good metrics to track but it doesn't provide much of a moat.
Re: Launch HN: Okay (YC W20) – Analytics for engineering teams
#25Some things (maybe with a focus from a German perspective):
* some words are too complicated or seldomly used - "tenure", "runbook" are not words people know here.
* seems like a gdpr nightmare (connecting okay to all kinds of data sources like calendars, repos, etc. You would need legal agreements, in the best case servers in Europe) so yeah, maybe just focus on the US :D
* as a data source in Germany you would definitely need Outlook and Azure DevOps
* upload the product demo on a new YouTube channel. Add a voice-over. Currently it's too fast and I did not understand it.
* I'd prefer a "getokay.com" domain, hq makes no sense, also hard to understand
Re: Launch HN: Okay (YC W20) – Analytics for engineering teams
#26Wow this is really smart. Extrapolating "developer happiness" is a great idea.
Thanks for the kind words. Our mission is really to enable this concept and make it more actionable
Re: Launch HN: Okay (YC W20) – Analytics for engineering teams
#27Does this work with systems outside of the Microsoft/Google ecosystem (i.e. not github, not g suite/gcal)? I'm interested, but it's unlikely that I'm going to be building teams on either of these platforms in the future, considering how easy these are to host internally now.
Currently we only support these ecosystems because most of our early customers are on these platforms. We do have a tracing-like API that you can use to send custom events, but that would require more integration work of course.
Is there somewhere where we can suggest/vote for the next integrations? I can only seem to find a message that you are adding more integrations. We'd love to see Microsoft/Office 365 integration, and GitLab.
The tool looks awesome, exactly the right kind of metrics, without the invasive accounting for every second that others have tried to enforce in the past! Excellent work!
Re: Launch HN: Okay (YC W20) – Analytics for engineering teams
#28Disclaimer: I'm a competitor of Okay along with others in the software development metrics space. I just want to comment on > We also learned that the discussion about engineering metrics always falls into a false dichotomy: don’t measure anything because engineering is creative work (it is!) or measure engineers in intrusive ways along meaningless dimensions like lines of code. I think with close to 50 years of doin…
The way to get engineers to adopt it is to demonstrate how it can be useful for them. Engineering quality of life can be derived from a lot of these metrics. Take for example, XKCD 303: https://xkcd.com/303/ . Engineers spend so much time waiting on compile, build, and deployment time. It is such a waste of time and resources. These are things that engineers tend to absorb resulting in engineers getting blamed for lo…
> Engineers spend so much time waiting on compile, build, and deployment time
Slowness in this processes can certainly frustrate and extend overall timeframes, but surely engineers must be capable of multi-tasking to some degree, and able to do something useful with those minutes between commit and deploy? ;)
Re: Launch HN: Okay (YC W20) – Analytics for engineering teams
#29What is the point of having a webpage called "Pricing", which has practically no information about pricing? (Rhetorical question)
I need to make sure that startups say something about this when they're launching. It came up yesterday too: https://news.ycombinator.com/item?id=27447214 .
It certainly would be nice. I have an off-topic, but, nevertheless, important request in the question format: is there any chance that HN UI will be improved in the nearest future by allowing users to selectively expand & collapse individual discussion threads? The lack of this feature is IMO a very annoying issue and a glaring example of how simplicity taken to an extreme leads to a significant friction in UX (which arguably could be fixed relatively easily in this case).
Re: Launch HN: Okay (YC W20) – Analytics for engineering teams
#30Earlier quoted context omitted.
The way to get engineers to adopt it is to demonstrate how it can be useful for them. Engineering quality of life can be derived from a lot of these metrics. Take for example, XKCD 303: https://xkcd.com/303/ . Engineers spend so much time waiting on compile, build, and deployment time. It is such a waste of time and resources. These are things that engineers tend to absorb resulting in engineers getting blamed for lo…
> Engineers spend so much time waiting on compile, build, and deployment time Slowness in this processes can certainly frustrate and extend overall timeframes, but surely engineers must be capable of multi-tasking to some degree, and able to do something useful with those minutes between commit and deploy? ;)
That capability varies a lot. Long build times create a situation where the ability to swap tasks efficiently is the main criterion for being effective.
I'm considered "extremely high output" in my current position, and I don't really deserve it - I ought to be called "unusually good at coping with our problems" instead.