Why I Finally Stopped Tracking My Engineering Team in Excel and What I Did Instead

Tracking your engineering team in Excel while Jira sits open in another tab. If that sounds familiar, this article is for you.

It was a Wednesday morning standup.

Eleven engineers on a fintech project. Solid team. Real pressure. The kind of week where things are either coming together or quietly falling apart, and you will only find out which when it is too late.

Before the call, I did what I always did. Opened Jira. Scanned the board. Then opened my Excel sheet on the side.

Wait. Excel? Why was I still opening Excel if we had Jira?

That question sat with me for days. And honestly, the answer to it is what this article is really about.

We Had Jira. It Was Not Enough.

Let me say this clearly before anything else: Jira is not a bad tool. It is a powerful, widely-adopted tool that works well for many teams.

But for me, as a lead managing a 10-person engineering team, Jira had a specific problem.

It gave me a board. It did not give me answers.

I could see cards in columns. I could see statuses. But I could not open Jira and ask: "Which tickets have been stuck in Review for more than five days?" I could not click one button and get a risk assessment of where the project stood. I could not look at a single screen and immediately know who was overloaded, what was blocking what, and whether we were heading toward a problem.

For all of that, I was doing mental arithmetic. Every day.

And that is exactly why the Excel sheet was still open.

The Real Reason Engineering Leads Keep a Spreadsheet Next to Jira

This is a pattern I have seen across teams, companies, and industries. The official tool is Jira. The real tool is a spreadsheet sitting next to it.

Nobody talks about it openly. But it happens everywhere.

Here is why.

Jira is built for tickets. Not for leads.

Jira tracks the state of work. It does not interpret that state for you. It does not raise a flag when three tickets are all blocked on the same dependency. It does not tell you that Priya has seven open tickets while Ankit has two. It does not surface the fact that a blocker added last Tuesday has been sitting there, untouched, for six days.

You have to go looking for all of that. You have to build filters, set up dashboards, configure reports. And even after all of that configuration, you still end up with a view, not an insight.

So what did I do? What do most leads do?

We built a parallel system. A simpler one. One we could control.

An Excel sheet.

How the Excel Sheet Was Born

In my case, it started small.

Some teams run sprints. Some run Kanban. Some run a loose hybrid where work just flows in and gets picked up. The process varies. But one thing stays constant across all of them: the lead still needs to know what is happening.

And that need is where the Excel sheet is born.

For me, it started during a Scrum project. New sprint, twelve tickets. I created a quick sheet with ticket IDs, assignees, statuses, and a notes column for blockers. Took ten minutes.

Two sprints later, the sheet had grown. Columns for dependencies. A column for "last updated." A color-coded blocker flag. A separate tab for team availability.

Then I moved to a different project running Kanban. Continuous flow, no sprints, work coming in from multiple streams. I rebuilt the sheet for that model. Different columns, same habit. Same daily maintenance. Same morning ritual.

By that point I had stopped asking why I was maintaining the sheet. I just accepted it as the cost of leading a team.

Let me be precise about what that cost actually was.

I was spending 20 minutes every morning updating the sheet. And another 15 minutes before every standup reviewing it.

I was manually rebuilding the picture of my own project. Every single day. Regardless of whether the team was running Scrum, Kanban, or something in between. Because the picture that Jira gave me was not complete enough to trust without verification.

That is not a process problem. That is a tool problem.

What Was Actually Breaking

I want to be specific here, because vague complaints do not drive change. Specific pain does.

Scenario 1: The Invisible Blocker

Ticket TK-014 was marked as blocked in Jira. Karan had added the blocker flag. But in Jira, a blocker is just a field. It has no age. It has no urgency. It does not scream at you from the board.

I found out in the standup, four days after it was raised, that TK-014 was blocking two other tickets. Two days of work were already lost on those downstream tickets because nobody connected the dots. Including me.

In my Excel sheet, I would have caught it earlier. Not because Excel is smarter than Jira. But because I was manually reviewing every row every morning, forcing myself to read through it.

The irony is painful. I was compensating for my tool's gaps with my own manual effort.

Scenario 2: Who Is Overloaded Right Now

Midway through a heavy delivery cycle. Deadline tightening. I needed to redistribute work fast.

I asked myself: who has bandwidth?

In Jira, I had to go engineer by engineer. Open each person's filter. Count open tickets. Note their statuses. Do this for ten people. Then compare mentally.

In my Excel sheet, I had a column for ticket count per person. I could see it in one glance.

Again, the sheet was winning. But I was the one maintaining it. At a cost.

Scenario 3: The History Question With No Clean Answer

A delivery manager asked me: "When did TK-008 move from In Progress to Review?"

I opened Jira. Found the ticket. Scrolled through the activity log. Jira does log changes, but the activity feed is cluttered. Comments, attachments, mentions, and status changes all mixed together. Finding the exact moment a status changed required scrolling and squinting through noise.

My Excel sheet had no history at all. I had overwritten the status when it changed.

Neither tool gave me a clean, instant answer.

Scenario 4: "How Many Tickets Did We Close in the Last 15 Days?"

Simple question. Asked by a senior stakeholder before a review meeting. Completely reasonable.

I went to Jira. Pulled up the filter. Set the date range. Got a number.

Then I looked at the tickets in that list and noticed something uncomfortable. Three of them were marked Done but the work was not actually complete. One engineer had closed the ticket when the code was merged but before QA had signed off. Another had moved a ticket to Done because "it is mostly done." A third was a duplicate that should have been cancelled but was closed instead.

Jira reported 18 tickets closed. The real answer was closer to 14.

And here is the root problem that nobody says out loud: Jira's reporting is only as accurate as the data your team puts in. Whether you are running Scrum, Kanban, or any other process, you are still depending on individual engineers to update fields correctly, every time, under pressure. In a 5-15 person team, that does not happen consistently. People forget to update fields. They use statuses loosely. They close tickets early. They write blockers in comments instead of the blocker field.

So when you try to extract a meaningful number from Jira, you are not extracting truth. You are extracting whatever your team happened to enter, filtered through whatever workflow someone configured months ago.

In Excel, at least I was the one entering the data. For a small team, that meant the numbers were more reliable because one person controlled what went in. But extracting anything beyond what you could see directly in the rows was painful. Want to know how many tickets moved to Done in the last 15 days? You were manually counting. Or building a formula. Or giving up and estimating.

On a Kanban board with continuous flow and no sprint boundaries, this problem is even worse. There is no natural "end of cycle" moment where you tally things up. Work just flows. And unless you have a clean, reliable way to query that flow, you are always approximating.

Both tools made a simple question unnecessarily hard.

The Gap That Neither Tool Was Closing

Here is an honest picture of what I was working with versus what I actually needed as a lead:

What Jira gave me:
+----------------------------------------------------------+
|  A board with cards in columns                           |
|  Individual ticket details when you click in            |
|  An activity log buried inside each ticket              |
|  Dashboards you have to build and maintain yourself     |
|  Reports you have to configure and then interpret       |
+----------------------------------------------------------+
Useful. But requires significant effort to extract answers.

What Excel gave me:
+----------------------------------------------------------+
|  A fast, flexible view I could shape to my own needs    |
|  A snapshot that I manually kept current                |
|  No history, no intelligence, decays fast               |
+----------------------------------------------------------+
Fast. But fragile and entirely dependent on my daily effort.

What I actually needed as an engineering lead:
+----------------------------------------------------------+
|  Live project state in one clean view                   |
|  Blocker visibility with age and downstream impact      |
|  Dependency chains surfaced automatically               |
|  Workload distribution across the team at a glance      |
|  Full change history per ticket, without digging        |
|  One-click health check of the project                  |
|  Ability to ask questions in plain English and get answers|
+----------------------------------------------------------+
Works the same whether your team runs Scrum, Kanban, or anything else.
Neither Jira nor Excel was giving me this. So I was using both. Badly.

This is the gap most engineering leads live in. Not because they are doing something wrong. But because the tools were not designed for their specific job.

Why I Did Not Just Configure Jira Better

The obvious response here is: Jira is configurable. You could have set up better dashboards, filters, custom fields.

I tried that too.

I spent two hours one evening setting up a Jira dashboard with four gadgets. Project health, open blockers, ticket throughput, and a filter for tickets by assignee. It looked good.

A few weeks in, two of the four gadgets were showing stale data because someone had changed a custom field name. The throughput chart was inaccurate because a few engineers were not updating statuses consistently. The blocked tickets filter was missing some blockers because engineers were using a comment instead of the blocker field.

It did not matter whether the team was doing Scrum or Kanban. The problem was the same. The dashboard was only as good as the discipline of ten engineers keeping every field updated correctly. Every time. Without exception.

That discipline does not exist sustainably on a real team under real pressure.

And that is not a people problem. That is a system design problem.

The tool was putting too much responsibility on individuals just to give the lead a clean picture.

What Changed When I Stopped Patching and Started Solving

I built LeadrEye specifically for this problem.

Not another enterprise project management platform. Not a tool your organisation adopts top-down. Specifically built to close the visibility gap for the engineering lead in the middle, the person managing a 5 to 15 person team who needs answers, not more configuration.

Here is what the actual change felt like:

Blockers became impossible to miss. When a ticket is blocked, the row turns red. Not a field you have to search for. A row that demands your attention the moment you look at the board. The blocker has a description. You know immediately what it is and why.

Change history became automatic. Every field change on every ticket is logged with a timestamp. When did this move to Review? Who changed the assignee? How long has this sat in In Progress? One click. No scrolling through mixed activity feeds.

Health reports replaced my morning spreadsheet ritual. One click. Green, Amber, or Red. Blockers analysis. Workload distribution across the team. Recommended actions. The system reads the project state and tells me what matters. What used to take 35 minutes now takes thirty seconds.

Ask Anything replaced my mental arithmetic. Before standups, I type in plain English. "Which tickets have been in Review for more than five days?" "Who has the most open tickets right now?" "What is blocking the release?" Precise answers. No filters to build. No columns to scan. No mental math.

The standup became a standup again. Not a catch-up session where I am scrambling to rebuild the picture I should have already had.

One Thing Worth Being Clear About

LeadrEye is not a replacement for Jira. Or Asana. Or ClickUp. Or any other project management tool your organisation uses.

If your company runs Jira at scale across multiple teams, release trains, and cross-team dependencies, keep Jira. It is doing a job that nothing else does at that scale. Same for Asana or ClickUp if your organisation has standardised on those.

LeadrEye is something different entirely. It is a personal tool. A private space for the engineering lead, the person managing a team of 5 to 15 engineers who needs clarity about their own project, right now, today.

Think of it the way you think about a personal notebook. Your organisation might have Confluence for documentation. But a good lead still keeps a notebook where they track what they are watching, what they are worried about, what they noticed in today's standup. Not because Confluence is bad. But because there are things you need to see quickly, personally, in your own format.

LeadrEye is that space, built specifically for how engineering leads think. Not for your Scrum Master. Not for your PMO. Not for your CTO's dashboard. For you, as the person responsible for a group of engineers shipping work under pressure, regardless of whether your team runs Scrum, Kanban, or something in between.

It sits alongside whatever your team uses officially. It does not replace it.

The Bigger Pattern Here

I have written before about how IT projects fail not because of bad code but because of communication gaps between teams. The same principle applies here, one level closer to the ground.

A lead who does not have a clear picture of the project cannot make clear decisions. And a lead who is spending 35 minutes every morning manually assembling that picture is not leading. They are administrating.

A blocker that sits for four days without escalation is not an engineer's failure. It is a visibility failure. The lead did not see it early enough.

A ticket nobody picked up because everyone assumed someone else would is not a people problem. It is a system problem. The system did not surface the gap.

The right tool is not the one with the most features. It is the one that gives you the picture you need, in the time you actually have.

Is This Your Monday Morning Too?

If you are leading an engineering team right now and any of this is familiar, the parallel spreadsheet living next to Jira, the standup where you are catching up instead of leading, the blocker you found out about four days too late, the Jira dashboard you built that nobody maintains properly, then you already know what I am describing.

LeadrEye has a fully working demo with no sign-up and no credit card required. Project Phoenix is already set up with ten tickets, five team members, active blockers, dependencies, and full change history. Open it and see if the view feels different from what you are working with today.

Frequently Asked Questions

Is Jira enough for managing a small engineering team?

Jira works well for tracking tickets and managing work at scale. But for a lead managing a 5-15 person team, it often does not provide the instant visibility needed to spot blockers early, assess team health quickly, or ask plain-English questions about the project. Most leads end up maintaining a parallel spreadsheet alongside Jira to fill that gap.

Why do engineering leads still use Excel when they have Jira?

Because Jira requires significant effort to extract answers from. Building filters, dashboards, and reports takes time, and those tools only work if every engineer updates fields correctly and consistently. Excel gives the lead a faster, more personal view they can control themselves. The problem is that Excel has no intelligence, no history, and decays as the team grows.

What is the difference between LeadrEye and Jira?

Jira is an organisation-wide project management tool built for tracking work across teams. LeadrEye is a personal tool built specifically for the engineering lead managing a 5-15 person team. It gives instant blocker visibility, automatic change history, one-click health reports, and plain-English queries about the project. It sits alongside Jira rather than replacing it.

Does LeadrEye work for Kanban teams as well as Scrum teams?

Yes. LeadrEye is process-agnostic. Whether your team runs Scrum, Kanban, or a hybrid flow, the core need is the same: the lead needs a clear, current picture of who is doing what, what is blocked, and where the risks are. LeadrEye provides that regardless of the methodology.

How long does it take to set up LeadrEye?

Under two minutes. Add a project name, add your team members with their roles, and start adding tickets. There is also a fully working demo called Project Phoenix with no sign-up required, so you can explore it before creating anything.

One Last Thing

This blog has always been about real problems and honest lessons. Things I have lived through, made mistakes in, and eventually understood clearly.

This one is no different.

Jira did its job. Excel did its job. The problem was that neither was doing my job. As a lead, my job is to see the whole picture, spot the risks before they become incidents, and move the team forward with clarity.

No tool can do that thinking for you. But the right tool stops making it harder than it needs to be.

If this resonated, you might also find this useful: Why On-Call Friendly Systems Are the Real Measure of Good Architecture. Different context, same idea underneath. Visibility is everything.

And if you have ever wondered why your well-organised project still feels chaotic, this one might explain it: Why Communication Breakdown, Not Infra, Is the Real Root Cause of System Failures.