Functional Teams Drive Service Ownership–Not HR Org Charts

Enabling Service Ownership is our north star at OpsLevel. We believe that true service ownership is the future of DevOps and a key to building agile, efficient engineering teams. As a part of making service ownership a reality, we’ve recognized that teams own services, not people. But of course, when you need to get something done urgently, you want to talk to a person, not a team. That’s why OpsLevel now supports tracking functional team membership alongside core service metadata.

When responding to an incident, it’s often not enough to know that the Order Management Team owns the Shopping Cart service that’s experiencing a latency spike. To quickly push a configuration change and resolve the incident, you need to talk to an actual service owner from that team to review your PR. Especially in large, growing engineering organizations, incident responders may not know team membership off the top of their head. But, with Functional Ownership Teams now defined in OpsLevel, this contact and team membership information is readily available.

A detailed understanding of who owns a particular service is also valuable in other less stressful, but still important situations. When it comes to building a culture of production readiness and improving baseline service health, progress is not always linear or straightforward. If you do have any services that are laggards in terms of passing checks or attaining the required service level, knowing which teams and managers to follow up with can make reaching your organizational goals more achievable.

Don’t rely on stale HR org charts that you have no control over

Importantly, team membership information in OpsLevel is not simply a duplication of data that lives in HR information systems like Workday and Bamboo or identity providers like Okta. We recognize that, within software engineering organizations, actual team membership is much more fluid than HR reporting structures. That’s why OpsLevel is focused on capturing and continuously tracking information about the functional teams that actually own and operate services in production.

This information can be manually added and updated within OpsLevel’s UI or programmatically with our GraphQL API. OpsLevel’s Slack integration can also be used to collect and update engineers’ team membership. When the integration is enabled, any user added to OpsLevel, but not assigned to a team, will be prompted in Slack to add themselves to one of the existing teams.

As architectures become more complex, dynamic, and ephemeral, having an up-to-date system of record of who owns what will only become more important. And beyond accuracy, OpsLevel believes this data can and should be foundational–integrated with and supporting a variety of routine workflows across software engineering organizations. Then you can use your system of record to break down knowledge silos–automatically. As one example, you could sync CODEOWNERS files from the team membership defined in OpsLevel to all your repos to ensure that new PRs automatically require approval from a member of the team that owns that service or repo.

Respond to incidents with context and confidence

In addition to the ability to track functional team membership, OpsLevel also recently announced the ability to store and visualize service dependencies in-app. Layering these two additional types of information on top of OpsLevel’s microservice catalog gives all users a more complete view into how your services, teams, and people are intertwined. By itself this is useful information, but for incident responders it can be gold.

When things go wrong in production, every minute wasted digging through spreadsheets or wikis for crucial information is a potential hit to your reputation or bottom line. With OpsLevel, provide your on-call engineers one central source of truth that can answer questions like:

• My service is seeing high error rates. Which downstream services could be the cause? Of those, which have been deployed recently?
• My service is down. Which services are upstream and who’s on-call for the owning team, so I can let them know?

With OpsLevel’s Slack integration, answers to these questions can be surfaced from incident or war-room Slack channels, further streamlining the process. If you’re ready to see Service Dependencies and Service Ownership Teams in action, request a demo of OpsLevel today