Getting your data into an engineering insights platform: what setup actually involves
What to connect, who to involve, and where setup gets hard: a practical guide for engineering leaders.
Taylor Bruneaux
Analyst
Engineering leaders invest in an insights platform to answer specific questions. Where does delivery slow down? How are AI tools changing the way teams work? Which teams need support first?
Whether they get those answers depends less on the platform’s reports than on the data underneath them. Setup is where measurement programs either build momentum or stall.
In our conversations with engineering organizations evaluating and rolling out DX, the most common questions are not about dashboards. They are about who needs to be involved, how to connect tools that don’t fit a standard integration, and how much manual work it takes to keep the data accurate.
This guide covers what it takes to get your data into an engineering insights platform. It explains what to connect, where the hard parts are, and how to plan around them. The patterns come from real onboardings, and the approach applies whichever platform you choose.
Start with what a complete view requires
Before connecting anything, be clear about what you are trying to measure. The DX Core 4 measures engineering performance across four dimensions: speed, effectiveness, quality, and impact. No single data source covers all four, which is why measuring developer productivity requires more than one kind of signal.
System data shows what happened: pull requests merged, deployments shipped, incidents resolved. Developer-reported data explains why: where developers lose time, which tools slow them down, and what gets in the way of deep work. A complete view of engineering performance combines both.
This matters for setup because it determines what you connect first. Most organizations need three kinds of data in place:
- Tool data from the systems where engineering work happens
- People data that links each person’s activity across those systems
- Team data that rolls individual activity up to the teams and leaders who act on it
The tool connections are usually the fastest part. People and team data are where most of the effort, and most of the long-term accuracy, comes from.
Before you start: who you need and what to gather
The person sponsoring a measurement program rarely owns the systems that hold the data. A director of engineering may champion the effort, while GitHub, Jira, and the HR system each belong to a different team. Identifying those owners early is the single biggest factor in how quickly setup moves.
Who | What they provide | Why it matters |
Security and legal | Review of data processing, retention, and compliance documentation | Approval is usually the longest lead-time item |
Tool administrators | API tokens or app installs for source control, issue tracking, CI/CD, incident, and AI tools | Each tool typically has a different owner |
Org chart owner (HR, engineering ops, or a chief of staff) | A current list of who reports to whom | Determines whether data rolls up to the right teams |
Chat workspace admin | Permission to install the platform's app in Slack or Microsoft Teams | Needed for surveys and for identifying participants |
Before kickoff, gather three things. The DX start guide covers the same prerequisites in more detail.
- A list of every tool you want to measure, including older or custom systems
- Credentials or a named owner for each one
- An org chart, spreadsheet, or HRIS export showing team membership and reporting lines
Approvals usually take longer than the technical work. Start the security review first. Team setup and developer surveys can then move forward while tool approvals are still pending.
Connect your core tools
Most organizations start with five categories of tools. Each one feeds a different part of the picture.
Tool category | Common examples | What it powers |
Source control | GitHub, GitLab, Bitbucket, Azure DevOps | PR throughput, cycle time, review turnaround, new hire ramp-up |
Issue tracking | Jira, Linear, Azure Boards | Investment allocation, initiative progress, planning accuracy |
CI/CD | GitHub Actions, CircleCI, Buildkite, Harness | Deployment frequency and lead time for changes |
Incident management | PagerDuty, Opsgenie, ServiceNow, Datadog | |
AI coding tools | GitHub Copilot, Claude Code, Cursor, Codex | Adoption, usage, and AI impact |
In DX, each tool is connected once from the connections page, using any of the supported data connectors. Connectors are read-only, and the same connection feeds every report that uses that data.
Three details cause most early surprises:
- Credential scope sets visibility. A connection only sees what its credential can access. If a token covers half your repositories, reports will reflect half your organization.
- AI tools vary in how they report. Some, like Claude Code telemetry, only show a user after that person’s client starts sending data. Others report per-user data only when developers use an enterprise workspace rather than individual API keys.
- Tracker structure shapes reports. Initiative views depend on how teams use Jira, such as whether epics are linked to initiatives. Imperfect hygiene should not block connecting. It shows you where to improve.
AI tool data deserves particular care. The DX AI Measurement Framework pairs usage data with developer-reported time savings and quality signals. Without reliable per-user data, it is difficult to connect AI adoption to outcomes.
Map people across systems
The same developer appears as a GitHub username, a Jira account, a Slack profile, and an AI tool user. An insights platform has to recognize all of these as one person. Without that link, a developer’s pull requests, tickets, and survey responses cannot be analyzed together.
Email is the natural way to match identities, but many tools do not expose work email through their APIs.
Tool | How identity is typically matched |
GitHub | Work email on Enterprise Cloud with a verified domain; otherwise usernames must be supplied |
GitLab | Usernames must be supplied |
Jira Cloud | Email, when accounts are managed by your organization |
Bitbucket Cloud | Linked through the associated Jira account |
AI coding tools | Email when the tool provides it; manual linking otherwise |
DX links users by email automatically wherever possible. Where it cannot, usernames can be set in bulk through a CSV, the API, SCIM, or directory sync. Teams can also link several accounts to the same person, which matters when a developer has both a personal and a work GitHub account.
Plan for this step explicitly. Ask which of your tools expose work email, and assign someone to review unlinked users after the first sync. Unlinked users are invisible in team-level reporting.
Set up teams and keep them current
Metrics are only actionable when they reach the leaders responsible for them. That requires a team hierarchy that reflects how your organization actually works, not how it looked at the last reorg.
A few principles make the initial setup reliable:
- One manager per team. If teams have both an engineering manager and a product manager, choose one role as the team lead and apply it consistently.
- Start from an export of your org data. A CSV of contributors, team names, and manager emails is the most common starting point.
- Use stable team identifiers. Consistent IDs let a platform recognize the same team across updates and preserve its historical trends when membership changes.
- Confirm everyone is reachable. People who are not in the chat workspace where the platform’s app is installed will not appear as contributors.
The most common mistake is treating team setup as a one-time upload. Organizations change constantly, and a hierarchy maintained by hand drifts out of date. Customers tell us that re-uploading spreadsheets after every reorg is one of the most frustrating parts of ongoing maintenance.
In DX, teams can be created in the app, uploaded as a CSV, or synced through an API. Once the API workflow is tested, it can run on a schedule from your system of record, so the hierarchy stays current without manual uploads.
When your stack isn’t standard
Few large organizations run only modern SaaS tools. Many have an on-premises source control server, a legacy monolith, an internal deployment system, or an issue tracker without a native integration. These systems often hold some of the most important data.
There are four common situations, and each has a different path:
Situation | Typical approach |
A self-hosted version of a common tool, such as Jira Data Center or Bitbucket Data Center | Use the platform's native connector for that version |
A system behind a firewall or VPN | Allowlist the platform's IP addresses, route requests through a network proxy, or run a self-hosted extractor that pushes data out |
Deployments, incidents, or pipeline runs from an internal tool | Send events to the platform through its API as they happen |
Any other data, such as usage exports or quality checks | Load it into custom tables and join it with connector data in SQL |
Two questions are worth asking any platform you evaluate. First, can it accept data from systems it does not natively support? Second, can that data be tied to people and teams? Custom data needs a shared identifier, such as an email address or username, to appear in team-level reporting.
Organizations with strict data requirements may also need more than standard multi-tenant hosting. DX offers single-tenant hosting, as well as deployment into a cloud account the customer owns.
Phase this work. Connect core tools first and establish a baseline. Then add custom sources once you know which questions they need to answer.
How long it takes
The technical work of connecting tools is measured in hours. The elapsed time is driven by approvals, the number of tools, and the size of the organization.
A typical rollout follows four phases, but timing can substantially differ depending on the complexity of your teams and setups.
- Week 1: Kickoff. Identify tool owners, begin security review, and gather the org chart.
- Week 2: Core integrations. Generate credentials, connect core tools, and upload the team hierarchy.
- Week 3: Validation and first survey. Confirm data has arrived, review unlinked users, and send the first developer survey.
- Week 4: Review. Walk through the baseline with leaders and decide where to focus.
The effort on the customer side is usually modest, often one or two administrators for a few hours. Smaller organizations, or those running a pilot with one or two teams, can move faster.
What extends timelines is rarely technical. It is a pending approval, an unclear tool owner, or a team hierarchy that has to be rebuilt from scratch.
Where to focus next
The goal of setup is not complete data on day one. It is a reliable baseline that leaders trust enough to act on.
The organizations that get there fastest share a few habits:
- They set expectations early. They identify which steps will be manual, such as identity linking for some tools or mapping services for DORA metrics, and plan owners for them up front.
- They start narrow. One or two teams with clean data produce a more credible first result than an entire organization with gaps.
- They automate what changes. Team hierarchies and user attributes stay accurate when they sync from a system of record rather than a spreadsheet.
- They pair system data with developer voice. Connected tools show where work slows down. Developer surveys show why.
If you are planning a rollout, start by listing your tools and their owners, then confirm which ones expose work email. Those two steps surface most of the setup work before it becomes a delay.