DevRel from the ground up with Sean Falconer from SkyFlow

Jack: Hi everyone. You're listening to Scaling DevTools, the show that investigates how devs go from zero to one. I'm joined today by Sean Falconer, who is the head of DevRel and product Marketing at Sky Flow. Which are privacy as an API service. Sean was previously DevRel at Google and hosts software daily and partially redacted podcasts.

Sean was also the founder of Proven and Brings a ton of founder experience into everything that he talks about also, I wanted to say a shout out to Harpreet Sahota who recommended that Sean come onto the podcast. And that's actually the first time we've had a recommendation of someone that he really wanted to bring on.

So thank you and Sean, thanks so much for joining.

Sean: Yeah, thanks for having me and thanks to Harper for mentioning me. It's, it's great that someone out there besides my mom is paying attention to the things I do. So, uh, it's always nice to, to hear that, someone's finding some value in the things that you're putting out there.

Jack: One of the topics that Harper mentioned he was really interested in is building, a DevRel function from the ground up. So my first question is, when should we build a DevRel function?

Sean: Yeah, and that's a question that I have actually got a lot this year from, I think there's a lot of, you know, venture capitalists now, probably cuz of the growth of the dev tools market and sort of API first economy. That they are, are trying to help their various, portfolio and they don't necessarily have like the expertise and in knowledge in developed relations.

So these fee firms over the last six months have reached out to me, and I'm sure many, many other people in the del overall community kinda ask this question. And the reality is there's, there's no one answer for this. And you'll see this as probably a consistent theme when I talk about, you know, developer relations strategies.

There's not really one size fits all for all these different choices that you can make. It depends on a lot of factors. Very context dependent, and I would say, that You know, one important thing to understand is that if you are a developer first, or even a developer plus product, you're Already doing developer relations. It's just something that always exists. If your customer is a developer, you just might not be calling it that. So it's the same as customer support, where customer support always exists within a business. Even if you have, don't have someone called a customer Support agent So someone is likely still at your business addressing customer issues.

It might be the founder, it might be someone else, but someone's still doing it. And it's the same thing when it comes to Developer relations is if you have an API product or you have some sort of, you know, library that someone's deploying somewhere, you're probably interacting with developers and doing a lot of the types of things that Developer relations does.

It's just not called that at your company. At the moment And like a lot of functional areas, sales, marketing, product, these areas are first owned by the founders. And one of the pieces of advice that I got when I was a founder was that when it comes to hiring is that if you're spending, you know, 20, 30% of your time, or even someone within your company that you hired is spending 20 to 30% of other time on something that's not sort of core to their job. Then it's probably a time to start thinking about hiring someone to do that job because then you can give that 20, 30% time back to the person who's doing it today, and you can turn that 30% into a 100 and sort of tripling your efforts that you're spending time in today and. The other thing that's really important to understand when you're making the decision about starting a DevRel function and whether it makes sense is DevRel can mean very, very different things.

So it's really important to understand what you're hiring for. It could be community, it could be product influence, awareness generation, and a lot of that's gonna come down to what are your pain points today and what are the problems that you're trying to solve. And then you need to sort of hire. Based around that, bring someone in that understands the, uh, the, the goals of the program and why you're hiring them. And a lot of this is a long term investment. It can take six, 12 months to see real payoff from something like a content strategy that's based around SEO or community building or even event strategy. People say when it comes to events that you might have to. Show up 3, 4, 5, 6, 7 times at different events before someone's kind of, you know, has your name in mind and remembers who you are. So pragmatically putting my founder hat on for a moment, you really need to viciously weigh. This choice in decision about whether you started a DevRel function and what that means for your business against the other types of things and investments that you could be making. If you're a seed company with 10 people, well, does it make sense to hire one devel person, you know, 10% of your total resources of your company to build up the de function?

And that might be the case. Maybe it makes all the sense in the world, but you need to kind of be thinking about it that way. Where out of all the things that I could be deploying resources, Is this the thing that is going to move the needle for my business the best? And if it is, then 100% you should make the move and the decision. And then, you know, we can figure out how do you, build that team and who are the types of people you hire. But you need to be really thinking about that from a strategic standpoint of what is gonna help my business the most.

Jack: I really like the framework that you kind of bring there around looking at what you're already doing and analyzing it. And you touched on it a little bit already there, but what would you say are kind of. Mvp. Minimal, viable Devel team looks like?

Sean: So I think it depends, of course, on your goals before sort of jumping into what the team potentially looks like, one of the really common mistakes I see people make is they end up hiring like a junior person for this. And I would equate that to hiring like your founding engineer as a first year graduate.

People don't typically make that decision and I don't know why they think that they should do that for developed relations. Like you're expecting essentially someone who maybe has never even worked in developed relations. To not only own execution, but the strategy metrics. Set the tone for the team and the function, Grow the community and do this all in authentic way.

Building real relationships in the deep trenches with real engineers. So don't be shocked if that doesn't work out for you. It's, recipe that's doom for failure. You need to hire someone who understands strategy and they can also kind of get shit done. You need someone that's, you know, not married to a specific way of thinking that needs to be flexible, and that's really important and crucial at a startup.

They can't kind of come in with, these are my, this is my set of tools and I know how to deploy these, this set of tools really well and kind of be inflexible about trying new things. A Startup is very, very fluid. It changes all the time. What may be something that makes all the sense in the world today a month from now is you're going in in a different direction.

So I think startup experience is probably key for that first hire early stage. Dev Rel often isn't about creating these like long term strategic plans and KPIs because at that stage you might not even know what KPIs make the most sense. So a lot of it is experimentation. You know, there's this quote that I like you know, lots of people use it and I probably overuse it, but you know, Mike Tyson said that everyone has a plan until they get punched in the face.

And that is very, very true. At any startup, you can have something that's, you know, exists on a whiteboard that things like, seems like a great idea, and then you put it out there into the ether for real users to try it and, and they hate it or it doesn't work. So when it comes to building business, Businesses go through these different phases where they, at the early stage, you're essentially need people who know how to, or like they have to figure out how to build the machine. So you need like innovators and creators, essentially. Every person you're hiring needs to kind of have a founder mindset. And then once you get to a place where you have product market fit and you figure it out, go to market, then it's really about how do you scale the machine And it's very rare that the innovators and the scale people are the same.

So companies go through these phase where they have a bunch of innovators, they reach a certain stage, they bring in scale people to scale it, but then they reach a plateau where they need to figure out how do we, you know, do new creative things. So then they need to bring in innovative people again to kind of, you know, spin up those projects. At an early stage company, a startup, you need innovators, not necessarily to scale people. So that's something that you need to take into mind when you're hiring this, uh, initial Deval person is they kind of need a founder mindset because they're gonna be creating a lot of things from scratch. So it starts with a single person.

You need a leader that can set the tone in initial vision, and then they'll eventually wanna hire a small team and make those people successful, improve the value and who they hire. Depends on, of course, on a lot of different things. Might be a developer advocate, could be a community person, could be a, a DRE or developer relations engineer, depending on what you need. And a lot of it, of course, as I mentioned, depends on the context of what the company, the product. Is trying to accomplish what your skills are as a leader, Where do you need to fill in the gaps? Where do you need to make investments? And for me, I, always err on the side of don't scale too fast. Don't hire just simply cuz you can hire, it's better to hire slowly and make the right decisions.

It took me at Sky Flow, but eight months to make my first hire. I talked to a lot of people, but it

wasn't about filling seats, it was about filling. A role with the right person and being patient and finding that right person. And you can potentially think about outsourcing some work, like if writing's not your strong suit for you, maybe you can outsource some aspect of that, but I think most people do a bad job at content and outsourcing.

It isn't going to make that a better situation also. When you outsource things, typically they will only deliver what you ask them to deliver. So you need to know what you're asking. So it's important to kind of, understand that when you go into these, like contract relationships with, with different companies, it can work, but you really need to know, sort of, you need to set the guardrails of, what that experience is going to be , in order for it to be successful.

Jack: Actually on that, you mentioned that if you aren't doing a good job on content outsourcing, it probably won't solve it.

Could you share a little bit? Cuz my, in my, my head immediately I, I'm thinking, Oh, but maybe if I'm not a good writer and someone else is a good writer, wouldn't that solve it?

Sean: When it comes to content, obviously writing is a component of it, but a real content strategy, especially for startup, is your website and your blog is not a destination site. Like people aren't going to be, Coming to your blog on a daily basis to look up what you every release. You're not Google, you're not snowflake, you're not some known entity where people wanna are inherently interested in what you're doing.

You need to manufacture interest. And the best way to do that, for a blog is to essentially assume that all your visitors are gonna come from either paid marketing or better organically through Google search results, which means that you need to be able to rank on Google. Which means that every piece of content you're creating has to have discovery value. So a

lot of it. In terms of content starts with the question of what are the things that people are searching for? What is the volume of that search like? Essentially, what is the opportunity there? how hard is it for me to rank? And then applying different strategies around crafting content that is going to match up against those keywords that are strategically important for your business. And then also, Figuring out how do you actually increase the SEO value of that artifact in terms of, you know, generating links and generating, you know, other types of, of interest to it. But most people, what they do when they come to content is they get a bunch of random ideas that they think might be compelling or interesting in new people, and they just churn out a lot of, of content that's either very thin or has very little discovery value. That's where I, I think the mistakes get. And every page that you're adding to your blog or your website that isn't increasing the SEO value of your content is essentially a dead weight page that's actually dragging it down. So there you can actually, a lot of times do better by eliminating pages than by generating new pages. It's really about quality over quantity.

Jack: Coming back to something you said as well in the previous point about spending eight months trying to hire someone, what were you looking for in that person?

Sean: For what we needed to accomplish is right now. Our team, our biggest challenge, and, and, I think there's a, consistent challenge that most startups have is that, you know, there's a Lot of things.

that Dev all can do. And if you think about a full developer journey from sort of, developer marketing to education, to success, to developer experience and community.

Well, most startups, the biggest challenge in pain point that they have for the things that DevRel can do is really around. Amplification of the products are so more than the top of the funnel, the marketing aspect of developer relations. Whereas a company like Google, when I worked at Google, we didn't do a lot of work on developer marketing because people know what Google is.

There's a lot of built in mechanisms to drive interest in eyeballs, what you're doing. So a lot of our efforts were on, you know, further down essentially to developer journey, to how do you make them successful? How do you create a great experience for them, how do you educate them and so on. But for startups, it's primarily like, I need to make people understand that we exist and care about what we're doing. So that changes sort of who, Who, the types of people you hire that you hire, and then the other factor. I had to take into account was, , our team's gonna be relatively small for a long time, so you need someone who's, fairly general that can do a lot of different things, and again, goes back to having this founder mindset. The way I think about building teams is that it's not about me sort of dictating everything that happens. You need partner. And it's really about creating like partnership between the people that you hire so that they're contributing ideas. So you need someone who's kind of mature enough in their career, experienced enough that they are able, able to contribute and also drive entire programs on their own While.

also having enough sort of general skill set to do all the sort of potential aspects of developer relations that they might need to do. So it's very, you know, it's hard to find somebody that has that breadth and also, um, is, uh, you know, mature enough in their career that they can understand, uh, be able to kind of own and run with [00:14:00] programs, and then also understand, The, you know, day to day aspects of being at a startup where they need to, to not only own programs, but they might need to sort of pivot on a dime or try different things and wanna experimentation.

So finding that right mix of personality with the skills for the job is, something that's hard, to do, and that's why I took me a long time to, to find the right person.

Jack: If someone's very much a generalist, and clearly you have a lot of, probably wear a lot of hats as well. How are you dividing your kind of responsibilities essentially?

Sean: Yeah, it's a great question. So I think over time as Endeavor all team grows, you get more and more specialization and people kind of owning particular areas of the program. So you might have people who are. heavily on the engineering side and they own, you know, maybe they own SDKs and they own samples and demos and so forth.

And they have people that are more on the sort of awareness, generation size, the standard sort of advocacy things where they're going and speaking in events and generating content and interest in the product. Maybe you have community leaders that own sort of community engagement and so on, for us, we kind of need to own.

And lot of those different aspects are across like a small team, so you need people kind of, kind of, that can, contact switch and own different parts. But in terms of segmentation on the team, you know, the person I hire still very, very new. So we haven't defined the specific products or sort of programs that they're gonna own. But I like to work with people to. Let them have a little bit of choice about what are the things that they're going to own. There's a lot of different things that we can do. , you get the best set of people when you can align the types of projects that they're interested in with the, you know, potential projects that they can own.

You know, there's a lot of things that, uh, the person that we hired can potentially dive into and is best to try to align that as, as much as possible with where their interests are. So they could be, you know, community building. Content is a big area that we're investing. And a lot of these are kinda not necessarily owning wholesale, but it's a team effort.

So just because they start contributing content doesn't mean that I stop contributing the content. I think it's something that, everybody on the team needs to do, over time, but eventually as you scale the team, you might have people who. Solely focus on content generation, and that is their primary functional area of ownership.

But in the early days, you can't really afford to have somebody that I think siloed and specialized. You need people who kind of can own a breadth of things.

Jack: There's one thing that you mentioned early on, and that seems to be the general theme of giving people a lot of ownership and everyone having that founder mindset and also being flexible on what you do.

It seems to be, and I've seen a lot of people really strongly agree with you on the early stage. Side of things that you shouldn't worry too much about, like measuring everything and performance, but how do you think about measuring or or showing your value at that early stage when things aren't so measurable?

Sean: It's not that I don't think you should measure things. You should definitely measure things, but what I, I think the point that I was trying to make is that, you know, your North star metric for your, your function. Could change over time or things that you are investing in today that seem important could change because it turns out that you were wrong about the investment or, the product changes in some way where that thing is no longer important or whatever.

It's so you should be trying to measure as much as possible. In order to convey the value of something, even if it's not something that you are sort of pushing up the, the chain and surfacing at, you know, the C level or something like that, you need that information even for your own knowledge so that, you know, did the thing that I put my time and effort into actually work? And if not, what are the changes that we need to make in order to make it successful? Is this something that we should just kill from the program and invest our time somewhere else? So you should definitely be measuring things. But I think a

lot.

of the, and I'm actually hosting a panel in a couple weeks for the DevX Summit, where we're gonna touch on this topic, but I think it's a lot of, conveying your value. In the early days, and this might be true, I think this is probably true across the board, cuz I, I, I did the same thing at Google as well, is since Deval touches so many different areas of a business, there's not really any sole individual within the company that has full visibility into what you're doing. So if you are interacting with. I don't, the the marketing team, they're gonna see you in the lens of the contributions that you're making to marketing the sales team. Same thing, product, same thing. Engineering, same thing. So on. So that is their snapshot of what your contributions are and no one really sort of has visibility across all those different areas.

So what's really important is, one, you try to. do what you can. You own your visibility and try to do what you can in terms of articulating All the different areas that you're influencing. The other thing is that any of these cross functional leaders that you're interacting with, you should be building the, strong relationship with them and building trust with them so that they become your own internal champions.

So, When I think about develop relations, it's about building relationships with people, specifically developers. And a lot of times we focus that effort externally, which is very, very important for what we do. But you also need to be building relationships and trust internally, and that's one how you're going to have more sort of influence over the company in terms of continuing to advance and develop relations and doing the things that make sense for developers. But it's also how you build internal champions so that when questions come up about, we need to make cuts for whatever reason, where are we going to make those cuts? Well, if the sales leader, the marketing leader, the engineering leader, the product leader, whoever they are, are all saying, Well, we need de because they're helping us with this thing, this thing, this. They're absolutely critical to what? To us being successful and the ceo. The company's hearing that across four or five different functional areas. Well, you know, even if that person doesn't have full visibility into what they're doing, they're gonna understand, Wow, this, you know, person or this team is doing a lot to help us succeed as a company and there's no way that we could get rid.

Jack: That's really, really nice way to put it, that you can build the trust across the different teams.

Sean, one last question. I saw that you are not only the head of de but you're also the head of marketing, and so you might be uniquely well positioned to discuss how de and marketing into play.

Sean: Yeah, so I, just to clarify one thing, I'm head of product marketing, but marketing, you know, within Sky Flow also consists of like growth marketing and, PR as well, which are owned by other individuals. Just kind of zooming out for a moment about develop relations and marketing. According to recent develop relations, like reports, 30 to 35% of dev teams actually report into marketing. It's probably, I wouldn't be surprised if it's higher in startups because as I was mentioned earlier, awareness generation, which is most closely aligned with, marketing is usually the biggest sort of pain point for startup. And why they're building out developer team relations teams in the first places is they wanna essentially try to win the hearts and minds of developers at the top of the funnel and generate, build a, a community and so on. But, over time, a lot of times dev teams will move maybe down funnel where they're reporting their product in engineering or directed CEO or the office of CTO and the. The big thing though, even if you report to marketing, is, you don't need to be bound by reporting structure. Like we talked about, develop relations touches so many different areas you shouldn't be limited to, even if you report to engineering, you shouldn't be limited to just, you know, siloed within engineering.

You should be working across all these different areas in, in building those champions, like I said. But despite the fact that a lot of developed relations teams actually reported into market, There's, I think, this kind of weird and somewhat unproductive, tension that exists with some people in developed relations and marketing teams and perhaps sales teams.

You know, I don't know exactly where it comes from, but there's like this feeling that somehow marketing and sales is like beneath them or that, somehow having roi. Relates, for, for essentially KPIs for dev somehow taints their credibility as a technical representative, a community. And I think part of that comes from, you know, maybe there's a lack of confidence or naivety there.

They don't wanna be considered, you know, not technical enough by being associated with marketing. There's also historical reasons where. Engineers have historically [00:23:00] seen marketing as, you know, less important or less technical thing than, building a product or something like that.

But ultimately it's unproductive because it doesn't really matter what you do within your silo if the company fails. And that's more important than a startup, than anywhere else. You know, building a great company, building a great product, it's a team sport. Silos don't matter. All that matters is the success of the company.

And you need to hire people to understand that as well. Now, At Sky Flow, I lead develop relations and product marketing. And the way I think about develop relations, someone that works in developed relations, it's like this intersection, you know, this Venn diagram between engineering product and marketing and product marketing is this Venn diagram between product, product, marketing, and sales.

So there's a lot of, actual similarities between the two areas, especially at a company that has a highly technical product. Areas are about storytelling. Deval, you're telling stories to the, your audience with primary engineers and product marketing. You're telling stories a lot of times to a broader audience.

But if your product is actually selling the engineers, then you're actually telling stories to engineers or a technical audience as well. So since Sky Flow is such a technical product in terms of us, we are a data privacy vault, delivered as an api. Our primary user is a developer, an architect, or CTO or cso.

It makes a lot of sense to have someone with a heavy engineering background to lead product marketing as well as something like develop relations.

Jack: That's a really great answer, Sean. Thank you so much and thank you so much for your time. I really appreciate it. If people wanna learn more about Sean or about Sky Flow, where can they learn more?

Sean: Uh, for Sky Flow, you can go to Sky flow.com. Uh, we also, one of the podcasts that was mentioned at the top of the show is partially redacted, which you can find is sky flow.com/podcast, and it's a podcast focused on security and engineering topics. And then in terms of myself, you know, you can find me on Twitter at my name Sean Faulkner, or on LinkedIn. Similarly, about there on all the, uh on all the socials.

Jack: Thank you so much for joining Sean, and thanks everyone for listening. We'll see you again next week.