The system has observability on every service. The people keeping it up have observability on nothing.
Sloane Labs is the capacity intelligence layer for engineering organisations. It reads recovery and cognitive load across product, platform and on call rotations, forecasts where velocity and incident response will degrade, and acts before the sprint review or the pager tells you.
Velocity is not a function of headcount. It is a function of how much of each engineer's week survives contact with the calendar.
You instrument every service to the percentile and page a human the moment a metric drifts. That human's own state, sleep debt, recovery, fragmentation of their week, is invisible to the same organisation that depends on it to resolve the incident.
Under a fixed hiring plan, you cannot out hire fatigue. The remaining lever is throughput per engineer per week, and that is governed by recovery, uninterrupted focus time and how on call load is distributed. All three are measurable and almost none of it is managed with data.
Four places capacity turns into outcome
The on call rotation
A night page does not cost one night.
The architecture decision
Fatigue makes senior engineers narrower rather than slower.
The fragmented week
Focus time destroyed by meeting fragmentation is the largest and most controllable loss in most engineering organisations.
The senior pipeline
When a staff engineer leaves, the context leaves with them.
A release cycle, read the way you read your services
Squad readiness across a sprint and launch, with the forward projection that lets you rebalance the rotation, protect focus blocks or move a launch date before velocity and incident response degrade.
Select an operating state to redraw the forecast.
Normal sprint cadence, quiet pager. Recovery clears between weeks and readiness holds inside the tolerance band.
No intervention. The Monday brief confirms the squad can take on additional scope.
What we read, and what each signal decides
A signal earns its place only if it changes an operational decision. Anything that does not is telemetry for its own sake.
What is actually running, not what is on a roadmap
Monday readiness brief
A single page before planning. Squad readiness, what changed over the weekend, the two squads to watch, and one recommended action.
Cohort readiness by squad
Product, platform, infrastructure and support reported as separate cohorts with trend lines across the quarter. No cohort renders below five people.
Forward risk alerts
When a squad is forecast to cross a readiness threshold inside 72 hours, the alert fires with contributing factors and stated confidence.
Rotation and launch simulation
Model a plan before you commit. Split the rotation, move the freeze or protect focus blocks and see the projected effect on the squad.
Individual agent, opt in only
Engineers who opt in get their own coach: recovery targets after a pager week, focus protection, answers grounded strictly in their own data. Nothing is visible to management.
Retention evidence record
An aggregated, anonymised record of how load was distributed across squads and what interventions changed the trend.
Reading human capacity only works if the boundary is unambiguous
Trust is the adoption constraint. These are commitments, written into the agreement, not preferences.
Never a productivity surveillance tool
No keystrokes, no commit counts, no ticket throughput per person. Excluded from performance review, calibration and disciplinary process, contractually and in the data model.
Opt in, always
No one is enrolled by default. Participation is individual, explicit and revocable at any time, with data deleted on withdrawal.
Five person minimum cohort
Aggregate views suppress any group smaller than five. Leadership sees cohorts, never a named individual's physiology.
Metadata, never content
Calendar and messaging integrations read timing, density and participant counts. Titles, bodies and message content are masked at ingestion and never stored.
Separated from selection
Contractually and architecturally excluded from selection, appraisal and disciplinary processes. That separation is written into the agreement.
UK GDPR and DPIA ready
Lawful basis, retention schedule, data subject rights and a pre drafted DPIA template supplied for your DPO before the first device is connected.
Every service has observability. The people keeping them up have none.
An eight week pilot with a defined exit
We take a small number of design partners per sector. A partner shapes the roadmap directly, gets preferential terms, and keeps the right to walk away at week eight with no obligation.
Scope and governance
Agree cohorts, success measures and the data boundary. DPIA reviewed and signed. Integrations connected in a sandbox with a small internal group.
Baseline
Volunteers connect wearables and calendars. Individual baselines establish across a normal cycle and a peak one. No alerting yet, observation only.
Live briefing
Morning readiness briefs start reaching leadership. Forecast alerts switch on. Calibration against what the organisation already believes about its own load.
Readout and decision
Joint review of accuracy, adoption and the decisions the signal changed. Written readout, roadmap input, and a clear go or no go.
What we need from you
- One executive sponsor with authority over how work is scheduled
- Twenty to fifty volunteers across two or three cohorts
- Calendar and messaging integration approved by IT and the DPO
- Two review sessions across the eight weeks
What you get
- Full platform access for the pilot cohorts, configured to your operating calendar
- Direct roadmap influence on capability specific to your sector
- A written readout of accuracy, adoption and decisions changed
- Preferential terms and first refusal on the sector in your market
The questions we get asked first
Is this developer productivity monitoring?
No, and it is deliberately architected so it cannot become that. Sloane never reads code, commits, tickets or keystrokes. It reads consenting wearable signals plus calendar and rotation metadata, and reports at cohort level only.
How is this different from DORA metrics?
DORA measures the output of the system. Sloane measures the state of the people producing it and forecasts where that state is heading, which is the leading indicator DORA cannot give you.
Will engineers accept it?
Adoption depends entirely on the boundary being real. Opt in, individual data never visible to management, cohorts of five minimum, and a private agent that works for the engineer. Teams that get this right see adoption above sixty percent.
What does integration require?
OAuth for calendar and messaging, optional on call rotation metadata, and individual device authorisation for wearables. No endpoint agents, no repository access, no network changes.
We already give people WHOOP or Oura. Why add this?
Those devices answer an individual question well. They do not join physiology to workload, aggregate to squads, forecast, or act. Sloane sits above whatever hardware you already deployed.
How do we know the signal is real?
Every score is deterministic and reproducible from versioned features, every forecast carries stated confidence, and the pilot readout compares prediction against what the organisation observed.
Give the humans the same observability as the services
A thirty minute conversation covering the architecture, the data boundary and what an eight week pilot would look like inside your engineering organisation.