North star metrics and OKRs to show dev rel value

Vera Tiago: Thank you for joining my session. So I'm Vera and I'm here to talk about North Star's metrics and OKRs and how this framework can drive results, alignment, transparency, and also show impact to the business at our systems. We have been using OKRs for four years now and it's been quite a ride. So to start with and some sanity check time. Everyone knows that developer relations is a direct line between business and the developer community. And while some teams are more aligned with marketing, others are more aligned with engineering product or customer success. And regardless of where the rail sits, you can touch on all of these disciplines. So why is this topic relevant to you?

Essentially? Because you can work on many things, but it's important to have priorities, clear objectives, and to be successful. Reason number two, it's also important because you should create value to developers, but at the same time, you should have impact on the business outcomes or business goals.

And third, last but not least, your team needs budget. And in order to get budget, you need to prove the value of your work. So let's get straight to the business. What is the North Star metric and why does it matter? So the Northstar metric defines the relationship between the customer problems that your company is trying to solve and the revenue that is generated by doing so.

Also, the North Star metric is what drives direction and long-term growth for the company. So Northstar metrics helps in many ways. So number one, your entire company has the same focus and at the team level they can work in different things, but in the end it's everyone is working towards achieving the same goal. So reason number two, it's about clarity. So it's clear for everyone what the company is trying to achieve on the long-term vision. So reason number three, it makes our company customer centric because it's not just about generating revenue, but it's also caring about customer satisfaction. In the end, it's all about money and customer satisfaction. So two main outcomes.

Let me share some examples of North Star. On the left side, you can see the OutSystems North Star, which is live applications with many end users and number of live application is important, but also the user adoption of those applications is very critical because the users that are going to use those apps is what will bring benefit to our customers. So live applications and end users. And of course to achieve these numbers, we need developers. And this is where our developer relations narrative starts. So another very important aspect when talking about North Stars is the vision statement. And this is important because you want to make sure that everyone in the company remembers the North Star and the vision helps with that. Also the vision, having a vision in place helps with creating an emotional connection to your company's mission so everyone will remember.

So on the right you have more examples of North Star.

So Spotify is a very popular one. I don't know if you are aware, but there's a lot of resources online. Actually those resources explain a bit further how in this example time spend listening will bring benefits to the end users and at the same time we'll generate revenue. So what about Northstar Metrics and OKRs? So let's deep dive into it. So OKRs stand for objectives and key results. And almost like any strategic planning framework, it has three main elements.

So number one is a big overarching goal. Number two, a way to measure progress. And number three, the actions you'll do to achieve those results. When I started with OKRs four years ago, we did the exercise completely the wrong way because we start by looking to the initiatives that we had in hands and we created key results for this. So we created key results to justify the things that we were doing. And this is completely wrong. So what is the right way to define your krs? The answer is always start by looking into your North star and the business goals.

So how can OKRs bring alignment? As you know, DRE is in a unique position to maximise the work internal teams do already, but depending on where your team sits, you can receive some pressure or pressure on where to focus. For example, if your team sits at marketing, you probably are being pushed for demand generation or sales. And if your team sits, for example, in product, perhaps it'll be about education, developer experience, content, et cetera. So this example shows a framework that can help you to define your goals. It's kind of a mental framework for you to define your goals. So the North Star is something long and it'll translate into two primarily business outcomes. So money and customer satisfaction and to help achieve those two outcomes.

Developer relations can help for main areas, it can be awareness, adoption, education and retention to your developer community team. But the question is, so I can help in these four areas, but what should be your focus, right? So what should be your priority to answer that question? And besides the pressure that your department is doing on your team, you should look into two different things. One is the community and another one is the product. So maturity of your product and community. So for example, if you have a mature product and a growing community, you'll probably going to focus on education. Or if you have a new product in the farming community, it makes sense to make awareness your priority.

So all depends on the stage that your product and community is and of course your company goals. So let's get into an example here. Here you can have a glance at what North Stars and OKRs look together.

Like I said previously, our North Star is the number of live applications with many end users. So let's say our target is 50,000 live applications with 50 million of end users by 2023. To achieve these numbers, our company has some OKRs that we define each year. So objectives and key results that we define every year until 2023. So at the developer relations level, we need to make sure that there are enough developers to build those apps, those great apps that will be adopted by end users.

So we need to make sure that we have enough developers to serve our customers. So it's not just about the number of developers but also about their expertise with the product as well. So in this process of defining key results and objectives, we came up with our own not star, to help us bring us some clarity and focus, which is we want to achieve the zero talent gap.

I will explain what it is. So the zero talent gap or the Zita gap is about the operation model demand versus supply. So we need to make sure that there isn't enough supply in terms of developers in a market to fill in the needs of all of your customers. So to reach the zero talent gap, we need to one, add new developers to the ecosystem and to find the best ways to retain current developers and level their proficiency to meet the global talent demands. So to do so, we decided to focus on many areas, which is acquisition and retention.

And actually this had an impact on how our team is structured right now. So on a quarterly basis we define our goals for acquisition and for retention. This example here shows two of them. So one for acquisition, one for retention, we have more, but I wanted to highlight these ones too.

So in terms of key results, one was about to reach out to new developers. And for that we have an initiative that we called Low-Code School, which is a free two week training targeting developers from other technologies that are already in the workforce. So it's kind of a transition course. And another one is related to the online community and it's the target number.

Mission is to evaluate the progress in creating advocates in our community. So to achieve this, so to achieve this number of advocates, we have several initiatives like for example, badges, our champions, programme recognition initiatives and others.

But what about shared OKRs? What does mean? What does this mean? So sharing your OKRs a very, very effective tool as it creates alignment around outcomes and not just on organisational structures. So in a shared O2 or more teams share the same OKR, but each team has different initiatives or roles. So it creates kind of a virtual team that should be in sync to achieve goals.

So once you have defined your narrative on how to bring impact to the business, it's time to start evangelising other teams with your pitch and your joint efforts so them to join efforts with you to achieve your goals. So quick example around improve our experience this time, there's a lot you can do to help your developers to have a better experience with their products, but you will be more successful if you're not alone. So on the random note and related to develop developer experience, two weeks ago at DevRel Con, Jeff Schneider from ANA talked about feedback sessions that are very important to shape the product according to your developer needs.

So they created a team called the developer voice. So I recommend you to check this presentation for developer experience. And also last week, kilo from Google talked about removing friction and any specific example developer advocates were in charge of writing friction logs so that the product team could have access to them and resolve or solve those friction points in the product. So getting back to our shared here, I dunno if you saw the state of development relations 2020. So it is stated there that ideally Devra is a companywide responsibility and DevRel should work with others to develop these shared OKRs and share the success together.

That's why it's important not you to define these goals to your team, but create alignment and you bring other teams to help your goals.

I wanted to share this picture. These are some pictures from one of our exercises to define OKRs for a specific quarter. And this shows that everyone works on everything together. It actually, we brought many people from other departments to help in defining what should be our focus or what should be our priorities for this quarter. But what is the downside or what can go wrong when using OKRs? Ask me how I know. So not all roses when using OKRs and there's a few things that you should avoid when defining them.

So let's get straight to it. So first one is it's important that you don't confuse tasks with results because OKRs is about outcomes or results not about the activity. So OKRs are not tasks and because being busy doesn't mean you are accomplished results or you are bringing impact. So let's see an example.

So good key results and bad key results. So here we have an example for an objective and we have here for key results. So the first two ones, as you can see, they are about outcomes. So the numbers that we expect to achieve in order to evaluate if we were successful with that objective or not.

So it's about creating blog articles that are meant to be published by our community. And the second one is about the reach that content will have. So the last two ones are the bad ones, so are the bad examples. So ensure promotion in social media is in fact a task or an initiative or an action. And also create content guidelines is about an action or initiative that will help on those key results.

So number two, make sure you define measurable results because sometimes it's easy to do this. So it's easy for you to define non-measurable key results. Rather it's because they are impossible to track or because you're setting them as objectives or initiatives.

So key results must be a way to measure your goals and for this purpose, your key results need to include numbers to help achieve your goals. Ideally you have a baseline metric and a target metric so that you can track the progress. So picking in my previous example about developer experience, the way key results were presented before is now how they should be defined. I mean if you set your key results as just sign up to first up running time, you won't be able to measure or evaluate progress. So you need to know what is your starting metric and what is your target metric. So some hypothetical key results could be reduce the signup to first up running time to 10 minutes. So from, I dunno, one hour to 10 minutes or for example, increase the developer net promoter score to 55. So very random examples here.

So another very common pitfall is defining to many OKRs. And this is a real example by the way, this was one of our first quarters when we started with OKRs and the lesson here is if everything is a priority then nothing is right. So defining too many key results will result in a lack of focus and will be hard for you, show impact and to really show the value of your work. You are focused on too many things at the same time. So number four, one thing that you should avoid is define your orrs in silos. Silos hurt, alignment a lot. Everyone must be must have experienced that at some point. So while using OKRs, if teams don't align with each other or the company, they end up with very, very poor results.

So almost finishing my presentation here, but before I close I would like to share some tools that we use and that can be useful to you if you are considering to adopt this framework. So about tools, we use Confluence pages to document the company in our star vision strategy, product OKRs and to share with everyone internally. And we use Snowflake to store all the data that we need to be able to track progress and to measure in terms of reporting progress. And to update the numbers on a quarterly basis or to show progress, we use Google Sheets And speaking about this, one of the things that you should have in mind when working with OKRs is make sure that you have this cadence on checking in or updating progress on a regular basis with the entire team. So it can be something that you have scheduled on your calendar, it can be a weekly thing or every two weeks or a monthly. So make sure that you have this moment where everyone gets together, everyone from DE team gets together, update the numbers and we talk about the numbers.

So we call this OKR Check-in. So it's the KR check-in session and not just we update the numbers in that session, but we also update the level of confidence that we have about if we are going to achieve those numbers or not.

So we use red, green, and yellow to show this level of confidence and we use shiny dashboards to share all the metrics and to share everything that we are measuring with the entire company. So we have a global dashboard where everyone can see the numbers on the talent gap, everyone can see the numbers on active developers, everyone can see the numbers of what are the contributions from our champions programme. So it's a global dashboard for our team that we show with everyone about tips. There was a lot of trial and error, what to measure, what not to measure. And we realised that are things that may not be a priority but you still want to keep an eye on. And those are called health metrics. So health metrics can be a great addition to avoid setting up too many OKRs. So instead of trying to cover all the aspects of your business, you should only focus on the ones that matter for that quarter.

So everything else can be measured and reported without having a specific target for that quarter. And please note that these examples that I have in this slide can eventually become key results with specific targets if that is a priority at the moment. Last but not least, communicate and communicate your achievements. Don't assume everyone knows the results of your work. So by oversharing the work you are doing, you will find more collaborations opportunities and you'll find more allies that will help in achieving your goals. So wrapping up here, I would like to leave you with some key takeaways. So first one, you can apply the concept at the team level and this will bring more clarity and focus to your own team so everyone knows what is your direction. Number two, always align your OKRs with company goals and make them transparent to everyone.

Number three, don't let OKRs turn into new year's of resolution.

So update progress, communicate them, do the regular check-ins that I just spoke about. Number four, avoid OK R overload. So don't define too many OKRs. Again, everything is a priority then nothing is. So find the right balance between key results and health metrics. Number five, make sure you put your narrative in place when you are negotiating your ok because you need to explain why the goals you are proposing will impact on the business goals and also be transparent with your progress and always communicate the results you are achieving. So no matter if they are good results or better results, don't forget to communicate them on a final note.

So finding the right metrics and key results is key. But don't forget that DevRel's mission is about to build relationships and improve the lives of developers overall. And you know that not everything can be measured and you never know what benefits may come from the smallest interaction. So I recommend you to always follow your instinct, but whenever it's possible, prove them with data. Thank you so much.

Taiji Hagino: Hey, thank you very, thank you for your great presentation. It's interesting. Same for me.

The O okr. Yeah, actually now I'm trying to use OKR, the whole measurement of my work instead of the classical measurement method, but I'm sure how it the best way to use OKR. So it's very beneficial for me and I believe that it's beneficial for all attendees. And actually we have not yet. We have no questions from the Slack and YouTube and Twitch, but we get a great comment for you. The oks and no, a great tools for arming between people and the cross-functional teams. It's all.

Vera Tiago: So yeah, you are asking about cross-functional teams

Like having DevRel working with product team r and d.

Yeah, that is a very key factor inspection when you are focused on improving, for example, the developer experience with your product or your API. So it's API or products no matter. So it's important to have this a shared mission or shared goal where someone at your team can be responsible to achieve the key results, but then you have head another person from the product team to work together with you on achieving this. So this will make sure that the product team is listening to our feedback and you have the pet open for you to share your feedback, the feedback that you are collecting from the field. So from your developers because our main mission is to amplify the voice of our developers. So if you establish from the beginning that these teams have the same responsibility, so it's better for you in terms of achieving, in terms of being successful.

Taiji Hagino: I see. Thank you.

Okay. Now the one question that come here from Slack, just I read how do you avoid rabbit hole into metrics to the determinant of the thing you are trying to measure?

Vera Tiago: And I'm sure I understood the question, it's about the key results versus the metrics that we keep an eye on.

Taiji Hagino: Yeah, I think so.

Vera Tiago: Yeah. So we define the key results based on the priorities and again, to define our priorities, we get the team together, we talk about it, we talk about the areas that we need to improve. Of course always synchronised with the company goals. And then we have these side metrics that we keep an eye on.

Suddenly one of those metrics dropped. So we have a very hard drop on those metrics. We maybe stop or we maybe pause the things that we are doing to achieve key results and get back to those metrics, try to work on them to try to keep them at least stable and unhealthy. So this is why we do the trade-offs if nothing changed. So if the metrics maintain a constant basis, we will continue with our planned work, which is moving forward with our strategy to achieve the key results.

Taiji Hagino: I see, I see. Okay. And maybe it's my question.

So it's a relative question of this one. So how OKR is a very short term cycle to make a plan to measure of our work more than the classical measurement of the work method. So how long should we make the plan that each task of the to measure a work? What do you think about that?

Vera Tiago: Yeah, so that is a very good question. So what is the period of times that you should work on For us, we are using, so we define new OKRs or revisit our OKRs every quarter. There are some teams that they think or they feel that three months is too short to show some progress. So there are some teams that work in six months, for example.

One year I think is too much. So something between three months or three to six months I think is the right balance. And in your company, if imagine that your entire company adopt these OER things thing or framework, you can have teams that are working on a quarterly basis and maybe they are teams that are working on first half of the year or second half of the year. So like six months, six months, you can have different speeds for different teams. But I recommend on a quarterly basis.

Taiji Hagino: Okay, thank you. So actually the some audience comment for me, mic below is very low. Can you hear me?

Vera Tiago: Yes. Yes, right now. Yeah.

Taiji Hagino: Okay. Sorry. Okay, now we have no more questions from the Strat and YouTube would like or to track. So for audience, if you have any question for this session, please post to your question on the channel or you can ask her the directory via Twitter or emails or something like that.

Vera Tiago: Yes, I'm happy to answer any questions that the audience may have because I know some people watch this live.

Someone prefer to watch this maybe later in the days. So feel free to reach out anytime through Twitter or I'm in Slack too, so feel free to reach out.