Asking for the access you need

I asked for codebase access for two parts of our support team. The escalation team needed to read the code. The team building support tools needed to contribute changes. Those were different requests, and I wanted the permissions to reflect that.

For escalations, reading the implementation would let us follow an investigation further. We could check how a feature actually worked instead of stopping at the behavior we could see in the product. We could bring engineering a better explanation of the problem, even when we weren’t going to write the fix.

Support Systems needed write access to the web application, backend, and infrastructure repositories so we could contribute changes through the normal pull request process. The engineers who owned those systems would still review the work and decide whether it should ship.

That distinction made the request concrete. I could explain what each group needed to do, which repositories that required, and where engineering’s ownership stayed the same. A broad request for support to have engineering access would have left all of that for someone else to figure out.

The code access was approved the next day and implemented the following week.

Earlier, during my transition into management, I’d pushed for support access to our data lake. We needed to be able to query the state behind a support case without asking someone on another team to look it up for us. I was doing both jobs for a while, still close to the investigations while starting to take responsibility for how the team worked.

The codebase request went further. We wanted to contribute to systems another team would have to maintain. It was reasonable for the people responsible for those systems to care about what we’d do with that access.

By then, engineering had worked with us long enough to know what to expect. Our escalations came with reproductions and relevant data. We pulled the useful context out of customer threads, corrected a diagnosis when it changed, and followed up so the people who helped knew how it ended.

That’s the kind of history I want behind an access request. Someone deciding whether to let us contribute should have more to go on than my confidence that it will be fine.

It’s easy to make that decision harder. If every bug is urgent, people have to redo your assessment of urgency. If you forward a complaint without investigating it, you’ve handed over the work along with the message. Access doesn’t fix either habit.

I eventually used that code access to ship fixes of my own. An engineer still had to review and approve them. We had a way to take a support investigation through to a proposed change, with the code owner involved before it reached customers.

When I’m blocked now, I try to get specific about what I need and who can decide. Sometimes the answer is no, or the request needs to be narrower. At least then we’re discussing an actual decision instead of working around an answer nobody gave us.