Development Teams, scrum teams thrive then they have a fixed scope and can limit the amount of unplanned work which creeps in and disrupts their sprints.

An issues I've come across a couple of times in my career is when Support Teams feel overwhelmed by some of the issues which arise in live. There's often a development queue involved, surgeries, on call developers and all sorts of very expensive alternatives.

In very bad environments Support Teams appear to wash their hands of issues they believe they can't solve and their update to customers is "it's with development".

I want to make it clear that these aren't bugs, these are often the sort of tasks which a larger company would assign to operational DBAs... data fixes, requests for information, issue analysis... that sort of thing.

I also want to stress the goal isn't to cut support off, it's to protect the developers so that prioritised fixes/features can be released in a timely manner.

I've tried a number of techniques in the past to manage this and encourage Support's ownership of live software. One of the best I've seen is a Support Signoff being required before software is pushed live. However, there's often little motivation to give this signoff if the release deadlines rest with the development team - especially if from their perspective it can lead to "having to live with a build" with reduced development support.

What strategy should a development manager employ to encourage Support Team Members to own live issues throughout the issue lifecycle rather than handing them off to other teams?

  • 1
    No idea why this has been downvoted - it's a great question.
    – berry120
    Commented May 3, 2018 at 13:18
  • 2
    Thanks @berry120! I tend to ignore downvotes but it's nice to hear that you think it's a good question
    – Liath
    Commented May 3, 2018 at 13:29
  • In your workplace, are the Support Team members actually developers? Do the original developers of new changes have any accountability of faults identified when a new change goes live?
    – user34587
    Commented May 3, 2018 at 13:42
  • Does Support work for you? I don't see how support has to sign on on release would fix this. If they may be afraid to do a data fix as they could make it worse. Have they ever gotten in trouble for trying what they may think is developer turf?
    – paparazzo
    Commented May 3, 2018 at 14:34
  • Have the support person close the ticket, simple?
    – RandomUs1r
    Commented May 3, 2018 at 22:10

6 Answers 6


It sounds like your support team is junior to your dev team. This can create a number of issues:

  • Your support team might not know how to fix the issues. Maybe they are younger or less experienced, maybe they lack the training. If you hire people to answer phones for $15 an hour, you can't expect them to handle problems like a Senior DBA ($65 an hour).
  • Your support team probably feels like they get thrown under the bus a lot. The end users don't know that their $15 phone jockey isn't a $65 database monkey. They can't tell the difference and they wouldn't care, even if they could. On the other side, if your developers aren't taking ownership of their development, they might also be throwing support under the bus. "it passed QA, therefore it's not my problem".
  • Your support team probably don't feel like they have a say in introducing new development. One day, some new widget arrives in prod, causes a whole bunch of issues and now they have to fix them. That's not really fair.

here's what I'd try:

Mix up your dev and support teams. Some of your devs might like a promotion to production DBA. Some of your support peeps might like a promotion to developer. You'll end up with a more skilled support team and a better QA process.

Get your support staff trained. Are they qualified to fix things in production? Probably not.

Protect your support staff. Nobody likes to fix things in prod on the fly. There are soooo many opportunities to fail publicly and spectacularly. Sometimes, you have to, and when you do, its a failure of your Development and QA teams (and management, of course). If the support guy reaches into the live machinery, tries to fix a part and metaphorically gets his arm ripped off, he's not going to want to do that again.

TLDR: Here's your issue:

to protect the developers

Who's protecting your support staff?

-Sincerely, a Senior DBA at a Hospital in NYC

  • Having worked in companies with operational DBAs too I don't know how any businesses work without them!
    – Liath
    Commented May 3, 2018 at 16:14

Fairly obviously, you need to construct some support documentation so that the Support Team have the information available to triage and resolve any issues that occur.

Anything outside the scope of the document of course comes back to the development team, and the support documentation evolves as a result of that.


In very bad environments Support Teams appear to wash their hands of issues they believe they can't solve and their update to customers is "it's with development".

If people in any situation can make their lives easier by getting someone else to do it, chances are they probably will. If it's really trivial for the support team to just chuck it over the fence at development and say "they'll deal with it", then that's exactly what will happen.

Instead, make sure the owness is on the support team to prove that it's a development issue with a reproducible example before they chuck it at the development team. They should be able to take the user's query to produce a step by step guide of exactly what happens (and what should happen instead), verify this is still the case in an active staging system, and (only!) if that's the case they can then hit the development team with a reproducible defect report. That's the only case where something should get added to the development queue.

I want to make it clear that these aren't bugs, these are often the sort of tasks which a larger company would assign to operational DBAs... data fixes, requests for information, issue analysis... that sort of thing.

There's two approaches here - long term, I'd work towards procuring tools & documentation so the support team can start to own such requests without having to bother the developers.

In the meantime, it still needs to be kept clear of the development queue as a whole - you don't put such information requests and issue analysis in a sprint. Ideally you'd have someone that dealt with these issues exclusively, but in a smaller company you can still deal with it by assigning this role on a part-time basis (Bob might take Wednesday afternoons, and Alice Friday afternoons to deal with such requests for instance, and they get put in a separate support queue until then.)

Yes, you might be essentially down a man day a week that way, but that's a constant you can predict, which is much easier to handle than a potentially endless supply of support queries getting added at random to a sprint.


I know this is long, but I have a lot to say on this subject. I have worked in high-level Tech Support for enterprise software for 10+ years. Support staff, if they’re doing high-level technical stuff, and not just parroting, “have you tried turning it off and then on again,” into a phone, are techy people. We like to solve problems ourselves; it’s what we’re good at; that’s why we’re in this position. If this isn’t true of Support staff who you have hired to do support that involves DBA-type work in live client environments, then you have hired the wrong people.

TL;DR: If Support can’t solve problems by themselves, then they don’t have enough time, skills, or access, or there is no workflow process in place that lets them know how they should be handling these types of requests.

You have used these terms to describe a Support staff: “feel overwhelmed” and “believe they can’t solve [some issues]”. Are they overwhelmed and unable to solve all the issues they’re being asked?

Are there enough people on the support team that they could, with the right skillsets, be able to answer all the requests that come in? If there are more requests coming in than is possible for the Support team to answer, that’s an obvious problem. Be aware that Support staff in understaffed departments have to do an algebra that looks like this: I can dig into this one complicated issue and leave 4 other issues unanswered today, or I can ask the developer in charge of this area for help on that one issue, and be able get back to all 5 issues. In my experience, the Support staffer’s preference would be to have the time to be able to dig into the complicated issue and learn about the product themself, but when there is no time, that isn't an option, especially if there are support SLAs you have to meet.

Are there requests coming in that require skills that aren’t present in the Support Team, but only in Development? You mentioned DBA skills. If there’s no one in Support who understands whatever you’re using databases for with your product, then it’s not going to be possible for them to solve the issues themselves (at least not in a timely manner; see the previous point). Get Support staff the training they need to solve the sorts of issues they’re being asked. If you can’t afford general training, have them sit with the developer they’d usually forward these sorts of issues to while the developer goes through the troubleshooting process so they can learn enough to be able to answer these questions themselves. Once you do this once, then the Support team itself should now have an expert in this area and other members of the team can ask that person, rather than the developer. If your Support staff does not have enough time to spend learning the skills they need to answer questions efficiently, then you’re back to problem #1 - not enough staff.

You mentioned requests for information. What pieces of information are your developers hoarding from Support? If there’s documentation Dev has that they’re not sharing with Support, then Support is going to have to ask Dev for it. If the information is available to Support, then Dev should just be able to point Support to it. This goes for the codebase, too. Is there part of the codebase that Support isn’t allowed to see? If so, you can expect more questions forwarded from Support about those parts of the product.

Now to discuss the process. There should be a Tech Support process or workflow. Probably a flowchart for each type of request with steps like: being assigned a ticket number, assigned a Support technician, escalated to the Support manager, escalated to Development, being resolved, etc. Each different type of request and condition should have its workflow mapped out. There is a place for Development involvement here, like when legitimate bugs are reported, or because we all know that there is that one Dev guy who is the only person in the whole company who truly understands [obscure authentication process] in [obscure environment]. Having the process diagrammed helps everyone see when Development involvement is appropriate.

Noticed I also put a Support manager in there. Does your Support team have a manager? While the Support team is learning their new process – i.e. how to become more self-reliant, they can make it part of the process to have escalations to Development have to go through a manager. To be honest, once the team is in the habit of exhausting internal options first, I think you’ll find that you won’t need this step, but while you’re changing habits, if can be useful to have someone within the Support team to help make the call on what’s worth bothering Development with. A Support manager should know the skills and schedules of both teams in order to determine when it’s appropriate to shift resources from Dev to Support. The Support manager is also who you (as the presumed manager of the Dev team) can have a discussion with when you feel that Dev is being called on too much by Support.

Finally, if you're super-concerned about how many requests are being passed to Development, you should be able to create metrics for this in your support ticketing system (you are using a ticketing system that tracks who's working on what issues and what the issue statuses are, right?) Metrics are not just for shaming the person in Support who asks the most questions of Dev (that Support technician probably takes all the hardest questions), but are also to look for trends, like "we pass a lot of questions about weird Oracle permissions to Dev," or "two weeks after a new release the volume of questions goes up, and we need to call in Dev resources." These can help find solutions like "get someone in Support some Oracle training" or "we are probably going to have to schedule for extra volume of Support requests x weeks after a new release."


Great question. I'd reframe this as development and support are there to support the business. The business makes the money for your company which allows us to have a job.

First (this is extremely important) is to get your management and (hopefully) the management for the support team involved in delineating roles and responsibilities. You won't get much accomplished without management buy-in.

Some of this things you're talking about should have development input. Or at least business analyst input. If you're following your agile process to the detriment or supporting the business then your process is the main problem. And while I do love agile as a process it can't be the final determining factor. Supporting the business is the determining factor. They (the business) don't care whether it's a help desk tech or senior java developer - they just want the problem fixed, question answered, etc.

One thing that can really help is to use your ticketing system. All (and I repeat all) support requests need to first go through your support team where they can either be worked or assigned to the proper team (and this is important) the reason it's being assigned. These can then be tracked, metrics can be reported and future steps can be planned.


Either you, your company, or both are living in a fantasy land. Someone's time has to give.

As much as your team would love to have those fixed sprints with fixed requirements, that doesn't sound very agile to me (note the lower-case 'a'). Sprints need to be planned around the realistic time available for your development team. One or more of you may spend most of a sprint fixing a problem, so don't plan on them burning down your todo list very much.

Another area your team will probably have to devote time to is support staff training. Someone in authority needs to make a business decision and determine what they can do, how long it may take them (you're team is probably 10 times as fast) and how much training and supervision they may need.

A typical scenario for the time being is to sit down with them when this occurs and walk with them through it. Check their work. Answer questions quickly. Make it clear this is something they will be able to handle in the future. Then when they pass it on to your team, you can confidently kick it back and let them know they should know how to do it.

At some point, people are given tasks and either they can handle them or not. Your support staff may be completely under-qualified and the company will have no intentions of paying more and finding better people. They'll just let the developers handle it. You need to make sure that they understand time spend on these tasks limit the amount of work you can expect to get done during the next sprint. Especially the ones after a release.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .