Reposting because the previous version had a font rendering issue in light mode

Hi HN! I'm Antoine, co-founder and CEO at Okay (YC W20). We are building analytics for engineering teams and we have released our new application on Github Marketplace.

Getting good metrics on engineering work is hard. On the one hand, you can build your own pipeline by ingesting API data from Github, JIRA, your CI tool, etc. Then you have to ETL that data, link it to teams and services, and finally select a dashboarding tool to display metrics. That gives you ultimate flexibility at a high cost of maintenance. On the other hand, you can go with out-of-the-box products but a lot of them focus on very specific metrics, such as DORA Metrics, PR throughput, etc. - not necessarily what you'll be interested in tracking, and you might even disagree with the metrics definitions or ethos of the product.

We've gone through several iterations of Okay and we think we now have the right balance between flexibility and ease-of-use. We solve ingestion + ETL and we give dashboarding features, but we leave users free to define metrics using our no-code query builder (with plain SQL coming soon). We specifically avoid forming opinions on what users should actually be building in terms of dashboards - in that sense, we are closer to an observability tool than to "development analytics" products. We are seeing a range of use-cases, such as incident tracking (with JIRA and PagerDuty data), sprint reviews (JIRA / Github), velocity & DORA (mainly Github + deployment data). We are building on BigQuery, DBT for the ETL and our custom ingestion code for API syncs. Our frontend is using Vue with a mix of D3.js and common charting libraries.

We'd love to get the community feedback on this current product approach! This Github app makes it easy to start on our free plan.

The job market for top engineers is supply-constrained, as demonstrated by the rapid increase in SWE wages in the past 15 years. If you agree that top engineers are the primary input to these companies' success, then it makes sense for them to adopt a "hoarding" behavior.

In other words, these companies have over-hired as a way to prevent competitors from hiring these same engineers. Although this has created a situation where the company has hired past the theoretical "productive" point, it was still a rational behavior.

Now that the tide is turning, the productivity goal becomes relatively more important than the competitive goal. In the long run though, I don't think the job market will fundamentally change - there is still a shortage of top engineering talent in the US.

80% of the value of OKRs is in the discussions they create, not in the actual list of OKRs that is produced in the process. The more an organization focuses on the technical aspects of producing a perfect OKR list or on "grading" the OKRs, the less value they will have.

In particular, the "KR" part - quantifiable outcomes for the goals - usually helps in clarifying vague projects or ideas that may otherwise harm the team's focus.

It's similar to the famous Warren Buffett's advice on identifying your priorities: pick 20 ideas you have and identify the top 5 goals that you absolutely want to get done; then, throw away the other 15 goals and make sure that you never get tempted to work on them.