The problem with good work

I recently worked with someone on one particular project who is very good at design. The problem was that she was slow, and she didn't communicate much. At first I thought these were two separate problems. I'm starting to think they're mostly the same problem.

There was one incident on this project that made this unusually clear. We had a client meeting scheduled for 2pm. At 1:50pm, the client messaged us. Only then did she say she was going to be about two hours late.

The first thing I thought was: what if the client hadn't messaged? Would they have found out at 2pm? Later? Being late wasn't really the interesting part. People are late. Things happen. The interesting part was that the meeting was being moved because of us, but the client had to be the one to initiate the conversation.

Later, the client suggested another timing. Her response was essentially: "I won't be home yet." And then the conversation stopped. That bothered me for a different reason. There's nothing wrong with saying you can't make a time. But that's only half a message.

The useful version is: "I can't make that time, but I can do 6pm tonight or 11am tomorrow. Would either work?" The difference looks tiny. It isn't. In the first version, you've handed the problem to someone else. In the second, you're helping solve it.

Because no alternative was immediately offered, the timing kept moving around. The client couldn't make the next available day, and a two-hour problem became a three-day problem.

Good communication makes the next action obvious. Bad communication creates more decisions for everyone else.

My first instinct was: She needs to communicate better. That's true. But it's not a particularly useful management conclusion.

"Communicate better" is like saying "be more organised." It describes the outcome you want without telling you what should actually happen differently.

The better question is: What information does the business need, and when does it need it? If someone is going to be late, when should the client know? If the client proposes a timing that doesn't work, who owns proposing the next one? If something is stuck, when should it be raised? If a deadline is going to slip, how early should that become visible?

Once you ask those questions, this stops being only a people problem. It becomes a systems problem.

So the goal isn't for me to get better at rescuing projects. It's to make problems visible earlier. Because I can work with almost any problem if I know about it early enough. A delay is manageable. A mistake is manageable. Someone being overloaded is manageable. What's difficult to manage is not knowing.

I still think skill matters enormously. But without a sense of ownership, it wouldn't work.

The best people to work with aren't people who never have problems. They're people who make problems visible while there's still time to do something about them. And when they bring you a problem, they try to bring the next step too.

That's ultimately what I want clients to feel when they work with us: I don't have to chase them. They've got it handled. That sounds like a small thing. It probably isn't.