When Developer Friction Stalls Transformation

Digital transformation is a top priority for modern software organizations. Yet all too often, ambitious transformation initiatives stall out due to an overlooked factor: developer experience (DevEx). If your developers are mired in inefficiencies, disconnected tools, and information silos, even the best strategies can grind to a halt.

Imagine a large SaaS company in the IT & Software Services industry with over 1,000 Jira users. This enterprise embarked on a digital transformation to modernize its platforms and processes. However, progress was painfully slow. Developers were frustrated by context-switching between disparate tools, hunting for information spread across Confluence pages and wikis, and untangling unclear ownership of hundreds of microservices. Releases missed deadlines, incidents took ages to resolve, and morale was sinking.

In this blog, we’ll explore how that company turned things around by focusing on DevEx as a catalyst for change. With Atlassian’s new developer experience platform Compass – and Atlas Bench as a strategic partner guiding the journey – they resolved their challenges step by step. The result was a dramatic acceleration in deployment velocity, quality, and team morale. This real-world use case shows how improving DevEx can unlock the full potential of digital transformation.

The Challenge: Disconnected Tools and Silos Slowing Delivery

For a large software company, the symptoms of poor DevEx were evident:

Scattered Information: Critical project knowledge was fragmented. Architecture diagrams lived in one Confluence space, API docs in another, and tribal knowledge only in senior engineers’ heads. Developers spent hours every week just searching for up-to-date information or the right contact person.
Tool Fragmentation: The company’s engineering toolchain had grown organically. Jira for issue tracking, Confluence for docs, multiple CI/CD pipelines, monitoring dashboards, and countless repos – but no single source of truth. The tools didn’t talk to each other, forcing manual work and context switching that broke developers’ flow.
Unclear Ownership: With microservices proliferating, it was often unclear who owned each service or module. When an incident struck, teams scrambled to identify the responsible team and locate runbooks. Resolving outages took far longer than it should, impacting customers and adding stress on developers.
Inconsistent Practices: Each team did things differently. Some services had thorough documentation and tests; others had barebones readmes. Governance and best practices were not being uniformly followed, since there was no easy way to enforce standards or even measure them. This inconsistency led to quality issues and technical debt.
Developer Frustration: All these issues created friction that sapped productivity. Talented developers were bogged down by “toil” – repetitive manual tasks, searching for info, resolving avoidable issues. Morale was dropping, and leadership feared burnout or attrition of key engineering talent. It was clear that developer experience problems were business problems: slow delivery, higher costs, and risk to the transformation’s success.

The company’s engineering leaders recognized that to accelerate their digital transformation, they needed to eliminate these frictions. They needed to empower their hundreds of developers to move faster and collaborate better. That meant unifying their tooling and information – essentially, creating an Internal Developer Platform to bring everything together. This is where Atlassian and Atlas Bench came into the picture.

Tools overlaying a laptop – illustrating the automation and scorecards driving continuous DevEx improvements.

Finding a Solution: Enter Atlassian Compass and Atlas Bench

Facing these challenges, the company's CTO and DevOps leadership team sought help to improve the developer experience across the organization. They partnered with Atlas Bench, an Atlassian solutions specialist, to assess the situation and formulate a DevEx improvement strategy. Atlas Bench brought deep expertise in Atlassian’s tools and a fresh perspective on internal developer platforms.

In the discovery discussions, one solution quickly stood out: Atlassian Compass. Compass is an internal developer experience platform recently launched by Atlassian to serve as a “mission control” for modern software development. It promised to tackle exactly the problems the company was facing by providing:

A unified catalog of all software components (services, libraries, APIs, etc.) along with their owners, documentation, and links to tools.
Health scorecards to automatically evaluate components against best practices (security, performance, compliance, etc.) and track important metrics.
Integrations with Jira, Confluence, Bitbucket, and other tools to break down silos – ensuring information flows where it’s needed.
Golden path templates to standardize how new services are created and configured, making consistency automatic and accelerating onboarding.
A focus on DevEx at scale, meaning it’s built to support thousands of components and developers with ease.

Atlas Bench had seen Compass deliver great results in other contexts (even for smaller startups), and believed it was the right fit for the company's enterprise-scale needs. With leadership buy-in, the company decided to implement Atlassian Compass as a cornerstone of its DevEx-driven transformation – with Atlas Bench guiding the journey from start to finish.

The remainder of this post walks through that transformation journey step by step, from initial discovery to full Compass rollout, highlighting how each phase addressed the company’s pain points. We’ll see how Compass, paired with expert strategy, turned developer experience from a roadblock into a growth engine.

Step 1: Discovery – Uncovering DevEx Pain Points

Every successful transformation starts with understanding the current state. In the Discovery phase, Atlas Bench and the company's engineering leaders conducted a thorough assessment of the developer experience gaps:

Interviews & Surveys: Dozens of developers, team leads, and IT staff were interviewed or surveyed. They openly shared their daily frustrations – from “I waste half a day searching Confluence for docs” to “setting up a new dev environment took me two weeks”. This feedback helped quantify the impact of poor DevEx on productivity.
Tool Audit: The team catalogued all the development tools in use (source repos, CI servers, artifact registries, monitoring systems, etc.) and how they connected. The audit revealed a spaghetti of disparate systems with little integration. For example, there was no easy link between a Jira issue and the code or service it affected, and documentation was often not linked to either.
Process and Incident Review: They reviewed recent incidents and post-mortems to see how DevEx issues contributed. A pattern emerged: when an outage happened, teams lost precious time figuring out who owned the failing service and where its documentation or runbook was. In one case, a critical customer issue took hours longer to fix simply because the team didn’t know about a dependency service owned by a different group – a classic silo problem.
Baseline Metrics: Together, they established baseline measures of key indicators. Deployment frequency was averaging very low (e.g. monthly releases in some teams) and lead times for changes were long. Onboarding a new developer to full productivity was taking over a month. Developer satisfaction scores (from an internal survey) were below industry benchmarks. These baseline numbers set the stage for improvement goals.

The discovery phase made it clear that inefficient developer experience was a major drag on the company’s digital transformation. It aligned everyone on the urgent need to fix it. The good news: the analysis also highlighted specific targets for improvement – for instance, “reduce time to find documentation from hours to minutes” or “enable teams to deploy on demand instead of monthly.”

Atlas Bench presented a roadmap to address these pain points, centered around implementing Atlassian Compass as an integrated DevEx platform. With a solid understanding of the challenges and a vision for the future state, the company moved forward confidently to the next steps of the journey.

Step 2: Onboarding Atlassian Compass – Creating a Unified Component Catalog

With the problems clearly identified, the company and Atlas Bench kicked off the onboarding of Atlassian Compass. The goal of this phase was to stand up Compass as the single source of truth for all the company’s software components and teams. This involved several practical steps:

Setting Up the Platform: Atlas Bench helped the company spin up Atlassian Compass (a cloud service) and integrate it with their identity management for single sign-on. Very quickly, the core platform was ready for use by the teams. Compass is designed to be easy to adopt – they were able to start populating data within the first day.
Populating the Component Catalog: Next, they assembled a comprehensive list of the company’s software components to import into Compass. This included over 200 microservices, numerous shared libraries, internal APIs, and even critical infrastructure pieces. Atlas Bench utilized automation scripts and Compass’s APIs to pull data from existing sources – code repositories in Bitbucket and GitHub, container registries, and even an old spreadsheet that one team had been using to track services! Within a short time, every service and component was represented in Compass’s catalog. Each component entry in the catalog recorded metadata like the repository link, description, and most importantly – the owning team.
Defining Teams and Owners: Because Compass links components to the teams responsible, the company took this opportunity to clarify ownership. They created team profiles in Compass for each of their engineering squads (over 50 teams across various product lines). Each component was claimed by a team, and those relationships were now visible to everyone. This was a big cultural shift – no more guesswork on who to contact for a given service. For example, the “Payments API” service was clearly marked as owned by the Payments Team, with that team’s Slack channel and tech lead listed.
Linking Documentation and Context: As part of populating the catalog, they also linked each component to relevant resources. Compass allowed adding pointers to runbooks, design docs, Confluence pages, or support dashboards for each service. The team made sure that for each critical service, the latest documentation and operational playbooks were just one click away in Compass. This immediately started chipping away at the information silo issue – developers could go to the Compass component page and find the links to everything they needed without manual searching.

During the onboarding process, Atlas Bench conducted workshops and hands-on sessions with a pilot group of developers and site reliability engineers. This pilot group acted as early adopters, providing feedback and championing Compass within their teams. Their excitement grew as they realized how much easier it was to navigate the company’s complex architecture using the Compass catalog. A developer could type a service name into Compass and instantly see what it does, who owns it, where the code lives, and where to find its documentation. The days of sifting through Confluence or hunting down the “service owner” were over.

By the end of the onboarding phase, the company had a living, breathing software catalog in Compass that mapped out their entire system. It was already reducing friction – new employees said it was a game-changer to have an internal “Wikipedia of services.” But this was just the foundation. The next steps would leverage more Compass features to drive deeper improvements in consistency and quality.

Two people reviewing large documentation.

Step 3: Configuring Compass to Fit the Organization’s Needs

Having all components and teams in Compass was powerful on its own, but now the company needed to configure and tailor Compass to get the maximum benefit. In this phase, they focused on shaping Compass around the organization’s processes and governance requirements:

Custom Tags and Organization: The teams organized components using tags and fields that made sense for their business. For instance, they tagged each component by product line (e.g. Mobile App, Web Platform, Data Pipeline) and by type (Service, Library, External API). This allowed developers to filter and search the catalog easily (“show me all services related to the Mobile App” or “find all shared libraries”). It mirrored the architecture domains that architects and product managers were familiar with. By configuring these taxonomies in Compass, the company ensured the tool felt natural and intuitive to navigate for their staff.
Integrations with DevOps Tools: Atlas Bench guided the company in connecting Compass with their existing DevOps and CI/CD tools. They installed Compass apps/integrations for their source control and pipelines so that Compass could automatically stay up-to-date. For example, when a new repository was created in Bitbucket for a microservice, an integration would auto-create a corresponding component in Compass. Similarly, build status and deployment info from Jenkins was linked, so each Compass component could show its latest build results or production deployment status. This real-time syncing meant Compass always reflected the current state without manual data entry.
Team Access and Permissions: Given the enterprise scale, they configured role-based access controls. While Compass is largely meant to be open and transparent, the company ensured sensitive components had appropriate visibility settings. They used Atlassian’s permission schemes so that, for example, only certain leads could modify critical metadata, whereas all developers could view and comment. Atlas Bench shared best practices on balancing openness with control, aligning with the company’s internal governance policies.
Defining “Golden Path” Standards: At this stage, the company’s DevEx committee (a cross-functional group formed during the project) defined a set of best practices and standards – their “Golden Path” for software development. This included things like: every customer-facing service must have an on-call rotation defined, must meet a minimum test coverage, must have a corresponding knowledge base page, and follow the latest security guidelines. Instead of keeping these standards in a policy document no one reads, they leveraged Compass to bake them in (to be enforced via scorecards and templates in the next phase). The Compass configuration included custom fields and placeholders for these items (for example, a field for “on-call schedule link” on each component). This laid the groundwork so that Compass would actively promote and track adherence to the Golden Path across all teams.

By customizing Compass in these ways, the company essentially molded the platform around its unique environment. The configuration phase turned a generic tool into a tailored internal portal for the company. Developers appreciated that Compass spoke their language – using the team names, tags, and categories that made sense to them – rather than a one-size-fits-all structure.

Atlas Bench’s expertise was valuable here to apply lessons from other implementations: they knew how to structure the data model in Compass to scale, and how to avoid over-complicating things. The end result was a Compass setup primed to drive consistency and transparency, while still flexible enough to evolve.

With the catalog populated and configurations in place, the company was ready to connect Compass with the daily workflows of developers, especially through the tools they were already using like Jira and Confluence.

Step 4: Integrating Compass with Jira and Confluence – Uniting Workflows

A key goal for the company was to break down the walls between planning, documentation, and engineering. The next step in the journey was integrating Atlassian Compass with the company’s ubiquitous planning and knowledge tools: Jira Software and Confluence. These integrations ensured that Compass didn’t sit in a vacuum but became an embedded part of everyday work.

Linking Compass Components to Jira Issues: Atlas Bench enabled Compass’s integration with Jira so that developers could associate work items with the relevant software component. For the company, this meant when someone created a bug or user story in Jira, they could select the affected Compass Component (from a dropdown of the Compass catalog) right inside the Jira issue. For example, a bug ticket in the Jira project “Payments” could be tied directly to the “Payments API” component from Compass. This simple linkage paid huge dividends: any engineer looking at that Jira issue could now click through to see the full context of the component – its documentation, owner, recent changes, etc. It also allowed roll-up views, like seeing all open issues or incidents associated with a given component. In practice, this trimmed down the time to troubleshoot issues, since developers no longer had to ask “what is this issue about?” or “who knows about this service?” – Compass provided the answers instantly via Jira.
Surfacing Component Info in Jira: The integration also enabled a Compass widget inside Jira. When viewing a Jira issue, a panel would display key info about the linked component (like its health score or lead developer). During incident management calls, teams would pull up a Jira ticket and immediately see which service was impacted and who to ping, thanks to that Compass contextual data. This kind of cross-tool visibility was new to the company and eliminated a lot of back-and-forth communication.
Confluence Knowledge in Compass (and vice versa): the company heavily used Confluence for project documentation and knowledge bases. To prevent Confluence from remaining a silo, they integrated it with Compass as well. They established a convention that each service in Compass had a corresponding Confluence page or space for detailed docs. Using Compass smart links and macros, they embedded links to Confluence pages on each component’s Compass page (and could even embed Compass excerpts on Confluence pages). In practical terms, if a developer was in Compass looking at the “User Profile Service” and needed technical details, a link would take them straight to the design spec in Confluence. Conversely, if they were reading a Confluence runbook and wondered who to contact for updates, the page showed the Compass info with the owning team. This tight integration meant information flowed seamlessly: no more treating documentation as separate from the components it describes.
Automation Between Tools: Atlas Bench also helped the company set up some handy automations using Atlassian’s Automation framework. For example, when a new component was added in Compass, an automation rule would create a Confluence page using a template for that component’s documentation (ensuring every new service had a docs starter ready). Another rule updated Jira issues’ fields if a component’s status changed (so if a component was marked “deprecated” in Compass, any new Jira tickets linked to it would get a label or warning). These automations reinforced consistency and saved manual effort, allowing tools to stay in sync in the background.

By integrating Compass deeply into Jira and Confluence, the company transformed the developer workflow into a connected, context-rich experience. Developers no longer felt like they were working in separate islands of activity (writing code here, filing tickets there, reading docs elsewhere). Instead, all these activities became interconnected. The information silo walls were effectively torn down:

“It’s like the fog has lifted – I can see everything I need in one place,” noted one senior engineer. “If I’m in Jira, I have Compass context. If I’m in Confluence, I know how it ties to our systems. It just feels like our tools are finally talking to each other.”

This integration step had immediate benefits: it reduced the time spent searching or switching apps, and it improved cross-team collaboration (since everyone could easily get context on any part of the system). Importantly, it also set the stage for the next phase: using Compass’s capabilities to drive improvements in the health and consistency of those components now that they were all being tracked.

Woman managing software components on a desktop interface

Step 5: Leveraging Scorecards and Templates for Continuous Improvement

With Compass fully embedded in the organization, the company turned to the powerful features that would sustain and scale improvements in DevEx: Scorecards and Templates. These features helped the company enforce best practices and make lasting changes in how software is built and maintained.

Implementing Health Scorecards: The engineering leadership, together with Atlas Bench advisors, defined a set of health scorecards in Compass. Scorecards are essentially automated checks that rate each component against defined criteria. the company created a few targeted scorecards:
- Reliability Scorecard: ensuring each service meets operational readiness standards. This scorecard checked that a service had an on-call schedule defined, a runbook linked, monitoring alerts set up, and had been through a disaster recovery test. If any of these items were missing for a service, Compass would flag it and the service’s reliability score would drop.
- Engineering Excellence Scorecard: focusing on code quality and maintainability. It aggregated metrics like unit test coverage percentage, linting/code quality tool results, presence of CI/CD (continuous integration) pipelines, and whether the latest build was passing. A service with outdated dependencies or low test coverage would show a lower score, signaling the owning team to improve that aspect.
- Security & Compliance Scorecard: ensuring adherence to governance. This checked for things like known critical vulnerabilities (integrating with the security scanning tool), whether the service had completed a threat model document, and compliance with data handling guidelines. It also tracked if each service’s documentation and API were up-to-date with the latest compliance requirements.
These scorecards ran continuously, giving each component a dynamic “health grade.” For example, a service might show 85% on the Reliability scorecard and 90% on Engineering Excellence. If a team neglected something (say, their test coverage dropped after some rushed releases), the scorecard would catch it. All teams could see their scores on a Compass dashboard, and leadership could see an aggregate view of overall software health. This gamified and incentivized best practices – teams started competing in a friendly way to have the healthiest services. More importantly, it brought lagging areas to light. Within weeks, teams responded to scorecard alerts by adding missing documentation, improving tests, and fixing security issues before those issues caused incidents. Compass scorecards turned governance from a painful, occasional audit into a real-time feedback loop integrated into daily work.
Establishing Golden Path Templates: While scorecards improved existing services, Templates ensured new services started off on the right foot. Atlas Bench helped the company create a set of “golden path” software templates in Compass. These templates were essentially blueprints that any team could use to bootstrap a new microservice or library with all the best practices built-in. For instance, the company’s backend teams now had a “Standard Microservice Template” which, when used, would automatically:
- Create a new Git repository with a skeleton project (including a basic service framework, example tests, a CI pipeline configuration file, and a README outline).
- Register a new component entry in Compass for that service, pre-filled with required fields (like the team owner, links to sample docs, etc.).
- Generate a Confluence page (via the earlier automation) using a template for design and support documentation of the service.
- Set up the initial scoreboard entries (so the new service would immediately be tracked by the health scorecards from day one).
Using this Compass template, teams could literally create a new service in minutes, with one consistent process, rather than spending days copying boilerplate and configuring tools. It also meant no new service would fall through the cracks or be missing critical pieces – the template made sure the golden path standards were applied uniformly. One developer remarked that spinning up a new service used to be a week-long ordeal of ticket requests and manual setup, but “with Compass templates, I had a hello-world service with our company’s standard build and monitoring ready in under an hour!”

The company didn’t stop at just code templates. They also defined templates for things like “New Team Onboarding”. When a new development team was formed, there was a Compass-driven checklist and Confluence template to ensure each new team set up their space, listed their services, and followed the same proven practices as existing teams. This effectively scaled the DevEx improvements to every corner of the engineering org.

Through scorecards and templates, Compass became not just a static catalog but an active DevEx improvement platform. It continuously measured and guided the engineering teams toward better practices. Over time, this led to compounding gains: each quarter, the average component health scores went up, and new projects hit the ground running faster than the ones before.

Atlas Bench monitored the metrics and helped adjust the scorecard criteria as needed, fine-tuning them to avoid any unintended behaviors (for example, tweaking the test coverage target to be ambitious yet realistic). The partnership ensured that the focus was always on improving outcomes, not enforcing rules for the sake of rules. Developers appreciated that the scorecards actually helped them by highlighting issues they might’ve missed, rather than feeling like micromanagement. It was like having an automated coach for each team, pushing them toward engineering excellence.

With Compass fully utilized – catalog, integrations, scorecards, and templates – the company started reaping tangible benefits. Let’s look at the results after they completed this transformation journey.

Designer updating a mobile UI – symbolizing customization and configuration to fit team needs.

Results: Measurable Impact on Velocity, Quality, and Morale

After several months of using Atlassian Compass, the company saw a transformative impact on its engineering performance and the success of its digital transformation initiative. By focusing on DevEx and systematically improving it, the company achieved results that were impossible before. Here are some of the notable outcomes:

Accelerated Deployment Velocity: Teams significantly increased their release frequency. What used to be monthly (or slower) release cycles for many services became weekly or even daily deployments. Overall deployment velocity improved by ~40%. With less time wasted on coordination and setup, developers delivered features faster, directly supporting the digital transformation goals.
Shorter Lead Times & Faster Recovery: Lead time from code commit to production dropped markedly, thanks to streamlined workflows. Moreover, when incidents did occur, the Mean Time to Recovery (MTTR) improved by an estimated 60%. Compass made it easy to identify owners and dependencies during outages, so issues that once took hours to diagnose were resolved in a fraction of the time.
Reduced Time Spent Searching for Information: The single-source-of-truth approach paid off in daily efficiency. Developers reported saving several hours per week that were previously lost searching for docs or the right person to ask. In fact, a follow-up survey showed an 80% reduction in time spent finding information. Nearly everything was accessible via Compass in a few clicks, keeping developers in flow instead of on scavenger hunts.
Fewer Incidents and Better Reliability: Proactive improvements driven by scorecards led to a drop in production incidents. Over the first half-year, high-severity incidents fell by ~30% as teams addressed issues (like missing monitoring or stale components) before they caused failures. The overall system health trend was upward – Compass’s health scores confirmed that services became more resilient and compliant over time.
Greater Adherence to Standards and Governance: Thanks to automated scorecards and templates, the company achieved near 100% adherence to its engineering standards across all teams. Security scans were being run on every service, documentation was consistently maintained, and every microservice met the baseline requirements set by the governance team. Internal audits and reviews that once turned up many gaps now found far fewer issues. The CTO could confidently report to the board that the software delivery process was under control and continuously improving.
Improved Developer Morale and Engagement: Perhaps the most important result was the cultural shift. Developer sentiment soared. In engagement surveys, developer satisfaction with tools and processes jumped by 25%, reversing a downward trend. Teams felt empowered – they had the clarity and resources to do their job without unnecessary hindrances. Knowledge sharing became the norm. New hires ramped up faster (onboarding time for new devs reduced by 50%), which boosted confidence and morale. Anecdotally, engineers said they felt like they were “finally working on the product, not fighting the infrastructure”. The renewed energy translated into more innovation and a willingness to embrace further transformation changes.

These outcomes illustrate how improving DevEx isn’t just about making developers happy in a vacuum – it directly drives better business results. the company’s digital transformation was back on track and even speeding up. With developers freed from mundane roadblocks and aligned on best practices, the company could tackle ambitious projects (like new customer-facing features and platform modernization) much faster. In fact, the gains in productivity and quality gave leadership the confidence to pursue initiatives that previously seemed too risky or slow to attempt.

Scaling DevEx Improvements Across Hundreds of Teams and Thousands of Developers

One of the most impressive aspects of this journey is how the improvements scaled across a large enterprise. company’s success was not limited to a small pilot team or a single department – it spanned hundreds of teams and over a thousand developers. Here’s how Atlassian Compass enabled DevEx excellence at scale:

Unified Platform for the Entire Organization: Compass proved capable of handling company’s vast ecosystem of services and users. At full rollout, the Compass catalog contained information on hundreds of components maintained by dozens of teams. Yet, performance remained snappy and organization remained clear, thanks to the structured approach taken during configuration. Whether a team was in a core product group or a supporting infrastructure group, they all worked off the same platform, ensuring consistency in how work was documented and tracked.
Consistency Without Centralization Overhead: Traditionally, enforcing standards in a big organization requires heavy-handed governance and lots of meetings. Compass changed that dynamic. The scorecards scaled the governance – once set up, they automatically applied to every relevant component. If leadership decided to raise the bar (say, increase required test coverage across all teams), they could adjust the scorecard and that expectation would instantly propagate to every team’s dashboard. This is far more efficient than chasing each team individually. It created a lightweight, automated form of governance that kept all teams aligned without constant oversight.
Cross-Team Visibility and Collaboration: With thousands of users on the platform, Compass became a social nexus for engineering. Teams could easily discover what other teams were working on, reuse internal APIs, and avoid duplicate efforts. For example, one team planning a feature could search Compass to find if a service already existed to provide that capability – something that previously might be hidden in a different department. This led to more reuse and design consistency across products. Essentially, Compass helped scale knowledge sharing, so even as the company grew, it acted “smaller” in terms of being able to know what’s going on.
Supporting Hundreds of Deployments and Changes: The integration of Compass with CI/CD and Jira meant that at any given day, dozens of deployments and code changes across various teams were being tracked and reflected. Compass’s architecture handled this continuous flow, updating component statuses and health metrics as changes happened. It served as a central dashboard for engineering leadership to monitor progress across all teams. Executives could open the DevEx dashboard in Compass and see key metrics (like DORA metrics for each team, overall incident counts, etc.) in one place. This holistic view at scale was invaluable to guide the digital transformation at the strategic level.
Adaptability for Different Team Needs: Despite being company-wide, Compass wasn’t a one-size-fits-all straitjacket. Different teams could extend it to fit their unique needs via the extensibility features. Some teams built small custom Compass apps – for instance, the Data Engineering team integrated a data lineage tool into Compass so that their pipelines showed lineage info as part of component details. Another team integrated Slack notifications with Compass scorecards, so they got alerts in their chat channel if their service’s health score dipped. This flexibility meant that even with thousands of users, each subgroup felt Compass was working for them. The platform scaled not just in number, but in versatility.

In short, Atlassian Compass enabled the company to standardize where it mattered and customize where it made sense. That is crucial when scaling DevEx improvements in a big organization. By applying common foundations (catalog, ownership, basic scorecards) universally, and allowing tailored extensions, Compass supported growth without becoming rigid.

Atlas Bench’s guidance was also instrumental in scaling. They helped establish a center of excellence at the company for Developer Experience, so that knowledge and improvements continued to propagate after the initial project. They trained internal “Compass champions” within different departments to support their teams, creating a self-sustaining ecosystem. The improvements in DevEx proved not to be a one-time win, but an ongoing journey of enhancement that the company could carry forward long after the consultants wrapped up.

Team collaborating at a desk with dashboards – visualizing cross-team visibility and collaboration.

DevEx as the Key to Digital Transformation Success

The company’s journey vividly demonstrates that investing in Developer Experience accelerates digital transformation. By identifying and removing the friction points that slowed down their developers, the company unlocked potential that had been sitting latent. Atlassian Compass, deployed with Atlas Bench’s strategic partnership, was the enabler of this change – providing the platform to unify tools, information, and best practices at enterprise scale.

What changed for the company was more than just adopting a new tool; it was a cultural shift. Developers went from feeling frustrated and siloed to feeling empowered and connected. The organization moved from chaos to clarity: every service known, every team accountable, every process streamlined. This clarity allowed them to innovate faster and respond to change more readily – which is the very essence of digital transformation.

Crucially, the improvements were quantifiable. Faster deployments, fewer incidents, higher satisfaction – these are outcomes any technology executive would celebrate. They make a strong case that DevEx is not a “nice-to-have” but a strategic lever. When you improve the daily lives of developers, you improve the outputs of your entire tech organization.

For other large software companies on a transformation journey, the company’s experience offers valuable lessons:

Start by understanding your developers’ pain points – they often highlight systemic issues that can be fixed.
Treat your internal development platform with the same importance as your customer-facing platform. A tool like Compass can be the backbone that holds everything together.
Don’t underestimate the value of centralizing knowledge and ownership. It eliminates waste and builds a stronger engineering culture.
Use automation and metrics (scorecards) to continuously guide teams, rather than sporadic mandates. Continuous feedback leads to continuous improvement.
Ensure new projects and hires follow a golden path from day one, so scalability doesn’t breed inconsistency.
And consider engaging experts or partners who have done it before – a fresh perspective and experience can jump-start your efforts and avoid pitfalls.

The company's digital transformation is now far ahead of where it was a year ago, largely because they made DevEx a priority. Developers are happier and more productive, products are shipping faster with higher quality, and the company is more agile in the face of new business challenges. By improving DevEx, they didn’t just transform their IT – they transformed their ability to deliver value as a business.

In the end, the company's success boils down to an enlightened approach: Put developers at the center of your digital transformation strategy. Equip them with the right platform and support, as Atlassian Compass did, and they will drive your innovation forward. Digital transformation is about people as much as technology—and when your people (developers) have a great experience, they’ll create great experiences for your customers in turn.

The company’s story is a testament to the power of a better developer experience. By eliminating friction and connecting teams through Compass, they turned a faltering transformation into a thriving one. Any organization looking to accelerate its own transformation can take a page from this journey: invest in DevEx, and the rest will follow.

Interested in learning more? Contact Atlas Bench to book a complimentary consultation with our Certified Atlassian Experts.

How a Large SaaS Company Improved DevEx with Compass