Track everything, measure everything, it still won’t be enough

Ekene Eze: My name is Ekene Eze. I I'm a developer advocate at Flutterwave. And today, I'll be speaking about how you basically, not just tracking everything and measuring everything, but, ideally, how we did this my team did this at Flutterwave, and it wasn't enough. And we we did a lot of iterations going back and forth, and finally, something worked for us. And I'm really happy that I'm given the opportunity to share that with you today.

So if you're asking you or she wanted to know why this is important, why we are even considering this topic in the first place, you're probably asking the right questions. Because measuring the impact of activities communicating how it adds value to the company is a general challenge for different teams. And the truth is, DevRel is really young, and a lot of us are still figuring it out. So there's really no golden rule at this time that specifies exactly what you should be doing in this role or what exactly is expected of you without making references to the particular organization and the particular structure and the particular activities that you are doing as someone endeavor. So as a result, we are all kind of constantly figuring things out and doing what works for us individually.

So most some of the struggles that we go through or that we did go through while starting off in in at Flutter with is how what metrics we should track. Right? Every person working in DevRel today and almost every other DevRel team has, at some point in their careers, in their life cycles, asked a lot of these questions, and finding the answers is what drives us and what we keep on doing, to continue to improve ourselves. And how do we measure our impact as well? Finally, how do we communicate the value we are creating, to the company and to the people who are paying us to do this work?

These are very important, especially for people in our field because it it is this it is answers to these questions that helps you do well as someone in DevRel. It's answers to to this question that show that you are doing well in your job. If you if you provide these answers very well, your company will appreciate you. The developers who you are representing will appreciate you. You will be fulfilled in the job that you do, and you will be and you'll feel happy knowing that you've done a great job of it.

But the downside is if you are unable to overcome these struggles, it can lead to some unwanted outcomes, some of which are loss of confidence. Because when you don't know how to communicate your value or how to define the metrics that will shine a light on your skills, you can easily lose lose confidence in your in yourself, which will in turn results in in postural syndrome. Disbanding of teams also happens, I think, even just within the period of the COVID nineteen pandemic. We witnessed a lot of teams lose their jobs, and and that's that's really even by the side. This could also happen as a result of you, not figuring things out really well, knowing what should work for you, and setting up yourself and your team, to really understand how to communicate your values, how to measure what metrics that should matter to you, and and doing all all of that.

It could as well lead to lots of jobs. So let me quickly introduce you to my team. This is Rafael at at my far right, and I'm in the middle, and he's Adewale. We all joined our Flutterwave at the same time, and we were the first set of people coming into the company as developer advocates to work in a dev team that previously didn't exist. So in a of what we did was figuring out what would work, what wouldn't work, back and forth.

And and, basically, in this talk, I'm going to walk you through that journey, what we did, how we what how what was wrong, what was right, what worked, and what didn't work. So that at the end of the day, probably you have 18 or two to learn from our experiences. Alright. So I'll start with all the things we did. Joining Flutterwave, Flutterwave is a payments company in Nigeria that simply has a goal to simplify payments for endless possibilities.

I like to call it the strike of Africa because we power most of the payment processing going in and out of Africa. So what we did when we joined Flutterwave was organize community events. Of course, this is what you would expect from a dev team in a new company that has product that are developer centric. So you want to get into the community. You want to speak with your users.

You want to tell them about your products and services and all you can do. We did a lot of that, and we organized hackathons as well because we wanted to target young developers who are still in tertiary institutions. We went, and then we had hackathons, and we had students all over there take part in the hackathons, use some of these products, give us feedback. How is it working for you? Is it going well?

Is it not? We also did a lot of speaking at different conferences in and out of the country and basically evangelizing about what we do about the products we have and and then telling them more about what product is coming on and what's not. I will do blog posts because you would expect that a dev role team in a company that offers APIs and offers integration services with other services out there would, of course, be in charge of educating our users and writing blog posts where they will where they will learn about some of these things that we don't get to see at at at the conferences we attend and the community events we organize. Also, we provide a support on all sorts of e channels, Quora, Stack Overflow, Twitter, the developer forum, and all of these places where developers are on the side and where they have questions about our products and services. We are always available there to answer these questions.

Alright. So it it seems like we're doing a lot. I know. Right? But the truth is six months later doing all of this, we we started getting questions like this.

I mean, it it was time to do a bit of performance review and evaluation and all of these things that happened afterwards where you have to report your what you've done to the to the management. And, yeah, we thought we were doing a lot, and we thought we're doing enough. But, apparently, we got questions like, how does this contribute to revenue? What are the business implications? Why did we do this and that and that?

And is it in line with the what difference is he making? Is it in line with the business goals? And all of this. So at this point, we understood that we were doing what we should, but somehow we were not tracking any of the things we were doing. Right?

We're just doing a lot of things. So we we don't we're not benchmarking our activities against anything at all. But we know that every day we wake up, we go to the office, we do a lot of work, and we go back home exhausted, and we know we're working. But questions like this raised a lot of eyebrows and forced us to go back to the drawing board and rethink our strategy and try and find new and better ways to handle this. Alright.

So what did we do? You probably guessed it right, judging from the topic that I'm I'm I'm presenting. But, yeah, we tracked everything, right, from the how many readers we we got on the articles, on the blog post that we wrote, and how many users signed up from the conferences we've attended. Because we attended a lot, and we spoke at a lot. And then all of these things, we kept on doing this.

Right? It wasn't a a one time thing. We finished one. We then work on the next one. And, subsequently, we do a bunch of all these other things that we try to continue to do in the course of carrying out activities.

So we even monitor how much support we are providing on channels and social social media engagement, how how are we enforcing in party, how are we how how are we helping people understand better, and even sentiment analysis that we all know how difficult that can be to track or to measure. But we tried as much as we can to do to cover up all of these things. And the truth is it still wasn't enough. Right? And it wasn't enough for two for two reasons.

And the first is metrics don't equate to value. So they only kind of help you see it. So and at this time, we don't know what the value we are providing is. We just know that we are working and that we are tracking our numbers, but it doesn't exactly tell us what value it is we're providing for the company. So when we get that question, at this point, we still don't have that answer.

Then secondly, we figured out that the the company didn't quite understand what advocacy was. As at the time. The management didn't know what to expect from us because it's easy to get in a a a dev team and and have them do do some work for you. But then and and as it happens at the time, we were the first teams, the first team coming in into Flutterwave as a dev team. Right?

So it it doesn't exist before. So at that time, both us, our managers, the management team, we were all on the process of figuring all these things out on the way. Right? So we we we realized that the management team doesn't exactly know what to expect from us. And when that is the case, when expectations are not defined, every result you bring on the table has a 50% chance of being either good or bad.

Right? So irrespective of what you do, you can't be confident. You can't be comfortable with the result that you've achieved. Right. So that's why tracking everything and measuring everything, and it wasn't enough.

It didn't it didn't work for us. And then this is what we did. This is what worked for us. The first thing we did was go back to the drawing table and restrategize again for the second time after six months having been full time staff working on this. We had to go back and redefine our purpose.

And, basically, it means we wanted to properly inform the company that we're working with that this is what we do, and this is why we're doing it, and this is why it matters. Because if they don't understand these things, you can do all the work in the world. And when it's time to evaluate and review, and they don't know that this is what they should be looking at when they are looking at all the works you've done, It it wouldn't matter at all whatever you did. Right? So and, usually, this is really simple and easy.

It just means coming up with a probably one line statement that clearly answers these questions and then communicating it effectively to your managers and and and to the management team. So with us, we what we did what we came up with was we work with a lot of engineers on early stage products to offer delightful developer experiences to our users. This was easy. This was easy to assimilate. It's easy to tell someone that this is what you do.

And and it was easy for us to know that whatever we're doing in this company, whatever we intend to achieve, it is guided by this purpose that we've defined for ourselves. The next thing that we did that worked was setting expectations and goals for ourselves. The truth is before now, before we go to this stage, we really we really didn't know what we're doing or what we're trying to achieve. We just know that we are attending conferences and and doing all developed advocates related tasks, but we didn't know to what end. Right?

So at this time, we figured out we needed to streamline our activities and tailor them all to go towards a certain angle and to achieve a certain goal. And it could be anything. Right? As long as as long as you're doing what works for the organization you're working for and tell us to achieve the goals that you've set. And your set your your set goals could be anything that would help you at the end of the day look towards your activities and see what you've achieved.

Right? So in our case, we did a a lot of things, but it doesn't have to apply to you because, like I said, most of the time, this is still relative the company you're working for and the activities you're doing as a as a as a dev team. So it it could be improving developer experience. It could be driving sign ups. It could be getting a thousand stars on GitHub, send developers to Mars, pilot to Rocket, really whatever that would help you achieve the the purpose you've defined for your team.

The next thing is to establish the metrics. I chose pro properly and intentionally to leave this out, what metrics it is, because I strongly believe there are 90% chances these metrics are not going to apply to you depending on what it is you're doing. But, basically, it is how will you know if you are working towards the set goals. Right? In this step above, we talked about all the goals you need to set, and the metrics ideally are just there to help make it obvious for you that you are working towards goals that you've set.

Right? It could be it could be anything. Right? It could be if if if the goal is to get a developer on Mars, what are you doing along the line between now and when that goal expires? What are you doing along that line to ensure that at the end of the day, that developer is on Mars, right, which is the end goal.

So these metrics would help you keep you in check and keep you in the line towards the time you've set your goals and when you when you achieve it. And finally, report your progress because sometimes what we found out was we didn't we were not proactive enough with our reporting. Right? So we waited until after six months before we went before we went back to report what we've done. And at that time, we got all these questions about that we didn't have answers to.

Right? Which if we had done this earlier, we could have figured out that we're not doing the right things on time and probably taking measures to solve them and to make them better. So we did all of this, and I think this is what worked for us because since then, up until now, we've been operating properly on this structure, on this model, and we don't have any questions that we don't have answers to. And we've learned a few a few things doing this. One of the greatest lessons we've learned trying to set up a different team and getting a structure that would work for us and for the company we're working for was always one of the first lessons is to always involve your management because at the end of the day, you're not working for yourself as much as you are trying to do what you want and help developers and make the process of integration and everything easy for the end users are trying to meet their experiences better, you still have to answer to the companies who are funding all those events, who are paying for the tickets to the com to the conferences you're attending, who are helping you in every way possible professionally to get these things that you want to do done.

And if you don't involve them, if you don't know what's what's going on and why you're doing what you're doing, it will interfere with the activities that you've set out to do, which are the goals that you want to achieve at the end of a specified period of time. Also, we start trying new things and doing them differently helped us a lot. Because when we started, we went straight up to make some research, look at the real existing dev real teams, you know, that organizations, and we kind of followed a template, it seems, because we we were the first, and we didn't have prior experiences. We were all new to the field, and we figured, okay. We should really just check what other people are doing and doing.

And we did that, and it didn't work. So we learned that lesson here that trying to do things your way and maybe, of course, making research and finding solutions are very nice, but it it's only as nice it's only very nice, and it only works when you tailor it to your own particular organization, your own structure so that you would know exactly what to expect. Secondly, find out what others in your position are doing to know it's exactly what we did. At the first few months, we went on straight up to go and and make research and find out what similar dev teams in similar positions are doing and how they are going about it. And even though it's everything we found out didn't exactly apply in our case, but we're able to, at the end of the day, pick all the things that we needed and then streamline it to align with our goals and our expectations.

And it it was just, like, a step further for us to get that initial idea of what to do and then to know as to what we needed in our team. Another good lesson was to establish clear communication lines internally. Most of the time, when when in the course of doing the advocacy work, you need you need the team internally to help you out. In most cases, you need the engineering team, the sales team, the customer experience team. When you go out for conferences, when you get feedback, when you're trying to provide support, when you're trying to do when you generally, when you're trying to make sure that you offer developers out there using your product, it creates developer experience.

You want to communicate directly with the people who are in house, who are responsible for getting the things you want to be done for those developers done. Right? So we learned that this was really key in effectively doing our work because if a developer comes to you with an issue with a complaint that you can't solve on the spot, you won't you you would like to have someone in house answering you immediately and on the spot at that time, ensuring that you're doing that all the all the support you need is coming to you on the spot. Finally, one of the biggest, biggest, biggest lessons we learned was to always put developers first. Most of the time, we most of the fights that we've had has been with our engineering team, making sure that we do everything we see everything from the developer's perspective.

So once a new version of the API is out, we are we are the ones checking doing the QA for the developer experience, trying it out, making a few calls, trying to basically, trying to experience it the way a developer would. And each time we go back and forth, we we have to try and continue to put put the ideas in, tell them that this highlight is, oh, we've already done this. Are we are you saying we have to redo this? And, yeah, that's we keep doing that and doing that and making sure that at the end of the day, when this product goes live, developers don't have any issues at all using it. And a very good lesson as well is that it's okay to learn on the job because that is basically what we did.

We didn't come in with prior or previous experiences. We all came in at the same time and with zero knowledge. So we learned almost all that we know now that in general on the job while we're doing it. So we did a lot of back and forth, a lot of trials and perils, and we asked a lot of questions. And it helped us, not just tailor what we did, but shift the experiences that we offer to people who who we are representing within the company.

And, I can tell you that right now, the team and and our activities has evolved as well because we've gone from what we were when we joined, to where we are now. Community, tech support, developer experience, education and content. Now we help with APIs, optimizations, performance, and documentation. Most of these, we didn't know or we didn't think we should do at the time we joined. But right now, this is what the developer experience team at Flutterwave domicizing and what we do the most and where we try to put all our efforts in to make sure that at the end of the day, all the goals we have for all these activities are met.

What I would say to end is you have to do what works for you. Right now, developer experience and developer relations is spread out across multiple things, and there's a chance that what I'm doing at Flutterwave is totally and completely different from what you're doing at your company. And in that regard, nothing I say or whatever I what I I put onto you that I'm doing and it's working for me, there's a chance it doesn't work for you. Right? So at the end of the day, you need to do what works for you.

There's no golden rule yet. There's no there's no standard generally word accepted acceptable formats to go about developer relations. And that is what I will leave you with. Do what works for you. Try and and figure out what what activities is required of you as a dev team in your organization, and then tailor all all the things you found out and all your activities and all the ideas you bring in to those set goals and make sure that you communicate it properly with your management team.

So thank you very much. If you Matthew, if you have any questions for me, I will be ready to take that now.

Speaker 2: Hey, Kenny. Thank you so much for your talk there. I think my first question is around you mentioned that you looked at what other developer relations teams were doing Yeah. And other programs, what what experience they've had. Did you find that there were one or did sorry.

Did you find that you got the most useful information from programs that were like, that were from companies like your own, or did you learn from multiple different types of program?

Ekene Eze: So I think where we got the most effective information from were from companies who were doing almost the same thing that we were doing, and they had several teams trying to help out. But that wasn't all. We tried reaching out to several teams in existing companies like like Microsoft and Google, and we had we had contacts that we spoke to in person, and they told us and they give us kind of, like, an insight on how they are going about this, how they did that. And one other thing that was very helpful was joining the DevRel team, the DevRel global team for developers who are for for everybody who is in DevRel. There's a very a very huge Slack channel, yeah, that we joined and, yeah, and we got to meet a lot more people working in DevRel and learning from their own expenses as well.

But what what worked the most for us while we were trying to see what other people are doing and how it's working for them was speaking with advocate and DevRel teams in organizations that did similar to what what we're doing Flutterway.

Speaker 2: Okay. And and how long you mentioned in the beginning that your management weren't necessarily sure what to expect from developer relations. So do you feel that now that you've defined the purpose of the team and and Yeah. Your activities are more more well defined that Yeah. The people in leadership of the company have a better understanding of of what what you contribute.

Ekene Eze: Yes. Yes. That was particularly why we did the whole definition of purpose and goal setting and expectations then because we knew at the time that there there was no way for the company to and the management team to know that this is what we want or we need to expect from this team. And so we we created that document, and we shared with the management team, and we said, this is what the dev team is about. This is what you should expect from us.

This is what these are the expectations. We did all the setting up by ourselves, and then we made sure that we communicated that to them to know that at the end of the day, this is what we are. This is what we do. This is why we are here. And we're I don't I don't think most of the time, if you're joining an existing dev team, this wouldn't be a problem for you because there would already be something like that on the ground.

Right? So you probably join and and follow-up with what your colleagues are doing. But if you're starting a new role, a new or joining in a difficulty way doesn't exist before, I think it's very, very important that you do this and that you specify and clearly define what your purpose is and why what you'll be doing and just help the company and the management understand what to expect from you at the end of the day.

Speaker 2: Okay. Well, look, Kenny, thank you very much for your for your talks and sharing with us your experience of Flutterwave. It's it's been really great to to hear from you. Yeah. Now where where can people find you on the Internet?

Ekene Eze: I'm on Twitter most of the time at kenny underscore io is my Twitter handle. So if you want to reach out to me, I'm always available.

Speaker 2: Great. Well, thank you very much, and, well, thanks for being part of DevRelk on Earth.

Ekene Eze: Thank you very much for having me, Matt.