Earn the Ask

Read access to our data lake was the first ask. It let support stop guessing at the product state behind a ticket.

Full codebase access came later, and it was a different kind of request.

Nobody had explicitly rejected read access. Codebase access involved real risk. Support didn’t own the services, and a bad change could create more work for engineering. “This would make us better at our jobs” wasn’t enough on its own.

By then, the team had work we could point to. We could reproduce bugs, query the underlying data, separate product issues from user error, and give engineering useful diagnoses. We were already doing the investigation. Code access would let us follow it into the code.

We got the access. Support could now submit small fixes through the normal pull request process.

What engineering had already seen

“Build your network” has never been very useful advice to me. It makes work relationships sound like a visibility problem: meet more people, get into the right rooms, make sure leaders know your name.

I think about social capital as work history. Do you follow through? Is your information accurate? When you bring somebody a problem, have you already done the part you can do yourself?

Our bug escalations included a reproduction and the relevant data. Engineering didn’t have to start the investigation over every time. If our diagnosis changed, we corrected it.

We made escalations easier for engineering to pick up. We sent the useful context instead of forwarding a long customer thread, then followed up so the people who helped knew what happened.

Asking for the codebase

The data-lake request started with checking whether the blocker was real. Codebase access was different because engineering had a real risk to evaluate.

We could explain exactly what the access would change. Support could read the implementation, investigate past the symptom, and contribute through the same process as anybody else. We weren’t asking engineering to lower its review bar or let us work around code owners.

Engineering still could have said no. The previous work gave them something more useful than “trust us” to make the decision with.

What would have made the request harder

Calling every bug urgent would have taught engineering to ignore our urgency. Forwarding complaints without checking them would have taught them to redo our work. Missing commitments without saying anything would have made the next promise harder to trust.

Promising timelines we didn’t own would have been just as bad. A customer SLA explains what the company owes the customer. It doesn’t give support control of engineering’s roadmap. We still had to ask the owner before committing on their behalf.

Those mistakes don’t always create an argument. They show up when another team starts rechecking the facts or asking for more proof than they used to.

After we got access, support could read the code and send PRs. Code owners still reviewed them. The team could take an investigation farther without changing who owned production.