What are the best practices to manage Infrastructure work that provides services to all other teams?

[Meital]

Hello,

Our Infrastructure team provides development services to all teams + they have their day-2-day operational work. What would be the best way to manage the different requests coming from all teams?

We have Infrastructure project in jira, which is not 'Product' oriented and used for on-going day-2-day operational work.

Our other JIRA projects are setup to be 'Product' oriented.

When product team member needs Infra services he either opens an issue in the existing Infrastructure project (and then links it to another duplicated issue on his project) OR opens an issue in his project, labels 'Infra' and assigns to Infra team member.

The disadvantages are:

• Anyone that is not in Infra team can go and create/update issues in Infra project and it can create a mess sometimes. It's harder to manage
• Having duplicate issues with linking between them is not convenient as you need to go for the 'Linked issue' to see the status and you have duplicated issues in the system
• When they create the issue on their product project the big disadvantage is that the issue inherits the project workflow. Infra members end up handling issues from different workflows, which are not relevant to them

I would like to know if someone has tried to use the below direction and if it works well:

• Create New Issue Type (i.e. Infra Task) and apply this type to all projects
• This issue type will have its own workflow and screens
• Each team can create Infra Task issues in their project, see it in their board and manage it
• Infrastructure team will have a board that will present all Infra Task. They can manage and prioritize everything and it doesn't affect Infrastructure project which is used for other purposes

Any ideas for other best practices will be appreciated!

[Alina Kurinna _SaaSJet_]

Hi @Meital 

I think your `Infra Task` approach can work, but I’d treat it more as a workaround than a long-term best practice.

The main issue is that it keeps Infrastructure intake spread across multiple product projects. That usually means more admin overhead, less control, and more chances for the process to get messy over time.

If your Infrastructure team is really acting as a shared internal service team, I’d normally separate "request intake" from "delivery work":

• keep the Infra team’s operational backlog in its own project
• create one controlled path for requests coming from other teams
• let the Infra team triage, prioritize, and manage that work in one place

In practice, that often works better in a dedicated Jira Service Management setup, because you get request types, queues, and cleaner control over how work comes in.

Your `Infra Task` model still makes sense if you want each product team to keep visibility in its own project. But if you go that way, I’d standardize it hard: one issue type, one workflow, one required set of fields, and one cross-project board for Infra. Otherwise the team will end up managing the same service through too many different project rules.

Also, if Infrastructure has expected response or delivery times for internal teams, this is a good use case for SLA or OLA tracking. Native JSM SLAs may be enough if everything goes through one service project. If the process spans multiple Jira projects and handoffs, SLA Time and Report for Jira app can help track those internal commitments more consistently.

[Emma Foster]

If your infra team supports everyone else, the main goal is simple: enable teams to move fast without turning infra into a bottleneck.

What actually works in practice:

• Treat infra like a product
  Define what you offer (deployments, environments, access, monitoring) and set clear expectations/SLA. Don’t operate as ad-hoc support.

• Standardize setups
  Avoid one-off configs for each team. Use templates and repeatable patterns so things are predictable and easier to maintain.

• Enable self-service (with guardrails)
  Give teams pipelines, access workflows, and ready-to-use environments so they don’t depend on you for every small change.

• Get the basics right on security
  MFA, least-privilege access, and proper logging. Especially important if you deal with regulated data like GDPR.

• Monitor what matters
  Focus on uptime, performance, and critical failures. Too many alerts = everyone ignores them.

• Be ready for failures
  Backups, tested recovery, and simple runbooks. Things will break—it’s about how fast you recover.

• Keep documentation practical
  Short, clear, and task-focused. If people can’t use it in 2 minutes, they won’t use it at all.

Most infra teams struggle because they stay reactive. Once you build systems and automation, everything scales much smoother.

If bandwidth is an issue, some teams bring in partners like ByteTechnosys to set up and manage a clean, scalable infra foundation without overloading internal teams.

[Craig Nodwell]

Your second direction below is exactly what I would recommend you do.  This is an easy practice to follow.  You might also want to look at Jira Service Management.

[Pranay Singh]

@Meital I was interested reading your query and the solution that you were thinking of.  We are on same boat and looking to implement something for our Infra and DBA team. Can you shed some more ideas on your implementation of Infra board please. Any learnings, lessons learnt etc. 

We could really benefit from your ideas. Thanks much