The advocacy versus evangelism debate

Scott Davis: We could spend our entire conversation simply unpacking the politics behind those two phrases. I prefer "advocacy" over "evangelism" because it implies a more measured, thoughtful, and nuanced discussion. But I can appreciate the passion behind evangelism, and my speaking style has been compared favorably to a "pastor in the pulpit" more than once.

For most of my professional career, as an author, teacher, and speaker at software conferences, I've tried to focus on advocating free and open-source tech.

I like lending my voice and passion to projects that may not have large corporations behind them.

Geertjan Wielenga: But wouldn't you say that in the term "evangelism" there is something about enthusiasm that "advocacy" might be missing?

Scott Davis: Since I'm not being paid by a corporation to talk about its products, I definitely have an honest, heartfelt fire in the belly for what I choose to talk about.

The first time I spoke at the Great Indian Developer Summit in Bangalore, India, one of the attendees went up to the conference organizer after my talk and said, "I don't remember his name, but be sure to invite back the speaker who has hair like a lion!" I love that! Admittedly, I do roar about standards-based development and open-source solutions quite a bit; it's an apt comparison.

On a related note, it's interesting that what works well on stage (having an outsized personality and a booming speaking voice) works less well for pair programming. You don't want someone who is boisterous and loud as a partner; you want the power dynamic to be far more balanced. Ideally, you want to pair up with someone who listens more than they talk.

Geertjan Wielenga: Would you consider the term "spin doctor" to be applicable to you at all?

Scott Davis: We're really drawing a fine line here. I think developers, generally speaking, tend to be averse to that kind of marketing spiel. "Marketecture" is the unflattering portmanteau of "marketing" and "architecture" that we use to describe disingenuous tech solutions.

We've all heard stories about key architectural decisions being made between a sales rep and a vice president or chief technology officer (CTO), out on the golf course. True or not, when a tech stack isn't the right solution for the problem at hand, it simply doesn't smell right, and no amount of persuasion will convince you otherwise. It's not the job of the sales rep to point out a product's shortcomings.

I think that, for developers, authenticity is really crucial to the message. I'm a long-time Apple fan, but I'm not an apologist. There was a recent scandal where Apple was accused of intentionally slowing down older legacy phones. The technologist in me can say, "Oh, so Apple is slowing down phones to protect against aging battery issues? That sounds plausible." The suspicious skeptic in me says, "No, Apple is slowing down older phones to make the latest model seem more appealing." The truth is probably some combination of the two, but once you lose that authenticity, it's really hard to win it back.

Geertjan Wielenga: Have you ever actually worked for a company and promoted its tech?

Scott Davis: I haven't. I've interviewed a number of times with a number of different companies for roles like that. I've had lots of opportunities to be a "product evangelist," to use that phrase.

One of the things I bring up in those interviews is "hey, are you okay with me saying good things about the competition? Are you okay with me talking about rough spots in our API or our product?" I think those questions are crucial to my credibility as an advocate.

Mostly, the response is "are you kidding me? No, you can't say nice things about the competition! No, you can't point out the shortcomings of our product!"

Not being able to speak honestly about a product would mean that I was failing as an advocate. Here's a hypothetical example: if I was a product evangelist for MongoDB, I would want to be able to say, "I really like MongoDB. I've been through the training. The software is good. It has great professional services and support, but it's purely a server-side solution. There isn't a solution if I want to keep some or all of the data local, like in a browser, or if I want to synchronize between multiple instances. It doesn't seem to have an "offline" story. In that case, I'd look to something like PouchDB or CouchDB. Now, if you don't need local synchronization, then MongoDB is a solid option. Let me show you some of the cool things it can do."

That, to me, doesn't feel like I'm being hard on MongoDB. I mean, if it's a feature that the software simply doesn't have, I feel it's important to address it and offer alternatives.

Geertjan Wielenga: What would you say are the advantages or disadvantages of being a developer advocate working for a company versus working for yourself?

Scott Davis: I ran ThirstyHead—my own software consultancy—for a decade before joining ThoughtWorks. What I enjoyed about working for myself was the freedom to talk authentically about the tech that was really exciting to me.

Thankfully, ThoughtWorks encourages me to continue talking about what I'm most passionate about. It doesn't exert any editorial control at all over what I say on stage or in my writing.

The upsides to working for a large organization in a product advocacy role are that you get a steady paycheck and deep insider knowledge. You can talk about the cool, new, upcoming features that no one else knows about.

Geertjan Wielenga: How did this all begin for you? If you go right back to the very beginning, was there anything in your family life or in your past that led you to where you are now?