EMS - Workforce Intelligence

The client, a 280-person engineering organization scaling rapidly after a $45M Series B, was experiencing the growing pains that hit every fast-scaling tech company: invisible burnout, unpredictable delivery slips, and resource allocation decisions made on gut feel rather than data. Engineering managers were running teams of 8-12 engineers with no quantitative visibility into workload distribution, capacity utilization, or early warning signs of team health deterioration.

The symptoms were severe. Delivery timelines were slipping by an average of 2.3 sprints per quarter, with no reliable way to predict which projects were at risk until they were already behind. Attrition among senior engineers had spiked to 22% annually — exit interviews consistently cited "unsustainable workload" and "lack of visibility from management" as primary factors. The company was spending $1.2M per year on recruiting replacements, and each departure created a 3-4 month productivity gap while new hires ramped up. Three critical product launches had been delayed in the past year due to unexpected departures of key engineers mid-project.

The engineering leadership team had tried several approaches: biweekly 1:1 check-ins, anonymous pulse surveys, and sprint retrospectives. But these methods relied on self-reporting, which was inherently lagging and unreliable — engineers experiencing burnout often don't recognize or report it until they're already updating their LinkedIn profiles. The VP of Engineering needed a system that could surface objective, leading indicators of team health and delivery risk from the signals already being generated by their engineering workflows: commit patterns, PR review cycles, sprint velocity, Slack activity, and meeting load.

The platform follows an event-driven architecture with a clear separation between data ingestion, analysis, and presentation. The ingestion layer consists of a set of integration connectors — each implemented as an independent microservice — that poll or receive webhooks from source systems (GitHub, Jira, Slack, Google Calendar, PagerDuty). Raw events are normalized into a canonical activity schema and published to a Kafka event stream. A stream processor consumes these events and maintains materialized views in PostgreSQL: per-engineer activity timelines, team-level aggregate metrics, and project-level delivery indicators.

The ML analysis tier runs on a scheduled cadence. Feature engineering pipelines, orchestrated by Celery, compute the 34 behavioral signals for the burnout model and the project-level delivery indicators from the materialized views. The burnout prediction model (XGBoost ensemble) and delivery risk model (gradient-boosted regression) run weekly inference jobs that update risk scores in the database. A separate anomaly detection service monitors for sudden shifts in individual or team patterns that warrant immediate attention rather than waiting for the weekly cycle.

The application tier is built with Django and Django REST Framework, serving a React frontend. The dashboard provides three primary views: a team health overview with burnout risk heatmaps, a project delivery confidence dashboard with trend lines and risk factor breakdowns, and an individual contributor view (accessible only to the engineer themselves and their direct manager) showing workload distribution and sustainability metrics. All data is presented with strict privacy controls — engineers can see their own data, managers can see aggregate team metrics and individual risk flags (but not raw activity data), and executives see organization-level trends. The system runs on AWS with RDS for PostgreSQL, ElastiCache for Redis, ECS for service orchestration, and S3 for model artifact storage. A/B testing infrastructure allows the data science team to evaluate model improvements against historical accuracy benchmarks.