Meet Matthew Groves

Tell me about your role at Couchbase

MG: I’ve been a Developer Advocate at Couchbase for almost three years.

In my time here, I’ve mostly been involved with creating content (blogs, videos, tutorials, samples, etc) and events. Our team goes to a variety of tech conferences as sponsors, speakers, or both.

At events, I will typically be at the Couchbase booth answering questions, running demos, and just talking to people about databases. Those are the two major areas, but I spend the balance of the time interacting with developers on Stack Overflow, the Couchbase forums, blog comments, chat rooms, social media, etc. I also spend as much time as possible trying to communicate the other way: curating feedback I get from the community and sharing that with leadership.

What brought you to this point in your career?

MG: You can blame it all on the first job I got working from home. At first, I was uncertain about working from home. I thought that if I didn’t take steps to make in-person connections, it would harm my long-term growth. Since I couldn’t always be with my coworkers in-person, I decided to get a lot more involved in my local developer user groups. That led to me speaking at user groups, which led to speaking at conferences, which led to helping to manage user groups and conferences, and so on. I also decided to write a tech book during this time, “AOP in .NET”, which led to me doing some “part time” developer relations work and creating my blog: Cross Cutting Concerns.

I was doing all this stuff on my own time and my own dime. Juggling a full-time job with traveling, speaking, and writing was very stressful, but I have a great family that supported me throughout. I started getting more confident at public speaking and I was learning a tremendous amount along the way. It occurred to me that a full-time developer advocate position would be something I would like, but over the years I wasn’t really able to find a company that I thought I would be a good fit at. At some point, through all the connections I had made on Twitter, I discovered that Couchbase was looking for a developer advocate with a Microsoft-oriented background.

How does dev rel work at Couchbase?

MG: 

Metrics:

I think the main focus of the developer advocacy team at Couchbase right now, and what I think all dev rel teams probably should be focused on, is adoption.

What activities can we do to help drive and increase adoption? We’re a very small (but growing) team, so we need to be especially careful with how we spend our time. Adoption metrics are going to vary widely from organization to organization.

In the past, we’ve looked at “crude” or “passive” (for lack of better words) metrics like number of downloads, number of page views, number of people who have come to the booth, etc. These are all valuable things to know, but I don’t think they really go deep enough.

We’re starting to look at more “active” metrics. How many people are asking (and answering) questions in the forums and Stack Overflow? How many actual nodes of Couchbase are installed and running? How many people are willing to complete an interactive demo at the booth?

Team:

Our team is small, but we divide responsibilities by a couple key factors.

Couchbase is a data platform that can be used by a variety of different tech roles: developers, operations, back-end, mobile, etc. So one factor is technology. We’re always trying to learn new stuff, but most of us have a “specialty”. Mine is Microsoft/.NET/Azure. I also tend to focus on Couchbase Server (as opposed to Couchbase Mobile, since I don’t have much experience as a mobile developer).

And finally, we try to divide up by geography. I live in Ohio, so I tend to focus on the right half of the United States. These aren’t hard and fast “territory” rules. Every once in a while, I’ll help out on the western half of the US, or I’ll help with Mobile, or I’ll write some Java or whatever.

Reporting:

At Couchbase, we technically report to engineering. However, we interact with marketing, sales, solution engineering, documentation, partners, support, and even recruiting. Any team that impacts adoption, we try to learn from and be helpful to.

What’s you dev rel philosophy?

MG: I believe that developer advocacy should be a two-way street. Yes, we are out there trying to increase awareness and increase adoption. But as adoption increases, it should also be our role to curate and funnel feedback from developers. We should be listening just as often as we’re speaking (and probably more so).

I believe that developer advocacy should work with a variety of departments within an organization. It’s often discussed which department that dev rel should belong to, or if it should be its own department. But a developer’s needs are complex. It’s not just about documentation, or SDK support, or where something is on a Gartner report. It’s about how can Couchbase solve problem X?

And with that in mind, I believe developer advocacy has to attempt to be as impartial as possible. This is where I believe most tension between developer relations and the rest of the company comes from. If a developer has problem X, and Couchbase is not a good fit (for whatever reason), a developer advocate has to say so. I think of the film Miracle on 34th Street where Macy’s started to advertise for their competitors if a customer came in asking for something that Macy’s didn’t have. This gives an advocate (and therefore, the organization) credibility.

Finally, I believe that any approach to dev rel has to understand that it’s a long game. It’s not something that can be effectively evaluated on a short-term basis. It’s a long-term investment in community and adoption. There is almost never a direct path from dev rel to sales. Dev rel is about adoption, community, credibility, awareness, feedback. Those things all eventually lead to sales, but it’s difficult to track directly and accurately, and developer advocacy is far from the only factor in that journey.

What do you see as the big challenges for dev rel right now?

MG: I think it’s important that dev rel has thoughtful, stated goals. It also needs buy-in from executives. Not just sign-off, but understanding.

Software development is one of the youngest professions in the world, and developer relations is even younger than that. And like software development, I believe that just about everyone is still trying to figure out how it works (along with “if it works” and “why it works”).

What are you hopeful about?

MG: I’m a pretty optimistic and hopeful guy about everything, despite being plugged in to the constant stream of sarcasm and antagonism on social media.

But from a dev rel point of view, I’m hopeful about community and open source.

There are huge swaths of developers that have little or no involvement with any technology community outside their own team. Scott Hanselman calls them the dark matter developers. However, as large companies really start to embrace open source (as we’re seeing Microsoft actually setting a pretty good example of), I believe that will motivate these developers to take steps into the community, even if they are tiny, in order to differentiate themselves and continue to stay relevant.

It’s tough to keep up, it’s tough not to give up, and some days I fantasize about dropping out of technology and opening a cookie store. Sometimes being a developer advocate seems like “2 steps forward, 3 steps back”, but I choose to remain hopeful that the ratio of steps will change, even if it’s only by a small fraction.