Diligencing a Startup's Engineering Org Before You Sign

You have an offer. Before you sign, you want to know whether the engineering org behind it is actually healthy, using only evidence you can see from the outside. This guide carries one company through a repeatable read of its public engineering signals - GitHub cadence, deployment rhythm, incident discipline, and where the engineers came from - and shows the intermediate counts, the forks, and the wrong turns. It is written for engineers weighing an offer, and it treats the join decision like code review, not vibes.

Most "how to evaluate company culture" advice stops at Glassdoor reviews and gut feel. That is fine for temperature but useless for the question you actually have, which is whether this team ships, recovers, and keeps people. Those things leave a public trail. The trail is thin by default and it lies in specific, predictable ways. This guide is about reading it correctly and knowing exactly when it runs out.

What public artifacts actually expose an engineering org's practices

Four artifacts carry the weight, and each proves a different thing. GitHub org public events show whether the team works in the open and at what rhythm. Release tags and changelogs, read against deployment-frequency bands, show shipping cadence. Public status pages with timestamped incidents and post-mortems show how the team behaves when things break. Job postings and the engineering blog show the claimed stack, which you then check against the observed one.

Here is the trap that catches everyone first: absolute output is a weak signal. GitHub only exposes public repos, and the live events API is capped at the last 300 events per source, so what you can see is partial by construction. More importantly, volume varies with team size and repo strategy. A company pushing 500 commits a week is not necessarily healthier than one pushing 50. What matters is the rate of change - acceleration or deceleration against the org's own baseline.

The artifacts also differ in how easily they can be gamed. A curated LinkedIn page is easy to arrange. A two-year trail of timestamped incidents and release tags is not. That ordering matters, and it shapes the procedure below: do cadence and reliability before you read the team.

The read, step by step

Work the signals in the order that puts hard-to-fake evidence first. Scope the footprint, read cadence, pull the trend, audit reliability, then read the team, then reconcile the stack, then assign confidence. Signal-intelligence sources tend to lead with GitHub activity and recruiter-facing sources lead with tenure; for a join decision, cadence and reliability come first because they are harder to fake than a tenure page.

The rest of this guide walks one worked example through these steps, with the intermediate numbers and the two wrong turns I took.

The worked example: reading cadence from release tags

Start with the footprint. My target had a public GitHub org with a handful of repos: an SDK, some infrastructure tooling, a docs site, and a marketing repo. The product itself was nowhere - private, as expected. Last-push dates on the public repos ranged from two days old on the SDK to eleven months old on a sample-app repo. First read: the org works in the open partially. That is the common case, and it caps confidence at medium, not low.

Then I read cadence from the release tags. The SDK had 34 tagged releases over the trailing 12 months, clustered into bursts: several in a week, then quiet stretches. Mapping the tag timestamps onto the DORA deploy-frequency bands gave a picture between high and medium: mostly weekly, occasionally faster.

Here was my first wrong turn. I nearly wrote the company down as a medium performer on the strength of the SDK tags alone. That is the failure mode where release-tag frequency gets read as deploy frequency. Teams that deploy their product continuously often tag public libraries rarely, so the public SDK cadence tells you almost nothing about how fast the actual product ships. The correction: treat tags as a floor, never a ceiling, and corroborate with changelog dates and PR merge cadence. The SDK's own changelog and the merge timestamps on its pull requests told a tighter story than the tags did - closer to high than medium. But for the private product, I had to accept I could not band it directly and said so.

Building the trend so you read acceleration, not a snapshot

A single snapshot of activity tells you where the org is, not where it is going, and direction is the whole game. Pull 12 to 24 months of history and build a monthly series. GH Archive holds hourly public GitHub events on BigQuery, with Events-API-based data since 1 January 2015, and there are ready-made queries for pulling an org's ReleaseEvent and PushEvent history. Ecosyste.ms Timeline mirrors over 8 billion public events with an open API if you would rather not touch BigQuery.

For my target, the monthly ReleaseEvent count over 18 months rose from roughly 1 to 2 a month in the first half to 4 to 6 a month in the most recent quarter. PushEvents on the public repos tripled over the same window. That is acceleration, and acceleration against the org's own baseline is the signal that survives the volume trap. I did not care that the absolute numbers were modest. I cared that the second derivative pointed up.

If the series were flat or declining while the company was raising and hiring, that mismatch would be the interesting finding - not the raw level.

Auditing the status page as a culture test

A status page is a communication artifact, not a monitor. Monitoring detects problems; a status page communicates them to humans. Because a human updates it, the page tells you how the team behaves under pressure, which is exactly the thing you want to know before you join. Read it as a culture test.

The discipline markers are concrete. Look for short, timestamped updates that carry impact, scope, action taken, and a time for the next update. Look for post-mortems, and check whether they ship promptly - the working target is within 48 hours of resolution. The gold-standard tell of a serious org sits at the far end of this spectrum: Honeycomb takes reliability so seriously that it publicly reports a 5-minute delay in data processing as an outage. A team that reports small things well almost always handles big things well.

My target's page had nine incidents over the trailing year, each with timestamped updates and a next-update time, and post-mortems on the two largest, published within a couple of days. That is good discipline. It reads as more incidents than a rival with an all-green page, and here is the second wrong turn: I initially scored the all-green rival higher on reliability. Wrong. The page is human-updated, so green during a known, reported outage means poor incident discipline, not uptime. I cross-checked the rival against third-party outage chatter and found two customer-reported outages that never appeared on their page. The nine-incident company was the reliable one; the silent one was hiding.

Reading the team: tenure distribution and where they came from

Tenure is where good diligence separates from lazy diligence, because the headline number is almost always misread. Start from the benchmarks so you know what normal looks like.

Against Zippia's analysis of about 103,000 developers, 45% have just 1 to 2 years of tenure and 69% stay under 2 years at a single employer. So short tenure is the industry baseline, not a scandal. The engineering-wide average rose 22.3% in 2025 to 2 years 11 months. Now hold the Google figure next to that: a reported 1.1-year average. Is Google in crisis? No. When a company doubles its engineering team every three years, the average tenure falls mechanically because most employees are recent hires, even with zero attrition.

That is the core insight: low tenure has two opposite causes, and the mean cannot tell them apart. Read the distribution of join dates instead. The red flag is mass-recent joins - if nearly everyone joined in the last six months, something changed, and high early turnover is almost always a symptom of leadership issues, technical debt, or a culture that interviews well and delivers poorly. A wide spread of join dates around a growing headcount is healthy even if the mean looks low.

A 1.1-year average tenure can mean hyper-growth or quiet collapse; only the distribution of join dates tells you which.

For my target, LinkedIn showed 40 engineers with join dates spread across three years, thickest in the last year but with a solid core from the early days still present. That is growth-driven, not attrition. I also checked provenance - where the engineers came from - which tells you both the calibre bar and the retention pressure the company faces.

Provenance connects to a hard supply constraint that most candidates never price in. In Refolk's index of professional profiles, there are 1,631 US engineers skilled in Kubernetes and SRE against just 423 in the UK, a 3.86x gap. The top current employers of those UK specialists are JPMorganChase and Apple. If your target is a UK startup competing for the same 423 people against JPMorganChase, it faces structurally higher churn pressure than a US peer drawing from a pool nearly four times larger. That is a real, quantifiable retention risk you can raise in the offer conversation.

Pulling the tenure distribution and provenance by hand across LinkedIn is the slow part of this whole read. Asking for it in plain English is faster.

I use Refolk for exactly this: the join-date distribution and the previous-employer list are the two facts that separate growth from attrition, and they are painful to assemble profile by profile.

Reconciling the stack, then assigning confidence

Cross-check the claimed stack against the observed one. Read the job postings and the engineering blog for the technologies the company says it uses, then compare against what the public repos actually contain. A match raises confidence. A discrepancy - say, job posts demanding a language that appears nowhere in any public artifact - is not automatically a red flag, but it is a specific question for your interview.

Then assign confidence honestly, weighted by how much of the org is private. Since GitHub has offered unlimited free private repos since January 2019, most startups keep product code private and the public trail is thin by default. GH Archive and the events API only ever contained public events, so private work is entirely invisible there. Some larger organizations run inner-source workflows - private repos with open-source-style review where anyone inside can read and submit PRs - which you cannot see at all from outside. The correct response is to lower stated confidence and lean on tenure, job-posting stack, and status-page evidence, not to over-read a handful of thin public commits.

Write the verdict as join, negotiate, or pass, and document the wrong turns so a peer could audit it. My target: partial public footprint (medium confidence ceiling), accelerating release trend, disciplined status page with nine well-handled incidents, growth-driven tenure distribution with a retained early core, and a stack that matched job postings. Two wrong turns corrected along the way. Verdict: join, with the SRE-supply retention risk raised in negotiation.

How this read goes wrong

This is the most valuable section, because the signals mislead in specific, repeatable ways. Every one of these is a false positive I have seen or nearly made. Learn the check for each.

• Low public commit volume read as a dead org. A healthy team doing all its work in private repos looks abandoned. Check: confirm the repo visibility mix and cross-read job postings and status-page activity before concluding anything is dead.
• Low average tenure read as churn. Fast headcount growth mechanically depresses the average with zero attrition. Check: look at the distribution of join dates, not the mean.
• All-green status page read as reliability. The page is human-updated, so green during a reported outage means poor incident discipline. Check: compare the page history against third-party outage chatter and dates.
• Release-tag frequency read as deploy frequency. Teams that deploy continuously but tag rarely look "low." Check: treat tags as a floor and corroborate with changelog dates and PR merge cadence.
• Absolute commit count read as velocity. 500 commits a week is not healthier than 50; only acceleration relative to the org's own baseline is meaningful. Check: build a 12 to 24 month series from GH Archive.
• Star and fork counts read as engineering health. Popularity is marketing, not delivery. Check: ignore stars for a join decision; weight releases, incidents, and tenure.
• AI-inflated cadence read as high performance. Deployment frequency and lead time have become misleading when AI generates a significant share of code, because they measure how fast code ships, not how much value is delivered. Check: pair cadence with change-failure and incident evidence.

That last one deserves a beat. The DORA bands remain a sound spine - the framework was validated across more than 39,000 survey responses, and elite performers deploy on demand while low performers deploy less than once a month. But high deploy frequency alone can overstate delivered value when much of the code is machine-generated. Reliability evidence is your counterweight: a team shipping fast and recovering well is real; a team shipping fast with hidden incidents is not.

Before you call it done

Run this checklist before you write the verdict. Each item is something to verify, not a topic to think about.

Keeping the read current after you sign

The public trail moves, so a diligence read has a short shelf life. If you are deciding between offers or want to recheck a company you already read, re-pull the two signals that decay fastest: the trailing-quarter release trend and the last few status-page incidents. A cadence that was accelerating six months ago and is now flat is a different company. Similarly, watch the join dates - a wave of departures among the early core, visible as those profiles moving on, is the attrition signal you could not see at snapshot time.

The one number worth tracking for a role with scarce supply is the size of the local talent pool the company competes in. Where that pool is thin - the 423 UK Kubernetes and SRE engineers against 1,631 in the US is the case in point - retention pressure is structural and will not improve because the company wants it to. Price it into your comp expectation now, and revisit it if you ever weigh a counteroffer. The method here does not expire. Only the values do, and you now know exactly which ones to refresh.