The Case for Engineering Intelligence

I manage programs with 50-plus engineers across multiple accounts and time zones. The hardest question I face is not "what needs to be built" — it is "who is available, what can they do, and where are the gaps." That information lives in spreadsheets, Jira boards, manager conversations, and tribal knowledge. It is fragmented and always stale.

So I decided to build something about it.

The Vision

I am designing what I call an Engineering Intelligence Platform — a centralized system that maps every team member's skills, current assignments, capacity, and project history. Think of it as a knowledge graph for engineering organizations.

The tech stack I am exploring: FastAPI for the backend, Neo4j for the graph database (because relationships between people, skills, and projects are inherently graph-shaped), and PostgreSQL for structured data. The idea is to ingest data from Jira, GitHub, and HR systems, then surface insights through a clean dashboard.

Why a Graph Database

Relational databases can model this, but they struggle with queries like "find me all engineers who have experience with payment integrations AND are available next sprint AND have worked with the Xenial API." In Neo4j, that is a natural traversal. The data model matches the mental model.

What I Want to Answer

Three questions drive the design. First: where are we understaffed relative to upcoming work? Second: which engineers are being underutilized based on their skill profiles? Third: if a key person leaves, what knowledge walks out the door with them?

Current Status

Right now this is in the early design phase. I have the data model sketched out and a proof-of-concept running locally. The next step is building the ingestion layer that pulls from Jira's API.

If you are a program leader who has felt the pain of zero visibility into team capacity, you know why this matters. The answer is not more spreadsheets. It is better systems.