I Was Relieved to Find Out He Was Playing Video Games at Work.

At a company I worked for, I had a developer whose work kept slipping. I went hands-on: walking through the story he had picked up, making sure he understood it, helping him break it into tasks, helping him estimate the hours. When the estimates ran short, I adjusted them upward myself, giving him more room on each subtask. Nothing landed on time anyway. There was always an excuse.

Then IT sent me a note. He had been playing video games on his work laptop, for hours at a time, during the hours he was supposed to be working. My first reaction was relief. Not anger, not disappointment: relief, because it meant the missed deadlines had nothing to do with my coaching and everything to do with him simply not putting in the time.

That relief is worth sitting with, because it exposes something uncomfortable. Until that note arrived, I had no way to know which explanation was true. I was coaching him with no actual signal either way: no evidence the coaching was working, no evidence it was failing. I was guessing, and the answer only reached me because a source entirely outside the coaching relationship, IT, surfaced something I had no way of seeing on my own.

The common instinct when a report keeps missing deadlines is to read it as a capability gap and accommodate: more time, clearer task breakdowns, bigger estimates. Most managers who have coached someone genuinely struggling have gone through exactly that escalation, each accommodation reasonable on its own, none of them actually telling you whether the coaching is working.

So what would it have looked like if the coaching had been working? That is harder to answer than it sounds, because the point of coaching someone is that they eventually stop needing you for a category of judgment. The signal that it is working is not something they produce. It is something they stop bringing to you. That is a real artifact, and it is trackable in principle. It is the mirror image of what I call The Escalation Default, the pattern where decisions keep routing up to a leader because nobody ever made the boundary explicit. When coaching works, that pattern runs in reverse: a decision that used to land on your desk simply stops arriving. Not a document. Not a ticket. An absence. Nothing in any system built to measure a manager's work is designed to notice something that stopped happening. Tickets get closed. Documents get written. A decision that no longer arrives leaves nothing behind for any of those systems to catch.

You cannot wait for an outside signal to tell you whether coaching is working. What you can do is track the one thing that actually is trackable: name the decision categories that used to reach you from someone specific, and check, deliberately, whether they have stopped arriving. If you cannot name one, you do not have evidence either way. You have a guess, the same guess I was making, until IT surfaced something I could not have seen on my own.

Name one type of decision that used to reliably land on your desk from someone you have coached. Has it stopped? If you have to pause and think about it, you do not have an artifact for your coaching. You have a guess, and you are waiting on your own version of an IT note to tell you whether it was right.

TeamOS™ has the practical installation for tracking exactly this, so you are not left waiting on an outside signal to find out whether your coaching actually worked: https://TeamOS.Coach