BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage Interviews The Role of Developer Relations in the Enterprise

The Role of Developer Relations in the Enterprise

Bookmarks
   

1. Hello and welcome, I have with me Adam Seligman who is VP of Developer Relations at Salesforce, and we are here at the Evans Data Corporation Developer Relations Conference 2015 at Palo Alto, California. So Adam if you can take a moment to introduce yourself to the audience, that will be great.

Sure, my name is Adam Seligman and I look after the Salesforce Developer community also the admin community and we are really excited because the developer community just passed 2 million registered developers, so big milestone for us.

   

2. Great, without going into gory details of what Developer Relations is, can you talk about why a developer or architect should care over Developer Relations?

I think every developer or architect should really worry about building the right apps, the right way at the right time. I think they work for a company, for their own company and they really care about the quality of their work, producing great apps and experiences, and the way you do that and stay educated, you stay plugged in as a developer to what’s going on in the market, the changes in the market on the technology and on the business side too, so the interface between most companies and their Developer community, most technology vendors like Salesforce which has a great platform and all of its developers, is usually Developer Relations program, that’s usually the interface between developer community and the technology company.

   

3. Salesforce obviously pioneered the Cloud, but they also had one of the earliest Developer Relations Program, if I can remember. Can you go a little bit into the history and how it has helped Salesforce in particular and how can Developer Relations Programs in general help enterprises?

Well Salesforce took an approach with its technology, to not just build tightly coupled apps but to approach the whole market as we see – a CRM, Salesforce automation and service marketing, all these different product lines we are in now. We took the approach, taking a platform approach, the idea was really been a platform underneath all these individual Cloud products, a platform that ties all together and a platform that business people, developers can extend and customize. So if you want to have great platform you have to explain that to the developers, and you explain that to our architects, you have to explain that to admins. So we’ve been working for a long time to get the word out and explain how to use this platform to create amazing applications and back to the whole Salesforce mission, how people connect with their customers in whole new ways, well you need the right custom code to go do that, you need the right custom apps to go do that, new experiences, new business processes to go do that, takes developers and admins to go make that happen. You ask about the history, the history is actually kind of interesting. One of my favorite stories in the history is where we were talking the other day with Dave Carol as a senior director at Developer Relations and Salesforce been there .for a long time, been with the company for more than a dozen years and somebody asked him how long he been doing Developer Relations at Salesforce, and his answer was all of them.

   

4. That makes sense, but Developer Relations and Evangelism is somewhat hard to measure, it’s just like marketing. What techniques do you use, what is most effective, what is not?

There is revolution happening in marketing right now, a revolution happening in measuring, marketing being very targeted marketing and taking everyone on a one to one customer journey, I mean that’s a big shift in marketing right now, the rise of digital, the rise of customer information system, CRM. You have a view on all your customers and know what journey they are on and what they’ve done with you, so we are taking the best of Customer Relations and taking it to the Developer Relations, so what we are try to do is to build a profile or a persona of every single developer in our community and then send her only really relevant information and help her advance her career and help her with the specific skills that she needs to take her career to the next level, her app to the next level. We invested in one specific technology and I’m really excited about, that’s called Trailhead.

So Trailhead is Salesforce’s digital learning platform for developers and admins and Trailhead is the fun, it’s fun, it’s social, it’s gamified, its got bite size chunks that make it really easy for developer to come in, learn one new skill and then advance and use it in their career, but we can measure all that, that’s the exciting thing for us is we can measure all of the developers that use our platform, what are they doing, what are they not doing and then help them learn the next new skill that is going to take it further, so Trailhead and really this whole Customer Relations approach, customer centric approach to Developer Relations is been a big focus for my team.

   

5. Ok, obviously any kind of evangelism or Developer Relations has to be based on good technologies, good platform, on a platform that developers care, right? How important is to get the technology right and when do you want to start the Evangelism and how do you kind of balance those two?

I love developers, they are kind of like toddlers. If the toys are boring, they leave. They are done with the toy. So we have this amazing developer community and we struggle every day to think really hard and listen what we call the “idea exchange” and go out to our community events where 125 developer user groups around the world, and hear they have to say what they want, you know one thing that we are giving example, one thing that we are seeing from our admin and declarative developer community is they want more tools that can really extend the platform in big ways but not requiring them the write code. So we made a big investment last year and we call it The Lightning Release of the platform, and a whole bunch of technologies is for drag and drop, you know customization and app building, and that was really in response to what our developer community and our admin community was asking for.

   

6. Open Source is making a big impact on the industry, obviously with developers as well, pretty much everything is on GitHub these days right? It’s a distributed repository but is all centralized on GitHub go figure, how does this affect developer programs or Developer Relations in general?

Well I mean the new normal is every developer expects to not only find some great library npm or GitHub, it’s going to do what they want and get them started on their app idea, but they also expect to be able to deploy instantly, right? An npm install or download somethingfrom GitHub and go, or the Heroku deploy button, where you can press a button and just instantly stand up any app with a description file and stand it up on Heroku instantly from GitHub. So yes, I think not only is that are we seeing the rise of Open Source, we are seeing the rise of friction reduction and so that all the friction goes out and the developer not only have the app, have the app and the package up and running and then start customizing it. You know the new normal is not having to build something from scratch, but being able to start with a really good frame of reference. Open Source started that trend, I think great Cloud services, Cloud services like Heroku, Cloud services like GitHub, I think are continuing that trend.

   

7. [...] Many of them don’t quite succeed frankly, what would be an advice for someone starting a developer program and how does this change for a big company versus a small company in terms of resources?

Rags' full question: I don’t know if you’ve been in the conference for the past 2 days but you’ve had people from different Developer Relations programs talking like Ford, Walgreens and really you name it, a lot of different companies. Many of them don’t quite succeed frankly, what would be an advice for someone starting a developer program and how does this change for a big company versus a small company in terms of resources?

I think it’s very good question, I think that really are different objectives that are reasonable to go for in a Developer Relations program, maybe a small organization where the API is an extension of your core product, like a car. You know Ford sells cars, this is all APIs, this is all service, sell cars, it’s my understanding. So APIs are going to be important but they are not really the core of their business. Company like the Salesforce platform is the heart of our business like if we don’t have developers and admins, we are not going to be successful. So I think we really need to go within your eyes wide open or what outcomes you are trying to drive to are. Is it some adoption of your API, is it commitment, someone’s career or their business to your platform technology, those are sort of different outcomes. First thing I would say is to be crystal clear with the outcome you are trying to drive to when you start, and then the second piece of advice I’ve got for anybody who’s in Developer Relations, is have a crystal clear message. Explain very simply in terms that the developer can understand, what’s your value proposition to her, what is it all about that you offer, how are you going to help her career, how are you going to help her build some new amazing app or some really innovative service that she’ll add to her app, I mean put it in terms of outcomes or growth or some forward looking place that you are going to help the developer go, that’s my advice, have a mission.

   

8. Ok I got it, and how does it change big company versus small company less resources, more resources?

You know there are small companies that have really big missions there are big companies that have modest missions. You are going to have to find the mission right for your company.

   

9. One final question, you know InfoQ audience are primarily developers and architects and if they are pondering a career in Evangelism or Developer Relations in general, what would be your advice to them, how do you kind of pick the wheat from the chaff if you will?

Well first of all I hope every developer has a little bit of Evangelist in him or her, I think every Evangelist should be out there sharing what they learn with the next generation, sharing what they learn with their peers, I think that dialog of showing what you’ve learned, showing what you know, sharing is a really healthy thing because every time you are trying to show something to somebody I think you learn in response. What do I look for in an Evangelist? You know it’s interesting, there are a couple of different archetypal models, there are models and Evangelists that have ton of experience, everybody already knows, and there are other Evangelists that are really passionate about a particular topic or communicate very effectively, and I think both of those models can work, I think ultimately what it comes down to is whether are you deeply connecting with developer community and they are responding well, are they embracing the Evangelist and everybody is in it together, it is not a one way job, it’s definitely a two way job.

   

10. [...] How can you be sure that you are telling your message to the developers who have signed up for your program?

Rags' full question: Absolutely, I think I said last question but maybe this is the last question, how many developers you think are there in the world and developers necessarily do not go to just do the Salesforce program or just to the Microsoft program or so on right, so they kind of pick multiple programs, right? How can you be sure that you are telling your message to the developers who have signed up for your program?

Ask them, a developer is not a developer, is not a developer. It’s a lot of kinds of developers and experiences and backgrounds and geographic regions and historical technologies that they’ve used, legacy technologies that they’ve used, this is a lot of diversity out in the developer community and I really think the right way approach is to just go in a really inclusive manner, you are always approaching inclusively and don’t make assumptions and sort of try to tune in to the different needs, the different sub-communities.

Rags: Got it, thank you with that, I like to thank Adam Seligman and thanks everybody for listening!

Thank you!

May 03, 2015

BT