DevRel and community building for authentic relationships with Mary Thengvall

Transcript

Ledge: Mary, it’s awesome to have you on. Thank you for joining us.

Mary: Thanks for having me, Ledge. I appreciate it.

Ledge: If you don’t mind, for those who don’t know – I mean, you’re totally famous and everybody should know you, but if they don’t – would you please give a two or three minute introduction of you and your work?

Mary: Sure thing. My name is Mary Thengvall. I am @mary_grace on Twitter. I’ve been involved in developer communities, technical communities for a little over 10 years now. Working with a variety of companies, from O’Reilly Media, to Chef Software, to SparkPost. These days, doing some consulting and contracting with companies on my own. My company is called Persea Consulting.

I have a couple of goals. My first goal is to provide resources for folks in the developer relations or technical community building industry. There’s not a ton of resources out there, and I want to help folks who are in that career path be successful. Set them up for success not only personally, but also help their companies set them up for success on those teams. That’s my goals these days.

I have a book that got release last year called The Business Value of Developer Relations. I put out a weekly newsletter called DevRel Weekly. I have a podcast of my own called Community Pulse.

If you are involved in or interested in developer relations and community building, you might have heard of me or known what I do. Though I have to say, it is a funny switch with the book being out and being more public with my resources these days to go from, I know a lot of people from community building and I have a lot of one-on-on relationships to people knowing who I am. I’m not used to that. It’s a weird switch.

Ledge: Anybody that doesn’t get your newsletter, if you want to know anything about DevRel, you make an encyclopedia every week on email. It’s sometimes so much stuff that I need to click the link at the bottom to get the full email.

Mary: Yes.

Ledge: I got to say, mad props. This thing is legit. I learned a ton of stuff. Almost all of my Twitter followers, I CTRL+Click down your list and follow all those people. I don’t know when you ever do any work for the amount of work it must be to curate all of that stuff.

Mary: There’s a lot of automation in place. Automation is my friend.

Ledge: As they say [inaudible, 00:02:32], bless your heart because that is a legit amount of work.

Mary: Thank you.

Ledge: So, DevRel – magic, new, important thing that’s not really new. We were talking offline about that. That is a great topic.

I know from your book, because I read a good portion of it, I haven’t finished it yet, but that there’s a little Venn diagram of what is now called DevRel, comes from historically a bunch of things. Let’s start there.

Mary: I like starting a step back from there. Before we define developer relations I like to define community. Community to me, the definition that I use, is a group of people who not only share common principles but also develop and share practices that help individuals in the group thrive.

It’s this idea of, people who come together out of shared interest or shared needs but really have each other’s best interest at heart. They’re motivated to help. Motivated to share resources. Motivated to help each other succeed.

Developer relations, at the end of day the TLDR is really just building communities for technical audiences. Instead of a knitting community or a mom’s community, it’s a community of people who use Jingo, or a community or people who are Ruby enthusiasts. Or a community of people around Chef software or a different open source platform. Things like that.

That’s the basic definition, is building communities for technical audiences.

Ledge: I wonder, how does community building reach the level of weightiness that it becomes a job? We all know it’s important, it feels good, but it’s a hard thing to put your finger on the pulse. In much the same way as, why in god’s name would a company pay some dude like me to sit on a podcast and talk?

Yet we know that there are far-reaching tendrils that go out, and relationships super-matter, but I would love your take on that because all of us – DevRel, Technology Advocate, Random dude on Podcast – have to answer the question of ROI.

We get paid money to do this stuff, and why? I know you have insights on that.

Mary: There are a couple of different reasons why companies tend to start communities, and it really depends on the goals of the company.

For open source companies or open source products, it’s a fairly logical conclusion. We need someone who can help manage and build this group of open source maintainers. We need someone to really get behind the community of people who are interested in our product and are contributing back to our product. Someone who can talk to them and interface with them, and not only manage but build relationships with this group of individuals who really is helping to build the future of our product.

But then you’ve also got companies that have APIs, let’s say. Maybe they don’t even have an open source side of their product, but they have a good number of people who are using their product who are developers. The end users are developers. People who are building with the APIs. It might be that they have a secondary audience of marketers, or director-level folks, or whoever is another user of the product – but if you’ve got an API, you’ve got developers that are interfacing with that.

A big part of it is, companies are starting to recognize there’s probably five or six companies for the same API idea. In order to stand out, it’s not just enough to have flashy marketing, or a snazzy looking API, or the latest and greatest software. You need the feedback from the community. You need to have those conversations and understand, what resources are people looking for? What needs are we trying to meet? What problems are we trying to solve, in order to be able to actually implement that feedback?

It’s not as easy as calling up your local developer and going, “Hey, have you tried our product? What do you think?” You’ve got to build the relationship with them to a point where they’re willing to sit down and talk to you and give you honest feedback about the product.

Ledge: Yeah. Developers can really smell a salesperson coming a mile away. As someone who’s sold to developers for many, many years there is no audience that is more attuned to authenticity, or the lack thereof, than the developer community. So I can completely appreciate that.

It’s not even in a, “Well, what can you do for me,” kind of way but there’s almost no transaction to it. It’s an entirely authentic relationship that our technical brethren really require.

That’s been an important thing in development of our business. Tens of thousands of developers have something in common.

Mary: That’s where the authenticity really comes into play. That’s one of the few pieces that really set developer relations apart from other community building exercises and community building teams. Is, in order to be fully authentic, you have to have people who at the very least are tech savvy.

All the way from, ‘I can handle a fairly technical conversation because I understand the greater pieces and where everything fits in in the bigger picture’, all the way to, people who have been developers in past lives, you can sit down and write code side by side with a potentially new customer.

But then there’s this third set of companies as well that are starting to get these developer relations teams and building these communities, which are interesting because they’re fully proprietary products. Their purpose, their intention isn’t so much to get people using their platform or get people contributing back to their platform, it’s more of understanding the needs of the community to improve their product, and also to be able to provide generic resources around a specific topic so that their audience is more successful in their day-to-day jobs.

This is something that I did back at O’Reilly Media in the day. We were selling books, we were selling conference tickets, and that’s fine, but it was more we want to be promoting these principles. We want to be promoting these ideas. So part of my job, as the community manager there when I started the program, was to go out and just talk to the thought leaders. Talk to the people who were speaking at the conferences. Talk to our authors. Find out from them, who are you listening to? Who’s blogs are you reading? What podcasts are you subscribed to?

All of those types of conversations so that we understood, here are the insights, here were the leaders are, here where the new thoughts and new ideas that are coming out so that we could be providing resources for those topics to better serve our community.

It was less about sales – even less about sales than DevRel ever is. Less about sales and far more about, how do we better serve our community? How do we better serve? How do we better meet their needs? How do we better provide resources so that we are empowering them to be more successful in their business?

Ledge: All of which sounds like what I would have, maybe in my business school brain, go, “Well, duh. That’s part of the marketing function.”

I think what sets DevRel, Technical Advocacy, all the names around that space apart is that we live in a world where the technical knowhow is such a critical component, and because we have a set of community members that will turn their nose up at messaging if in fact it doesn’t scratch the technical itch and get back to that authenticity.

In that way, it’s an overlap of functions that didn’t have to exist. There was no way to do it.

Mary: It’s true.

Ledge: When I started as a developer, it was totally cool and expected that we would be in the basement with the lights off, with the lights from the monitor the only thing on our faces. And the fire marshal would go, “You’ve got to move all these servers out of the dusty hallway here.” To never, ever, ever talk to a customer. Forget about it. The user was right upstairs but you weren’t going to talk to them.

That’s not a thing anymore. That’s only 10 years ago.

Mary: Definitely. It’s interesting to me especially. I’ve had a number of conversations lately where people are like, “Well, but is developer relations really necessary?”

My answer is two-fold. First of all, the marketing is a big piece of it. Product is a big piece of it. Customer success and user experience and all of those things are a big piece of it. All of those departments in a company that is truly customer focused all of those departments are talking to customers. But the developer relations team is the only team that their first top priority is that community. Their only priority is that community, and they are the only team that has only that focus.

Of course, they understand we need to pay the bills, things have to be up and running still, but they are the only team that isn’t split.

Marketing is split between branding and customer awareness and lead generation, product display. Between, we have to please our big-name customers and push these products out. Engineering has a focus on, we have to meet our deadlines, we have to get these things launched. Customer success wants to be clearing as many support tickets out.

Whereas, developer relations can look at that as a whole, as a big picture, and go, okay, yes we need to provide resources for our enterprise clients but also here’s a different problem that’s affecting free clients as well as mid-range customers as well as enterprise clients, that isn’t as flashy, isn’t as exciting as this other new feature is but impacts more people, and I’m hearing this from customers across the board. And, if we fix this, we can reduce churn and we can help these other customer have a better experience.

It’s that perspective and that context that they bring to the table that really makes them unique in the company.

Ledge: Is this an enduring phenomenon or is this sort of the five-year solution for… We know that all those things come together and there’s a missing connective tissue and today we’re going to call that DevRel. But, five years from now, does the… It’s almost like that level of empathy and organization needs to just percolate to all the other jobs.

So, is DevRel the temporary name and solution for what ought to have been a better, more authentic disposition for all those functions?

Mary: I love that question. I think there’s definitely a chance that it could be. I completely agree that it’s the connective tissue. It’s the department that can sit and listen in on a product and engineering launch meeting and go back to marketing and go, “Okay, cool. Here is how we should be positioning this, and here is what an effective way would be to talk to our community about this.” Or, “This is a breaking change and we’re the ones that are owning the communication between marketing and product and engineering to make sure it gets out to our audience the right way.

Ledge: Which used to be called crisis management and PR, and communications, and media. Marketing might be a little like, “Y’all, you’re taking our thunder here. This is what we do.”

In fact, I’ve talked to companies that have the community manager and the podcast kind of separate, but then, oh, we also have this DevRel thing, we really want to build a community around our API and we’re not sure how to do that.

I’m going, “That’s really interesting. I know a book you should read.” No.

Mary: Well, there’s also this idea of, these days marketing is largely lead generation. Those are the metrics that they’re judged on.

We almost need to go back to the original style of marketing, with mom and pop shops in the little tiny towns, where get to know everyone in the town. You accommodate people’s needs, and you listen to people’s problems, and you’re part therapist, and part coach, and part sales person. You work across the board to make sure that everyone’s needs are met, and because of that you are the general store in town and everyone comes to you for all of their needs.

There’s that aspect of it. Ultimately, and this is a conversation I’ve had with a few companies who say, “Is DevRel really necessary?”

I go, “You know what? If your product team is having regular meetings with your marketing team, and your marketing team has technically savvy people on it, and if your marketing team is working with your engineering team to run any of the marketing ads and things passed the eng team, to make sure that that’s a good fit for that audience – which happens to sit right next to you and you can run things past them – and they’re all working with sales to make sure that you’re selling to the right people and promoting to the right areas and all of these things, then maybe it’s not necessary. Especially if your engineering team is willing to be out and speaking, or writing blog posts and engaging with a technical audience.

There are very few companies that are, A, willing to do that, and, B, able to do that. That need for connective tissue is always going to be there and there’s going to be some companies that do it so well that you don’t need one point person to oversee that.

I think, without any sort of community management and without someone who has that community at the forefront of their mind at all times, there’s always a risk of the community not coming first and always a risk of missing voices or missing perspectives. Not being able to build as deep of a relationship that’s going to result in those connections that are made between community members as well as internally to your coworkers.

Ledge: This takes a really nuanced view of… It’s almost like, well, who gets the privilege to walk around the company and connect all the dots in a non-executive seat? Wait a second. This could have been Chief of Staff before. All of a sudden we are elevating a really ethereal thing to a great deal of authority and non-positional kind of power.

There’s a lot of stuff going on there. That you could tip off a political feeling of, “Well, that’s my job,” or, “That’s part of my… Why do you get to do that, and why do I not get to do that?”

I imagine you see some chilliness when you’re trying to figure these problems out. There’s a lot of territorial stuff.

Mary: Definitely. Definitely. And you said something interesting. You said, a non-positional place of power.

That’s one of the issues that I’ve been seeing more and more lately, is these community managers or developer advocates or head of developer relations or whatever the title is, they’re brought in in this ‘You’re the expert in the JAVA community’, ‘You’re the expert in the internet response community’, ‘You’re the DevOps expert.” Whatever community they are an expert in, they’re brought in with that level of, ‘you know this community better than anyone’, and yet they aren’t given a seat at the table. They aren’t given that power to really engage with the leadership.

So it does become this somewhat ethereal, “What are you doing, and why are you doing it, and why are you taking that work away from my team and that’s success away from my team?” because they aren’t given the power. They aren’t given the ability to do their jobs successfully. They aren’t set up for success within the company.

That’s been one of my big goals with my consulting firm, is figuring out, how do we set these teams up for success within the company? Part of it is giving them the proper titles.

I had a fascinating conversation a few months ago with a client who is looking to bring on a Head of Developer Relations. They would be reporting to a C-suite individual and they are fleshing out the rest of the company, and they had other VPs they would be peers with. Peer with VP of Engineering, a peer with VP of Product, and yet it was a Head of Developer Relations role.

I went back to them and I went, “’Well, so why is this only a ‘Head of’ role and not a VP role? Why the distinction in titles?” and the the answer was, “Well, because we don’t have a fully fleshed out team underneath them, and company policy is we have to have this many people reporting up to them.”

I went, “Okay. Great. But, A, those are your arbitrary roles that you’ve set in place and B, if you bring someone in and say you’re at a peer level with these other individuals but they’re not at a director level, they’re not a VP level, they’re only a ‘Head of’ level, then they aren’t going to have the authority to come into those same meetings and say, “We shouldn’t do this. That will be damaging to the community”, or, “If we move in this direction, that’s going to undermine the trust, the authenticity that my team has built up.”

It’s been interesting to watch as people go, “Oh, yeah. No, these people are experts. Bring them in and they should run the team, but we aren’t going to give them the same level of authority as everyone else has.”

It’s been a fascinating conversation to sit down and say, “Look. If you’re telling me that you really do value the community, and you value the voice of the community, and you recognize that the community is necessary for the success of your company, then put someone into a role where they have the power and the authority to impact that success. If you don’t, then you can’t expect to get the same types of returns that you’re looking for.”

Ledge: Well, there’s no organizational construct that would tell you what you just described in that role, what C level does it report to? It’s a combination of all those things.

That’s a lot of power to put under something, somewhere. It’s terrifying for someone to sort of go, “Well, I do that important slice, and I value that.” With any of this cross-functional, weird disaster on your org chart that has a bunch of dotted lines, and all this hybrid blah, blah, blah.

It’s an interesting thing. It reminds me of what happened to the CIO when the CMO and marketing toolsets got really, really powerful. It killed off the CIO, because that used to be their domain.

That’s what makes me wonder, what would future look like? You can’t end up with a Chief of Everything officer. That is interesting.

Also, I think traditionally speaking you would look at CEOs that rose out of the customer-focused functions would have overseen a thing like this. So then you’ve got a direct report all the way to the top. This is what VPs of special projects, and your Google ex’s and all kinds of stuff – “You don’t need to report to anybody. You can do what you want and here’s a blank check.” And nobody likes to not be that person.

So yeah, you’re up against some organizational stuff there.

Mary: It’s an evolution of the org structure. We don’t know what to do with them, so how do we figure this out? But if they are a three-person team that reports to a manager, who reports to a director, who reports to a VP, who reports to a C-suite folks, but you’re saying that community is a priority for the company but that community team is buried five people down, no one’s going to listen to them. They’re not going to be involved in the budget meetings. They’re not going to be involved in the strategy meetings. And so how does their…

Ledge: Who’s budget?

Mary: Exactly.

Ledge: Who’s budget are we under? That’s what it really comes down to, right? Well, three, four, five people who go and talk all the time? Who’s budget is that?

Mary: That’s actually a very good representation of how a lot of people see developer relations. Is, well, it’s just the people who go talk all the time, so what value does that give to the company?

This is one of the things that I’ve been working with a lot of companies on. Is, don’t focus on your work output, focus on the value that you’re contributing back. Make sure that you’re not only exhibiting, hey, we travelled this much in the last quarter.

Make sure you’re pointing out: We travelled, sure, but during that travel we met this many community members. We increased developer awareness by this much. We wrote these blog posts. We contributed this much direct traffic to the sites. We fixed these bugs or reported these bugs. We brought all of this feedback back.

Don’t focus on the things that are the most flashy, no matter how tempting that might be, because the CFO is going to look at that quarter report and go, “Great. We spent $200,000 shipping you all over the country or all over the world, what good did it do for us?”

Ledge: Right. You hit on the main thing, is the data tracking of these functions that are kind of on the edge of misunderstood areas, it’s the hardest data to track. It’s the reason nobody ever tracked the data in the first place, which resulted in these things not being managed, which resulted in there being a hole in what we were trying to fill with human effort and expertise.

But that still doesn’t solve the problem of, how do you manage the impact of a thing that we know is important but we can’t really smell it?

Mary: That’s part of the reason that I cover this. I have a whole chapter about metrics in the book. One of the bigger things that I really, really tell people to focus on is this concept of Libby boxes.

It’s basically just a flowchart structure to figure out, cool, here’s my overarching goal for this quarter. How do I break that down into, here’s my goal, here’s the generic ways I could possibly have impact toward that goal. Here’s a little bit more specific ways that I could have an impact on those fluid, ancillary things. Then here’s how I know whether or not I’m successful.

The nice thing about those four boxes is you can start at either side. If your CEO comes down and says, “Hey, this quarter your main goal is developer awareness,” you can go “Great.” Plug that into the upper right box, work our way down, figure out, we have to do increased developer awareness. Here is our specific work output that’s going to drive that goal forward.

Internally within your team, you talk about the work output all the time. As you’re working your way up through the company and talking to the different stakeholders, you don’t sit there and go, “Well, we increased developer awareness by speaking at eight conferences and attending six meetups and writing this many blog posts.”

You say, “Here’s the impact that we had. Here’s the conversations that we had. Here’s the observations we brought back. Here’s the feedback we provided internally. Here’s all the connections that we made from community members internally to the company.”

You phrase it and you have that storytelling ability to phrase it in a way that makes sense to stakeholders throughout the company. That helps them understand not only you’re doing your jobs and you’re doing a lot of work, but you’re doing work that is relevant and important and drives the company goals forward.

Likewise, if someone comes to your team and goes, “Great. This next quarter you have to attend six meetups a month,” and you go, “Well, why? What’s the point?”

I can just cherry pick six meetups, get them done in the next six business days – if you live in a place like San Francisco where there’s eight meetups a night, 12, 20. I don’t even know how many meetups a night – and pick random meetups, and attend all of them, and check that box and say, “Well I attended six meetups. Job done. I’m successful now.”

Or, you could sit there and go, “By attending meetups, what goal am I trying to achieve? Am I trying to increase developer awareness? Am I trying to get feedback on our new products? Am I trying to find community members who are super-passionate about this? To find influencers in these areas that we can connect with down the road?”

You can work your way backward through those boxes and then come up with an overarching goal. Then go back to your manager or the C-suite that dictated that metric down and go, “Hey, through attending these meetups, here’s the goal that we’re pushing forward.”

By being able to tell that story and frame it in a way that makes sense to other people throughout the company, you not only have a way to express and understand your own success to your team, but you also have a way to express it to the rest of the company. So that the CFO doesn’t look at your team at the end of the quarter and go, “All you did was travel. What’s the point?” And the board doesn’t look at your team and go, “All they did was travel. What’s the point? Your short on budget this next year? Cool. Let the DevRel team go. They aren’t contributing any real value.”

If you tell those stories, if you get those metrics to cross in a way that actually demonstrates the business value that you’re putting forth, then whoever’s at that board meeting can go, “No, no, no. Hang on. Yes, they spent that much money but they directly increased the awareness of the developer or the technical community that’s using us. They started some awesome conversations in the community that forced us to rethink how we are approaching this new feature and product. We now have beta testers who are excited about using our product and are now spreading the word on our behalf.”

There’s all of these things that you can go, “No, no, no. We’re not only spending money. Here’s all these various points of value that you get as a direct result of those conversations that we’re having, both in person as well as online.”

Ledge: It strikes me as a much higher burden on the performers of a job like this to make sure that you are communicating your value. That it isn’t just a thing that you can count.

Storytelling is exactly the right way to do it. The first thing that jumps in my head is, you better get a really good screen capture device because you are going to make sure that you grab that really qualitative, weird kind of conversation that you had deep in a Twitter DM that said, “Look, major influencer said a thing. You can’t get that without my work.”

Mary: Exactly. That’s one thing that I think so many people, and so many companies even, don’t understand. Is that, when I’m in the market to join a company full time, when you hire me you’re not only hiring me, you’re hiring my entire network.

The interesting balance is that I need to be able to continue growing my network and sometimes that’s going to mean, hey, I was invited to speak at this conference and maybe it doesn’t make sense from a company standpoint to sponsor it or for me to even attend, but if I attend this conference that’s a way for me to continue to network to spread the word about our product with this new group of people. Or even just continue to maintain my relationships with this older group of people, which may pay off in the long run.

It’s the idea of, ‘it may pay off in the long run’ that we have to counter with, ‘yes, there are things that are going to pay off in the long run.’

You, Ledge, as a result of talking to me, might, three jobs from now, decide to use this huge product. You now work at a huge enterprise company and you are the biggest sale of the quarter, and that started as a result of you and I getting to know each other on this podcast. But that might be three years down the road. Awesome.

Ledge: That’s brilliant. I’m going to do it. I’m going to do it.

You’re so right. It makes me wonder, is there a bias then in a DevRel or community building type of situation that you simply have to have people with more years of experience? You can’t come out in rookie zone and go, “I’m going to leverage my network that I don’t have?”

Mary: I think there can be part of that, but I would caution that people not only look to folks who have a huge network because we have to obviously be bringing in new folks. We need new people who can come in and keep doing this.

Part of the interesting thing is that, as you’re finding people who have those unicorn skills, if you will; who can write as well as speak, as well as code, or have a technical conversation. As you’re finding those people, those tend to be people who, maybe their network is small right now but they’re going to instinctively and intuitively be building that network as they’re travelling.

Maybe they just haven’t had the opportunity to do that yet. Maybe their community and their network is limited to one specific local area because that’s all they’ve been exposed to, but if you expose them to other areas they’ll have a network all over the world in a few years.

Ledge: You’re building the Instagram models of the future.

Mary: Yes.

Ledge: Burke Holland said that to me. That, DevRel is not just about being an Instagram model.

Mary: Exactly. I was going to say, nice callback.

It’s this idea of fostering those networks and looking for people who… I couldn’t care less if you’re a fantastic developer. I care far more about how your communication skills are. Whether you’re able to empathize with customers. Whether you’re able to be interested in topics enough to go research, “Hey, how does Jingo fit in with these new topics?” Or, “Where is the intersection of DevOps with APIs?”

Go tell me. Go do that research and be able to come back and tell me, hey, so I talked to these people and I learned these things and here’s how they connect, and there’s a fascinating Venn Diagram here, and we should focus on that section of people.

Ledge: That’s primary source research, which is very different than being able to sit there and kind of write a bunch of blog posts. “Because you wrote X, I need to talk to you about this thing that I actually care about. And what vehicle do you use to do that?”

That’s where I look at the podcast thing. Like, I could read your book, I could get your newsletter and all this stuff, but I want to ask you my questions and I want to ask you the questions that matter there and that’s that network thing. From each of us who’s interested in the particular little slice of the universe, we need to find the people that have something interesting to say about that slice that would never say that on their own. That’s that network connective tissue.

Alright. We could do this all day, and we’re way over what I normally do but when I get to nerding out with somebody I can appreciate, that’s what happens.

Mary: Awesome.

Ledge: Let me shift. This is how we finish up here. We have this lightening round. This is critically important stuff.

Mary: Okay. I’m geared up.

Ledge: Star Wars or Star Trek?

Mary: Star Wars, definitely. I do appreciate Star Trek, but if they’re up against each other Star Wars all the way.

Ledge: You would not believe how much people feel they need to qualify their answer to that question.

What are you reading right now?

Mary: I am reading a book that I thought I was going to have right here at hand, and I don’t. It’s an interactive book, actually. It’s basically tackling how to balance your work with personal passions. So your work passions with personal passions.

It’s an interactive guide, and what I mean by that is it’s almost a workbook of sorts. It helps you kind of figure out your balances and why it’s so difficult to balance those things.

It’s called How to Not Always Be Working. It’s by an author called Marlee Grace.

It’s this fascinating exercise in, what are you passionate about and how many of those passions are work related, and how many of those passions are personal related. There’s an overlap there, often.

I say this on my website, I am a community builder personally and professionally but that’s difficult when I’m building professional communities and that’s also where my personal friendships are. There’s a lot of overlap there where things intertwine. So being more intentional about separating those two.

Ledge: Good boundary setting. I love it.

Alright. What can you not live without?

Mary: Coffee? It’s interesting. It’s not even necessarily about the caffeine, it’s the idea of having a few minutes and having a routine in the morning to; I make my coffee, I sit down, I look at the news, I adjust to a new day. Having that hot cup of something. It could be tea, it could be coffee, it could be I don’t know what.

Ledge: Right. It’s the ritual. And those of us who are solo-remote types, it is that anchor to the old ‘stand around the coffee machine’. I completely relate to that as well.

What is the last thing you Googled for work? This should be easy for you. You spend half your day on Google for work.

Mary: I’m sure it did. How to do a DevRel or a conference. Is there a way to look up my Google search history? That’d be scary.

Ledge: You probably could but…

Mary: Probably something DevRel related.

Ledge: That’s the problem with all of us nerds. We’re just, “I don’t know. Let me check. I can log in right now.”

I don’t know if you’re fan of The Office.

Mary: I have seen a handful of episodes, yes.

Ledge: So you’re aware of Jim and Dwight. There is a classic episode where Jim is sending faxes to Dwight from future Dwight. He’s messing with him and he’s saying, “The coffee’s poisoned today,” or whatever. Dwight thinks he’s getting messages from future Dwight.

I like to ask people, if I gave you one sheet of paper and a big, thick Sharpie, you’ve got to write yourself a message – you are now future Mary – and you get to fax it back to yourself, what would you write on there?

Mary: This is a lesson that I’ve been learning this past year. Something along the lines of, “Done is better than perfect.” Or, and I have this hanging on my wall behind me, “Don’t go for perfection, go for better than before.”

This idea of, I was an A student in high school and had standards for myself. These days it’s difficult for me to sit there and say, “No. The blog post is good enough. I don’t need to stress about it for another three months. I can send it out as is, and I can always edit it down the road. But, done is better than perfect and it’s better than it was before.”

Ledge: Great answer. I love that. I like when people give me their reasons too. Sometimes people just say, “Yeah. Accept that job.” “You want to expound on that?”

Mary: I’m a storyteller. Sorry.

Ledge: Yeah, I know. I love to tell stories. Well, Mary, this has been so much fun.

Again, where do people find you? I’ve no doubt there are copious on our list here and on our distro that would benefit from your thoughts. Where do they find you to do that?

Mary: Awesome. Twitter is mary_grace. My DMs are open so you can reach me on there easily. My personal website with my blog is marygrace.community, or you can find my company website at persea-consulting.com.

Ledge: Awesome. It’s so good to have you on. Thank you for spending so much time.

Mary: Absolutely. Thanks, Ledge. I appreciate it.