Getting started with Span: for engineering managers and leaders

This guide helps engineering managers, team leads, and directors get started with Span: where to find your teams, which reports to open first, and how to use them.

Why it matters

Span shows how work flows through your teams, from your Git host, issue tracker, calendars, and AI coding tools. Use it to unblock work, protect focus time, track AI adoption, prepare for 1:1s, and back requests with evidence.

Span works best at the team and process level. A number about one person leaves out context such as on-call weeks, mentoring, or a hard migration, so treat individual numbers as the start of a conversation, never a ranking.

Talk with your team early about what Span is for: spotting blockers, balancing workload, and improving how the team works. Make clear it isn't for stack-ranking people and doesn't replace talking with them.

Your first 30 minutes

1. Sign in. See Signing in to Span.

2. Find your team. In the sidebar, go to Organization → Teams and open your team. Overview summarizes the week; Metrics goes deeper. On a team without sub-teams, click Subscribe on the Overview to get a Weekly Update email for that team. If you lead a team with sub-teams, Subscribe isn't available there; build a custom dashboard or schedule a Playbook instead.

3. Check that the numbers look right. Open the reports for your biggest pain points (see the table below), filtered to your team, and confirm they match what you know. If someone is missing or a team looks wrong, tell your Span admin.

4. Check your Targets. Click Targets at the bottom of the sidebar. On Manage, you can adopt, adjust, or switch off targets for your teams. Targets aren't on by default; your Span account team can set up a starter set. Start with no more than three.

5. Set up your digest. Once a team you belong to or manage has adopted a target, go to Settings → Personal → Notifications and, under Email, turn on Manager Target Digest, a daily email on your teams' targets. If you manage other managers and your organization uses Workstreams, Manager Weekly Wrap appears there too.

6. Try Src. Src needs the Use Src permission, which Owners and Admins have by default; for anyone else, an admin adds it to a permission group. Open Src in the sidebar and ask "Which of my team's pull requests waited longest for a first review last month?" Src cites its sources and runs with your permissions, so it names individuals only when you can see their data in Span.

Pick one or two pain points

Start narrow: choose the problems your teams feel most and focus your first weeks there. Reports marked Productivity are under Insights → Productivity.

For each one, set a baseline and a goal. If Span has turned on industry benchmarks for your organization, use Industry P50 as a baseline and Industry P75 as a goal; otherwise, start from your team's own last quarter. Then adopt or adjust a Target so Span flags when the team drifts. See Benchmarking in Span.

Use cases

• Unblock work and spot review bottlenecks. PR lifecycle splits cycle time into Coding, Awaiting First Review, Reworking, and Idling. A long Idling stage, for example, means finished PRs sit with no new commits, reviews, or comments before someone merges them. Review capacity shows who carries review load and how evenly it's shared.

• Understand AI tool adoption. Tool utilization shows active users and AI Days / week by team. Use it to find teams that need help getting started.

• Agree on team norms. Targets turn a metric into a team agreement, such as a first review within 48 hours, measured over a rolling 7 days. If your organization connects Slack, Span nudges the PR author or reviewer before a PR goes stale.

• Hear from your team. Surveys live under Insights → Sentiment for people with the Manage Surveys permission; if you don't have it, ask whoever runs surveys at your organization. Run a developer experience survey or the Agent Readiness Survey. An Anonymous survey shows no results until at least 4 people respond, and the bar rises when you slice by more attributes.

• Have better 1:1s and celebrate wins. Open a person from Organization → People. Activity Log lists their commits, pull request reviews, and completed issues. Brag Sheet summarizes their work once they have 3 months of history (see Brag Sheets: summarize your work for reviews and 1:1s). With Src access, choose Generate → Tailor with Src to focus it on a purpose or impact area. Share it with the engineer first so they can add context.

• Get updates on a schedule. A Playbook runs a Src prompt on a schedule you write in plain English, such as "Every Monday at 9am", and delivers the result by email, to a Slack channel, or by Slack DM. Start from a template, save it, then click Test Run to check the output; only the playbook's owner sees that button.

• Make the case for change. A quarter of trend data, such as review wait growing with the team, makes a headcount or process request concrete. Build a view in Custom reports or Custom dashboards under Productivity, or ask Src to draft the summary.

Build it into your week

Who sees what

• You: Span adds you to the Managers permission group when someone reports to you. By default, it lets you see team-level reports for every team, and individual data for the people on your teams and everyone in your reporting line. Team Leads see the same, but by default can't change Targets or build custom reports.

• Engineers see their own data and team-level reports for their own teams.

• Src and Playbooks: Src answers with the asker's own permissions, in Span and in Slack, so an engineer asking about a teammate gets team totals, not the teammate's numbers. Survey responses need Manage Surveys, and agent trace data needs the Agent Trace permissions. A Playbook runs with its executor's access, so if you post one to a team channel, everyone there sees what your permissions allow.

• Agent traces: if your organization uses them, pages such as Traces, AI investment, and Harness health need separate Agent Trace permissions. Prompts and transcripts are private to the engineer by default.

• Your organization's admins control all of this. When a report says "You are seeing a limited set of data based on your permissions.", click Learn more to open My Permissions.

Things to know

• Some reports depend on your setup, such as Jira for Sprint Tracking or calendars for Focus time. If you don't see one, ask your Span admin.

• Data isn't live. New work shows up within a few hours, and history starts at the start date set for your organization.

• Who counts: per-person "/ week" metrics include only people marked as Contributors and leave out out-of-office days, and work counts only once a person's GitHub or GitLab username is linked. If someone's work is missing, ask your admin to check both.

• Read trends over weeks. For example, the Time to First Review target uses the 75th percentile of the past 7 days. If your team merges 8 pull requests in a week, that value sits between the 6th and 7th fastest, so 2 or 3 slow reviews can push it over 48 hours even when the rest moved quickly. Look at 4 to 6 weeks before you act.

• Small teams swing more. On a team of four, one vacation or one large PR moves the averages, so compare a team with its own history first.

• Ask before assuming. A spike may be a large refactor, a migration, or time off. Ask the team before you draw conclusions.

Related articles

• Getting started with Span: for engineers

• Targets: set team goals and get notified when work slips

• Summary Notifications

• Custom Reports Guide

• Roles & Permissions in Span

• What determines contributor status in Span user profiles?

• Using Src to understand your engineering metrics

• Using Src Playbooks

Need help?

Ask your internal Span admin about access and permissions. For anything else, contact your Span account team or reach out to support@span.app.