DevRel In Hard Places Podcast: Empathy, Community, and Business Alignment
A link to my latest podcast with Saim Safdar, where we covered some of the more challenging topics within developer relations
Saim Safdar was kind enough to invite me to his Cloud Native Podcast last week for the 100th episode, “DevRel In Hard Places | Ep 100”. We had a fascinating chat about some of the more challenging aspects of developer relations, and I also shared advice on building a career in this space. I’ve summarised the key takeaways and included an auto-generated transcript below.
Key takeaways
Looking for a tl;dr of our conversation? This is it!
Empathy and Community Engagement: Successful DevRel requires building empathy with developers and engaging effectively with the community to understand and address their needs.
Business and Community Goals Alignment: Balancing business objectives with community goals is crucial, ensuring both are aligned for mutual success.
Communication and Collaboration: Effective communication and collaboration with internal teams (such as product and marketing) and the external developer community are vital to driving successful outcomes.
Feedback and Adaptation: Regularly seeking feedback from both the community and internal stakeholders is essential for iterative improvement.
Mentorship and Learning: Engaging with mentors and continuous learning are vital for personal and professional growth in DevRel.
Video
The complete recording of the conversation between Saim and me can be found on YouTube: “DevRel In Hard Places | Ep 100”
Complete transcript
(Please note that this is an auto-generated transcript, so I’m sure that there are some humourous things that we didn’t actually say included here :) )
Saim (00:33):
Hello everyone and thank you very much for tuning into the cloud native FM podcast. Happy February for everyone watching us or listening to me currently and has been a player while talking to you today on this YouTube channel. We managed to pull together some of wonderful guests on this show because of your continued support and listening and your contribution on this channel is being some awesome today's, I'm actually recording and live streaming hundredth episode on this YouTube channel. I started this YouTube channel in 2021 with my first guest from Azure. That's name is Mike Piper, and he's the one who helped me support kick off this journey of initiating the YouTube channel. I started podcasting on cloud native Islamabad and then I created a new YouTube channel called Cloud Native Podcasts that focus more solely on the interviews and the insightful reviews from the people and the community folks who are doing some tremendous work in the Kubernetes platform, engineering, DevOps, software engineering, and developer relations domain.
(01:47):
It's been some one hell of a journey. Once again, thank you very much for listening to use this channel every week and sharing your reviews and that give me a dopamine that will continue my journey on the podcast. And today we have a wonderful topic to start off the February the second month of 2024 and we are speaking about developer relations. It's mid and some curtains that already been not actually covered. We are actually speaking to one of the wonderful guests who help us understand the nuances and the new roadmap that required to be a successful in the developer relations domain going forward. Before any further delay, it's been an historic moment and let me introduce Daniel Bryant. A few words about Daniel. Daniel is also hosting podcasts on InfoQ and his full description is an independent technical consultant, the news manager at InfoQ and emeritus chair for QOC Con London. Over to you Daniel, once again. It's pleasure talking to you today.
Daniel (02:59):
Thank you Saim, and congratulations. First off a hundred episodes, right? That's monumental, right? You think about mental words spoken that would fit into the books, that would fill all the shelves, so kudos on that. It's great to be here. I'm looking forward to a good chat. I know we've got a bunch of great questions already flying around. I will just caveat, this is just one person's opinions, right? I've built a couple of dev rail teams, I've had some successes, I've had some failures. The successes are all mainly due to my team, right? So fantastic folks. I'm sure I'll name check them as I go along, but if folks have got questions or don't agree with me, that's totally cool as well. Let us know in the comments and we can pick it up on air. We can pick it up afterwards via DMs or I'm on all the CNCF slacks, Kubernetes slacks @danielbryantuk. Most of the places love chatting to folks, love teaching, love learning.
Saim (03:41):
Yes, absolutely. And Daniel, we have some question ready, but give your perspective how you delve into the dev world, how you started this journey and what are the different developer communities who happen to be involved today and in the past?
Daniel (04:01):
Yeah, great question Saim. And like many folks. I kind of fell into the role, if I'm being honest. So I'm a longtime developer. I sort of cut my teeth primarily in the Java space, but was doing a lot of my SQL or SQL in general doing some JavaScript back in the day. And we are talking prototype and Tacular days showing my age here, but two thousands kind of was when all these tools were coming out. So longtime engineer moved into architecture, moved into operations, but I'd always enjoyed sharing what I'd learned. Do you know what I mean? So very early on in my career, I loved going to meetups in London. It was big back in two thousands. I loved reading books and I spun up a blog and all these kind of things. So I'd always enjoyed just that kind of community vibe. I wanted to be part of a community and I was super lucky.
(04:47):
I think it was late two thousands, early 2000 tens when I was working in London once again. And I met some amazing folks in the Java community and that was my first proper taste of helping to build a community, particularly around at the time open JDK, which was the open source version of Java. Still going strong and I only played a tiny little part in it, but it was a fantastic learning experience. I've got to name check folks like Manny Kar, Richard Warton, Jim Goff, Trisha G. There was Simon Maple. I'm sure folks will recognise some of those names. There was many people that brought me along on that journey. Martin Verberg, Ben Evans, my mentors really encouraged me all the time to like, Hey, don't just learn stuff. Teach it, you'll learn it even better. You'll bring other folks along on the journey. And I did that and I did meetups and then moved on to other conferences.
(05:37):
Absolutely loved that. And then along the way I moved more into the product management kind of things. I really enjoyed some of the marketing stuff and I've been doing dere for a number of years, but my boss at the time, I was working for a company called Ambassador Labs. This is like, I dunno, a few years ago now, he was like, do you want to spin up a proper dev rail team? And when I looked back, I'd kind of built some DevRel teams when I was at Spectre Labs with Hover Fly, I kind of helped build some of the open JDK community around London. And I was like, you know what? Let's give this a try. Let's be a professional DevRel, right? Rather than being a hobby, let's be a professional. And I loved it. Great feedback from the community as the demands and the company got bigger, we brought in more money, we had bigger goals.
(06:23):
I built a team out. Fantastic folks, I will shout out. Did young Dave, Cindy, Erica, Gabby, as many folks along on the came with me on the journey. We had some successes, we had some sort of losses or whatever, not so successes, but I really enjoyed being part of this bigger community, not only cloud native but Java and then sort of meta level. There's even a dev community, which I'm sure we might get into today, but there's a bunch of community slacks I belong to that are thoroughly beneficial to my career. I've recognised, I've kind of found my people there sometimes, right? When you find your tribe, your people, I'm always an engineer at heart, but I definitely identify with the dev rail folks now and yeah, long-winded answer, but that was kind of my journey into accidental dev rail and my journey continues. I'm doing other stuff now as well, but it's always about computers, always about programming typically be it code infrastructure and it's always about learning and teaching. Oh, I can't hear you Saim. You're on mute.
Saim (07:27):
Yes, thank you. So I'm actually following you for a very long time. I think your work on the Ambassador Labs is really wonderful because I happen to live in the service match world and API gateway, seeing your blog posted and have some wonderful feedback in there. So I think you have been one of the person who has been is great to initiate the discussion that is actually being currently in the horizon in the ecosystem as well. And I think currently when we started Kubernetes is 20 24, 20 14 and then going into the 2018 and the cube going becoming a big thing that the companies is actually pushing the boundaries beyond the Kubernetes and making open source project a lot. And that's where you need to build a community because a collaborative wisdom and collaborative learning is essential for a product and plus for the organisation who delving and investing in the open source surround as well. So I think we can start off why do developers join communities?
Daniel (08:39):
Yeah, speaking of my own experience, I think you want to be part of something bigger. Do you know what I mean? I remember when I was, again showing my age, right? Reading Java books, I was like this is cool, I'm learning about Java. But when I started meeting other folks online and in person that were doing the Saime thing, there's a social aspect to it. Even though I'm definitely, or I identify as an introvert, I just coding away sometimes I still like the social interactions. Do you know what I mean? Maybe not all the time, but I really enjoyed being with people that had similar interests, similar goals. And the biggest thing for me is they often pushed me. I think a lot of us join communities because we want to get better. We see Kelsey Hightower and we're like, I want to be like Kelsey one day.
(09:22):
How do I become like Kelsey? I join communities and people lift you up, they give you feedback, they give you new skills, they push and poke you and push you in different directions. So I think it's just human nature. We are social animals. Even though that said many of us are introverts, that's not a problem. I think you just got to recognise how you manage your energy. But I really enjoyed the learning aspect and what I've seen in my DevRel career, a good chunk of folks turn up to the community to learn. Do you know what I mean? Either they've got the immediate goals of I need to use this framework and this community seems like they're for sale. Oh, next yes or whatever this community is really going to teach me. Or they're more in it, they want to see bigger picture or they want to be part of something bigger. Like OpenJDK Kubernetes would be a good example. A did on my team, she joined the shadow release team, she saw the bigger picture, these kind of things, and she was part of that Kubernetes community and did all our CNCF certifications and things. So I think there's an inherent of yearning in us to be part of something bigger. And I think particularly with developers, that's revolves around learning.
Saim (10:28):
Yes, absolutely and truly absolutely agree with you what you actually said because I think what happened is without joining the community, what happened is let's say you work on an open source project, let's say Kubernetes and you setting up an ous controller and as you set up, there are few troubleshooting scenarios pop up. You see some errors appearing on the screen rather in I think 20 10, 20 11, 20 12 when I started my journey, I go into the open stack stack overflow and then the Google answer. And sometimes, sometimes things works and sometimes work because machine is I'm actually using is windows. And the answer is actually for the Mac it's very tough when you go into the community, it's 1000 people in there and 50% might be having the Saime machine, Saime error. If not one person answering your question, there might be three, four other who can give you the pinpoint of the question and you feel very relaxed because these are not robots not written, but these are the human you interacting
Daniel (11:34):
With.
Saim (11:35):
That's the super important of the developers community is. And I think with companies who build out some of investment, actually they are living the space of the Kubernetes and open source. But now another question we can actually delve into. Why do companies invest in developer communities
Daniel (11:52):
And think if we're honest, there's two answers to this, Saim, right? There's always the altruistic, A lot of us who create companies or are leaders in companies, we want to bring people along on the journey, whether that's your individual team or the community at large. So there's definitely that aspect of it. Undeniably many of us are running businesses, there's a business aspect to it as well, I want you to use my products if you are looking at service mesh or API gateway, when I was in BA labs, I wanted you to look at my product. So I recognised that or we recognised, I should say the whole team recognised that a big part of the technology you choose is the user experience. To your point, it's the community experience. Can I get interesting people supporting me on this journey? So I think that's a key thing with companies investing often it will start out as a way to sort of generate buzz, generate noise, get some interest, bottom up interest, the developers, the platform engineers, the QA folks, the folks that are actually doing the work, bring them into your orbit.
(12:49):
Oh we're building on Envoy here, let's educate folks around Envoy proxy or pick your technology. And then you do realise that some of these folks just by the nature of it become customers, do what I mean. They really like the community, they get a lot of help. They're like, Hey, I'm not paying for this. This is really good. I want to support you folks. Can I give you money? Can I buy licences? So there's always that sort of business aspect to it as well. There is this sort of natural pipeline or funnel as we call it, where folks are like, I really like what you do here, I'll pay you money. And some of them it's more an awareness thing. They don't want to pay us money, but they want the support so they do eventually pay you money. Those kind of things. I think that's the two aspects and I think it's really important as a dev rail leader not to lose sight of both of those.
(13:32):
It's very tempting, done it myself. I think at times where you do lose sight of one of them, if you lose sight of the business aspect often you get a lot of pushback from your leadership. And we're seeing this sadly with the layoffs and things like that. People are saying, how do you justify the impact of Dev Rel? And that's something to always keep your eye on the prize in terms of when you're part of a business community should we say, or a community that's backed by a business, you do have to recognise that business aspect, but you must also never lose sight of your building the community for the people. Exactly as you said Saim, right? It's really important. If you're just trying to monetize people, well that's an audience, that's not a community, it's one way conversation, it's transactional, not a good look in general. So I think always bear those two things in mind. If you're a professional dev rail, it's a bit different if you're a hobby dev rail, but if you're a professional dev rail, there's always that community people aspect. There's always that business aspect too.
Saim (14:26):
Yes, absolutely. And I think that we can kind of look at it because let's say if you are actually using some of the product today, what are the different support the company's actually providing you is 24 by Saim and let's say you can actually email them and your query will be resolved or you can actually answer them on their Slack or some other places your query resolved. But you see you talking to the Saime set of individuals all the time and it's a product and the customer relation and it can be break anytime and you switch to another customers another layer and both of the parties is actually losing grains of gaining the knowledge, how to effectively provide a feedback that companies can improve upon when you build out the community, I believe is a trust factor that you see. It's not me and Ambassador Labs or me or VMware, tan Zu people speaking it's bunch of other folks as well.
(15:28):
And sometime it's a very useful conversations. It's a conversation that help the product team make a better solution and otherwise that is truly difficult to understand what the customers want. So if kind of a look, if you do an investment in the right direction, I think there's a big win in there, but I think that's where the discussion, the most important discussion start. We started off why do developers join communities? We talking about companies, why they invest in developer communities. Now the next layer of the question is how and why to build a developer relations team?
Daniel (16:09):
You're asking the easy questions today, Saim, right? This is a hard question. I'm guessing most of us watching are from developer tooling companies or platform tooling, companies, ops, tooling companies. So the answer is going to be different than if there is sometimes companies where the developer market is kind of secondary and there the answer would be different. But if you're mostly working in the C NCF F space you and I do in other places, I think you need to always have an eye on Rel even from the company formation moment. Do you know what I mean? Because bottom line, the customers are going to be developers, are going to be platform engineers, QA folks. So whenever you start a company, you've got to build an amazing product to your point, you've got to listen to feedback, make sure the product addresses the pain point, but you've got to let people know about the product.
(16:58):
You've got to let people know about the pain points. I think you are always doing derel. And if I look back at my time in Ambassador Labs, I was there roughly six or seven years I was advising at the start and then I went full time and I was doing derel pretty much from day zero. But folks around me were, I think I was employee number eight. The founder was clearly doing a bit of dev, he was going to conferences, he was creating conferences actually in the Bay area in the us. He was running these meetups, these conferences. So that's kind of dev even though he was the CEO, he's not dere leader, right? But when I joined, I started doing a lot of articles and going into the community. So the dev function is always present even if we don't label it as the DevRel team, if that makes sense.
(17:44):
I think initially was brought on as a product advisor, not really, but I think the key inflexion point for us was when we were getting a reasonable amount of cash in the bank, like the product, we had what we call product market fit. So there was clearly a demand for the ambassador, API, gateway, telepresence, all these other products we had. And that's when we decided to decided to level up, not just rel in fairness, we levelled up many other parts of the company, but we made it more formal. And I'd say it's roughly three years ago I think it was where we spun up the dere team and we had I think a second round of funding series B funding. And my remit from my boss at the time was drive this amount of impact in the community. We wanted X number of folks trying the products, we wanted Y number of folks succeeding and maybe entering our sales pipeline, these kinds of things.
(18:35):
And they were like, give me a plan on how you would build the team. And I was like, well ideally we've got two main products, so I want two specialists, so a dev generalist but specialist in the product. And I was like, I would love to do lots more writing, but my time is limited. Can I get a technical writer? Boom. And we already had someone doing an amazing job in the company at sort of community type things, managing the slack channel, that kind of stuff. So she came over to my team as well and that for me was a perfect kind of startupy vibe. Again, the company at this point was only about 50 people, but it was a perfect combination of me being the leader. So me sort of seeing what the business wanted to some degree shielding some of the folks I was working with for some of the craziness we get the business craziness and that was my job, but also listening very closely to my team about what they were seeing in the market.
(19:23):
And to your point, many times I'd go, that's super interesting, that bit of feedback from the community pass that onto product. So I was often doing a kind of air traffic controller job where I was routing interesting things around. I wasn't the one necessarily doing the work because people like Didion and Dave and other folks, Peter along the way were doing the work, but they were saying to me, Hey, I'm seeing these things. And that team sort of like the four folks I mentioned, five folks scaled quite for a long time. It was only like I moved on from BAS labs last year. But at that point as the company's getting bigger and bigger really we were looking to keep that kind of shape of the team but perhaps make it bigger. So like product specialists, generalist, writer, generalist, community person was a really nice general shape of the dev rail team.
(20:09):
And I think the key thing when your team are saying, Hey, I'm really overloaded every cube we used to touch the limits of our capacity. I remember a few times I was feeling super stressed and poor did young who ran KubeCon eu I think for me last year and she did an amazing job, but I could just see we were really pushing on the limits of her time, right? Dave was running all the OSS stuff for me at the CubeCon and he was just like, I can't do it all. And I'm like, right, if we want to do more, we need more people. It's not fair on my team to, we burst occasionally so to speak in terms of CPU bursting, we burst the limits occasionally people sort of give up bit of their own time if they can. But then after that we sort of compress down more time for the family, more time to chill out, maybe go on vacation, right? You've got to look after your team. But that was a cue for me that hey, if we want to do bigger and more events, I've got to scale the team.
Saim (21:03):
Yes, absolutely, totally agree with what you actually said. And I think if you look at the ecosystem after 2014 and 2018, I think there's when the companies become boosted as the community and the companies adopted Kubernetes in production that we see a lot of the companies that never ever contributed open source, they start contributing into it. And then C, we have some sort of expertise in our team that can contribute in the Kubernetes project, but now why not? We can create some product based on our contribution in the upstream version of open source project we have got. So that's where you need to tell the audience, we are in the space of 1 million people that actually implementing and contributing in the wide spectrum of upstream open source software. So that's where you need a team that tell the truth. And also I think when you start up contributing, there is a one two spectrum and that's a very two different question came up on my mind right now.
(22:15):
Some companies have an open source and nothing on between, it's just an open source and then they start then actually climbing the ladder and then they make a product that is based on that open source project and then they give it 24 hours services, 24 by salmon as enterprise offering. What is several for W those team and what is devel for those team is like who don't have any open source project who companies have wasn't the full customer list and they never contributed to the open source. But whenever they go to the conference, they see we are isolated, no money want to speak with us, there's only customers and only me, nobody know what to do. How do we tell the people that we exist in the ecosystem, we contributing into it and then they make an open source project and what their idea was to make this open source project be a booster for their commercial offering. So open source based company versus enterprise heavy company, what are the two different personas for their dev ideas?
Daniel (23:27):
Yeah, interesting Saim. So I think the first one you mentioned is what we call the open core business model. So you have an open source project. We did it at Ambassador Labs. We had what we eventually donated to the CNCF as emissary-ingress. It was called Ambassador API Gateway before and a few other things, but it was emissary ingress and then that was the core and we wrapped on Ambassador Edge stack on the top. Again, a few different names there, but that's a very common model amongst service mesh vendors, API gateways, many other things there. To your point, it is a bit easier as a dev rail because if you want to only talk about the open source, you can do you know what I mean? I went to open source conferences, my team did as well and they were very clear, if you are submitting a CFP, there's no mention of the commercial aspects.
(24:10):
C ncf, F CubeCon, they say the Saime thing, right? Talk about the open source mentioned by all means perhaps once that there is a commercial product, but the focus of the talk should be on the open source. So that made our job somewhat easier. The challenge often there was from a business perspective linking up the open source with the commercial because we were there to educate folks but we're also there to drive the business forward. Do you know what I mean? So we did have to be very careful about creating content and sort of poking and pointing folks in the direction of the commercial. Sometimes folks looked at the commercial, it wasn't for them, no problems. Do you know what I mean? But we had to create that avenue. So I think open core, you've always got the open source to talk about. You've always got the open source community.
(24:54):
The tricky bit is the sort of bridging into the commercial world. To your point where you are in the other space where you've got say only commercial closed source products, you have to really focus on what you can build with that tech because you can't really talk about the tech itself, right? Because hey, it's proprietary, no one can see it and you can't have perhaps lots of input into the actual product, but you can have input into what you can build and maybe you can have input into the APIs, things like that. Do you know what I mean? So I've seen some folks who are delivering their products via APIs, like a message service, I'll say Twilio, right? But you know what I mean, that kind of company. Maybe a whole bunch of their stuff's proprietary, but the dev rail folks can say, Hey, with these APIs you can build all this cool stuff.
(25:39):
Do you know what I mean? So you're not focusing so much on the open source, you're focusing on the potential you can build with the tooling. And that comes with this own challenge. The commercial angle is really obvious there. If you want to build stuff, you may have a few free API calls, but after a certain point you're going to have to pay for the API probably, right? But it is possible to focus on say things you can build. That's the open part of it, right? It's not open source, you can't look at the code, but you can look at the code of the demonstration products. Sorry, the demonstration projects, they're sort of Saimple apps you are creating.
Saim (26:12):
Yes, absolutely. And I think that's where I live in the last year as well. The companies that has not open source but is a customer heavy, enterprise heavy and they kind of shielded away from open source because they don't have one and they have a C of very much pain point, like nobody talking to us. We feel very depressed every time we go to the how do people bring into their conference? And that's where it's a tricky, that's where I believe a lot of layoffs happening. If you live in the open core business model, things were easier because top tier to the bottom tier, what is you're doing? And a lot of the feedback as a developer relations and the team is getting from the top layer, oh, we want this open source to do this thing. It's your job to do it how to do it, we are not good at it.
(27:05):
You are best out at it. But all I want this project become an influencer in the front of my company's customer's eyes and plus in the community's eye, that's a very easy because you already have a roadmap, clear and enjoy the life. You're that spectrum, a different spectrum. It's tough because sometime you need, nobody has to tell you because to be honest that the company doesn't know how to sell a product. With developer relations personas, it's difficult. So sometime you make your own decision, but what happened is the top management actually decide are you doing good or wrong? And then you make a point, oh, you haven't tell me that I am responsible for these four things. How do you account to me that I have done wrong? So that's where a lot of, I see the segregation between the thoughts and opinion in the company's mind, but I think it's a tough word and sometimes general is a cultural shift.
(28:09):
It is not a one aspect. You need to shift a cultural thing. Like sometime being a developer relations, you tell your seniors you have to do this and it's tough because they have a very limited capacity to either accept your opinion or either reject your opinion and then you end up nowhere because if the rejection came up then you don't bring up new plans and you're creating plans, nothing executed. At the end of the day it's tougher on the roadmap that you haven't done anything. So its life is tougher, don't worry about, but you learned a lot of the different angle as well. And I think that's where this question is very vital to answer that who owns the devel team and how to create a devel messaging flow cycle because it's somewhere along the software development lifecycle and some companies own one of the SDLC process and you need to communicate that only one messaging that you actually being owns. Like something like Kio, a policy engine, a service match, an ingress controller, but the community me and you actually is pretty much bottle now down with all of the different SDLC problems. So first thing first, let us know who owns the Dere team.
Daniel (29:36):
Yeah, it's an interesting two part question Simon. So you definitely have to remind me of the second part, who owns it? That definitely is dependent on the business and the business goals. I think, and again, this is just my experience, I've mostly seen Derel teams in the marketing area, but I know many successful Derel teams, clearly in larger companies that work as part of engineering, if you go to the hyperscaler clouds, a lot of the dev rail teams are embedded with the engineering teams for good reason because a lot of the rail folks are actually doing coding as well as they are going to the community and sharing stuff. I think in terms of, sorry, I've lost my train of thought. There was who's the devel team? Sorry. I think that marketing mostly engineering is probably second. And then I also see some dere teams in product because to your point, Saim, getting the feedback from the community is a key part of our job.
(30:30):
We're not just educating, we're not just teaching, we are listening, right? It's really important that again, that's the difference between it's probably a community and an audience with an audience you are just broadcasting stuff. I think it's really important as Dev rel to listen and therefore if you are trying to build your product and get product market fit, actually embedding the Dev Rel team in product makes a lot of sense, right? Because then the collaboration between the product leadership and the dev rel team is really tight. So I think it depends on your business goals is where I'd go with that. In terms of who owns it, I think the most important thing, and you've alluded to this in what you just said, is whoever's leading the team be super clear on the goals. Do you know what I mean? Whether they're engineering goals or whether they're marketing goals or product goals, whatever.
(31:17):
Where I became the most stuck was where I didn't understand my goals in the context of the company or there was a bit of a misunderstanding between my boss and I, do you know what I mean? He was like, oh, I want this. And she was like, oh. And then oh, I'm optimising for different things. So I think the most important question, regardless of where you live inside an organisation, I love to work for startups. With startups, it's often very fuzzy who owns what, do you know what I mean? What department is what? When you're small, everyone does all the things pretty much, but being really crisp, really clear on your goals and how when you've got there, so sometimes it is metrics, right? X number of blog page views, Y number of people in our slack channel. You can start quite basic and then get a lot more complicated. But I think aligning on those goals is probably more important than exactly who owns the team.
Saim (32:12):
Yes, absolutely. Super important. And I think I'm really happy at this moment of time because I have some similar feeling and it's tougher to me to tell people what actually just said. It's really make me make some smile on my face because I think what happening in the ecosystem is a lot of the dere guys who are really concerned about low numbers in the slack, low numbers in the webinar, low number, the YouTube views and low number in these Twitter spaces. I think that's one of the criteria to judge yourself you are doing bad or good or bad. And sometime some companies don't demand you to make sure that you have 1 million people in the slack. They just want only five to 10% of the people who can just give you a feedback what they think about the project and they can clearly communicate into the product team.
(33:11):
And as you said, a lot of the team is working entirely with the marketing team. What I did in my previous company, I spent 60% of the time with the product team because they are the communicator with customers and I am the communicator in the public. Sometime the communicator of the customers doesn't know what happening in the community and if you know the solution exists, the product team can neatly communicate with the customers and might be resolved the issue. And then sometime the customer has a better opinion than the community because community is far away abstracted with the noisy words and the buzzwords and the customers have the real knowledge of the business. So I think another very frustrating to see that a lot of the companies and the folk investing solely on the marketing angle and growing the prospect of the product angle as well.
(34:16):
Very few company I know who developer relation start communicating with the product team. And another, I think I speak with one of the person in the passport, he said developer relations, that a wonderful guy. They speak and listen to everyone within the company. They're not only one person in the company. It's an interesting point. That's frustrating. That's really frustrating to see because you are the communicator that brings feedback to the internal companies employ and the product and the marketing and you need to communicate as well. Now I think I need your opinion because we have to answer the second part of the question, how to create the dev messaging flow cycle.
Daniel (35:04):
Yeah. What exactly do you mean by this? Saime in terms of how the product messages flow through the organisation? Is that what you're after?
Saim (35:12):
Yes. I think we can drill down to one specific. Let's say you have a mystery ERs in your product, then you have a product mindset, you have an open source and then you have a business offering as well. So sometime you just do only the open source side of thing and then the companies tell you shift towards product market
Daniel (35:35):
And this is constant collaboration, particularly amongst their leadership levels. And I think there's always some aspect of, I listened to my leadership team that are above me and they said this quarter we're optimising for number of logos or a RI annualised revenue, that kind of thing. But then I always sort of pushed back a little bit as well because I was like, you can't just optimise for number of users in the community. We've got to be, to your point earlier, we've got to be true to our community. We've got to be authentic because the moment we start going trying to monetize everyone, we're going to get pushback. People will be like, this is not a community, it's like a sales room and then everyone just walks away. So there was definitely me listening in terms of we are steering towards this product, we're steering towards this use case.
(36:22):
Maybe we're going after banking or gaming or whatever. Sometimes we had vertical targets we called it. It was definitely me listening to that. But then also me pushing back a little bit too in terms of, I mean that's sort of the gift and the curse of being a middle manager. I was you've got to shield the team a little bit but also listen a lot to what the goals are of the company that the bigger leadership, but also listen to your team. What's coming up in terms of the community wants this or would value this or doesn't like this. And as a leader, as a middle manager, you kind of have to figure out the happy medium there. And then the key thing, I'll echo it again is once you've got that alignment amongst all the folks there, try and storyboard it. Try and write it down, try and put clear metrics because the best success my team and I had was when everyone was super clear on the messaging flow.
(37:17):
We're focusing on the WAF web application firewalls, we're focusing on the web application firewall thing of emissary ingress for the banking domain. Here's how we're going to approach it. Here's the measures of success and here's the kind of metrics we're going to feed back to the business. And my team went, oh that looks great. Super clear new target audience, I'm going to learn about waf, dah dah dah. And the business were like, oh yeah, great. I understand what you're trying to do. You're trying to target this vertical with this messaging. Everyone was happy and if stuff goes wrong, inevitably it does. You can look back and say where did we go wrong? Did we not set the right goal? Did we not execute the plan properly? Were we too over ambitious with the numbers? But it's a much easier conversation that way around when someone just goes, make noise about API gateways.
(38:04):
Do you know what I mean? So I've had that direction in the past as a sort of messaging flow. The company's like make noise about API gateways. And I'm like, cool, but how do I know if I worked? And they're like, just make some noise. We're customers. And I'm like, no, no, no. Dev rail does not work like that. It's a bit more, you need to be a bit more experimental, a bit more systematic in your approach. But I think hopefully that addresses your question, having those conversations, collaboration, as you rightly said, perfectly said just a moment ago, it is building the connections internally to the product, to the customer service people, all the folks where you can share and learn from building those collaborations, listening to the goals that are coming down, hopefully that your goals aren't changing much in a quarter hopefully. And then being super clear on the plan, executing it and then retro expecting at the end going, did we do well? Did we meet our goals? What was the problem that I think is, and then feeding that back into the whole team, that's the best way to get this flow going I think.
Saim (39:01):
Yes, absolutely. And I think in the last company what I did was I tried to create some sort of documentation. What I literally like 15 days and 20 days of interaction with the community. I literally write down something and then share with my product team. Oh, you talking about people having some struggling point in the policy and the compliance angle, but I don't seem to see it because it all just, you need to do is actually create a open source project and then you cut your compliance and security some sort of being critically much, much stronger than it's before. So it's difficult in the product spectrum that people can buy a product that having some sort of two to three layers of security and compliance, that's my messaging is so then they understand, yes, few words you have speak about is not, you are clear, but few words you have already clear, we have internal discussion going on.
(39:58):
That's not happening, that's not happening anywhere. I think that's the toughest job we have as well. And I think as you mentioned, the messaging you have to congregate with the top to bottom with the messaging flow because if let's say you, your company is creating some sort of template for Terraform or Permi or the cross plane and you communicate on the public around Kubernetes API, that is going to be a different story. You need to bridge those together like how the Kubernetes API correlate with Terraform Tating that the massing gene become very simple and orchestrated. It's tough sometime you need to feel very hard debate and a very fiery a bit. But no worries, people are actually listening to you as well. So I think we spoke about from those angle or living in a spectrum doing job, creating messaging, writing content and having some hard time in the company. Now why now we spoke about for the persons who wanted to become a developer relations going forward. So that would, I think we definitely spend few minutes. So why number one why? And question is why not develop relations as a career professional?
Daniel (41:19):
Yeah, I like the way you phrased that Saim. It's always good to ask why not as well. I think many of us just fall into it. Many of us do love the teaching and the learning aspect and that's a good reason perhaps to become a dev because as you move up in your software development career, just as an individual contributor, as an engineer, there's always an aspect of teaching. You are often mentoring folks, right? You're teaching the more junior folks as you move on through. So you can always do that. But I think many folks who get into dev want to take it a step further. They want to be able to tell stories, they won't be able to build communities and bring people along on the journey. So I think if that speaks to you, and I'll just say it again, you don't have to be an extrovert.
(42:01):
I find it quite funny in some ways, many of us on the community that you would think are not introverts are in fact introverts. We love being on a stage. It's a controlled environment. We are in charge, right? We are doing our thing on stage. We're actually not so happy. Not at the booth or off stage where it's all unscripted. So you do not have to be an extrovert. But I think you do have to love that learning or teaching and maybe if you don't want to do talks, you can do blog writing, you can be active in the community slack, that kind of thing. You don't have to be a public speaker, you don't have to be a podcaster. There's many things you can all do there, but if that sparks your interest, I think that's a good signal for you entering a dev rail career or at least giving it a try.
(42:39):
You haven't got to do it permanently. I know many folks who go into DevRel for a couple of years go back to engineering or do other things. Even me, I'm doing springboarding sort of more product marketing type things. There's many things you can do afterwards. I'd say why not do it? I think there is a danger of, it's just like people think of it as just like engineering, but at fancy locations I'm going to be at nice hotels, I'm going to be on aircraft flying business class and sometimes there's a bit of that. But I've been stuck in the middle of Austin in Texas and I've been stuck Berlin one time desperate to get home and see friends and family and you're like, ah, or I'm sure and many of us endeavour have got crazy stories. So you always see the best angle and I try to do my best when I come onto these kind of shows.
(43:25):
There's always the rough times. I have been stuck places. I've run out of money One time my credit cards didn't work, it's been pretty weird. So it's not that if you really just want to build production level systems, probably dev rather isn't for you. That's probably the thing I miss the most is building production systems. I build toy applications now hellowell, Webscale kind of thing as the joke everyone says, but it's not the Saime as running an app in production. It's not the Saime as being responsible for a tool. And I've made my peace with that. I still miss it, but I've made my peace. But the folks where they've gone into REL and fallen out quite quickly where they were like, oh, I just thought it was engineering and doing a few talks and I'm like, no, no, it's a job, right? There's just hard bits of any job. Do you know what I mean? So I think that's the thing I definitely say to folks, if you just want to sit in a corner and write code or listen to business requirements and write code, I respect that probably Derel is not a career to put high on your list of things to try out.
Saim (44:26):
Yes, that super agree with you definitely. Because sometime I think what happened against sort some personal, have some wonderful communication skills by birth or by nurture and sometime they don't have some sort of engineering and they don't want to be a developer for the entire entire life. We want to do some certain different things as well. So he kind of a thing, oh he is very less engineering, more on the public front, but he kind of lose the spectrum. You can be effective in communicating tech if you have spent far amount of time in the technological spectrum because it's tough.
Daniel (45:08):
It's that empathy Saim, right? I think I often say empathy a lot in that I do advise folks coming out of college or university be very careful about taking a dev job straight away. Just as you've said, I always recommend becoming an engineer even just for a bit because you build that empathy. It's very hard to be a dev without having any of the dev. Does that make sense? You need the dev and the re. So it's a really good point you make there Saim. I do think you kind of need to be an engineer. It's not mandatory. I know actually Microsoft has got some really cool dev rail folks that aren't engineers and they're just really good at what they do. But in the grand scheme of things, folks I mentor, I say it's much easier to develop empathy by doing the job of an engineer, developer operator, whatever first before you do the dev rail thing.
Saim (45:54):
Yes, absolutely. Super agree. Because I think that's really, I think it's a larger because software development, if you work, because some folks in my career it started from the software engineering and then it started with the operational angle, then moving to DevOps and then I saw the very much interest in the open source. That way you not feel and entirely looking at the one screen all the time. It's some difference happening all different days. So it's a good way to engage. And then you see, well now I have some sort of communication hurdles always in the company. Why not? I can gain communication skills internally or externally and then come back in the community company and see what other roles fit in for my need as well. So I think it's about testing, it's about testing your skills. I love it as you testing your unit, testing is good for the code and unit, wonderful for your professional skills.
Daniel (46:51):
That's interesting way of looking at it. I like that.
Saim (46:53):
Absolutely. And now I think before I let you off, I think that's where I see a very lack of interest and people don't have some good people to talk about, but who or how, number one, who should I go to talk about how I can set my dev rail career goal? And number two, how I can tell you that I can set my career goal is because it is a matter of finding a person and it's a matter of communicating with the person. So how do you answer those two questions?
Daniel (47:28):
Yeah. Oh these are deep questions. They're good questions. I think I would start if you've got a job and then typically a manager, that would be a good place to start. Do you know what I mean? I've been lucky enough to work some amazing DevRel folks over the years. If you haven't got that sort of within your company, I think looking to communities is really good. I've mentioned a few folks, there's definitely a bunch of Slack communities, there's other communities around as well. You can often find informal mentors there. The slight challenge with DevRel is there's not lots of senior folks. So I already do a lot of mentoring and folks say to me, Hey, can you mentor me? And I'm like really sorry, but there's only so many people I can look after. And I see this with my other senior friends as well.
(48:10):
So recognise you can reach out to us and we'll do our best to get back to you and help you nudge you in the right direction with careers. But there's a lot more folks beginning careers than there are senior endeavour. And they're probably the Saime with many professions. But I definitely noticed this in Dev Rel. So yeah, start internally, maybe look to the community, maybe look on the Slack channels, ask about some of the career goals and then also do check out the books as in fact I actually got 'em on my desk here buried away somewhere. The two books I recommend in Dev re space, one is Mary Vale's business relations. And the second one is the business relations there. If you haven't got access to mentors, because not everyone has, right? I have learned so much from books over the years and both of these books talk about setting career goals and how you might level up.
(48:58):
Do you know what I mean? Because the engineering side of what you do, creating more code. But then there's the business side creating more impact. And then there's the leadership size side of it. How do I enable other people to do these things? Does that make sense? How do I enable my team to do these things? So if you haven't got access to the people, I do think that the books are never as good as people. As you rightly said, the people are what make it, make the community. But the books are a good start for at least thinking what kind of skills you'll need. And not just individual skills, but skills as you've already said at a bigger level around communication. Because a lot of people say to me, do I need 30,000 followers on Twitter? Should I run a podcast? And I'm like, maybe, I dunno, but what are you optimising for?
(49:43):
And they went, oh, I want to build my personal brand. I want to be seen as an expert in the JavaScript community. I'm like, cool, look at the JavaScript community, try and find an opening. Try and find a niche. There may be no podcasts there or there may be too many. So if there's too many, maybe do a newsletter, maybe do something else. So I think focusing at the bigger picture if you can, it's hard when you start your career. I know I ask the Saime questions when I started my career, but if you can focus on the bigger picture skills, better engineer, better leader, better communicator, and then a rough of target area. I really like go, I really like Verno, take apic, right? But then you can kind of dive into those things and hopefully working with someone in the community even better, they could help you set a plan and action of how you might level up those things to reach your overarching bigger picture goals.
Saim (50:35):
Yes, absolutely. And I think pursuing a developer relations career, it can be good if you're speaking very often in the public. Because what happened to me in the past, whenever I learned, I started learning in the frontend languages in angular and the backend of the.net. I learned something and then think, oh, it is enough. It's so much I learned about and then we start communicating in public there are few questions you don't have answer and then your mind, what's happening, how do I miss it? And then you learned again. And then there are a few four questions that you don't have answer. Then you learn again and you understand by going forward, those person who asking those questions have 20 year of experience and you just started in a four year and then your mind relax. It's good. I'm asking those question to the person who asking me that have a 20 year of experience.
(51:30):
So I think that's where it is a very good energy. And I think really echo the noise of the book because that way is articulated in a way that you have a storytelling in your mind. You have this, you are starting career from this angle, this angle, that angle. So it feel like you already covered as well. So I think we spoke about so many things and we definitely want you to conclude here. I think it's two angle. I definitely see developer relations from the two angle. Are you going from this open source core business model versus you the enterprisey business model where no open source, no communities, just customers and your company and your company want you to give some boost so other people can talk about their product in public. So that's where you feel to gain a momentum and that you actually experiment, validate and some failure and some successes tune you as you go. But setting up developer communities is widely important. I don't think so. Those developer communities don't go anywhere because those are, I love about, because sometime I have some question around a mystery ingress or I go into the Slack channel, my answer is already been covered.
Daniel (52:47):
Yeah, it's kind of cool, right?
Saim (52:48):
Yes. That's where I don't see any of the developer communities going anywhere. I think we can debate in the next few years. Is development relations a 10-year-old role or is going away after two to three years? We don't know. Might be there. Something comes up. But we do know irrespective of what this role is, a communication challenge is necessary. It's going to be present today. And even our kids suffering from the Saime disease of the effective communication challenge. Because you need to tell your people this is a product it, it doesn't do that. You need to fill in the gaps where it doesn't do that. And when you do it, then you need to communicate. We already have those integrated in place that are missing in the previous year. That's where I think the communication challenge still be a hurdle. And the messaging flow is difficult to get because there are so many orchestrator, so many in term of you need to communicate with your top peers, middle peers, and the low tiers. And you need to communicate the messaging and then you have to agree or accept or reject and have to debate upon it. Agreed. But it's no hard actually, we haven't covered all different things, but I want Daniel to actually give us five takeaways on table
Daniel (54:15):
Five. You put me on the spot here, so this is good. So I do think probably trying to iterate on what we said earlier on is establish empathy, so understand your customers. That's a really important one. And our customers are developers. So building empathy with not only developers, but your community at large is really, really valuable. So that's one takeaway. The second takeaway, I'm going to say be super clear on the business and the community goals. At the start of our conversation, we said there's often a healthy tension, hopefully between those two things. So be super clear on that. The third takeaway, I will say, constantly seek feedback in everything you do. So I'm a big fan of whatever you're doing. Create a hypothesis around it, do some experiments, get some metrics, collect some data, iterate on that. I think that's really a key thing.
(55:11):
Fourth would be seek mentors. Even if they are just books, I definitely, I consider some books my mentors, right? As well as I'm very lucky to have actual real mentors as well. I'm super privileged in that regard. But do seek out advice from Twitter, LinkedIn, blogs, books, slack channels. I think it's really important to stand on the shoulders of giants, right? I mentioned Kelsey Hightower, but he genuinely is one of my heroes. I just see what he does as lead, doing demos or doing talks without slides, and I'm like, one day I would love to be like that, right? I'm lucky enough to know Kelsey and got some advice from him and he's as advertised. So yeah, seek out mentors, seek out advice. And the fifth one, what should we say? For the fifth one, make sure you are happy, right? Try some dev re stuff.
(55:57):
If it doesn't work for you, no harm, right? You can go back to being an engineer or to a product person, QA person, whatever it is. I think I've definitely seen some folks are stuck at careers, not just Dev Rel, but sometimes Dev in particular where they're not really happy. They have this vision of what it was like. They tried it and they're like, oh, it's not for me. I can't go back. And I'm like, yeah, you can. No one's going to really care, right? As in, I think it's like imposter syndrome. It's more important to you than it actually is the other people. So do always seek advice from people, but if you're not happy in the role, move on to something else. No harm, no foul. But if you liked what we've said in the conversation and you think Dere could be interesting, give it a try. It might make you even happier. I think you're the Saime, Saime. We genuinely love, we're privileged to be able to build communities and share our knowledge. That's amazing, right? It's pretty awesome. You can do that. So try it out. asin, what have you got to lose, right?
Saim (56:51):
Yes, absolutely. Thank you very much. Jan is a great, great recap of all we actually have covered today. So I do call out Daniel. Daniel is also doing a podcast on InfoQ. Very informative conversations, some very good technical deep dive. He writes the books, all Availables behind the scene and also some wonderful blogs still present today. When on that
Daniel (57:17):
Note, Saim, can I shout out Avocado bytes? Folks are looking for avocado bytes.co uk. That's where I'm sharing all my DevRel knowledge. So it's a Substack newsletter doing a lot of things. The things we've talked about today, there's a bunch of blog posts on there. If folks want particular topics covered, hit me up on there and I'll try and write about them too. So thank you for sharing that.
Saim (57:35):
Absolutely. I would definitely include the link in the YouTube description so folks don't forget to meet out as well. But it's a pleasure talking to you and I encourage people to go into the In InfoQ podcast because I educate myself a lot for some wonderful conversations you have with your guest as well. So today's hundredth episode and we learned a lot, is a very important topic to understand. So I think for my few conclusions are B and to understand which spectrum you are is an open source course with business model versus the enterprise heavy customer business model. That number two is you need to communicate effectively every week internally and make sure you have listened to the feedback internally and externally and do a analysis what's best for you, and create a reporting that you share internally within the product team and the marketing team and have some sort of weekly calls or biweekly calls between product marketing and the native marketing team as well.
(58:42):
And make sure the messaging is already being drafted, documented. Everybody can take a feedback and a stab out of it and provide a feedback and you open for the feedback and suggestion. And if you want to adopt de kael, make sure if a communication give you a hell, a lot of experience, you're able to meet with people like Daniel and a bunch of other as well. And if you want to sit the different role, no hurry, no wastage because you already learned how to be effective in communications. That will help you in other roles in the next career phase because communications challenge is all always there irrespective of where spectrum are. So thank you very much. Attend for listeners, hope you enjoy the conversation. I will be looking forward to your chats on the YouTube description, on the comments side, and we'll make sure Daniel and I will actually answer those as well. And have a wonderful day and we'll be meeting you again with another guest. Stay happy, stay healthy, and have a wonderful rest of the day.
Want to know more about DevRel?
I hope this post has helped clarify some of the challenges within DevRel, both from an individual contributor and leadership role.
Please comment below and let me know if you want more similar content (or not!)
And don’t forget to subscribe! I’m aiming to share a post every two weeks or so.