Our CTO was visiting the Vietnam office. I had a problem to raise, so I raised it.
I explained it clearly and I waited for the answer I expected: "OK, I know. I’ll find a way to sort it out."
That’s not what I got.
Here’s the problem. Our company is split into many teams, and each team has only one tester. Before every release, all testers stop what they’re doing and focus on regression testing. That’s the top priority, and it should be. But it also means the testing inside our own teams pauses.
And those same weeks are full of planning meetings. Important ones, where we discuss the features coming next. A tester’s voice matters in those rooms.
So there I was, with two top priorities and only one of me. Every release, the same feeling: whatever I chose, I was letting something else slip.
I’d been carrying this for a while. When the CTO came to visit, it felt like the right moment. Someone with the full picture was finally in the room. So I told him how hard it is to prioritize between regression testing and planning meetings in those weeks.
He listened. Then he asked me something I didn’t expect.
"If it were you, what would you do?"
I said what felt reasonable: maybe the company could balance things better, so testers aren’t pulled in two directions at once.
He asked again.
"So why not you? Why aren’t you the one to coordinate it?"
I’ll be honest. It annoyed me. I smiled and nodded, but inside I thought: then what are leaders for? I had come with a problem, and I was leaving with homework.
It took me a few days to understand why his question bothered me so much.
Without noticing, I had believed that my part ended once I raised the problem. I had spotted it, named it, and brought it to the right person. Solving it was their turn.
A Hiring Story I Almost Forgot
Then I remembered something a former boss once told me about how our company hires.
If a candidate says, "I want to join to learn," they’re turned down right away. The company isn’t looking for juniors to train. It wants senior people. His reasoning has stayed with me: we don’t hire you so we can tell you what to do. We hire you so you can tell us what we need to do.
I put the two stories side by side, and something clicked.
The CTO wasn’t dodging my problem. He was treating me exactly the way the company says it treats its people: as someone who can see a problem and has a view on how to fix it, not someone who files an issue and waits.
The question that annoyed me was, in a strange way, a form of respect.
Raising a Problem Is the Start
I still think raising the problem was right. The CTO needed to know. Silence helps no one.
But now I see it as the first step, not the last. I wrote more about where this habit comes from in Thinking About Ownership. This is the small, everyday version of it.
Raising a problem says: here’s what’s wrong. Owning it says: here’s what’s wrong, here’s what I think we could try, and I’m willing to start. The second one doesn’t need to be a perfect plan. It can be rough. It can even be wrong. But it gives the conversation somewhere to begin.
What changed most was how I hear that question. I used to hear a refusal. Now I hear an invitation.
Before I raise something these days, I try to ask myself the CTO’s question first: if it were up to me, what would I do? Sometimes I don’t have a good answer yet. But even a half-formed one makes me a different kind of person in that conversation.
Think of the last problem you raised, and then waited on. If someone had looked at you and asked, "So what would you do?", what would your answer have been?