Priya had been on the receiving end of a support contract gone sour more than once. At two in the morning, a monitoring alert fired for a service the outside team supposedly looked after. Nobody answered for forty minutes, and when someone did, they asked which of the company’s several environments was affected. She remembers sitting at her kitchen table thinking that the mistake was not theirs alone. Months earlier she had signed the engagement with a single paragraph describing what she wanted. This post collects the beliefs that led her there. They are myths about requesting DevOps support, and each one deserves a gentle debunking.<\/p>\n
Expertise is real, but it is not mind reading. A support provider knows how systems tend to fail; they do not know which of your systems you would defend with your last hour of sleep. Without a written description, they will apply sensible defaults that may not be yours: business-hours cover when you wanted nights, reactive fixes when you expected proactive checks.<\/p>\n
What to do instead:<\/strong> Write down which services matter most, when you need someone reachable and what “responding” means to you: an acknowledgement, a first diagnosis or a fix. Experts do their best work when pointed at a target.<\/p>\n This one sounds practical and costs a lot. Once the contract is running, every missing detail becomes a negotiation between two parties who are already committed, and the person who raises it first often appears to be asking for extras. A gap that would have been a line in a brief turns into an uncomfortable “that is out of scope.”<\/p>\n Priya’s gap was precisely this: nothing said which environments were covered. The provider’s view was the production cluster only. Hers included the staging environment that fed customer demos. Nobody was lying; nobody had written the sentence.<\/p>\n What to do instead:<\/strong> Name the services and environments that are covered and, just as plainly, those that are not. A table of environments, a list of services and a short note on hours takes less than an hour and prevents months of friction. Understanding the wider landscape of roles helps here; a plain guide to the various job titles in DevOps work<\/a> clarifies who normally owns which tasks, so your scope list uses the right words.<\/p>\n The opposite tends to be true. The first week of any engagement is spent gathering facts: where things live, who decides, what the usual failures are. A brief delivers many of those facts before day one. The time you spend writing is time the provider does not spend asking, and you answer once rather than five times through scattered messages.<\/p>\n Think about what the page actually needs. It does not need diagrams or legal language. It needs a sentence on the result sought, the deadline behind it, an affordable bracket, the rules the provider must respect and a picture of what a good month of cover feels like. That is about a page.<\/p>\n Many managers fear that a specific request will box them in or make them seem difficult. In practice, specifics signal seriousness and make flexibility easier. When both sides know the baseline, a change is a clear adjustment, not an argument about the original meaning. A brief should say which parts are fixed and which are open: “We want overnight cover, but we are open to a rota that combines your staff and ours.”<\/p>\n The principles behind dependable delivery apply here too. The core ideas that make software delivery effective<\/a> stress shared understanding and fast feedback, and a brief is simply a way of getting both before any work begins.<\/p>\n What to do instead:<\/strong> Mark each line as “fixed” or “negotiable.” It makes the document sound collaborative rather than defensive.<\/p>\n The worry is understandable: if you reveal a ceiling, will everyone quote up to it? Sometimes a reply will touch the top of the range. But withholding the figure produces its own problems, namely proposals that are plainly out of reach or that describe a different, grander service than the one you wanted. A range lets a provider say, “That covers weekday cover with one named contact, but not round-the-clock support,” and that kind of honesty is precisely what you need to hear.<\/p>\n What to do instead:<\/strong> Give a bracket, not a single number, and say what is flexible. Describe the value of the outcome rather than guarding the amount.<\/p>\n Smaller teams actually have less slack. A five-person startup that loses two days to a support misunderstanding feels it far more than a large enterprise would. And the owners of small shops are the ones most likely to rely on one outside engineer who also happens to be a friend of a friend, which makes it awkward to raise problems later. A page written at the start gives everyone a neutral thing to point at.<\/p>\n That page matters for people on the provider’s side as well. Engineers moving into operations and support roles will find many ideas in an article on the path from infrastructure scripting to reliability engineering<\/a>, and a clear request makes their on-call life calmer.<\/p>\n After the bad night, Priya rewrote the request. It begins with a sentence about the customers who rely on the service. It lists three named services and two environments. It says overnight acknowledgement within a stated window is essential, while a full fix can wait until morning for anything marked low impact. It gives a budget range for the first quarter, with a review before renewal. It names who on her side can approve changes and who gets called. And it ends with a definition of a good quarter: no unanswered overnight alerts, a short written summary after each incident and one improvement suggested per month.<\/p>\nMyth 2: “We can sort out the details once the contract starts”<\/h2>\n
Myth 3: “A written brief is paperwork that slows things down”<\/h2>\n
Myth 4: “A detailed brief makes us look rigid”<\/h2>\n
Myth 5: “Mentioning the budget only invites a higher number”<\/h2>\n
Myth 6: “Only big companies need this”<\/h2>\n
So what does Priya’s brief look like now?<\/h2>\n
Finding people to send it to<\/h2>\n