Champion's guide: How to navigate an internal developer portal rollout

You’re sold on how and why your organization needs OpsLevel, but getting leadership and your teammates on the same page requires coordination. That’s why we’ve created this “champion’s guide” walking you through the stages of the buy-in process—to minimize the guesswork and streamline your OpsLevel onboarding and adoption.

This article walks you through the process assuming you’re starting with a smaller group of stakeholders to test things out and troubleshoot before launching to a larger team. But when you’re ready for a full rollout, you can refine and repeat these steps.

1. Define your "why" and set baseline goals

As you make a case for OpsLevel, it’s important to identify the pain points you’re experiencing and the goals you hope to achieve with OpsLevel. This rallies the team around a clear future where they overcome these frustrations and operate at a higher level.

Common pain points our customers experience can be things like:

Given these pain points, here are some common goals our customers start to achieve as OpsLevel is rolled out and teammates move past the “old way” of doing things to help inspire you around your initial goals:

As your team gets more comfortable with OpsLevel, you should continue to revisit goals to make sure you achieved them, then set new ones to ensure you’re getting maximum value out of OpsLevel’s extensive platform.

2. Build alliances

Once you’ve got a clear list of your pain points and goals, it’s time to make sure you’ve got the right stakeholders involved to help you drive buy-in and adoption. This means enlisting the help of colleagues from across your org: someone in senior leadership, individual contributor (IC) developers who will use OpsLevel, and central platform teams who are responsible for security, reliability, and other important standards or best practices.

You should also establish which team will drive the initial rollout and who could become an OpsLevel admin to make sure they’re involved in the process too—especially if that’s not you or your immediate team.

For each unique group of stakeholders, you need to demonstrate a clear and urgent “what’s in it for me” to show that you understand their problems and goals, and are committed to ensuring OpsLevel addresses them—otherwise you risk getting put on the backburner.

For leadership, you’ll want to highlight how OpsLevel drives business goals:

1. Improved leadership visibility to assist in planning cycles and KPI assessments
2. More proactivity rather than reactivity
3. Saving time and effort that can be spent on more valuable development work

For ICs, you can explain that OpsLevel:

1. Automates standard processes and answers important questions about your architecture that would otherwise take time away from development work
2. Simplifies things as they change roles and the org scales (i.e., they don’t have to keep answering questions about work they aren’t doing anymore; can dive into a new team or service with ever-current metadata and documentation)
3. Make it easier to put out fires before they even happen (and in the moment when they inevitably do)

For the initial rollout teams and admins, emphasize that they can:

1. Curate what developers see and interact with the first time they log into OpsLevel.
2. Set standards for the rest of the teams, monitor who’s compliant, and drive change with campaigns
3. Use data and insights from OpsLevel to better advocate for platform team needs to leadership

3. Set expectations, share documentation

With a few checks set up, now it’s time to start doing some basic training, setting conventions and standards, and inviting teammates in to contribute. Most engineering teams find OpsLevel intuitive—especially when you give them this starting point.

Teach the basics

Teaching your team the OpsLevel basics is the first step, and it can be helpful to walk through something you’ve already created to show them what you did and how. You can also share our resources, like:

1. The OpsLevel knowledge base
2. The OpsLevel blog

And don’t forget to leverage the help of our Customer Success team for training, tips, and more.

Enhance your existing documentation

Additionally, you probably already have guides for incident response, service creation, onboarding, etc. so instead of reinventing the wheel, cater what you already have to include the new process in OpsLevel. OpsLevel is the means to an end, so framing your documentation this way makes it easier for the team to understand how it plugs in with what they already do, instead of being an entirely new system.

Set the right expectations

Even when everybody is trained on what to do, it’s important to set expectations to guide their work in the right direction. Here are some tips to keep up momentum:

1. Make it a priority - The work won’t happen unless it’s prioritized. Make sure you allocate sprint time and that leaders are dedicated to implementation.
2. Gamify it - Baked into OpsLevel is a prioritized rubric that lets you define which checks must be complete for a passing grade, then which checks are “better” (silver) and “best” (gold). This helps you prioritize which standards you want your team to focus on first rather than handing them an endless list of low-priority items. 
3. Focus on quality not quantity - Understand how much time and work it takes to get checks set up and monitor the work. If it feels like too much work, the team gets discouraged, but if things are happening in silos, it can get disconnected.

Create your first checks

While you’ve already set your overall goals in step one, at this stage, it might be a good time to start getting tactical and setting some implementation-specific goals like:

1. Catalog all of your services in the first two weeks
2. Establish key checks (e.g., service property for catalog completeness, or security-related checks) and ensure they’re running and passing in the first month
3. Ensure 90% of services are passing after three months

Once you’ve done an initial catalog import, one of the best ways to dive in is with simple service property checks, because all checks depend on services. These checks surface which metadata about your services is missing, so the teams that own those services will add that information to pass the check. 

Starting here is how many organizations complete their catalog creation phase—especially because the more complete the catalog is when someone logs in, the more likely they are to log in again. Check out our check creation 101 article to get more examples and see the check lifecycle.

4. Have regular check-ins

The final step of your implementation trial period is to have regular check-ins with your stakeholders to assess what’s working, what’s not, and how you can address it.

This can also be another place where leveraging our team is helpful, as you’ll have a dedicated Customer Success team to guide you through any questions and help you make progress, with regular calls and an exclusive Slack channel.

Though there’s always more to learn and improve upon, ideally by step five, you have: 

1. Clear goals for what OpsLevel will help you achieve (and checkpoints to make sure you’re working your way towards them)
2. Buy-in from major stakeholders
3. Some product training and best practices knowledge
4. Existing architecture in OpsLevel so new users have a starting point
5. The confidence to launch a larger rollout to the team

Success can come in many forms, with some teams completing their catalog in mere days to others that may need more hands-on support from our Customer Success team. Regardless, achieving this first milestone is key to reaping the benefits of OpsLevel to clean up and power up your development operations.