Most companies uses a lot of different technologies, and it's not reasonable to expect everyone in the company to know everything about all of them. But when we have problems we need help with, there are a few useful steps we can take to make sure the people helping us can do so effectively. There are a few guides around the Internet that give advice on how to ask questions -- I very definitely recommend Jon Skeet's Stack Overflow Checklist. But asking questions internally can sometimes be very different from asking questions in a public forum. So here are some things you should bear in mind.

1. Read The Documentation
2. Explain the Impact
3. Start Nearby
4. Avoid Solving the Wrong Problem
5. Include Context
6. Talk To Vendors
7. Don't Expect Magic

Read the Documentation

Most internal services have at least some documentation. And a lot of common tooling is built with Open Source and will have publicly-available documentation. Before you raise a support request, make sure you've read the documentation.

Explain the Impact

It is said that "a lack of planning on your part does not constitute an emergency on mine" (attributed to Bob Carter). But that's not always the case when helping colleagues. The first thing you need to understand (and explain) when asking for help is the impact of the problem you're having. Impact here relates to business impact -- either in the form of an incident, or a goal. The team you're asking for help needs to be able to balance what you're asking them to do against the work they already have on their plate -- if you can clearly explain the business impact of what you're asking them to help with, they'll be much more able to prioritise appropriately. This also feeds into the rest of this article: if you have a high impact incident, your colleagues will be much more forgiving of a general cry for help than if you have time and space to do more research yourself before asking.

Start Nearby

Whatever you're looking for help with, the people in your team are most likely to know why things are set up the way they are. Even if you're looking for help with someone else's service, it's people in your team who are most likely to know the context in which you need to use it. Ask your team before you raise a support request.

Avoid Solving the Wrong Problem

You need to understand the XY Problem and how to avoid it. Often this means asking yourself "why do I think this is a problem I need to fix?". Make sure it's obvious how the question you're asking affects the impact you've identified.

Include Context

Make sure that someone reading your question can understand why you decided to ask it. Remember that people outside your team probably don't know what your services are supposed to do or which other services it interacts with. If you think that something's broken, make sure to explain why you think it's broken. If you include screenshots, log entries, or any other evidence, then make sure you include either a link to where you got the evidence or instructions for how to reproduce it. People answering support tickets want to be able to help, but when we ask questions we need to make sure that the person we're asking knows why we asked them rather than asking someone else. If you've followed the other recommendations on this page, you'll have already talked to other people and tried some different things to fix the problem by yourself. Make sure to include this context too.

Talk To Vendors

There are lots of services, and lots of code within services, that we've written ourselves. But there's even more that we get from a vendor. If the problem you're having is with a vendor-provided service, it's quite likely that we have a support contract. Our internal documentation should explain how best to raise a support request with a vendor: sometimes we can and should approach the vendor directly, other times we need to talk to the owning team who will submit a support request on our behalf.

Don't Expect Magic

The easier you make it for someone to help you, the more likely they are to be able to help. This includes making sure you plan ahead, where that's possible. If you know you're going to need help before finishing a project, asking early helps the other team plan appropriately. And remember that the people you're asking for help are humans, just like you: before sending a support ticket, read it through and imagine that it was someone else sending that request to you. Can you understand the impact? Can you understand how the question relates to the impact? Is there anything missing that may be useful?