Made by
Made by
Josh Dzielak
Two things a developer relations program should understand are ‘How much do our developers like us?’ and ‘How many people are they telling about us?’ The answers shape the growth of communities, but it’s not obvious how to put numbers to them.
In this talk, Orbit co-founder Josh Dzielak shares examples of how real companies use data to calculate the love and reach for their communities and use that data to prioritize dev rel efforts. He also describes how you can start doing the same today to win the hearts and minds of more developers! No expensive BI tools or data science required.
My name is Josh, Josh Dzielak. I’m a developer advocate and software engineer. I’m currently the Co-founder and CTO at Orbit. Before that I was the DevRel lead at Algolia and VP of Engineering at Keen IO, which is all to say that I’ve spent a lot of time in developer tools in the space of developer community building, all the way back from probably 2013.
So, a lot of what you’re going to hear today is just informed by that experience that I’ve had. So today, I am building something called Orbit. This is the only time during the talk, I want to briefly mention the product because the product is really based on the model. And if you’re interested in any of this stuff that you see in here, then there’s certainly a way that we can help you with that.
We are in early access now. We’re letting people in. So, get in touch or check out orbit.love if you want to learn more there. So a lot of people, when they hear about the model, they asked me, like, first, what is it? But then also, where did it come from? What’s the backstory?
And I’ve actually never really mentioned this before in a talk. So the Orbit model actually goes all the way back to November of 2014. I was working at Keen. We were doing an off-site and just ended up whiteboarding some ideas for a community strategy with a few other people on the team and created this concentric circle model. And it wasn’t called Orbit or anything back then.
But was this formation of an idea that would continue on later. At 2016, when I joined Algolia, we started to use this idea more formally and even created assets that we shared to the company to describe how we were visualizing the community, what kind of metrics we were looking at and so on. After I left Algolia, in 2018, I started a consulting company called DeveloperMode where we, among other things, helped people use the Orbit model.
In 2019, we opened-sourced it. And now in 2020, we are continuing to build the open-source project as the model. We’re building a product, and so on and so forth. So what you’re seeing today still is just the very beginning of an idea. And there’s a long ways to go. But it’s something that I think has gotten better over time because it’s been iterated on, and we’ve gotten more and more people eyeballing it and contributing to it.
Let’s see. Some of the questions… So switching from the what to the why a little, the questions that prompted me to create the model and to think this way are things that I struggled with when I was doing DevRel and building communities. Like, how do I measure my community’s engagement and growth?
What members should I prioritize spending time with? What contribution should I ask each member to make? And how much value overall have we created for the community? You know, some of these questions, I assume, are very familiar to a lot of you who’ve sat there and then thought, or maybe are thinking for the first time, like, “How do we actually answer some of these questions?
So in today’s agenda, I’m going to take you through an overview of the Orbit model. And then for two of the Orbit models, key concepts, love and reach, we will go in and actually do a little exercise to set up how you would measure each of these for your community. And one of the things with the Orbit model, it’s designed to be really, really simple.
We’re not going to do any calculus or data science or anything like that. Calculating a lot of the basic things is just arithmetic and it’s very easy. The system is really designed for people who are already very busy and not full-time data analysts to be able to use. And yeah, I absolutely welcome discussion throughout.
I’m going to keep an eye on Slack. And thank you, Charlie, for dropping the message in there. I think the best time will be after each section. So as I go through the overview or as I go through love, or I go through reach, think about any questions you might have in there. And then I’m happy to, if we have time, to come back and answer those at the end of each one.
So without further ado, let’s just jump into the… I’m sorry, the overview of the model. So start with a little multiple choice. What is the Orbit model? A, is it a space-themed mental model and visual canvas for building communities, born out of working with developers? B, is it a metaphor for community in the way that the funnel is a metaphor for marketing and sales?
C, is it a vocabulary instead of metrics for measuring the impact and ROI of community? D, is it an open-source project that you can contribute ideas, documentation, and experiences to? Or E, is it an algorithm for doing a bitwise or operation? And if you answered A through D, you would be correct.
So I alluded and hinted at some of these in the introduction. Probably some of you already felt pretty confident about the answers. Yeah, A through D. The Orbit model, it’s a mental model, a vocabulary, a metaphor, and then, as I mentioned, an open-source project. And there’s really two things that we’re looking to do with the model, two outcomes or objectives that we want.
We wanna be giving our community members a better member experience, that’s more intentional, more deliberate, has something for them at every phase, all the way from onboarding, to activation, to retention. And then we want to show the impact of our team. We want to prove ROI. We want to demonstrate that our actions are valuable, are creating value in the community and creating valuable for the business.
So now here, I will show you this big image here and I will park, and stop a minute. And if you have coffee or tea, feel free to take a sip. I actually have a glass of water over here. So I’m going to take a second, as I know there’s a lot to take in here. But the Orbit model’s a visual model.
And so we have this graphic that tries to put everything on one canvas. And actually, if you get into it, there’s just a couple of concepts that I’m going to go over as it stands here. The one is the Orbit levels themselves. When you think of the center of the system, that’s the team in the center of gravity, the purple heart down there.
That’s you, the developer advocate, the developer relations, the developer community team. You and what you build, and what you do is what everything revolves around. The next level out from there, we call the ambassadors. And these are your inner circle of developers. These are developers who are out there giving talks, creating content, evangelizing for you, being your advocates.
You know them by name. You probably have a direct message chat going with a handful of them at any time. They know how to reach you, and there’s a very close relationship there. Before I move on to the fans, one thing that I’ll say, it’s a very common question is, do I have to call my Orbit levels the same thing? Do I have to use ambassadors and fans?
Maybe I don’t think about these people that way. And that’s totally fine. I would highly recommend you to use whatever labels you think are the most appropriate. If you’re an open-source, it might be core team, maintainers, contributors, instead of ambassadors, fans, users. Ambassadors, fans, users, comes a little more from products…when there’s more of a product in play, and that’s where users comes from.
But really, you can use whatever you want. And we encourage that so that it feels natural when you’re using the vocabulary and other people in your company will understand what you’re talking about. So to jump back here, the fans are not ambassadors. They’re not quite that passionate. You don’t know them quite that well. But maybe some of them will become ambassadors someday.
And they’re definitely tweeting about you, talking about you, reading content, attending your events, very common family things to do. Now, if I go up to the users. My clicker works here. So the users, and especially if we have a product, the idea of a user is very clear.
But these are folks who have used our technology and then are actively using it to at least do something. So they’re familiar with it. They know how to… If we’re making something for DevOps, they’re using that tool. If we’re making something for application developers, they’re using that tool. But maybe they haven’t discovered the community yet. Maybe they haven’t had enough experiences or moments to join the fans or the ambassadors.
We might call them product-activated but not community-activated. The last level are the observers. The observers may or may not have tried your technology, but they know about you. They could recognize the logo. They have an idea of what you do. Maybe they’ve done a demo or read a blog post or something like that. And they’re not a big part of the…
They might not know you very well, but there’s generally a lot of them. As you go out further and further in the Orbits, you probably go up by about an order of magnitude each time in terms of the number. Usually, communities have a kind of balance like that. You don’t have an equal number of ambassadors and observers. So there’s a lot of observers and that means that even though they only have a small relationship, they can still be very impactful for creating awareness.
So if you’re using the Orbit model, you can have some questions that you think of when you’re designing the member experience and what to offer to members at each stage. And then the visual Canvas as I’ll show you in a minute helps you figure that out. Questions like…or approaching members with questions like, “Do you want to give a talk at our next event?
Are you interested in mentorship or training? Can we include your blog posts in our newsletter? Can we hire you? Can we send you some swag?” and so on. Okay. So we’ve got a general overview here. That’s what we’ve just gone through.
So you have the vocabulary, the concepts. You’ve seen this big diagram with lots of colorful things floating around on it. The next part that I want to go into is about particularly measuring of the love. Now, if I go back very quickly here, you’ll see the increased reach and increased love on this diagram.
We’re going to talk about love. And as you can see, the big planetary looking thing, as we increase the love, it’s going more towards the center. So keep that in mind as we flip back here because we’re actually going to measure that, and I’m going to show you how we do that. Before I go into that, I do want to acknowledge a wonderful quote from Erin Frey, who is one of our Orbit community members.
And she put this in our community Slack the other day we were having a conversation about why do we use love instead of a term like engagement or something a little different. And she said, “Well, love is the currency that drives community.” And I thought that was really nice. And we know that we use these kind of funny words, like love and reach that aren’t super businessy.
But it’s important that they’re mapped to the concepts that exist in the business world. Again, as a set of vocabulary and terms, it’s important that not just within the DevRel team you can use these words, but when you go to other people in the company. So if you want to talk about love, you can also talk about engagement. So “Love is a member’s level of engagement and investment in the community.”
This is from the Orbit model documentation. “And someone with high love is highly active, plays key roles in the community like moderating, contributing, and organizing.” And there are five steps that we take to measuring love. And for each one of these, yep, I’m going to go through it right now. And you’ll be able to get a sense for how you might do it for your community. And this is a great time, if as I’m going through the section, you have questions, I will keep an eye on the Slack.
And we can take a pause right after this section if we want to see that and to answer any questions. So the first step is defining the activities. Because what we’ll do with calculating love is we’ll figure out the activities that matter the most to you, that your community members are doing, and we’re going to add those up and give the points to them.
The first step in defining the activities, the question is what actually matters in your community. What’s important? Is it community members publishing content? Is it community members giving talks? Is it community members coming to your events, doing pull requests or issues? In the developer world, there’s many, many ways that the communities get built and each one is a little bit different.
So, defining the activities that matter to you, in particular, is very important. Now, if you have questions about that or you need help jogging your brain, we actually have a resource for this. template.orbit.love will take you to a set of Orbit model Airtable templates, where you can see the mechanics that I’m about to describe coming together in Airtable format.
One of the tabs is called Activity Types. And on here, you’ll see a bunch of different options or a bunch of different activities for events, open-source content, and look at those. Those are all things that you might want to measure in your own community. Once we know what activities we want to measure, we can give each one a score. We can do that on a 1 to 10 scale, and keep it very simple.
To what I said before, we really want simplicity in the Orbit model. We don’t want you to give an activity of 4.75 points. It just gets tedious. It becomes harder to talk about, harder to calculate. So we’re very you know, like, shedding free in our encouragement of how people use the model.
If you’re not sure how much of an activity is worth, just pick a number and watch it over time and see if it feels right. But some examples to give you kind of a directional guidance, Joining a mailing list might be one point. Having a successful support interaction might be six. Giving a keynote at the user conference, well, that’s a lot. So that might be 10. Now once we have both our activity types and the scores for those types, then we can go and start recording those.
You can use a spreadsheet. You can use Airtable. You can use Orbit, the product. That’s one thing our product does to help you do this. But in general, you know, it’s not a ton of things, usually, unless your community is huge. And if you just take a few minutes each day or when interesting things happen, jot them down, put them in your spreadsheet or your table, and that way you’ll have this running list of activities and their scores.
Once you’ve done that, the next step is to assign love based on the sum and the max of the activities that have been created. So, here I’ll show you by example because I know this gets a little bit trickier. When we calculate the love, we look at the highest points activity that someone has done in a recent timeframe.
Maybe that’s six months in a lot of communities. So, if someone gave a keynote within the last six months, that’s our highest value activity, and so we’re going to give them the highest score for the love. And we do that instead of… You know, the other way would be to add up everything and add up all of the points. And that’s actually another interesting thing to do that doesn’t show you the best and the highest activity someone has done.
It just shows you the sum of all the activities. So if they’ve done 50 pull requests at 3 points each so that they have 150, that can tell you a great measure of activity. But a lot of times, for love and for what you’re using that for, you’re trying to see what someone is…what kind of activity they can do, what’s next for them? And looking at the maximum thing or highest score thing that they’ve done tends to be pretty helpful for figuring out what they could do next.
And so we assign love here. The next thing we do is the Orbit level. And that’s easier now because we have love and because we can sort our community by love. If we take all of the activities, if we take the love, we sort that, we get this list, we can start to break it up into the different parts that we think roughly represent our ambassadors, our fans, our users, and observers.
And I say Orbit level is a choice. It’s not something that usually just the numbers can provide because your concept of who’s an ambassador might be very hard to just get with the numbers or very pro-intuition, in addition to the data. So use your intuition to put people into the right category. But a lot of times, you should have a pretty good correlation between the love and the Orbit level if you’re actually tracking all of the activities.
Okay. Once you have all that data, you can usually generate reports. These are coming right out of the orbit model Airtable templates. Airtable templates are great, you can copy that. You can start using it on your own. And after a little bit of usage, you’ll be able to create reports like this.
On one side, we have just a grouping of members by Orbit level in our community. And on the other side, we’ve thrown another dimension in there, the location. So we have our Orbits in New York, in London, in San Francisco, in Tokyo. And that just helps us see locally or regionally in those areas, what is our distribution.
And if there were things like… We had tons of ambassadors in New York, but we had no ambassadors in San Francisco, well, we would see that just by looking at this graph. Once all of the reports and all that work has been in place, what you can then do is just discuss the information on an ongoing basis. Going back to our two pillars of member experience and team impact, we can ask and discuss questions like, “Who are our highest love developers? Who is ramping up or who is going dormant?”
I think that’s a really good question that you can see from the data. You have someone who you have always regarded as an ambassador or very high-love person but maybe they haven’t done anything in a year, maybe that’s a great opportunity to reach out to that person, and the data will tell you that. Do we have activities in place for members with each degree of love and on the team impact side?
Measure this over time. So we can see how is love changing over time and how is love changing in response to the activities that we’re doing as a DevRel team? And that gets to the question of showing the impact of our team and showing our ROI. If we’re creating a lot of love in the community through a lot of activities, one, we can show the growth of the community as a whole.
And secondly, we can show how that community activity is turning into business results, right? If we’re growing our observers by a lot, a lot, a lot, well, our content is going to get more traffic. If we’re growing our fans and our ambassadors, we’re probably getting more PRs, more product feedback, more signups, and so on and so forth. So, it’s a subject for a whole ‘nother talk that, hopefully, I’ll get a chance to do someday.
How do we take these Orbit metrics and map those to the business metrics that the rest of our company uses? Fantastic topic, and always happy to answer questions about that. But for probably a big topic, too, so I’ll unpack it another time. So, so far, we’ve gone through an overview of the Orbit model, and we’ve gone through how we calculate love.
I’m taking a look now at the Slack because I think we’re doing sort of okay on time. And I’m happy to answer a question so far if there’s been something about how we do all of this activity calculation or what all those Orbit levels were. Oh, great, and it looks like we’ve got a question here from Giam La Forge [SP].
And he’s asking, “Should we closely track each and every person in all of these Orbits? It’s fairly easy for the inner Orbits because we can name folks, but as we’re going further, it’s harder. That’s a very, very good question. One thing we say about the Orbit model is that it’s incrementally adoptable. Meaning that you don’t need to take your entire community and the whole thing, which for many of you might be tens of thousands of members, and start to track everyone’s activities at every level.
The first two Orbit levels, they’re the ambassadors and the fans. That’s where it’s most important, and especially with the ambassadors because if you have 10,000 people in your community, maybe you have 50 or 100 ambassadors. Maybe you have a couple of hundred fans. So at that size, even tracking all that fan activity can be hard. And then the most value you’re going to get about the strategy and priority on who you’re working with is going to come out of the inner Orbit levels.
So as a decent rule of thumb, you’re trying to have as much resolution around the ambassadors and the fans, in terms of the activities is really the important part. And then as you get to the outer levels, like users and observers, it’s not a first name basis thing. You might have some signal about them, but you’re not probably going out of you. way to write down the activities manually.
You’re accomplishing, I think more with doing integrations, like maybe connecting your support system or your product to something where you can see that…at Orbit, the product, we do this a little bit too for those other levels because we know that it can be a lot of challenge to get that data in place. Let’s see.
So, I think in the interest of time, I’ll keep I’ll continue on to the next section. But if we have time, then I can come back and answer any of the other questions that pop in. So, from love, we’re going to jump over to reach which is our second metric. So reach is a measure of a community member’s sphere of influence and takes into account their reputation, their credibility, and their degree of connectedness.
If you remember from the Orbit model diagram, love is how close they are to the center, and reach, we show visually as the size of that planetary body that’s there at Orbit. So Jupiter would be…someone with a Jupiter-sized reach is going to be depicted much more large than someone with Earth-sized reach. And again, because it’s all about…
We care about reach because we’re thinking about growing our communities and we’re thinking about how is the story of what we’re doing going to be told? How is the word of mouth going to happen? And whether it’s someone who has a lot of followers on social media or someone who works in a company where there are a lot of developers, people have different capabilities, different capacities to help us spread the word.
These little capacities we actually call signals. And just like defining activities is one of the first steps for love, defining the signals that you care about for reach is the same counterpart on the reach side. So what kind of signals could we be interested in? Well, as I said, it’s social media followers and engagement. It might be stars and followers on GitHub, might be reputation scores on communities like StackOverflow.
One of my favorites is the title and the position of the developer inside of their company. Both if they’re maybe a senior developer or VP, engineer, or CTO, you could probably assume that they have some influence, and also the size of the company. Maybe if they work for an agency that has 2,000 other developers or an enterprise that has 200,000 developers, you know,that also, depending on where you’re trying to get your technology adopted, that can be very important.
You can also look at the traffic to their blog or PageRank if you want, something like that, but you have this concept of all the signals. And just like with love and activities, you can give each one of those a value. Here we have a little system where we give one signal point, if someone has 1000 to 2000 followers, two to five, if they have two, five-plus, if they have three, give them a point for an active blog and a couple of points for an open-source project.
And maybe over 100 followers on Dev, they get…in the the Dev community, they get two points. As you can see, the math here, again, is quite rough. It’s not meant to be precise. It’s meant to give you a pretty good idea when you look at two developers and you want to compare them who has more reach, who might I want to ask to work with me on this thing maybe versus someone else?
Once you have these values, then we can go and record them. So if we have our two community members… Here are our demo community members, Avery and Laura, then we can add up to see…add up various signals that they have. And we can get a reach of six for Avery and three for Laura. And then based on that information, we can make some decisions.
We can do some reporting. And we can have a discussion about four particular things that we might want to do in our community. Who’s in the best position to amplify those? Breaking down the discussion into our two parts of member experience and team impact, reach helps us see… we can find the highest reach developers. And we can also ask if we have programs in place to increase the reach of developers at each level because that’s one thing that I should make sure not to skip over is that it’s not just taking advantage of the reach of the people in your community.
It’s actually helping them grow that reach. And anytime that we drop a community members content into a newsletter or we tweet it out, or we put that on any of our channels, we’re giving them visibility. We’re helping them increase their reach. And for fans and ambassadors, that’s very important. Someone who’s an ambassador, and maybe they’re also, you know, a big Twitter influencer in the developer space, obviously, reach is important to them.
And if you can approach them and say, “Well, we have this great newsletter. We’d love to put you right up at the top in the next issue,” you know, as someone who cares about that, then that really feels like an appropriate thing to go and ask. And reach helps us also know the way that we should approach someone.
If someone has a reach of 10 and they have a huge audience, there’s probably a different way that we approach them sometimes than someone who maybe is, like, early in their career or just getting started and has written their first blog post. So, figuring out the appropriate action, whether it’s love or whether it’s reach, that’s a lot of what the Orbit model is about. So, you don’t have to guess since you can create systems inside of your team, where no matter who on the DevRel team is doing the outreach, they’re following you same kind of thing, because you have these ideas of the values for the love and the reach.
On the team impact side for reach, we’re going to track how that’s happening over time. Track those moments where you feel like someone’s reach has increased. Make sure to attribute those to the work that you’re doing as a team. And then overall building the reach has a lot of business value all the way from brand building to driving awareness, to creating referrals.
And the more that you can identify the moments where you’ve, increased the reach of the community, and that’s led to new acquisition, activation, brand awareness, those are very important too. And, so again, kind of a nice subject for another talk where we go deeper into the business metrics.
But just wanted to note that and say there that you can…using the frameworks that you already have, which Orbit is really meant to supplement not replace, you can probably find a way to tie these values into that. Okay, great. So that’s the end of the reach section. And maybe what I will do, if we still have some time, I’m going to flip back and just put our Orbit canvas up on the board here, and then pop over to the questions.
Lets see. So we have a question from Jason. I think it’s St Cyr if my French Pronunciation… I do live in Paris. Hopefully, I shouldn’t have butchered that too bad.
He says, “Did I miss if there was an explanation about why we use love as the measurement versus a typical marketing strategy term like engagement?” Very, very good question. I touched on it a little bit when I showed the quote from Aaron. Because the quote actually came out of a discussion in our community Slack where we were discussing that very same thing, like, “Why do we have love and reach? Why don’t we just use engagement and influence?”
And some of it, I think there’s a couple of different reasons. One is that engagement and influence don’t capture the feeling that we have when we think about, like…when we want to grow the community, the idea of a currency…like, love feels more like a currency than, I would say, engagement.
But we’ve come a little bit further recently in the making the mapping a little bit more clear so that when we say love, we do mean engagement. But there’s more to love than just the engagement. One, in particular, is the idea of, they’re not just interacting with us so that we get value but also we’re giving value back to them. One thing we say often is the Orbit model is a value for creating value for the community, and only a small part of that is capturing value for the company.
But we’re thinking a lot about not just, like, the love that the community members are giving us, but what we’re doing there. So that’s an answer on that one. Now, one question in here from Lorna is, “Would you reward any of the activities externally? Or is this model you mostly useful for getting an understanding of the shape of your community?”
I would say yes, you would definitely use this information to provide some reward or some recognition that goes back to the community member themselves. So, for example, we have some flows set up. So in the Orbit community, we use Orbit to build Orbit. We actually have a blog post coming out this week that goes into that a little bit more.
We have things like Zapier flows setup, where if someone does a certain thing in the community that rings a bell somewhere and we get something together to like a swag to send them. And potentially, based on the history of their participation in the community, which we can see right in Orbit, then we can say, “Oh, like, I’ve already gotten a few stickers. They’ve been doing so much amazing stuff for us. Maybe it’s time to give them a T-shirt or a hoodie or something like that.”
And so I think you have the activities that the community members are doing. But it’s good to be thoughtful about for each one of those, what is the recognition that goes in the other direction? You know, if someone gives a keynote, there’s a moment of recognition there. And we always want to make sure that as the community members are participating on their side, that we’re doing the same thing too.
That’s a big part that keeps the overall equation flowing. So each time you can look in… even in that table you have for the activities you could add another column that says, “How do we recognize this activity? How do we reward this activity?” And you can fill that out. And then sometimes that answer might be pull request activity and then t-shirt. Okay.
Go back to our diagram here. Okay. So any other questions here?
Thank you, Nicola, for dropping in the blog post about building Orbit with Orbit.
Can definitely check that out on the blog. Nicolas one of our software engineers. Works here with me in Paris. I see some people typing so I will just take a sip of water and see what comes through.
Okay, we’ve got a question here from Mike Elsmore, and his question is, “If the community a product is involved in is built of many other open-source projects, how do you manage those all together, especially as they may not necessarily be owned by your company?”
That’s a very good question, one that we tangibly come up…have to work with, especially when we’re working on Orbit, the product, because it’s a very common thing now where a company has their core internal technology that is maybe proprietary and then they’ve got the open-source projects.
And I think that the question we often get is how walled off should these communities be from each other? Should we track it just as one big you group or should we look at the other ones or should we put them into different buckets? And I think my answer is usually put them all in the same bucket because that gives you more option value later with the reporting.
But then try to put the dimensions in there so that you can separate them when you need. Like, if there’s any chance that you would imagine someone contributing, or someone who’s using the paid product or the SaaS product free version, whatever it is, if a goal of the program is to get them involved with the community or to introduce them to the open-source project, then I would try to attract that in the same database, essentially, whether it’s Orbit or something else to try to put them in their.
And then just make sure that you have a tag on that person or you have some way to filter the reports or if you need to just see the open-source. I didn’t go into it too much today, but as you get the activities, you start to create this timeline for each of the community members that you have. And it’s important to understand things like, maybe after six months, it’s pretty common for someone to find out about the open-source project and start using it six months after they’ve used the product itself.
If you can create insights like that, that’s pretty interesting because then you can say, “Oh, why does it take six months? Maybe it could only take three months.” But if you don’t have the full timeline, if it’s kind of broken in two parts, you can’t see the interaction, then it’s a little bit harder to piece the whole story together. And from a modeling perspective, you will have to…
I think getting a little bit more nuanced is totally good there for the activity types. So you could have this global set of activities that could apply to either one, but you could have a different score based on where they’re happening. So, maybe a pull request to something that’s related to the paid product or platform tends to be something that’s like documentation, I fixed a, you know, a typo or something in the documentation.
Maybe that shouldn’t be worth that many points if that’s the common way that it’s used. But on the open-source side, maybe that’s actual, like real development of the product or the project, and that should count for more. So I think the complexity grows a little bit of having to have some columns in the spreadsheet where you can say, “Well, if it’s this kind of activity, we give it one score. if it’s happening over here, it’s one score.”
And if it’s happening another place, it’s another. And I think that’s the way to do it.
I was writing code maybe 10% of the time, maybe 5% of the time by the end. And recently, in the last year, we’ve really been building a lot of products. So that’s been 80% or 90%. So I’ve gotten to jump back into writing code like I haven’t done in like a decade. And that’s been really, really fun and really cool to see. That’s kind of always been one of my theories.
If you’re on the more technical side, coming from a technical background in DevRel, I love to think about getting in and being very heavy on DevRel and advocacy for a while and then taking a break to go back and geek out really hard on a particular technology that you’re really interested in, we were building our technology… We use Ruby on Rails, the Jamstack, a lot of technologies that are just really fun to work with.
And we’re getting opportunities to publish open-source, to write blog posts, to do a little bit of advocacy around those technologies too at the same time. So I’m really finding that having the background of doing DevRel and coming back to software engineering for a while, it’s like they really work together.
And in everything that we do, we’re thinking of, “How are we sharing what we’re working on? How are we publishing blog posts about what we’re building in our tech?” and so on. So it’s been interesting to do that. I’m looking forward to the future where I think I’ll get to swing back a little bit more in the advocacy direction and do more talks and things like that.
But it’s been fun to kind of geek out and just write code for a little while.
So I thought that was a really good point. And I’m glad that I asked that. My other question is how do you tie people together when you’re tracking this amazing StackOverflow username and then this amazing Twitter username or, like, a real name that’s giving talks? Is there a way of being like, “Oh, those are the same human?”
As you get to get bigger and bigger into the, especially the outer orbit levels, you can’t do all of that manually, but you still want to stitch people together. So then we can talk a little about this whole part, something called identity resolution. It’s something that we’ve worked on inside of the product Orbit itself so that we can try to do this as automatically as possible on behalf of the user.
And you do a bunch of techniques. You could look and see if someone has the same GitHub and Twitter, well, it’s not a guarantee that they’re the same person, but there’s like a 90% chance. So, maybe you say, “Okay, we’re just going to make them the same person. And if the user wants to unmerge them, then they can do that.” Look at first names and things like that.
So there’s not, like, 100% confidence unless you have an email. Maybe you have, like, an email in the Discourse and an email on the Slack. And okay, well, so then you pretty much have 100% confidence that that person is the same. Otherwise, it’s a little bit of manual plus the automatic, you know, trying to get to some kind of confidence score and then making it easy to say, “Yes, these two people are the same.
Let’s merge them,” or “No, they’re separate, and I’m gonna keep them that way.”