Of course, and there'll be more singing with karaoke later.

I'm not gonna bore anybody with talking about myself. Matthew invited me to give this talk and he said, you know, we're gonna have some things, it's kind of a tough time, we're gonna be talking about the downturn and everything. He said, Maddie, it would be really great if you could come and give us an inspiring and energetic and uplifting talk to bring us out of all of that. Well, I'm sorry Matthew, this is the reality — it's rough out there right now.

One of the things I want us to think about is that being in a downturn really changes the calculus of how we think about a lot of things. There are ideas and statements and thoughts in this talk that I've been saying for years, but there's also some things that you would not have heard come out of my mouth six months ago. I would have had a different discussion on many of these topics even back in March. That's just the reality of where we are right now.

I've referred to myself before as the cynical DevRel — that's kind of one of my brands. We talked a little bit earlier about having your brand; I guess my brand is that I'm acidic. But when I talk about that, what do I mean by being the cynical DevRel? It's this cognitive dissonance — this idea of holding two thoughts in our head at the same time. It's a cognitive dissonance between the idea that DevRel is good and pure and unsullied by filthy capitalism, but at the same time the company has to generate revenue and make money, and DevRel is part of that.

The weird thing about cognitive dissonance is we as humans are actually capable of holding two conflicting ideas in our head at the same time. Capitalism kind of sucks — I used to give a lot of talks in the incident response space and I would say there's no root cause, well the only root cause is the Big Bang, or the root cause is capitalism. Well, that's happening. We may not like it but this is where we live. And when I say this, it doesn't mean that this is all about the pursuit of the almighty dollar or the almighty Euro or the almighty Crown, but it's still a fact of the way that we work for organizations. There are exceptions — you know, maybe you DevRel for a non-profit or a government agency — but you still have an outcome that we're going to work toward.

So keeping my theme — I decided to go for a little bit of a rock and roll theme through this, but I didn't retitle it because that would have messed up the program. But when you think about it, we're like okay, who gets to stick around for the encore? We're saying we're going to keep going. What are the things when we sit down and think about that?

Here's the thing: either you build the thing or you sell the thing. I'm not saying that the only people who are around are people who are writing code for something that's shipping, or someone in a sales executive or account executive role. Like everything else there's nuance to this and it's subtle.

As an individual, if you want to get yourself connected into these areas — either you're building or selling — the thing to remember is that if you're not connected in a measurable way to either of these things, well then you're pretty easy to get cut. We've talked about that a little bit before.

The important thing is "connected" — it doesn't necessarily mean "accountable." I'm not sitting there and saying that as DevRel you are fundamentally responsible for ARR or anything like that. But how can we connect those dots? One of the reasons we feel like this is counter — we don't like thinking this way about DevRel, it's rough, this is not why we do this, if we wanted to sell stuff we wouldn't be in this job.

I spent a couple years doing DevRel at PagerDuty and I'm going to talk a little bit about that later. I did a lot of work with our field and a lot of work with their sales helping customers and things, and it never really did feel like it was bad or that I compromised my values. I think a lot of the reason that we have a hard time with this is because we want our community to trust us. We've talked about this a lot — the value that we give, especially as advocates, is that we have the trust of our community and we have authority in that. We want our community to think that we're impartial. We want them to say, hey, if I'm telling you to do this thing it's because it's the right thing, not just because that's who's paying me. You can trust me because I'm not trying to sell you something.

Honestly, your title and your role actually does a lot more work about that than you think. And again, it's been discussed in earlier talks — there are people who will just go block everybody on Twitter just because they have DevRel in their title or whatever. Don't worry about those people.

So here's my real advice as we kind of think about it as we go through this: we have to get over ourselves a little bit. I'm also speaking to myself. This slide is an excuse to feature Depeche Mode, which is one of my favorite bands. We're not the front man for Depeche Mode, but even Dave Gahan, who's like one of the best lead singers and front people in the business, doesn't think that he's better than the rest of the band.

Now PJ's sitting here and later he's going to be like, well you know there was this one interview where Dave said blah blah blah. You know what PJ, I'm trying to make a point here.

But seriously, we're all part of this larger organization, we're all part of our business, and we want to collaborate. We don't want to set ourselves above. This is one of the things that I think — and it's hard — but we do tend to see ourselves sitting in kind of a bubble inside of our company. We have all these other things and then there's the rest of the company. There's a lot of really great stuff — we saw some great stuff about DevRel being the glue and that's really awesome. We should be doing that. But those membranes are really permeable.

This is a novel idea. I'm just going to let this one hang here for a minute, because it might make you feel a little uncomfortable. Also I want to fill a little time. But this is a tough one.

When I was building this deck I told a friend of mine that I was going to have to try really hard to not just have it be a whole bunch of screenshots of my own tweets, because I feel like I've written this talk on Twitter over the last couple of years.

But it is true: how many of us get tired of the stereotypes about DevRel? Like, DevRels can't code, they're just influencers and they just fly around the world and they go to conferences and go to beaches. By the way, yeah, that's part of what we do and that's awesome — KubeCon in Valencia. But we have no problem making these same comments about sales reps or something. And I will firmly acknowledge that underindexed folks deal with those DevRel stereotypes a lot more than someone who looks like me, so I want to acknowledge that.

But we are supposed to be high-empathy folks in this function. Kim Bannerman has said DevRels are empathy engineers and I agree with that. But we've also collectively decided that we have some colleagues who don't deserve our empathy because of the job they chose to do. And that just sort of sucks.

These are some of the common perceptions that people have about people who work in sales. One is that they're not technical — they don't understand the technical product, their skills are all relationship-based. And by the way I'm not calling out, you know, selling on the golf course and stuff like that, but that's what we think, right? We think about that. Another thing we tend to think about them is that they're dishonest. This might be very American-centric, I don't know if this is as international, but we talk about a used car salesman — that slimy guy who's like, okay, what's it gonna take to get you in here? We have these perceptions that they're going to use shady tactics and they're going to promise things that a product cannot do.

And then there's another one: that they're all just about money. They're coin-operated.

I'm going to talk about the first two in a little bit more depth, but for the third one, here's the thing. Years ago when I started working at Chef — I was part of the Chef community before I joined, and I loved Chef, it was really influential in my career. A couple months in, our VP of sales said, hey Maddie, we've got this new sales rep starting. It would be awesome if you could fly in and let's do a meeting with them and you could teach them about Chef, what the product's like, all this stuff. So both of us were flying into Boston. We meet at the airport, we're taking a cab to the meeting, and I'm sitting there in the back of the cab with him. I'm all starry-eyed, talking about stuff — like, this is really exciting to be working at Chef, I'm really looking forward to helping people do awesome stuff. And he sits there and says, "I'm looking forward to making a shitload of money."

And I hated that guy for six months.

And I kind of look back at it after and I was like, you know what — who cares? Because first of all that's a value judgment a little bit, but also that's what makes them good at getting the deal. Because at the end of the day we need to get those POs. They can be all about money — they're not billionaires. They can stick around. If your account execs are billionaires, then first of all Mazel Tov to your company's revenue because that's amazing, but usually they're not.

So the thing is the sales org is — again, qualifier — not totally evil. A little bit, a little bit, right, to be clear. This is not supposed to be "oh sales people are amazing and everything's great." Tech sales is fundamentally broken in a lot of ways, so let's just be really clear about that. I'm just saying that referring to people as "sales droids" or whatnot because of their job title is a pretty bad look. But there is a reason that your CEO's best friend is the CRO or the VP of sales.

The thing to think about is: no matter what your job is, whether it's DevRel or anything, you will do it better if you understand how your company makes money. And you'll do that even better if you understand the sales function.

Quick little side note because I say this a lot — not just to DevRels. When I would give talks to people on DevOps transformation and stuff, I'd say hey, do you know how your company makes money? If you don't, go find out, I'll wait. I spent a year working at Red Hat in the public sector working with state and local government agencies. One thing I found fascinating is people who work in the government, instead of private enterprise — the answer is "how does your company make money?" because they don't. But you say "what's the mission?" and they all know. You go to an average enterprise and ask people how does your company actually make money — people don't really know. Understanding your sales function helps you do that.

The other thing is, I want to acknowledge there are absolutely toxic people who work in sales, and yes I think there is something about that function that might attract that a little bit more. But there are also account executives, solution architects, and sales engineers who know way more about our technology, our product, and the people who use it than a lot of us do in DevRel. There's a lot to take from that. Getting to know how sales and marketing actually work — collaborating — can actually help us learn about our products and our users.

I talked earlier about whether, as the belts are tightening, you're building or you're selling. I'm going to be talking a little bit more about the second one, because this is not an hour-long way of closing things, but there are pieces when it comes into that and a couple other things too.

You may sit inside the marketing org — this is true whether you sit inside the marketing organization or you don't. And again, it turns out people who are marketing professionals know how to do marketing. They actually know how to do their job. There are a couple places where this comes in. One is when you think about folks in marketing — they do user research. They might call it market research; we call it user research. If we can join forces, the sum is greater than the whole of its parts. There are things they know about our prospective folks that we can work with, and they can help get that voice heard, because it turns out people whose job it is to get a message out there actually know how to do that.

Now this is a two-way street. We need to work with them, we do not work for them — unless you do. But the thing is, the way I always like to think about it is: DevRel does a lot of the same things but we do it a little more diagonally. And even if you're not in the marketing function, a lot of the things that a marketing group wants to do are things that we want to do. We want to understand our users. People in marketing have ways of understanding that. We have different ways of doing it. Let's join forces — even just combining budgets, combining resources. Captain Planet, Voltron — these are all things. None of that has to do with rock and roll, I don't know where that's going.

The other thing is amplification. Going back to the earlier talk about paid placement — how many of you in DevRel work with your external comms or PR people?

PR people would love to make you famous. There's a lot we can do, and there's stuff that I'm working on right now trying to build up within our experience where I'm at.

Just to give a quick example: you're working at a startup or a company, the press comes to the agency and they want to hear from the founder all the time. They've got a question about the industry and they're like, okay, I gotta go talk to Jane Smith the founder. Number one, your founder is your CEO — they're busy. And also they're not necessarily the right person. Now if they want to say hey, tell me the story about how you got founded, sure. But if it's more like, tell me about the industry, who are good people who actually know this stuff and can speak to it? Developer advocates, because they know the industry.

DevRel contains multitudes — not every DevRel is the same person. This doesn't work for everybody. You may not be the person who wants to talk to the press. But the other thing is, PR people are very good at getting your stuff out there. Think about how many of us talk about wanting to repurpose content — you give a talk, you've gotta make a blog post out of it. What if instead of a blog post that lives on your own digital property, it was like I give a talk and that turns into a byline on DZone? That's expanding reach. People are good at getting the message out there. Other people in the organization can help with that, and you're actually helping them solve a problem as well.

I say we want to believe so hard that DevRel is not developer marketing, because somehow we decided that sales and marketing are icky. A lot of ways they can be, and that's not bad — by that I mean we're trying to accomplish similar things. Angie Jones has a great blog post that's a little counter to this and I love that as well — I've got some links that I'll give at the end.

The way I want to think about it is: there are a lot of things we do that rhyme with other parts of the organization. And that can really help us be superpowered. It helps us do this thing, because this is one of the best bits of advice I would give to us in a downturn: we need to do things that require less imagination to show value.

It is tough out there right now. The beans are being counted. The metaphor here is that a guitar solo — you don't have to imagine the value of that because it's right in your face. But a lot of times we do stuff where we say, okay, well let me explain to you why this thing is going to pay off dividends eight months from now, twelve months from now, eighteen months from now. I'm not saying only do short-term things, but we want to focus on the things where someone can connect the dots without us having to show them how the dots go.

That was an example of one of the things that I would have told you the story differently six months ago. The other one is: one for them, one for you. Sometimes you might need to do some top-of-funnel content, like okay you know I really don't want to write this inbound thing. I usually use a film analogy for this — you have to do the blockbuster movie so you can do the prestige picture. But I had to come up with a new one for rock and roll. Even Iggy Pop had a song in a cruise ship commercial. So sometimes you can sell out a little bit.

Also, apparently in the UK Iggy Pop did an auto insurance commercial and it was super controversial because musicians couldn't get insurance from the company. I thought that was kind of cool.

But the trick of these — and it's not necessarily one-to-one, maybe it's more like one for them, six for you, that's cool — the trick is don't put your heart and soul into this work. Don't work late over it, just get it done. Kind of do it. But here's the trick of this stuff: the best part about selling out? You get paid.

I also realized about two hours ago that I missed a reference — Reel Big Fish's song "Sell Out" could have been in here instead, but we went a different way.

So okay, let's talk about how we can do that — how can you sell out but keep your soul intact? Because we'd like it. I want everybody to keep their soul.

The example I'm going to give here is stuff I did when I was a DevOps Advocate — because that's what I called it, not a Developer Advocate, because heaven knows nobody wants to see me code — when I was at PagerDuty. I would do a lot of work with prospects and with customers. I was on the community team, the developer advocacy team. We weren't even connected to marketing or sales; we reported to the CTO — who had nothing to do with engineering, that's a whole other fun story — but we were a fundamentally completely separate team.

Here was a motion we kind of stumbled into by accident, but it worked really well. Let's say I was going to be in a certain region for a conference — let's say I was going to be in Australia speaking at a conference. You don't fly from Chicago to Sydney for two days, so I'm going to be in town for like a week or so. I would have like ten or eleven meetings while I was there with potential PagerDuty customers with our sales team. And not a single one of those meetings had anything to do with our product. It was not "come in and talk about what PagerDuty does, let me give a demo." They would be meetings with groups of people in that organization to say, hey, let's talk about how you're doing incident response, what are you doing with blameless postmortems, how's your DevOps transformation?

And it was all really high-level culture stuff, but it was really powerful because it did a couple of different interesting things.

It made the customers say, hey, one of the values of being a customer of yours is I have access to stuff like this that isn't just you coming in and pitching a product. And it added to the "you aren't just trying to sell me something" thing. We want to have this conversation on the side of your sales team. It gives them a reason to have a conversation with a customer, and an account executive wants nothing more in their life than to have a reason to talk to a prospect.

I can't tell you how many meetings I would walk out of and the sales rep would turn to me and say, "I've been trying to meet that CTO for six months."

Okay, so how can you do DevRel plus sales safely? Warning: this will not work for every kind of DevRel or every kind of product. I'm giving this as an example because number one, maybe you'll look at this and say I can actually implement this; but more importantly, it's to give the example of how can we think about things in a different way.

The first thing is: it's okay to meet with customers and prospects — not to talk about the product, but to talk about the ideas that might help them see value in the product.

A warning I'm going to give you: this depends on your organization. We are not sales engineers; we are not solution architects. It's not because we're better — we have those in our organization and they're very good at it. Now, if you are in an organization that does not have sales engineers or solution architects, do not do a single thing I'm going to show you on this slide, because you will turn into a sales engineer.

The next one: this is something special being offered to them. You remember a couple of slides ago I kept reiterating we have to get over ourselves? This is the exception. When I went to Red Hat after leaving PagerDuty, we were trying to do this again. I would go to the account reps and they'd be like, well I can't get this to work. I said, how are you doing it? They'd say, well I would go and tell them, hey Ms. CTO, can I get Maddie on your calendar? I said, no — you don't go to them and say that. You go, hey Ms. CTO, I have this expert, this person — I would love to be able to offer you the opportunity to have her meet with you. Can I get you on her calendar? It changes the calculus of that. So this is the one time when you don't have to get over yourself. But you need to be able to back it up — don't be full of it. Actually have the value of that.

And then your solution architects can follow up later with the topic to sort of say, okay cool, so remember we had this conversation, here's actually how it connects to the product.

The other thing is: if you're having these conversations with these prospects, we talk about advocating for our users and customers — this gives us information because we're having these conversations that we can then feed back into product and into all these other places.

I used to say that the most effective salesperson at Chef was Nathan Harvey, who was our VP of community. There's always been this running joke that a customer will tell a sales engineer something they would never tell an account executive, because even though your title says "sales engineer," they think, oh but you're not selling me something, I can trust you. That goes double for developer advocates. Everyone's like, oh cool, you're just the community person. Did Nathan Harvey want people to buy Chef? Yes, because he liked working at Chef and we keep working there when people give us money.

Nobody sees us coming — and it's not about being sneaky, I know it's sort of sounding that way. Here's the thing: this goes back to the authority and it goes back to the "why sales." If the only way someone would buy the product is if you tricked them, maybe you shouldn't be working at that company. So this is really about a partnering thing.

I like to talk about this idea of work as imagined versus work as done. Jimmy Chamberlain, the drummer of Smashing Pumpkins — this dude gets it done. That's work as done. Versus Billy Corgan, who goes and creates the latest album — it's seven records long, it's this exploration and whatever. Jimmy's just in the skins, getting it done.

This is the idea of: we talk about how we would like things to be, but what do we actually do?

We think about being able to provide feedback to product and things like that. That's great advocacy — it's a full-duplex, bi-directional thing. We advocate for our community. But how many folks here are actually enabled to do that in your organization? Unless DevRel is directly connected or part of product, this is very hard to do. And number one, when things are hard we tend to not do them.

Important point: I am not saying it's not important. I'm not saying we shouldn't keep trying. But in a downturn, this is the time to focus on the "work is done" stuff.

It's also great to say, okay I fight for the user, I work on open source contributions — all the stuff that connects to us and makes us look like a little bit of a target. So okay, but how are we going to show value with less imagination but still be developer advocates and DevRels and do all the things we know we want to do? That's why we do this job.

DevRel can rhyme with a lot of other parts of the organization. That developer success panel yesterday was really inspiring, because customer success is another part of the organization that DevRel is a lot like. DevRel is like customer success for people who aren't necessarily customers. If you go back and look at what customer success is really about, it's about enabling your customer to be successful. It's not about making them happy, because making them successful sometimes means you're not going to make them happy along the way. But it's letting them accomplish the thing.

There are lessons we can learn from that. I call it "business" because it's called different things — you think about partnering and whatever. But here's the thing: if your company is like, okay we want to partner, whether it's an ISV thing or building a partnership with someone else, that's a big undertaking. How do I do something with this other company? So if we're saying, okay, should we be partnering with Honeycomb? Well, we could go through the whole partner channel thing and then we have to build an integration and do all this work to maybe even find out like, was it worth it? It's not a big ask for me to go to my DA friend and say, hey, let's just do a livestream together in front of your audience and see — do people, when we put these two things together, does this resonate? Maybe if we get some good feedback on that we're like, okay cool, when we talk about these things together, it seems like a little bit of an experiment we can investigate more. Or we can say, well, that really went over like a lead balloon — turns out people who love Honeycomb could not care less about data platform as a service. So maybe those things don't go together. We can help build those partner things.

Also, this is the thing to remember: developer advocate partnerships are powerful. Our network is vast — we know all the people. This is how we can help other parts of the organization.

Fun story: when I was at Pulumi, we were wanting to do some more official partner activity with Datadog, and everybody wanted to do it. This was not like "how do we do it," but the Datadog partner marketing folks were just really super busy. Our partner person at Pulumi just couldn't get anything back — they're like, okay we'll get to it, we'll schedule it. And then I was at KubeCon and I saw Elon, who was the VP of product, and I was just walking out and I said, hey, do you think it — yeah, just call Waldo, let's just do it. And it was two DAs and we just slapped a thing together. So we can do that.

Now, we talked about all this — so we need to show value but set boundaries. This is always good DevRel advice. It is in our DNA to help people, or we wouldn't do this job. It is very hard for people who tend to work in this type of field to say no, even when we want to say no. We know we want to say no but it is so incredibly hard. I am trying so hard to teach this to my team right now — we're working on it.

And this goes in because here's one of the risks of the thing I just said about doing those shorter connecting-the-dots activities: the risk is this becomes the new normal. Boundaries help us with that. The other thing is that risk is a little less than you think, because what's the average lifespan of any org chart or strategy in a company? It's like eighteen months. So whatever the new normal is, it ain't gonna last that long anyway. Everything's always changing.

The thing about boundaries is they can be flexible and situational — they're not absolute. It's not always the same thing. I'll give a couple of examples. One might be: I'll call in a favor for someone, once. I was at a company I had recently joined and we had a big product launch. They had the usual Google Sheets list of all the influencers and they're like, okay, can we get these people to tweet about our new product launch? Who knows them? And there was one: Emily Freeman. Well, Maddie knows her — can you get her to tweet about whatever? And I said, you get one favor. Is this the one you want? Or do you want me to get her to keynote our conference?

The reason people do favors for me is I don't ask them a lot, and when they say no I say it's okay. But that's an example of a boundary — yes I know people, but I will do it one time.

Or: I'll share some promos in my social network, but I'm going to use my own words, in my own way. Not saying you have to do it, not saying anybody has any responsibility to do this, but it's an example of a way to set the boundary — I'll get you an accomplished thing, but I am not your faucet. You don't get to use me as your megaphone. But I will do this thing.

Or, a friend of mine gave this example: I'll write about a new feature that we have, but only after I've gotten to use it, and I'm going to use my own words. She's not saying that if she thinks it's trash she won't say so — it's going to be authentic and true. That's actually super helpful to be able to have.

So maybe not completely uplifting — karaoke is what's going to make us uplifted. But here's what is: we are gonna go be awesome, because we are in a rough time right now.

I was giving the metaphor before — your company is the band. DevRel is the bass player, marketing is the cowbell I guess, I don't know, I didn't really think this one all the way through. Heaven knows we don't need more of that cowbell. But if we think that your company is a band and we're playing together, our community is one big damn music festival. That's the message I want you to get out of this: all the things we have — things like DevRelCon — I think we got a lot of great ideas from each other over the last couple days about how we can add more value, we can build more things together, we can bring our networks together. That's the thing. We are going to amplify what our company can do by partnering with each other and with the other folks, and that's probably the biggest way that we can all help ourselves get through this so we can see it in the rearview mirror. We're just going to continue to add this value. But the biggest way to do it is to think in ways we haven't thought before.

So thank you very much. Thank you for celebrating my birthday with me.

Thank you so much. I just want to point out, I saw Ben's talk yesterday and I was like, damn it Ben. Matthew's like, I needed to flip those two.

Thank you so much for this great talk. I think you're right that we often forget other departments — we look at them as, oh they will take something away, or we don't see it as, we're all under the same roof, it's the same company, why aren't we working together to go further?

I will point out by the way that we are still better than everybody else. It wasn't on the video right? Okay. I'm never getting invited back.

We have time for three questions.

I was curious — maybe you can add a little bit more insight on how, as a DevRel person, you can collaborate with marketing and sales without losing your authenticity, because the engineering community also doesn't like sales and marketing.

Yes and no. I want to be careful with that a little bit. How many developers don't like marketing? Untrue — they don't like traditional marketing. Developers like people who solve their problems. And actually they don't like salespeople who do all the things we complain about, but someone in that role done differently is fine. The motion I was telling you about — the people who mostly came to those meetings were individual contributors and they loved it. There was a company in Australia called Car Sales and I got to be super good buddies with them — it was a weird thing where I would end up seeing them about every six months when I was in region, and they were just falling over themselves because they just wanted to show me the cool stuff that they were doing. That's the thing — you are collaborating with them because you're not going in there and selling them, but you're bringing something.

There are different ways to do it. In the PagerDuty example, it was cultural and transformational ways of thinking that had to do with the product. Not every product's like that. But you can do things like maybe it's a workshop, maybe it's something where you're saying, okay, what can you do where the sales people will get value out of that? What an account executive wants is an excuse to spend time with the customer. So you ask, what can I do where we can go and meet — and again, a meeting doesn't mean I've got my PowerPoint and I'm doing whatever — but spend time with the customer that gives them value? In my case the value was they were like, oh cool, let's step through how you do incident response — they were basically workshops where they were sitting there saying, let's talk it through.

Also, my business card at PagerDuty used to say "thought validator," because half the time all it needed to be was for someone to tell me what they were doing so I could say, yes, that sounds great, you are on the right track. So even if you're in a developer tooling space or similar, it's like, how is it connecting?

The same thing with collaborating with marketing — what are you trying to do, marketing, and how can we help do it in a way that maintains that authenticity? Some of it is: how many of us have been in an organization where part of your job is to tell the marketing people, like, don't say that? Yeah, so that's actually part of it. You can sit there and say, okay, and the reality is, at least in my experience, if you position it right and you don't go in with your big, okay you guys are a bunch of idiots let me tell you what you're doing wrong, but just say hey, how can we collaborate — people fall over themselves to do that. Because to keep that authenticity, that's why what you don't do is say, hey marketing, I'll do a bunch of webinars. If we're gonna do a partner thing, when I was at PagerDuty they'd be like, cool, we want to do a thing with Datadog. I'm like, cool, I'll do a thing with Frosty from Datadog, but we're not going to go in there and do a demo of how Datadog and PagerDuty work together. We're gonna talk about a topic, and that gets people interested and that's of value.

And it's still — this goes back to one other thing I think we have to be cautious about: we have our own preconceived notion about certain value. Sometimes, especially those of us who do community events, we over-rotate on community authority and we forget that sometimes people actually do want to see a pitch. They do want to see a demo. So it's a matter of saying — but in a concrete way.

I think that's it — we're all ready for karaoke. Thank you.