Hit the Wall on Purpose

For years, my support team had no database access to the configs or user data behind our products. Everyone treated that as policy. There was probably a security reason. Somebody must have decided.

None of us had ever been told that. We just worked around it, ticket after ticket, guessing at state we couldn’t see.

Eventually I asked for read access to the data lake, wrote down why support needed it, and got it. We could finally check configs and user state directly, and we started finding bugs that were hard to diagnose from a ticket alone.

There was no policy to overturn. The access had never been set up, and for years nobody asked.

A wall or a guess

When I feel blocked now, I check whether I can point at the blocker: an error, a missing dependency, an owner who said no, an input I can’t supply myself. That’s a wall.

If all I have is “they’ll probably say no,” that’s a guess. It might be right, but the person who owns the decision should be the one to confirm it. Not me, on their behalf.

Guesses are expensive because they’re quiet. A wall stops you, so you deal with it. A guess lets you keep working around it for as long as you let it stand. We let ours stand for years.

Make the ask specific

I didn’t ask for broad production access. I asked for read access to one system and explained what support would do with it.

Now I include what I’ve already tried and the exact task I’m blocked on, and I send it to the person who can actually answer instead of forwarding it around and hoping it lands.

A no is still progress

Sometimes the answer is no, for security, privacy, budget, or another team’s priorities. A no with a reason is something I can plan around. I can escalate, narrow the request, or come back when the constraint changes. A guess gives me none of those options.

Before I build a workaround

I ask three questions:

What exactly can’t I do?
Who can say yes or no?
Have I asked them?

Usually the answer to the third one is no.