Sometimes the First Ask is the Wrong Ask
How listening for Red Flags in a request exposed a team's real problem
As a coach, I rarely got asked to solve problems—only to implement solutions teams hoped would fix their problems. People normally don’t come to you with a problem they need solved. Instead, they approach with a solution they would like you to implement in hopes it will solve their problem. The hallmark of a great coach is the ability to see past the initial request and gently ask questions to work through the frustration to the original issue or problem. This is critical because, more often than not, implementing the requested solution doesn’t solve the problem. Today’s tidbit is a story about a request for a solution, a conversation to dig to the heart of the issue, and a response that still warms my soul.
📖 The Story
I can still remember the first few minutes of the conversation. Tyler, the leader of the team was literally rubbing his forehead. It was one of those head rub motions you expect when someone is out of answers. You know what I'm talking about.
Tyler mentioned the cause for his frustration was he had missed something in the team’s backlog and he would like my help to build him an automated notification whenever a new item was requested. (As a reminder, I help teams visualize their work using digital workflow apps like Jira, Trello, Asana, etc.) For my friend, all incoming requests landed in the teams digital backlog and he had recently gotten a call from a stakeholder asking about one such item. The leader had assigned an arbitrary date and Tyler was irritated he had missed the item. He needed a way to ensure this would never happen again. Thus the request for an automation.
Experience told me automation was never the real fix. This wasn’t a tech problem—it was a work management problem. Time to dig deeper.
The numbers reinforced.
Review/Testing: 47 items—stale, aging.
In Progress: 38—overwhelming.
Ready for Dev: 110—yikes.
Backlog: 106—buried alive.
They had more work IN FLIGHT, visible on their Kanban board, than they had in their entire backlog.
I started with the Review column. It was quickly evident that work in this activity was stale. Some of it had sat for over 1,000 days. I told Tyler, since that work is so close to being complete, why not take over your next team meeting and do nothing but revisit all 40 and move any that were complete to the Done status.
They moved all but 1 to Done in their next meeting.
They set their sites on Ready for Development column. It seemed like the team was moving items here with no real reason, and then any time someone reached out to prioritize other work, it would bypass this state. I pressed in and asked if any of this work could just be moved back to the backlog. He spent some more time with the team and the next morning when I checked, only 8 items remained. What's stunning is, of the 110 items, 90% of them were moved to the Done status, either cancelled or completed, not the back log.
What happened next was pure magic—the team grabbed a sledgehammer, not a scalpel. In a week, they slashed work-in-flight from 160 to 45. The backlog? Nearly halved. And the best part? 90% of those ‘waiting’ items weren’t waiting—they were already done.
🛬 Landing the Plane
Most people think they need automation when what they really need is visibility. Tyler didn’t have a notification problem—he had a clutter problem. His team wasn’t drowning in work; they were drowning in unfinished decisions. Once they stopped treating their board like a junk drawer and actually cleaned house, the real priorities became obvious.
This happens all the time. We convince ourselves we need a tool to keep up with the chaos, but more often than not, the tool isn’t the problem—the chaos is.
So the next time you catch yourself thinking, If only we had an automation for this... stop and ask: Do I need an alert, or do I need to declutter?
Because, as this team learned, sometimes the best automation is just finishing what you started.
Until next time, Keep Learning, Keep Growing