The Engineering Manager's Guide to Cross-Tool Visibility

As an engineering manager, you're responsible for visibility. You need to know: what's your team building? What's the progress?

What's blocked? What's at risk?

The problem: your team's work lives in multiple tools. Some teams use Jira because of client requirements. Some use Linear because it's developer-first.

Some still use GitHub Projects. Code lives in repositories. Docs live in Confluence.

You can't force your team to consolidate their tools. But you need to maintain visibility across all of them.

The Manager's Information Needs

You don't need the same information as individual engineers. Engineers need task details and code review. You need:

• Team velocity - Are we moving faster or slower than last week?
• Blocking issues - What's stuck? Who's stuck?
• Resource allocation - Is anyone overloaded? Underutilized?
• Risk signals - Are we going to miss deadlines?
• Team health - Is morale okay? Is anyone struggling?
• Progress toward goals - Are we on track for the quarter?

Most of this you can get from dashboards and syncs, not from diving into individual tasks.

Creating Your Command Center

You need one place you check daily for team health. This might be:

A Jira/Linear dashboard - If your team is primarily in one tool, customize it with:

• My team's current sprint
• Burndown chart
• Blocked issues
• Overdue items
• Team members' current workload

A spreadsheet - If your team is across tools, create a weekly summary:

• What each person is working on
• Estimated completion
• Blockers
• Status (on track, at risk, complete)

Huddle or similar - If your team is split across Jira, Linear, and GitHub:

• Unified view of all team tasks
• Filter by person
• See what's in progress, blocked, complete

The tool matters less than having one place you check daily. Don't force yourself to look at multiple dashboards. Create or find one that shows you what you need.

The Daily Standup (Still Matters)

Even with dashboards, you need synchronous communication. But make it efficient.

15 minutes. Three questions:

1. What did we ship yesterday?

What blockers exist? What's the plan for today?

You already know answers to these from your dashboard. The standup is for: catching things the dashboard doesn't show, team connection, and decision-making on blockers.

If your dashboard is good, the standup becomes very quick because you're not hunting for status.

One-on-Ones and Individual Visibility

Weekly one-on-ones are where you get individual context. This is separate from sprint dashboards.

In one-on-ones, ask:

"How's your current work going? Anything you need from me? How are you feeling about the project?"

You're not asking for status - you already have that. You're asking about their experience.

Are they blocked? Frustrated?

This is where you catch stuff that dashboards miss. Someone might be completing tasks on time but really struggling with the work. Or bored. Or taking on too much.

Managing Across Multiple PM Tools

If your team uses both Jira and Linear (common for teams with client and internal work):

Establish ownership - Jira is for client-facing work. Linear is for internal engineering. Don't duplicate.

Create bridges - When client requirements come in via Jira, they should link to engineering tasks in Linear. When engineering completes work, Linear should link back to Jira.

Check both dashboards - You should check both daily. But not five times daily. Once in the morning. That's enough.

Schedule tool-specific syncs - Once per week, review Jira for client health. Once per week, review Linear for engineering health. Separate from standup.

Handling Code and Tools

Engineering also happens in GitHub/GitLab. Code reviews, pull requests, CI/CD pipeline.

You don't need to review every PR, but you should understand:

• How many PRs are waiting review? (Indicator of bottleneck)
• What's the typical review time? (If it's increasing, you might have a process problem)
• What's failing in CI/CD? (Blocker indicator)

GitHub has dashboards for this. Check them weekly. If something looks wrong, ask the team about it.

The tool isn't the point. The point is understanding what's happening. GitHub dashboards show you CI/CD health.

Jira/Linear show you task progress. You need both.

The Risk Signal System

Create a simple system for how risk gets communicated:

• Green: On track, no issues
• Yellow: At risk, needs attention but not blocked
• Red: Blocked or will miss deadline without action

In your daily dashboard, you should see any red items immediately. Those get addressed in standup or directly with the person.

Yellow items get discussed at the weekly sync or one-on-one.

Don't wait for people to escalate risk. Have a visible system and check it daily.

Planning Across Tools

When planning sprints, you need input from multiple sources:

• What's in the backlog? (Jira/Linear)
• What code needs to ship? (GitHub)
• What technical debt exists? (Jira, usually in a tech debt epic)
• What are the team's capacity and constraints? (Your knowledge from one-on-ones)

Your sprint planning output should go into whichever tool is your source of truth, and be visible in your other tools via links or automation.

This is where the handoff system matters. Work should have a clear home (usually Linear for most teams) and links to related work in other tools (GitHub commits, Jira for client context).

Scaling to Multiple Teams

If you manage multiple teams:

Create a team-level dashboard for each team plus an org-level dashboard that rolls up from all teams.

The team-level dashboard is what you check daily for that team. The org-level dashboard is what you check weekly or send to your leadership.

Use the same tool for both - easier than checking ten different dashboards. Spreadsheet works fine for org-level if team-level is Jira or Linear.

The Tools You Actually Need

• Primary PM tool (Jira or Linear) - Daily check
• Code repository (GitHub/GitLab) - Weekly check
• Documentation (Confluence, wiki) - As needed
• Unified dashboard (if multi-tool) - Daily check
• Calendar - For sprint dates and milestones
• Email - For leadership communication

That's it. You don't need a separate tool for everything. You need the tools your team uses, plus a way to see across them.

Common Mistakes Engineering Managers Make

Over-relying on tooling - Tools show what, not why. Talk to your team.

Not checking dashboards regularly - Set a time (9 AM daily) and stick to it. Consistency matters.

Trying to be a developer - You're managing people and progress, not writing code. Stay in your lane.

Forcing tool consolidation - If your team prefers Linear, use Linear. Don't force Jira because it's "enterprise."

Not understanding individual work - Know what each person is doing, not just what the team is building.

FAQ

How do I know if someone is overloaded?

Look at: How many items are in their "in progress"? When are items actually completing?

How are they seeming in one-on-ones? If someone has 10 things in progress and none are completing, they're overloaded.

What should I do if someone is consistently behind?

Talk to them. It might be: the work is harder than estimated, they're blocked and didn't say anything, or they're struggling with something else.

Dashboards don't tell you why. Conversation does.

Should I track individual code commits?

Not usually. You should understand team output (velocity, deployment frequency) more than individual contribution. GitHub stats can be misleading.

How do I prevent status theater?

Trust dashboards and reality more than what people tell you in standup. If someone says they're on track but their tasks aren't progressing, that's a conversation starter.

What if my team uses tools I'm not familiar with?

Ask them to show you. Don't try to be an expert in every tool. Just understand how to read the status view and what blockers look like.

How do I handle tool sprawl with leadership above me?

Document why each tool is necessary. "We use Linear because it's where engineering lives.

We use Jira because it's where client requirements live. I have visibility across both through our dashboards." Don't let them force consolidation without understanding the cost.