How Distributed Engineering Teams Collaborate Across Different Tools
A Director of Engineering has their US-based department working entirely out of Jira. They collaborate regularly with software teams scattered throughout the EU and working in Azure DevOps. Neither team is willing to switch, and they both have good reasons not to. There may not be a technical barrier to forcing either department into the other’s tool, but there are other kinds. No VP will sponsor a forced migration that will frustrate at least one team, cost a significant portion of their technical budget, and potentially create compliance issues.
The answer isn’t to migrate, nor is it to settle for the status quo. It’s about connecting the tools you’re already using. An integration platform that enhances the technical work you’re doing, with deep support for fields and filtering, can close the gap between teams without an expensive migration.
Here’s how.
Why regional teams choose different tools (and why that’s rational)
Even when they’re in the same building, teams often use different tools. Software development teams use tools like Jira and Azure DevOps. Project managers and marketers use Asana. Salespeople and customer success use Salesforce and HubSpot. In some cases, it’s a matter of essential features. Jira is purpose-built for software projects in the way Salesforce is for sales.
Beyond losing out on specific features, you’re sacrificing something valuable: your investment. A software team that’s worked in Azure DevOps for years has built its repos, pipelines, and test plans in ADO. Rebuilding that from scratch in another tool could involve weeks or months of dedicated work, adding significant strain to their workload. That could mean pausing important projects, outsourcing work to contractors, or paying significant overtime.
With distributed teams, there can be other reasons at play. Local regulations might require using specific tools to maintain compliance. Data residency requirements might make more popular tools inadequate. Finally, a newly acquired or expanded team might have gotten used to a specific platform before working with the broader organization.
These are legitimate reasons that can often impact your bottom line in ways you don’t expect. Switching tools without having full context on a team’s compliance requirements could lead to an expensive migration back to the original tool. Formerly autonomous teams might need extensive support during the switch to a new tool, stretching your technical resources.
Teams don’t choose tools at random. If a team’s been using a specific tool for years — and doesn’t want to switch — there’s usually a good reason.
What forced migration actually costs
Migrations are invariably costly. Transferring data over, whether it’s done manually or with integrations, takes time and resources. Running systems in parallel as you migrate means you’re doubling up on at least a few licenses. Infrequent backups and other technical issues can cause essential data to go missing. Downtime impacts important projects as they’re put on hold. Teams need to be trained on new tools so they can adapt their workflows.
But engineering teams pay specific costs. Engineering work is highly technical and dependent on significant context and documentation. When engineers have to go back and forth between an old system and a new one to find the context they need — or that context goes missing in transit — they’re losing significant time that could go to engineering tasks. That loss in productivity can push back deadlines on important projects, causing a ripple effect throughout the organization. As you migrate, everything from planning sprints to reviewing pull requests becomes more complicated, creating drag for your workflows.
Forced migrations are rarely popular, potentially increasing these costs. According to Gartner, 60% of employees experience frustration with new software, and more than half want to go back to old systems after a migration. At best, that frustration can bleed into engineering tasks, causing delays. At worst, it can lead to a shadow IT situation, where engineers use their own systems without oversight from team leads or IT.
In short, the costs of a forced migration go beyond the actual budget and resources used to move data and teams between systems. They include a potentially lengthy dip in productivity, lost engineering time, and frustration in your teams.
The coexistence model: Sync instead of switch
The ultimate promise of a migration is the single source of truth. Ideally, it’s a single system all your engineering work flows through, meaning no update or work item goes missing. Standup meetings, sprint planning, pull requests, and everything else happens in one place.
Unfortunately, that’s rarely realistic. Even small teams working in the same office end up using multiple tools and needing to bridge the gap between them. Distributed teams, working in different jurisdictions with different compliance requirements, almost invariably use different systems. Chasing a single source of truth is likely to be more costly and less effective than you think.
The alternative? Coexistence. Specifically, using a two-way sync tool like Unito to keep data flowing back and forth between tools. With this kind of integration, you can get as close to working in a single system as possible without forcing a team to migrate.
Take Jira and Azure DevOps, for instance, two popular tools for distributed engineering teams. Without an integration, these teams have to manually transfer data and updates back and forth. A migration from one tool to the other is possible, but the two tools don’t serve the exact same function. Both can manage technical projects, but Azure DevOps has a suite of development tools that Jira doesn’t.
So what does the coexistence model look like?
Say you have product and project managers from one region working in Jira. They help engineers plan sprints, unblock work, and report progress to stakeholders. Meanwhile, engineers from another region do most of their work in Azure DevOps. That work is represented by Jira work items for reporting and planning purposes. Here’s what a two-way sync can do to bridge the gap between these tools:
- Work item statuses flow in both directions, so work items in Jira and Azure DevOps always have the same status, no matter where work is happening.
- Comments made in either tool are synced to the other, meaning questions and answers alike are logged in both systems.
- Hierarchies are maintained between tools, so an epic in Jira is synced with an epic in Azure DevOps, and both are still linked to the work items they contain.
- Rules and filters allow only relevant engineering work to be synced to Jira, keeping boards clear of tasks that need to stay within engineering.
Here’s an example of what that looks like in practice.
US-based project managers log bugs for a software platform in Jira after they come through a customer support tool. Using Jira projects, they prioritize bugs based on the number of users affected, the severity of an issue, and how urgent fixing it is. From there, they plan fixes around the engineering resources they have available, from multiple engineering teams throughout the EU. To do that, they go to a Jira project that shows a live view of all the engineering work happening at that time. Each Jira issue shows the status of a corresponding work item in Azure DevOps, the progress made in each one, and any relevant blockers.
When they’re ready to plan the next sprint, they add a label to relevant Jira work items marking them as “Ready for Development,” which syncs them over to Azure DevOps. Once in Azure DevOps, developers can ask questions about the work involved, and these questions get synced back to Jira. Project managers answer questions in Jira, and the answers are synced back to Azure DevOps. As developers work, status updates in Azure DevOps are synced back to Jira, where project managers can use them in reporting.
Curious to see the impact of this model? Check out how tech startup Topl saves $57K a year syncing Jira and GitHub with Unito.
Why this has to extend beyond Jira and ADO
Jira and Azure DevOps are two of the most popular tools for distributed engineering teams, so it makes sense to consider them first for migration or integration. But they shouldn’t be the end-all-be-all of your integration efforts. Closing the gaps in your engineering workflows leads to net productivity gains, but what about all the workflows that impact (or are impacted by) your engineering efforts?
There are dedicated integration solutions out there for syncing Jira and Azure DevOps, but they often offer limited integrations beyond this pairing. You might be able to add another engineering tool or two, but that’s when you start running into problems. Say you want to close the gap between salespeople and software teams for post-sales delivery. Can the integration platform you choose handle a Jira-Salesforce integration? Or maybe you have project managers in marketing or operations that use Asana, and you want to give them an overview of work happening in Azure DevOps. In these situations, you might have to add a second integration solution for specific tool pairings, which means dealing with a separate vendor, adding a different admin surface, and creating potential for conflicts when the two integration solutions overlap.
That’s why you need an integration platform like Unito. Unito has over 60 connectors for some of the most popular tools on the market, like Jira, Salesforce, Asana, Azure DevOps, GitHub, and ServiceNow. Unito’s deep integrations handle most, if not all, standard and custom fields, allow you to create deep filtering rules, and maintain hierarchies across tools.
Bring your tools together with Unito
FAQ: Distributed engineering
Does syncing Jira and Azure DevOps mean giving up native features in either tool?
No, by syncing Jira and Azure DevOps with a two-way sync platform, you can keep using the native features you need in each tool. Syncing work items just means the data in these work items is transferred seamlessly between tools.
What happens if a regional team’s tool changes after the sync is set up?
If a tool changes after you set up your initial sync, you may need to make small modifications to that sync. Adding new custom fields to your workflow means they need to be added to your flow, as well. If the names of projects or statuses change, you’ll need to update your sync to reflect these changes.
Is a two-way sync different from a one-way integration or automation trigger?
Yes. A two-way sync builds continuous relationships between work items in Jira and Azure DevOps, keeping data flowing back and forth between them by default. Status changes in Jira are synced to Azure DevOps, comments in Azure DevOps are synced back to Jira, and so on. One-way integrations and automations typically automate a single action, rather than creating that relationship. Creating a Jira issue manually leads to a matching Azure DevOps work item being created automatically, but changes made to either one after the automation runs aren’t synced. You can push some of these changes, but that requires chaining additional automations, leading to more maintenance and troubleshooting.
Does keeping separate tools per region create compliance or data residency risk?
Keeping separate tools can potentially create compliance risks if your data security and integration practices are different in each tool. But in some cases, using multiple tools is actually the best way to mitigate compliance and data residency risks. When different regions have their own compliance requirements, some tools are better suited to meeting these requirements than others. In these cases, using the right tool for each jurisdiction is your best bet.
Work in sync from anywhere
Distributed engineering teams shouldn’t have to choose between forcefully migrating everyone into a single system and manually transferring data between tools. A two-way sync platform like Unito allows you to keep multiple systems running simultaneously, with data in all of them kept up to date automatically as you work. That way, distributed teams can use the tools that make the most sense for them, without expensive migrations or the productivity drag that would otherwise come with distributed work.
Ready to see what Unito can do?
Meet with a product expert who'll walk you through the integration you need.