Patrick McFadin

Introducing Patrick McFadin

Patrick McFadin is the vice president of developer relations at DataStax and is devoted to making users of DataStax and Apache Cassandra as successful as possible and improving their experience as developers. Previously, he served as a chief evangelist for Apache Cassandra and was one of the leading experts in Apache Cassandra and data modeling techniques. Patrick has been fortunate enough to help with building some of the largest deployments in the world and he publicly speaks about the design of highly available distributed systems. Find Patrick on Twitter: @PatrickMcFadin.

Geertjan Wielenga: Would it be true to say that this whole profession is fairly new?

Patrick McFadin: As a job description, it's fairly new. If you go back to the early days of software, Apple employed evangelists in the '80s to help to build its developer ecosystem. That was a formal job, but it was more of an engineering advocacy role at the time.

If you look at the history of software, developer advocacy has been going on for a lot longer than many people realize. There might not have been an established job field, but there was somebody working at Apple, for example, who spent time with developers at conferences. Microsoft had a similar person. In the '80s, there was a small group of people doing advocacy, it just wasn't a really big field.

The growth of developer advocacy

Geertjan Wielenga: Over the last five years, developer relations has even become a service: you can hire a company to come in and set up a program for you. What has led to this progression?

Patrick McFadin: I think it's just a maturing of our industry and more companies understanding how much developers make a difference. Developer advocacy has grown so much in recent years because software is eating the world.

The dynamics of how we consume and buy software have changed. Open source, I would say, is to blame for that. Previously, when you bought software it was the most expensive part of your IT budget; now it's not. There's been such an explosion of options. Companies are fighting to get noticed and they're going to employ any strategies they can to make that happen.

"Businesses are starting to realize that developer relations is a significant way to get market share."

—Patrick McFadin

With marketing, you used to buy a full-page advert in a magazine to get your message out. You could go to a conference and have a big booth. By doing that, everyone would know your company. Nowadays, there's zero marketing budget for some of these small projects. If you have an open-source project that grows into a company, who's going to get people to use the software? Businesses are starting to realize that developer relations is a significant way to get market share.

Compared to marketing, there's a different voice needed when you're talking to developers. There's this old adage that developers are allergic to marketing. That's not entirely true, but you get great results from developer-to-developer discussions. Companies have to understand that flashy adverts or balloons flying in the sky alone aren't going to get them into a market; the key is knowledge transfer.

Geertjan Wielenga: Does being called a "tech evangelist" versus a "developer advocate" make any difference?

Patrick McFadin: That's actually only a recent debate. I started the evangelist program at DataStax about five or six years ago. "Evangelist" was the term that made the most sense at the time. We've since decided to use the term "developer advocate."

To my mind, evangelists are more about promotion and doing a lot of conference talks, whereas advocates spend time with the product and the engineering team, while also spending time with users and customers. Developer advocates not only advocate for the company, but they also advocate for the developers themselves. We switched the name for our team because "developer advocate" is a better description of what they do. I would hope that anyone who talks to a developer advocate at DataStax feels that they have a direct connection to our engineering team.

Geertjan Wielenga: What kind of personality is needed to be successful in this role?

Patrick McFadin: I've hired many advocates in my time and all types of people fit, but I think being a natural learner and explorer is important.

You need to be someone who wants to push the boundaries a little bit and you need to be excited about sharing your learnings.

Developer advocacy is not a desk role; you don't sit in a cubicle and write code all day. If you're not okay with getting out there and talking to people, you'll be really miserable. I've hired developer advocates who just wanted to spend time working with the code. That's straight engineering, so developer advocacy didn't work out for them.

Geertjan Wielenga: Isn't it true to say, though, that not every developer advocate needs to be out there doing public speaking at conferences? In some companies, there's also a need for blogging, research, creating samples, and so on.

Patrick McFadin: That's a great point. Recently, it seems that there's as much of a need for the online component as the in-person component, but creating connections with people is critical.

Geertjan Wielenga: How many people are there in your team of developer advocates?

Patrick McFadin: We have six developer advocates right now at DataStax. I'm sure that the team is not going to stop growing. We're always adding developer advocates because the plan is to put them closer to where people are.

I don't want to have a team of developer advocates in San Francisco serving India or Asia. People should be strategically placed so that they don't have to spend their lives on airplanes. Every region in the world has different needs, requirements, norms, and conferences. I also wouldn't want to have a purely online team; I think that would be really plastic.

Geertjan Wielenga: Are these developer advocates all doing the same type of work for your company?

Patrick McFadin: Mostly, but the key is that everyone is different and everyone has their own way of doing what they do. There's a requirement for speaking publicly and for working online, as we discussed. Those percentages are different for each person.

I stress this often: developer advocates need to build their personal brands. When I'm talking to my team, I always say, "Your personal brand and trust relationships are what we're building here. Don't worry about creating DataStax branding; we have people for that. You need to be the brand with your voice." If I needed someone to be Mr. or Ms. DataStax, I'd be looking for a product marketing person, which is a different role. I need someone who can bring their personality because it's a trust relationship that we're building with developers.

Geertjan Wielenga: Should a developer advocate ideally be someone who is seen as being more or less independent of their company through having a personal brand?

Building a personal brand

Patrick McFadin: Yes, not compromising on your personal brand is really critical. You don't have to be exactly following the party line, although that can lead to some conflict. Be true to yourself; if you don't want to talk about something, pick something different. There are plenty of choices.

Geertjan Wielenga: What's your personal brand?

Patrick McFadin: At this moment in time, my personal brand is just being a large-scale application person. Most of what I do is around data modeling. I'm known for data models and deploying Cassandra, but my brand is around building applications in general.

That has worked out really well because when developers walk up to me, they already know who I am. I don't know them, but they can immediately say, "Hey, I really want to deploy this application and here are some of the parameters. Can you help me to look at this?"

Geertjan Wielenga: What are the personal brands of the other people on your team?

Patrick McFadin: There are several different directions that people take. For instance, we have one person on our team who's just an amazing networker and they have a brand around DevOps. They're at conferences all the time.

We have another person who's very focused on frontend development and women-in-tech issues. They have a very strong voice and participate in outside groups. We then have some people who are well-respected for their enterprise software chops. They're known for being people you could trust to know about enterprise architectures.

You don't always have to be known for something cutting edge. It could be that you've been doing something for a long time and you know what you're doing. You just have to have a voice.

Geertjan Wielenga: This voice doesn't have to be 100% aligned with the company, then?

Patrick McFadin: That's a dangerous conversation to get into, but this is what I worry about: if company dogma says, "We need you to talk about X, Y, and Z; if you don't do that then you're wrong," that's not letting people find their path.

An example would be that, at DataStax, we sell tech in and around Apache Cassandra, but if a developer advocate wants to spend some time researching something else, within reason they can go down that path. Sometimes that turns into a product direction over time.

A specific example is that our advocacy team led the charge in Docker and Kubernetes. Before the rest of the company was ready to do that, we were already there. That direction could have been a dead end, but it wasn't.

"Embrace the crazy for a little bit and let your team be natural explorers."

—Patrick McFadin

You just have to embrace the crazy for a little bit and let your team be natural explorers. They may find a dead end or they may find something interesting. My only guidance is to make sure that what you're doing is adjacent to the company somehow. I don't want my team to go out and build a self-driving car, for example, because that's not what we're about.

Geertjan Wielenga: What can happen is that the company that you're working for takes a direction that conflicts with your own vision and/or with what you know the community is focused on. What would your advice be in that situation?

Patrick McFadin: Don't compromise yourself. If you really feel strongly about something, there are plenty of other jobs out there. I would never recommend that anyone just sucks it up and deals with something that they don't support. That's generally good advice for anyone who works for a company. If you don't believe in what the company is doing and you can't find a way around that, then you should leave.

If you just do whatever the company says with no conviction, then you're a mercenary at that point. Advocates should believe in what they do; I think that's so critical. If you don't believe in what you're doing, that's going to just start eroding your credibility. I've had discussions with advocates in my team who started changing their tune. I've asked, "Is this the right place for you right now?"

With every advocate I hire, I say, "You have an expiration date. We just don't know when that is." Developer advocacy is likely not a permanent position for the rest of their life. They will eventually have this moment where they realize they can't do it anymore. Maybe that will happen because they just want to get back to pure engineering. Maybe they will decide that they can't spend that much time on the road anymore. Maybe, as a result of the company naturally going through change, they just won't feel the passion anymore.

I'm not going to try to push someone up a hill. Passionate people, just by nature, can't pull passion out of thin air. I just don't see how that could ever work.

Geertjan Wielenga: You could have a really passionate developer advocate who sees things going the wrong way within their company and thinks, "I'm going to go along with it. In principle, I could quit right now because I don't agree with this, but maybe in six months or a year, things will have changed again. I'm going to stick it out for the interim." Is that a good plan?

Patrick McFadin: In that case, you could use your voice to advocate for going in another direction. I can't tell you that everything that DataStax has done has been awesome. I have had moments when I've said that we shouldn't go in a certain direction.

"You don't need to rage-quit your job."

—Patrick McFadin

When you get enough respect in your company, you're seen as being pure in your ideals. You don't need to rage-quit your job. You can say, "I believe our community of users will be negatively affected by this. I'm now going to advocate for all of them." Often, the company will make some changes because it didn't think about these roadblocks initially. When I see other companies making weird changes, I always wonder whether anyone actually said anything about that.

Geertjan Wielenga: What would you say are some of the disadvantages of the life of a developer advocate?

Patrick McFadin: There's a high likelihood of burnout. I try to live a healthy, balanced lifestyle and I really pay attention to burnout because I've burned out before. I've been an engineer for a long time; I get it. You don't see the warning signs until it's too late.

Geertjan Wielenga: What happens when you reach the burnout stage?

Patrick McFadin: You're done; it's an abyss that you can't escape from. Going on a quick vacation won't help because burnout really does ruin you in a lot of ways. The worst kind of burnout means that you need a career change and that's unfortunate.

When you hire a developer advocate, you're usually taking an engineer out of their natural habitat. When you do that, you put the engineer into an environment that they weren't originally planning on being in. That can be a risk.

Sometimes, what leads to burnout is getting too excited; for example, many new people get excited about going to all these conferences. By about the 10th conference, they're pretty sick of living out of a suitcase or just the continuous nature of the travel. I've done two weeks solid on the road bouncing through Europe to go to different events. By the time I got back to San Francisco, I didn't want to see another human, let alone talk to one.

Geertjan Wielenga: Developer advocates tend to be very passionate about what they do. We can work 24 hours a day and still have other things that we want to do. The problem is that if you're working from home, no one prompts you to take a break. How do you encourage finding a balance?

Patrick McFadin: My advice is always to block out a day on the calendar, put Slack into sleep mode, and take naps. I tell my team not to feel bad if it's only the afternoon and they need to take a nap. I'm not worried about my team using that as an excuse to not work; I'm worried about the opposite.

If I don't step in sometimes, I'm effectively helping my developer advocates to throttle themselves. This is a wonderful job; everybody that I've hired for developer advocacy says, "This is my dream job. I can't believe this exists." Then they are at risk for burnout.

Geertjan Wielenga: How did you get into this role yourself? What's your background?

Patrick's route to developer advocacy

Patrick McFadin: This career is not what I was originally planning. I have a degree in computer engineering and distributed computing. I'm classically trained as an engineer. I worked in the dot-com industry in the '90s and had a lot of fun. I made good money, but when the dot-com boom ended in the '00s, I got involved in large-scale infrastructure. I loved it.

I had my own consulting company for a long time until I sold that to another company. I ran an infrastructure team and in 2011, I started using Cassandra quite a bit for problems that I was having. I thought, "This is a really great database that no one knows about."

A friend of mine started a company called Riptano, which eventually changed its name to DataStax. He kept trying to get me to join the team. Finally, I acquiesced. I was about employee number 50. When you're in a small start-up, everybody has about 10 unofficial jobs.

I was mostly working as a consultant. I was traveling around helping people to do large-scale Cassandra projects. It was fun, but along the way, I started doing meetups and webinars. I became known for that.

Eventually, our CEO, Billy Bosworth, called me into his office and said, "I think that there's a good reason for you to just do this work full-time." For him to believe in me and pull me out of my field was a significant thing. I was given a budget to hire people and I was told to go out and do nothing but grow the Cassandra community.

I asked, "Is that a job?" But in fact, I believed in what the CEO was saying; I believed that this would be really good for the company and for Cassandra. At the time, the title I was given was "chief evangelist." Everyone said Steve Jobs was the chief evangelist for Apple, so I said, "Okay, I'll take that job!"

That's what got me into this role. This is a nice part of my career. I've spent 20 years building and doing things. Now, as I'm getting older, I can talk to the younger people who are coming in.

This is my personal journey. I'm almost paying back into the community that I learned from. After all, this is the most important job field in the 21st century.

Geertjan Wielenga: Why is this the most important job field?

Patrick McFadin: Because software is everything. It's also the biggest immigrant story that there is. I'm obviously a descendant of immigrants to the U.S. My wife is a first-generation American. Immigrants came to this country for a reason. My ancestors came to this country because they were looking for a better life and the same thing is true right now with software. The top three professions for green cards in the U.S. are all software positions.

"Software is building the future."

—Patrick McFadin

People are leaving their towns and their villages. They're coming to the U.S. from all over to do one thing: build software. It's exciting because people are making better lives for themselves. Their kids will have better lives because these people have chosen to go in this direction. Software is building the future.

Geertjan Wielenga: Where does the developer advocate role fit into this vision of software that you're talking about?

Patrick McFadin: Almost everyone in software is probably stressed out. They're behind schedule.

They have a boss somewhere telling them to go faster, make things happen, and not make any mistakes. There's a stress level built into this system right now.

Developer advocates are a friendly face. Support teams are great, but a developer advocate is the helpful face when you go to a conference. I know that look: someone with their laptop open looks at you and asks, "Can you help me?" That is a wonderful moment right there. That person realizes that they're not going to lose their job. Their kids are going to be okay. Just being a helper is such an important part of the tech world.

Geertjan Wielenga: What topics do you cover at conferences?

Patrick McFadin: The last talk I did was about the importance of the developer experience. That's a really critical part of a product, especially an infrastructure product. It doesn't have to be ridiculously hard to use a product. Developer advocates are at the cutting edge of delivering that message.

Geertjan Wielenga: What are some aspects of making a product easy to use?

Patrick McFadin: Everything from having great documentation and examples to providing a smooth path. How do you install the product and what's the user experience like? It's also important to have a strong community around a product.

Geertjan Wielenga: When you go to a conference as an attendee, rather than as a speaker, do you look first at who the speakers are? Which topics do you find inspiring?

Patrick McFadin: Sometimes it's the speakers who draw me to a conference. There's always someone who can make a topic interesting. I also look for names I know, but I think the topic is probably more important to me.

Knative is an example. It's a new Kubernetes project and at a recent conference there were people I'd never heard of talking about it. You should look for keywords that pop up in a conference. This is a good time for me to mention that you should always pay attention to the title of your talk because that's normally all that people read!

Geertjan Wielenga: What are some good titles that you would recommend?

Patrick McFadin: I wouldn't recommend a particular formula beyond making sure that people know what you're talking about in the title. If you're talking about Kubernetes, put that in the title. If you're talking about Cassandra, put that in the title. If you're at a Cassandra conference, you may get away with less, but you still need to be specific. If you have a title such as "The Glorious Ending to my Unicorn Lifestyle," people won't know what that is. I've seen fun titles, but speakers often end up having too much fun. If you're not a big-name speaker, don't get too fancy.

Geertjan Wielenga: What's the atmosphere like at conferences that are specifically for developer advocates?

Patrick McFadin: Along with the developer advocates attending, there's also a mix of marketing people. Many people are just there because they're trying to figure out the role itself.

It does seem a little chaotic, but the major theme is people asking, "How do I convince my company that this role is valid?"

Proving your worth

Geertjan Wielenga: This is the standard problem. How do you prove to upper management that you're not a cost center or that the cost center is justified?

Patrick McFadin: I've talked about this at conferences before. The pitfall in developer relations is that we get sucked into the same kind of measurement statistics that marketing does. We start to focus on qualified leads and key performance indicators (KPIs). We start trying to calculate how many people we've talked to. That's the wrong approach; we already have a marketing department for that.

Developer relations is about awareness and the developer experience. How do you measure that? It's very difficult convincing a business that you should be measured much more like an engineering team and much less like a marketing team. What's the return on investment (ROI) on a developer building code? Give me the metrics that show the ROI. They don't exist. We hire developers to work toward an overarching goal. We set that goal and we say, "Go and do that thing."

"Businesses now understand how success for developer relations is measured."

—Patrick McFadin

I think a change that is happening in developer relations is that businesses now understand how success for developer relations is measured. What I do for my team is set goals such as making inroads into a community. I can go back and report to my executive team, saying, "Here's what we tried to do. We wanted to be a larger voice in Kubernetes. Here's some stuff that we've done and look at the effect: we're being invited to these Kubernetes conferences."

From an awareness standpoint, that's really good. You've got to have people who believe in that approach. You can't have an executive team that replies, "No, we want marketing leads from you." In that case, they should go and hire more marketing people!

Geertjan Wielenga: Do have any KPIs with numbers, such as the number of conferences to attend per year?

Patrick McFadin: Yes, I want every developer advocate to try to get at least two speaking positions per quarter, but it's not the end of the world if they can't achieve that. It's not like you can magically get your name into a conference. I try not to put many numbers into our goals because when you add a number, that's all that people focus on.

Geertjan Wielenga: Are you still traveling a lot or do the developer advocates in your team do that now?

Patrick McFadin: I thought I wouldn't be traveling as much, but I end up doing it anyway. Travel is just in my DNA now.

I still really love meeting our developers and I can't stop doing that. I could never be relegated to a desk and be okay with that. I'm not as much of a road warrior as some of our younger advocates, who are out there all the time, but I make it a point to attend at least one event every month.

Geertjan Wielenga: If you could change one thing about your professional life, what would it be?

Patrick McFadin: I would like more acknowledgment in the tech industry that developer advocacy is a really critical role. DataStax is a full believer in developer advocacy, so I have no problems there. I'm very proud of our work, but I wish developer advocacy was more accepted and formalized in our industry as a whole.

When we start seeing senior executive roles related to developer advocacy, that's when we'll know that developer advocacy has arrived. If there was a chief advocacy officer, developer advocacy would then be on the same level as sales and marketing. That's the dream.

Geertjan Wielenga: Is a developer advocate within an organization doomed to be that forever? Is there a route into different positions?

Career development

Patrick McFadin: There aren't many options at the moment. In the industry, we're having discussions about what the path should be for individual contributors. Do we send them down a management path or an executive track?

If you're just starting out in developer advocacy, you can move up into more senior roles where you're managing groups of advocates, doing more substantial projects, and creating programs. Many people end up moving out of developer advocacy into pure engineering. I think there are many distinguished engineers who it could easily be said are developer advocates.

Geertjan Wielenga: How do you stay updated on the latest tech developments?

Patrick McFadin: Twitter is always a good channel. I have a pretty healthy diet of online sources, including TechCrunch and Hacker News. Hacker News is the bleeding edge of the bleeding edge. I just see what people are talking about, along with going to conferences and meetups. It's about paying attention and talking to other developers.

Geertjan Wielenga: What are you most passionate about at the moment in the tech industry in general?

Patrick McFadin: For me, it's the impact of what the cloud is doing to this entire industry. I think people are missing how disruptive it is and what it's doing to open-source projects, along with the changes we're seeing to how developers get their work done and how we do business internationally. The cloud came on fast and we can't measure its impact just yet. I'm very interested in the topic because it reminds me of when we went from proprietary software to open-source software. The cloud will have the same level of impact.

Geertjan Wielenga: Thank you, Patrick McFadin.