TE
TechEcho
Home24h TopNewestBestAskShowJobs
GitHubTwitter
Home

TechEcho

A tech news platform built with Next.js, providing global tech news and discussions.

GitHubTwitter

Home

HomeNewestBestAskShowJobs

Resources

HackerNews APIOriginal HackerNewsNext.js

© 2025 TechEcho. All rights reserved.

Launch HN: Okay (YC W20) – Analytics for engineering teams

123 pointsby tonioabalmost 4 years ago
Antoine and Tomas here - we are excited to share Okay (<a href="https:&#x2F;&#x2F;www.okayhq.com" rel="nofollow">https:&#x2F;&#x2F;www.okayhq.com</a>) with you! Okay is an engineering analytics platform focused on detecting bottlenecks and annoyances that prevent engineering teams from being fully productive. We connect with all the devtools in your company and give you a query and alerting engine to find and solve common bottlenecks like long review cycles, after-hours on-call pages, heavy interview load, etc. Think Datadog or Grafana, but for team analytics.<p>For the past 12 years, we’ve been engineers and then managers of teams of 5 to 150 in several types of companies - startups and big tech. We’ve seen the dev experience being affected by the same problems everywhere: maybe it’s a slow build on your local machine, too many meetings and interviews, or inefficient code review practices that force you to open 10 PRs in parallel to make progress on a given week. We personally struggled with automated tests suites that would take 4 hours to complete and we saw teammates become so desensitized to heavy oncall load that they would stop complaining and just give up.<p>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. We believe that the way to overcome this false dichotomy is to apply quantitative measurements <i>empathetically</i>, that is, with a clear understanding of the human impacts of what&#x27;s being measured on the people doing the actual work - for example, by measuring how noisy on-call pages disrupt an engineer’s life after hours. The key is to focus on bottlenecks instead of output, and on the team level rather than on individuals. So we set out to build a product where you can see all the data from all your dev tools, query it, make sense of trends, and build alerts for when things go wrong.<p>At its core, Okay is an end-to-end analytics platform focused on engineering data. First, we ingest data from tools like Google Calendar, Github, Pagerduty, etc. We join it with the team structure that we find in services like Workday. In addition to pre-built integrations, you can also use a tracing-like API to capture e.g. how long local builds are taking. Then, we clean up and enrich the signal: tagging interviews correctly, rebuilding the full history of a PR as a connected chain of review events, inferring dimensions like tenure (which can e.g. help capture new hire experience). Finally, we expose all this data in a query builder UI that closely maps to the underlying SQL query, and we enable users to choose from visualizations we built specifically for representing engineering work: time series of course, but also calendars (e.g. to understand the life of a PR) or heatmaps (e.g. to identify a painful on-call rotation quickly). The opinionated part of Okay is all in the data modeling we do on behalf of users - we aim to reflect our values (team-based vs individuals) and to retain a lot of expressiveness so that users can ask questions like “what is the code review experience of our new hires in our NYC office compared to the SF office?”.<p>You can check how Okay works by going to our website (<a href="https:&#x2F;&#x2F;www.okayhq.com" rel="nofollow">https:&#x2F;&#x2F;www.okayhq.com</a>) or checking our product video (<a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=jzzo3m4280k" rel="nofollow">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=jzzo3m4280k</a>). We don’t have free trials because once you identify bottlenecks and set the right alerts to create new habits, it usually takes several weeks to see the changes happen - we’re talking about humans working together after all, so it does require a little bit of upfront investment. We price based on the number of users and engineers on the team.<p>If you are interested or have specific questions for your use-case, we’d love to connect with your team directly in the comments. Thanks!

12 comments

MattGaiseralmost 4 years ago
I came expecting something for extracting higher velocity from a Scrum feature factory.<p>Very pleased that this is not the case. This is the most thoughtful attempt at software engineering metrics I have seen yet. Especially like the build time tracking because at a prior company, builds took 4 minutes and running the full test suite could take another 6.<p>We couldn&#x27;t convince management that this was a problem (multiplied numbers make people suspicious, idk). This would have shown them the hours wasted per year, which would have been far more than the cost of JRebel or installing HotSwap.
评论 #27463005 未加载
评论 #27463301 未加载
carstenhagalmost 4 years ago
Some things (maybe with a focus from a German perspective):<p>* some words are too complicated or seldomly used - &quot;tenure&quot;, &quot;runbook&quot; are not words people know here.<p>* 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<p>* as a data source in Germany you would definitely need Outlook and Azure DevOps<p>* upload the product demo on a new YouTube channel. Add a voice-over. Currently it&#x27;s too fast and I did not understand it.<p>* I&#x27;d prefer a &quot;getokay.com&quot; domain, hq makes no sense, also hard to understand
bradknowlesalmost 4 years ago
Unfortunately, this name choice destroys your discoverability.<p>Try googling for the word “okay”. Now, try googling for the word “google”.<p>The Chef and Puppet communities have some of this problem themselves, although with Chef you can at least include the original name of the company that created the product.<p>Imagine if IBM was to launch today, and they chose to name themselves “Machine”. Just how useful would that name actually be? Or if Microsoft launched today, and they chose to call themselves just “Soft”.<p>It’s not like you can copyright the word “okay”.<p>Naming is hard. For many reasons. We know that. It is one of only two “hard” problems in computer science, and I submit that it is the only universal “hard” problem.<p>You need to spend enough time to get this right, and do so before you launch, otherwise you are crippling yourself for the life of the company or product.<p>With respect, nothing you do with your product or company will make a difference if you don’t have a suitably discoverable and memorable name.
mrkurtalmost 4 years ago
Wow this is really smart. Extrapolating &quot;developer happiness&quot; is a great idea.
评论 #27466438 未加载
评论 #27466837 未加载
dickficklingalmost 4 years ago
I&#x27;ve got no feature requests or questions, I just want to say I&#x27;m really excited about this. It sounds like a really thoughtful attempt to be better than the standard approach to eng analytics, e.g. &quot;how many points did CodeMonkey complete this sprint&quot;
ilikebitsalmost 4 years ago
This is an excellent idea, and looks like an excellent product. As an engineering manager, I&#x27;ve built many of these tools myself before as one-off scripts. I&#x27;ve always wondered whether the market cares enough about this problem for it to be a viable startup.
oliverx0almost 4 years ago
Can you elaborate on how current customers are using it? Any fun &#x2F; funny insights that were discovered thanks to your product that helped them in meaningful ways?<p>Congrats on the launch! Looks like an interesting (and more human) approach.
评论 #27463441 未加载
JoshTriplettalmost 4 years ago
I love the idea of having metrics for things like &quot;how long are people spending waiting on builds&quot;.<p>You mention that you&#x27;re trying to get data from existing tools rather than requiring self-reporting. What are you using to track time spent on local builds?<p>I&#x27;m currently building a service to speed up both local and CI builds. I&#x27;d love to talk with you more; my email is in my profile.
评论 #27464635 未加载
sneakalmost 4 years ago
Does this work with systems outside of the Microsoft&#x2F;Google ecosystem (i.e. not github, not g suite&#x2F;gcal)?<p>I&#x27;m interested, but it&#x27;s unlikely that I&#x27;m going to be building teams on either of these platforms in the future, considering how easy these are to host internally now.
评论 #27465528 未加载
1123581321almost 4 years ago
Looks interesting. Are you far from Gitlab.com integration?
ablekhalmost 4 years ago
What is the point of having a webpage called &quot;Pricing&quot;, which has practically no information about pricing? (Rhetorical question)
评论 #27465907 未加载
评论 #27484200 未加载
评论 #27465558 未加载
sdesolalmost 4 years ago
Disclaimer: I&#x27;m a competitor of Okay along with others in the software development metrics space.<p>I just want to comment on<p>&gt; 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.<p>I think with close to 50 years of doing things wrong with software development metrics, we&#x27;ve left a very bitter taste in the mouths of developers and it is fully understandable that developers would be weary and skeptical of software development metrics. It is certainly one sided and I do agree this false dichotomy needs to be addressed.<p>When it is all over, if software development metrics is done right (with the emphasis on done right), developers should be the ones advocating for it, since it means:<p>- They can work more efficiently since software metrics can help them better understand how a piece of code came to be<p>- Better sell themselves for promotions and raises. For example, they can use it to highlight impact and what it means if they leave. Their manager may know they are a top contributor but if their manager can&#x27;t sell them, it won&#x27;t help. With software metrics, manager&#x27;s should be able to highlight how their developer is having an impact when the raise&#x2F;promotion pool is divided up.<p>- And so forth<p>I honestly think the best way to get everybody onboard with metrics, is to clearly show that it takes effort to generate meaningful insights. And this is why I&#x27;m not so much focused on providing canned reports, but rather, I want to provide business intelligence for the software development lifecycle.<p>The goal (which it sounds like Okay is working towards as well) is to connect all the dots in the software development lifecycle and provide users with the necessary data to make informed decisions. In the business world, we have &quot;business intelligence specialist&quot; because nobody takes for granted how difficult it is to get business insights. And it is truly baffling how we don&#x27;t have &quot;software development specialist&quot; to help us interpret efficiency and productivity as context matters and not everybody is qualified to interpret development metrics.
评论 #27464890 未加载