Selling your dreams as a service

Greg Poirier: Hi everybody. My name's Greg and I work for a tiny company of eight people called Opsy. I am very new to developer relations. So I was the first hire at Opsy. My title is actually like on paper factotum, which means an employee who does everything.

So I fell into this developer relations role because I like to go out and give talks and I'm sort of an extrovert but also an introvert and I am also a developer and I have been for quite some time and I know our space really well so it's very easy for me to stand up in front of a bunch of people and talk about what we do. So I do that a lot. I also write a lot of blog posts, that kind of stuff and so yeah, I spend a lot of time with developers. So part of starting a company is about having an opinion. So you have ideas, you have hot takes on Twitter, you have blog posts that have made it to the top of Hacker News, and you're like, think I'm gonna turn my ideas about how to do things into some kind of developer tool that people can use.

And so now you have to go out and convince people that your your way is actually good and right. So developer relations at a startup, it's not really just a channel for growth. It's very much more than that. And if you're doing things right, it ends up turning into a channel for growth and it ends up turning into part of your marketing strategy but for the most part, you're just trying to convince people, hey we have something, it's good, please come check us out. So in working on this talk, I actually came up with like a funny analogy between developer relations and this game that came out in 2004 for the Playstation by Namco called Katamari Damasi.

Now oh, that ended up turning up funny. So the interesting thing about Katamari Damasi is you start out, you're like this this space alien, this interdimensional prince and you come to earth and you start rolling up all these tiny little things like thumbtacks and pieces of bubble gum and wrappers and, you know, all these random little things. And you end up rolling up bigger and bigger and bigger and bigger things. So if you're in developer relations, like you can kind of see the analogy already without really knowing the game. But I thought it, you know, as fellow nerds, some of you might have actually played it and so maybe you might appreciate the analogy.

So you're an advocate for more than just your product at a startup. You're an advocate for your way of doing things, your contribution to the developer ecosystem. You are saying, hey, I've got an idea. I have a way of thinking about solving problems as a developer and I need you to come on this journey with me. Right?

You're gonna come experience software development the way that I experience software development. So you're a way you're an advocate for a way of doing things, for for a way of being as a developer. And it's about having an opinion and convincing people that you're right. So the interesting part about thinking of building a startup in sort of a a framework of developer relations is that once it's in the hands of users or developers, your product really takes on a life of its own that's a little bit outside of your control. People start to use it in new and novel ways, in ways that you probably wouldn't have even predicted.

Some of those ways may be horrible. Some of them may be absolutely brilliant. Some of those ways may push your product to its absolute limits and make it fall over. It's it's an exciting journey and you you have to work with developers to either understand your deficiencies. The deficiencies of your product that make what they're trying to do difficult or you have to get them to frame what they're trying to do in the way of thinking that you've molded your product around.

So it's a collaborative experience. You're going on a journey with developers to build a thing together. So going back to our analogy of Katamari Damasse, how do we roll up developers? How do we get people on board with our vision, our way of doing things? We have a thing that we say we want to be the product.

We want to make sure that we exemplify the behavior we want to see in our users and our customers and the people we interact with. We want to be at like the cutting edge of what's going on right now so that we're sort of shaping the narrative for how we're going to go forward, like how we're going to build products from now on. So show how your own product makes your life as a developer easier. One of the the biggest things that I see like failed startups do is they don't dog food. Like they have a thing that they've built that they're only interested in selling.

Like they're like, oh, I see this market niche. I'm gonna I'm gonna build a product to fit that even though I don't myself actually need it. So you actually have to you have to put these things into practice. You have to say, look, this is how we do things. This is how it's successful for us.

This is how it enables us to be better developers, to be more productive. The other part, and this is really important for developer relations too, is you actually have to listen to the people very closely that you're interacting with. It's very common when people come up to a new product for them to frame their usage of that product in a way that's safe and comfortable to them. Like, oh, I have my way of doing things. Your product should conform to my way of doing things.

This is kind of like for developers in here. It's kind of like when you go from one programming language to another. Right? Where the paradigms of your original programming language, they're all things you're very comfortable with. You have ways of doing things.

You have your favorite libraries. Then you switch from like Python to Go and then all of a sudden everything is completely different. All the primitives are different. Everything you're doing is really different. But you'll you'll end up carrying that baggage with you.

I have a way that I do things that makes me an effective developer and really like you're choosing this new way of doing things because somebody else is like, oh, I do it this way. It makes me productive. So there's this there's this cognitive dissonance in people that are switching to something new that makes it really difficult for them to sort of grasp the ideas behind why this product came about to begin with. So yeah, once once it's in the hand of your users, you you go into building this product thinking, okay, I know how I'm going to use it and I'm going to get people to use it like I use it. But then people come along and they use it in the way that they want to.

In the way that is actually good and beneficial for you as a product developer that makes you rethink like some of your fundamental assumptions of your ways of doing things because other people are brilliant and talented developers besides the people at your company. So you have to be receptive to this feedback that happens once new users come on board because they're going to say, it's really hard for me to do this thing or I don't really understand how to do this thing. And sometimes that means you're lacking in a feature And sometimes it means, oh, I need you to think about this in a different paradigm. And most importantly, no feedback is still feedback. Like you can hear somebody not saying anything sometimes because you'll reach out to them a couple of times and they don't respond.

They don't engage. They don't open the email. And that is you're not compelling. You're not engaging in the right ways. And most importantly, put everything about your philosophy into practice all the time.

So at Opsy, we are like entering a very noisy space. There are a lot of incumbents with very similar ways of doing things and we decided, you know, there's a way that we think you can do it differently. So we decided, okay, well let's look at some of the the current big trends, know, like microservices and really informative robust health checks and you know, everybody's doing things in the cloud. So let's really integrate with AWS. And most importantly, we demo our product in production all the time.

Like we use ourselves to monitor ourselves. And there's a lot of trickery that goes into that but it still is a thing that works for us. So we have a Slack for all of our users. And they come in and they ask questions like, hey, we have a WebSocket service. How do we monitor this with Opsi?

Hey, we want to monitor services running in Kubernetes. How do we monitor it? And it I don't necessarily always know the best answer because I may not be an expert in these particular things, services, types of services, frameworks that they're using. So you have to like sit down and really think, okay, well what does this do for you? Okay, well how do you use it?

Oh, okay. Well, let's figure out how to do this together. And one of the most important important realizations that we all have to make is that we're not the smartest kid in the cafeteria. And this is something that I say to my friends. This is something I say to everybody I come across.

There's always somebody else right there, like right next to you who has an idea that has a way of thinking about a problem that's different than yours. And just because it's different doesn't necessarily mean it's lesser. It means that there's just other ways of thinking about things. So just recognize that your users are also intelligent driven people and it's very important for you to really listen, engage, be receptive to feedback. Why are you so smart, users?

Just let me tell you how to do it. So yeah, that's that's it. Thank you very much for having me here. I'm really happy to be here. I'm new to developer relations.

It's been really great today. So yeah, I'm grepory on Twitter. If you have any questions, just hit me up.