Link: What is Developer Advocacy?

“Developer Advocacy has many names. You may have heard it referred to as Developer Relations or Evangelism, and while these roles vary company to company, we all essentially do the same thing — We represent software developers. I like to say that it’s my job to ask dumb questions so you don’t have to, but the real goal of a Developer Advocate is to become the voice of the user. We gather feedback in a way that most developers don’t, then use that feedback to shape the product to become what it needs to be.”
Original source: What is Developer Advocacy?

Developer Relations: More than Traveling the World and Buying People Beer

Some tactical advice, with some small survey figures:

It was a small survey of 79 people, which isn’t particularly surprising since there aren’t that many developer relations roles. Some of the top skills needed to be successful in developer relations include communication, technical, and empathy. They also travel to a lot of events, 50 percent attend more than 15 events per year and 55 percent of them plan to attend even more next year.

Events, direct one-to-one communications, content marketing, and social media are seen as the most effective channels for developer outreach. Developer relations is a fairly new field. Almost 50 percent of developer relations programs where these people work are 2-4 years old and just over 25 percent were less than a year old, which is similar to the experience of developer relations professionals with just under 45 percent of them in the field for 2-4 years. There are also a lot of lone wolves with 30 percent of people surveyed being the only person in their company doing developer relations, and just over 30 percent have teams of 2-5 people.

Link

Link: Don’t make the mistake of thinking the CIO is irrelevant – TechRepublic

“The world isn’t about to end, however. Yes, Forrester reveals in its “Understanding Shifting Technology Acquisition Patterns” research note that lines of business are taking on a greater role in technology purchasing, removing IT from the purchasing process in 6.3% of new technology purchases in 2013, rising to 7.2% in 2015, while IT-only purchases will fall from 23.7% (2013) to 21.6% (2015).”

From 2014.

Source: Don’t make the mistake of thinking the CIO is irrelevant – TechRepublic

Who run IT-town? Ops or Dev?

At container-oriented conferences, whenever a vendor or an open source contributor demonstrates the ease with which developers deploy containers to production, usually there are cheers. But in large enterprises, especially those that maintain strict compliance guidelines, it’s IT that makes the decisions about what gets moved from development to production, and how it is done.

This is what you might call the anti-RedMonk stance. In reality, nothing is as cut and dry as developers XOR operators being king. I’ve been in many strategy discussions over the past 5 years where the people involved would love for just one of them to be rulers of the roost. It’s make setting strategy so much easier than catering to both.

In my experience, it’s more like this: developers have a tremendous amount of influence and devilish-steering over long-term IT department purchases, while IT people control the gates and money.

  • Developers can also just subvert IT and totally ignore them. You get speed and flexiblity, but the trade-off is inefficiencies in the long-term: everyone is doing something slightly different so there’s no economies of scale with respect to knowledge, culture, or costs. (There’s a loop-hole where you all decide, for example, to run on AWS and “bottoms-up” decide to start collaborating and “work together” and all that – I’m not sure that pans out in donkey-land without a lot of centralized change management, though see below on DevOps.)
  • Operators can set orginization wide standards but have to “force” developers to follow their dictates. So, if you want orginization-wide standardization and “someone else” to pay the bill and help run it, you have to go through IT. Here, you have ultimate control and “governance”, but you sacrifice flexiblity and speed. (There’s a loop-hole here where IT establishes a centralized “cloud platform” [to use my work’s parlance] and lets the developers do whatever they want in the confines/contract on that box/platform.)

Of course, many of us have been trying to reuinite this “house divided” for several years, cf. DevOps. Hopefully that’ll pan out because what we really need are both those functions working together to not build boxes or subvert corporate best practices, but to focus on building good products and IT services. Good luck!

Selling to Hoodie and the Sticker-Festooned – Building a Developer Relations Program to Win Over Developers as Paying Customers

I’m just about the give a short presentation on developer relations and marketing at our HCTS conference. For those who didn’t make it, here’re the slides and the “script” I typed out. As you may recall, I wrote a large report on this topic published back in August. It’s been fun talking with people about over recent months.

I often type out a “script” for presentations, not something I actually read, but just something to figure out what to say. Here’s the script for this one:

HCTS Developers

Hello, I head up the infrastructure software team at 451. Part of that is focusing on software development, developers. Back when I did real work, I was a programmer for a decade, so to me, the old saw applies: the answer is developers, what was the question?

Slide 2

More seriously, if you study the IT industry as I do, you notice a common trend: developers seem to gravitate around successful vendors and platforms. Sure, there’s a chicken and egg, cause/coorelation issue, but if we look at some big names, it’s obvious that having the good graces and favors of developers is key to making money in for many technology companies.

In the 90s and 2000s, Microsoft’s was a developer powerhouse, and still is, with countless applications written on its platforms. AWS rose to prominence rapidly from nowhere largely fueled by developers desire to run application on their platform. Similarly, Softlayer (now owned by IBM), expertly targeted developers as a core constituency. And, of course, there’s Apple, which is really cheating as an analyst to use as proof of anything.

We’ll get to some lesser known examples, but the message here is clear: developers matter a lot in the technology world and learning how to “market” to them is key for many vendors in this space. That’s what this talk is about: how to market to developers.

Slide 3

Now, as much as I like to be hyperbolic and categorical, not all technology companies need to worry too much about developers. Aside from the obvious cases – you’re selling middleware, IaaS, or PaaS – there’s an interesting heuristic to use to figure out if developers matter to you. As this timeline from Geva Perry shows, the role of developers in IT buying has been enabled by friction removal in the IT procurement cycle. If I have to go through months of fancy steak dinners and procurement paperwork, developers will have less of a role. If I can just download a database, install it in the public cloud, and go, there’s virtually no friction…and developers will more and more be the primary movers for IT procurement decisions.

Again, metered IaaS is an obvious match, and PaaS, of course. Look at your go-to-market – really map out each step it takes from concept to quote to cash – and see how much friction there is. The less friction, the more likely developers will be an important constituency.

Slide 4

Here’s two examples of that Heuristic at work: DigitalOcean and Atlassian.

DigitalOcean is one of the handful of SSD-fueled cloud providers out there that developers are flocking to. They do excellent product and developer marketing. Just like there’s less friction when you remove spinning dishes, the IaaS nature of getting to a blinking cursor in minutes to near frictionless. Developers love the easy performance boost SSD brings and the love how easy it is to sign up. As our recent reports on them show, this has resulted in 30% m/m growth and rocketed DigitialOcean to the 5th largest hosting company in the world according to Netcraft.

Atlassian is another example. They’ve been at it for years, putting out developer tools (requirements tracking, version control, etc.). They’re famous for having “no sales” and instead have removed so much friction from their GTM that developers can easily get their tools. And the tools are good. As you can see, Atlassian has been able to grow revenue from $59m in 2010 to $149m in 2013. That’s amazing consider that, you know, “developers don’t pay for anything.”

Both of these companies are good at developer relations and marketing and have harnessed developers to grow revenue. Let’s look at some highlights from my recent report going over tactics.

Slide 5

First, let’s define the goal of developer relations and marketing. I borrow this idea from several folks in the field, and it’s that you want to establish your technology as the de facto standard. Think Windows, HTML, Linux, the LAMP stack, the iPhone. Each of these became one of the top short-list choices for developers. Not all of them were “industry standads,” or even the #1 in the market, but they became de factor standards.

The result is that developers do all these activities in my Smart Art here:

  • they consider using your technology
  • they try it out
  • if they like it, they word of mouth it
  • they’ll purchase it (if it’s available to buy)
  • and they’ll use it

This is pretty classic stuff, but the point is focus your goals around establishing your technology as the de facto standard. You can do other things, but it’ll be more difficult: you’ll have to convince people that your “exotic” thing is needed, like high-end Unix boxes vs. Linux and Windows.

Slide 6:

How do you do this? A lot of hard work and time. Really. There are no simple solutions. As analysts marketers ask us for the quick wins a lot – esp. towards the end of the quarter and year ;)

To give you a sense of what a developer marketing program will look like, here’s some examples.

  • You’ll do classic things like advertising

  • You’ll provide white-paper level research to help developer understand and evaluate your offering

  • Training is a large part of developer relations, and also a revenue opportunity: you’re indoctrinating people

  • You’ll also need to understand developers needs. Right now, that has a lot to do with APIs and documentation for how to use them. APIs are becoming the de facto standard for how developers interact with platforms, and you’d better figure out your plan there. You’d think docs were obvious, but it’s shocking how often vendors miss this.

  • At the code level, developer marketing is also often done in code. I call that “code as marketing.” You might source extenstion, do some biz-dev to get others to do it, or lucky enough that your community can do so.

  • And there’s lots of publishing. Lots. The Internet is the primary channel to reach developers and stuffing that channel is all about content.

Staffing wise, this could be a partially dedicated person, but pretty quickly you’ll want someone fully dedicated who can keep all the threads going in their head. Also, they’ll start to establish a personal brand, credibility in the space. Developers actually like people, just developer-y people.

The team can obviously grow. SAP’s team is massive, and it has massive effect.

Slide 7

So, you’ve got a notion for what it looks like. How do you plan what to do?

Don’t just throw up a blog an start typing. Take some time to plan. Get some ice-tea and patinad table like these hipsters here and establish goals.

And don’t forget that you’re doing this for business reasons. Talk with sales to find out how you can help them with deal flow and closing. Talk with product management to see how you can be a bi-directional channel for driving product direction.

Know what you want to accomplish with your developer marketing program so you can measure and meter funding. Once you have the developer in hand, you need to pass them off to someone who can make money from them.

Obviously, you need to establish metrics so you can track progress and argue for more budget and corporate oxygen. I find that most people rarely base-line current performance how they’re currently doing before starting a new project, so that’s a good start: otherwise how do you know if it’s working or failing?

Finally, make sure you understand who “your” developers are. One off project lone wolves in coffee shops, startups, other vendors, enterprise developers? It drives what comes next.

Slide 8

So, what appeals to developers? It of course depends on how long their beard is.

More seriously, while there’s different types of developers, there are some core value props that usually work.

Developers like speed. They want to do more with less, they want things to compile quicker.

Many of them (not all!) want to try out new technologies. Their worth is all locked up in their head, so each time they learn something new, they become more valuable. Any many of them just like learning.

To that end, they like stability in their knowledge. It takes a long time to learn Java or node. They want the investment to pay off. Don’t be changing things around all the time.

They like solving riddles and puzzles. That’s what programming is, what tends to separate it from more “factory” like work.

The business side is simple: someone else comes up developers and tells them the requirements, what the code must do. This is where a lot of “enterprise grade” features come in like compliance, audit, and regulations. Developers generally don’t care about that, but they like satisfying the requirements.

And, while they may act – and dress – like they care, they care a great deal about getting paid. Those 128 gig iPhone 6 Pluses don’t pay for themselves. Developers rank themselves by pay like any one else. Money means freedom to developers, like most people.

Slide 9

Let’s close out by highlighting a few tactics from the report.

First, show up! Developers are very social, esp. online. There are numerous “communities” that they rely on for their work and entertainment. GitHub is popular, Hacker News, Stackoverflow, and numerous other sites. Large developer marketing programs like SAP even setup their own, highly successful communities.

We did a survey of the early mainstream DevOps market recently and found some interesting results there. Obviously we like the analyst reviews, but it also shows that “traditional” outlets are valuable to.

Find where developers are and go there.

Slide 10

So, when you show up, what’s the work product?

Content can take many forms. Blog posts are good, podcasts can work for certain types of developers if done right.

And look at everything as a “store front”: support forms, your docs, demos, and other “marketing material.” All of this, if tracked and experimented with properly is can the ether your developer marketing program flits about in.

Books can be oddly effective if you write one that’s a definitive “how to” of a narrow topic. I profile one on code reviewing that helped drive growth for SmartBear before it was acquired.

Presentations, webinars, and talks are always good as well. Check out what goes on daily at InfoQ. It’s documenting the tribal knowledge out there, which is incredibly valuable in a knowledge economy like developers.

Slide 11

Here’s some specific topic ideas, all of them good.

Let me highlight one, a wicked problem solved.

Back in 2012 when Thailand was flodded, Backblaze had a problem getting cheap hard-drives from its supplier. So they arranged employees to travel around the bay area and beyond to buy hard drives at CostCos and Best Buys. Developers loved this story. It’s a classic puzzle to solve in an almost subversive way. I know many, many developers who love and use Backblze.

Stories like this come out from other companies.

Also key is explaining your “philosophy” on the industry and even culture. To go back many years, as it was called then “37 Signals” used their philosophy of rebelling against Enterprise Java to help advance the adoption of rails and their own products.

Slide 12

So, other than reading my full report and doing crazy amounts of consulting with me, what are some tangible next steps?

  • Understand how developers will drive revenue and growth. How do they fit into your value chain?

  • Figure out who these developers are. There’s probably at least three types, if not more. Know them, and how long their beards are. And then go talk to them!

  • Start with some cheap experiments. Have a beer and write-up what you think is wrong with how things are done; record a screen-cast of an obscure feature in your platform; rise-wash-repeat. Just do something!

  • As you learn what works, get a regular cadence for content production. Blog posts, podcasts, docs, code, whatever works.

  • Finally, never forget that your job is to move product. Engage with sales and product folks to fit into their pipelines and process. If you round up all this developer favor, how do you deliver that into your companies money makers?

Slide 13

So, that’s a really quick overview. If you like reading, there’s a full report on the topic available. There’s a lot more in there like:

  • types of developers
  • the role conferences play
  • more on different channels and mediums, topic ideas and content
  • and several large and mini-case studies of what’s been successful at for other companies.

Speaking of case studies, we’ve put together a panel of folks who’ve been successful at developer marketing and relations and we’re going to debrief them now to help you understand developers more.

I’ve gone back and forth on whether managers should code and my opinion is: don’t stop coding. Each week that passes where you don’t share the joy, despair, and discovery of software development is a week when you slowly forget what it means to be a software developer. Over time it means you’ll have a harder time talking to engineers because you’ll forget how they think and how they become bored.

Bored People Quit – makes my head hurt to think on it too long.

Coté Memo #034: No longer blending iPhones, Applefornia, Developer Relations & Marketing

Meta-data

Hello again, welcome to #034. Today we have 41 subscribers, so we’re +/-0. I’d love to hear what you like, dislike, your feedback, etc.: memo@cote.io. (If you’re reading this on the web, you should subscribe to get the daily email.)

See past newsletters in the archives, and, as always, see things as they come at Cote.io and @cote.

Sponsors

Follow-up

Tech & Work World

Quick Hits

Finally, I’ll be getting a new phone

Obviously, there was a big Apple event today. I’m overdue getting a new phone (I’ve got an iPhone 4s!), so I’ll be shelling some cash out once it’s available; I’ll see what kind of AT&T discount I get. I finally waited until I was due a new phone, so hopefully not that much.

Like most people I saw, I was impressed by the Apple Watch more than I thought. I like how Apple just kept piling on functionality to it. Pretty Amazing.

Kevin Lynch shows off the Apple Watch

It was also fun to see Kevin Lynch in action. I used to work with him in tiny ways, mostly over lunches, when he was at Adobe. He always seemed like a very genuine, very smart guy who actually had a passion for computers. I think that came through in his talk today. He had a nice sense of humor too which popped up a tad. Last we saw, he was blending iPhones, but you know, because the cause.

Applefornia

The other thing I find fascinating is the weird world that Apple’s personas all exist in. It’s somewhere between stock photos at Target and the mall, and high-end PowerPoint clip-art. I like to think of it as Applefornia: that cool, ocean-filled place where people seem to constantly be on vacation and covering them selves with patinaware. That Umberto Eco should write an essay on it.

Developer relations and marketing

At our upcoming HCTS cloud conference (look above for more info and discount code if you want to register), I’ll be doing a short talk on developer relations and marketing, followed by a panel on the topic.

I put together a first, incomplete draft of the slides. Take a gander and tell me if you have any feedback:

I’m not sure where I came up with that title, but it looks like something I’d type…

Fun & IRL

No fun today, just work.

Docker for Service Providers – Once again: developers

Swapping out old IT for cloud IT

As newsletter subscribers may recall, we’ve been talking internally at 451 about how service providers could use Docker, or not. The piece on that topic is now up, and free for all to view to boot. Here’s the 451 Take:

Given the gulf between the actual needs of application stacks and the ability of modern hardware to pool physical resources, there is an opportunity for providers to move IaaS forward for developers. However, it requires commercial container vendors (Parallels) to tune their products toward delivering open-ended environments for users to bring their own applications, or it requires providers to blend IaaS with containerization to varying levels of sophistication on their own. Cloud computing succeeds because it is better at getting the consumer access to computing power than the alternative. In this case, developers are the consumer, and developers do not want to deal with every part of an operating system or systems concerns outside of their application. Developers happily pay low-cost providers $5 or $10 a month for a VM. If providers can give them superior service in the form of VM-less, stateful and container-ready environments they control for 1/10th the cost of production, this could shake up the cloud business, just as cloud shook up hosting before it. No more virtual machines, only apps.

Carl Brooks did most of the heavy lifting here as he knows service providers (and existing containers-ish competitors like Parallels better than me.

Obviously, since “developers” are my hammer, it’s nice that yet again Docker is a handy nail. Part of the reason I wrote that “big ass report” on developer relations was to help education service and cloud providers about the importance of developers and how to reach them. It’s nails all the way down!

Cloud, obviously a big opportunity if you know how to target

In our surveys, we see a sudden shift to private, public, and the infamous “hybrid cloud,” as the chart above shows (from this 451 report). Folks are looking for technologies and places to run their apps, which is exciting and will create opportunity for lots of cloud and service providers if they know what and who to target. There’s some recent 451 survey work that’s study the toolchain needed and buyer’s plans for putting them in place which is nice and detailed here as well.

Docker for Service Providers – Once again: developers

Why Did Docker Catch on Quickly and Why is it so Interesting? | The New Stack

Excellent piece. Too bad my folks didn’t get around to writing it first, but at least now it doesn’t need to be written.

The insights in developer relations are great.

At a meta-level:

It’d be interesting to “crowd source” analyst research agendas by just bundling up pieces like this and original work and having that be your “corpus” of research. It’s what Techmeme does for news (no original content though). That’s kind of what InfoQ does for appdev and I think it works kind of well there (I find video a bit too oblique, but you could do 500-1,000 word summaries a a la Blinkist on all the conference talk videos InfoQ has – that’d be a good premium service). Probably a good business too. I suppose it’s the infamous HuffPo and Forbes model, but applies to IT industry analysis.

Why Did Docker Catch on Quickly and Why is it so Interesting? | The New Stack