Recently, the Linux Foundation announced its intent to form the Developer Relations Foundation to support people in that career.

On the most recent episode of our podcast, we interviewed Stacey Kruczek, director of developer relations at Aerospike and steering committee member of the Developer Relations Foundation, to learn more.

Here is an edited and abridged version of that conversation.

How do you define the role of developer relations?

Developer relations is really the practice of elevating developers and their world. We’re all about helping the developers, helping them solve their problems. But more importantly, part of my role and the importance of it is also to be the voice of the community to the company. So it’s important for us to be able to recognize that the developers are the influencers of much of our technology business today, and so my role as a DevRel lead is to help elevate them and share in their pains, glories and challenges, and help them solve those issues, if they have them.

I always like to sort of describe myself as the PR person for developers, if you will, promoting them, promoting the importance of them, their value to the organization and their value to the community.

Why did the Linux Foundation create the Developer Relations Foundation? Why did they see a need for that?

The importance of developer relations is really to add business value. When you think about the journey of a developer and when they first experience your company, your products, your tools, and solutions, they’re really starting their discovery period. At first, they’re discovering what your tools are, the advantages of them, and as a DevRel leader, it’s my job basically, to help them along that journey. I help them down the path from discovery to engaging with us to sharing their feedback.

So it’s really about the developer being the influencer. And I’ve seen a lot of this personally at Aerospike, and we’re having a lot of conversations with developers and architects about evaluating our tools, our products, providing us feedback, and even coming in and evaluating our community.

And oftentimes, more than not, there’s a misunderstanding of what DevRel is. Each company has their own placement of a DevRel team or practice that really depends on the needs of the company, and that can be customized to them, but from a developer relations standpoint, it’s still all one in the same. 

And the major benefit of forming this foundation is to create some synergy and some common best practices, common terms that we all can share as a wider global community, to elevate the practice and practitioners in DevRel. So the major benefit of forming the foundation, why we did this is that it’s really to promote participatory governance. That means that no single company can monopolize the project or dictate its direction.

So our focus is on that community-driven governance. We’re taking and absorbing all the feedback of all of the DevRel practitioners across the globe. We’re ensuring that all of their contributions are reviewed, they’re all based on their merit and their expertise, and moreover, we’re creating a trusted, credible, and export resource to all of those professionals in the field. It will help promote best practices, what it means for businesses, and how we can add value.

What can DevRels do to elevate the development profession?

So really we have to look first at the challenges that some of this has faced. And I just want to tie in my own personal experience with this. I’ve been in this for over a decade. And when I initially came in, I came in as a technical marketer to a developer relations team, and I had the experience of sitting with five experienced engineers on the Android and Google development platform. And then we actually sat in the sea of engineers. So I always like to attribute my role as being the loan marketer in the sea of engineers, and they kind of kept me afloat. 

The beauty of that relationship, and what it really gave me, personally, was just really inspiration. There was a lot of collaboration. I became their voice to the broader customer partner ISV community, but more importantly to all the developers, I was helping them elevate their expertise. 

I think at that point, DevRel was sort of a newer thing. It had been around for a while, but people really didn’t understand it. I was thankful during my time at Zebra Technologies that we had that experience with them. It ignited my passion for helping developers in the long term in DevRel, and I soon moved into creating the first developer marketing strategy for that company, and then I really wanted to take on more as an individual for that, in terms of helping elevate DevRel as a practice, because dev marketing is just one component of it. 

When we look at it long term, there’s a reason for having a foundation. There’s actually a DevRel survey that just came out, and a large portion of developer advocates who responded to the survey stated that they felt like they needed a professional practice in one space, one community of where they could go to and share their experiences, but also learn from others. Because a lot of what I’ve learned in DevRel, I’ve learned from peers in the industry, and that’s been so important and so crucial for my learning and my development. So it’s not only the engineers, it’s also the other DevRel professionals. And when we were dealing with Covid for so long, I was fortunate to be included in many groups of DevRel advocates and professionals that would hop onto a Slack or a Discord channel, and we’d just start talking about the challenges of DevRel and how we were all dealing with it, especially during that challenging time. 

What emerged from that was the thought that we really need a foundation. We need an association of some sort that’s inclusive, and it includes our wider developer relations community and allows them a voice to be heard. 

We all bring our own personal expertise into it, but what we also bring is the ability to share with each other and collaborate. And that’s the beauty of DevRel. That’s what I love so much about it.

What is the ultimate goal, beyond bringing the community of DevRel together and having people share and exchange ideas? 

The broader developer relations umbrella as I’ve experienced it, we’re talking about community at the very core. You need to have a community in order to grow your business. And so that’s where it really starts. And then the various branches of that are related to developer experience. What kind of experience are they having? Are your tech docs easy for them to find? From a developer marketing standpoint, are we communicating the right messages? Are they technical? Are they authentic? And then we talk about developer success and education. We want to educate them just as much as they educate us. We want to make sure that we’re providing them the right tools, and we’re setting them up for success. 

And so these various components under the DevRel umbrella become so important. This foundation will essentially help define some of these areas and provide more clarity, but being that it’s open to the community, and it’s a community-driven project, we’re going to get varying viewpoints and opinions and it’s going to create this, this awesome catalog of knowledge. And then, by partnering with the Linux Foundation, they offer global credibility and they offer this robust governance structure that supports long term sustainability. 

Now, we’re an intent to form a DevRel foundation, so we’re still in the area of exploration and learning, and we do have a mission statement that we’ve created in collaboration with the community that we’ve shared. Everything is open and out there. We have a wiki page, we have a GitHub, and we welcome anybody to participate and communicate with us. 

We have weekly community calls across the globe, and many developer relations professionals are joining us on those calls and sharing their experience and their knowledge. We assign topics for the week, we review our proposals of how this will roll out, and the idea is that as a steering committee, we’re there to help guide the ship, we’re guiding the boat through the sea, and we’re going to help them stay on target, if you will. 

The project itself, the foundation, it really is going to rely on contributions from the community, individuals, supporters of the organization, and they’re going to provide expertise, guidance and content.

The post Q&A: Why the Developer Relations Foundation is forming appeared first on SD Times.

What is a Developer Advocate? 

I recently looked up the word “advocate” online. It is defined as “a person who publicly supports or recommends a particular cause or policy.” At face value, this is someone who is actively engaged in supporting developers and their interests at companies. I assume that means enabling them and helping them do their best, be their best, make their work easier or more efficient, and hopefully more enjoyable. Is that correct? I can see the need to have someone in place for the developers. I am definitely not saying they aren’t needed. They are.

DevRel was started by developers, but it has expanded to include other roles, but the title still remains. 

Rejected as a DevRel

I recently found out about a popular Slack channel made up of DevRel professionals recommended to me by several of my peers. My parody videos were shared on the channel and got a very positive response. I decided to apply to the channel myself to get connected with the group. After several weeks of waiting and wondering, I got a rejection email:

“Based on the description you left, it doesn’t seem like you’re actively working as a Developer Advocate or Technical Community Professional.”

My description was based on the actual things I do online around software engineering topics and performance engineering and observability. I figured if load testing companies have DevRel people in the group, I would fit in. Perhaps my description was not what they were looking for. Perhaps they are right. Maybe I am not a Developer Advocate. Or maybe that title is just not helpful because a lot more roles need advocacy. That got me wondering – what am I?

The Performance Advocate

Perhaps I’m just being a fish swimming upstream, but I think developers have enough advocates supporting them today. I have experienced developers who push causes and policies that I cannot support – those that result in poor performing applications, grossly inefficient systems, or a horrible end user experience – all for the sake of “good enough being good enough”. I’ll continue to be an advocate for the Performance Engineers to support the causes and policies that result in better software and less technical debt. I know, I know – we all say that everyone (including developers) want that. However, I have not experienced that discipline en masse from the developer community like I have from the performance community. I want a relationship with the developer, but I advocate for the performance engineer. 

I was recently told by someone, “We are ALL developers”. I have to respectfully disagree. I may write code here and there, but that does not make me a developer any more than calling me a car because I am in a garage. I love the developer, but I will never be one of them. I want the developer to be successful, but not at the expense of losing the ideals and disciplines I advocate for, which may be different from theirs. It doesn’t have to be an “us versus them” situation, but there must be a balance in the ecosystem. Therefore, I remain the Performance Advocate, to bring that balance. Maybe I’m foolish, misdirected, uninformed, crazy, or all of the above. 

The Need For Specialization

What about areas where specialization is required – like performance engineering? I see Developer Advocate titles in load testing vendor companies. Does this assume that mainly developers are doing the majority of load testing? In my opinion, that is not only wrong, but if it is right, it is not a good thing. Developers shifting load testing left is a good thing, but it is not the only thing and certainly not a replacement for all performance testing that needs to occur. What about other parts of the software lifecycle outside of developing code? Doesn’t there need to be at least a few advocates for the Performance Engineers, System Engineers, etc? Should everybody be lumped into the Developer category? 

The same people who have been telling me for the last five years that developers CAN make good testers, and SRE’s CAN code and test and handle performance and security, and, and and…. these are the same people now talking about burn out rates and the need for platform engineering to relieve cognitive overload. 

An even worse consequence I’m seeing in the market is the loss of fundamental skill sets and the missing context of things that should be known before ever attempting to optimize a system. Add to this the lack of BUSINESS context, and you just have a group of loosely coupled people putting together loosely coupled systems based on fuzzy requirements – and then we wonder why the end result doesn’t make end users happy. By making specialized skills sets a commodity, it lowers the competency and ultimately the product suffers in several ways: technical debt, poor end user experience, higher support costs. Overall, this leads to a bad reputation – which you can’t put a price on.

The post Why I can never be a developer advocate appeared first on SD Times.

The same thing happens in reverse. An American will roll up to get their hot brown liquid fix, and there is all the hot water in the world with bafflingly fancy tea service, but no joe. Right now, we are all having that moment. We can’t go out and meet people face-to-face. That was coffee-world, and right now we’re in tea world.  

We could try to make tea act like coffee, steep it extra long and try to make it more bitter, add sugar and milk. We could try to gather acorns and chicory to roast and grind for something not entirely unlike coffee. Or we could accept that tea isn’t coffee—that it has a different flavor profile and different caffeine levels. That lemon or honey are maybe a better fit than caramel syrup. 

If we try to entirely replicate our in-person interactions with online substitutes, we’re not actually grasping that this is a different world. And you’d miss the fact that we have different options and different constraints. 

Same but different
This is a trying time for us, both as humans and as parts of companies. Many of us are in various forms of social distancing, isolation, quarantine, or reduced service. Some of us are working from home in ways we didn’t expect. 

One thing I didn’t expect was how much my role would stay the same while being entirely different. All of the skills I usually use to help developers relate to each other and collaborate are still meaningful and useful. What’s even more important is that this is a toolbox that I can help my company with. 

Here are some examples:

Communicating
No matter what the sub-specialty of Developer Relations someone works in, I haven’t met any of us who don’t love communicating. We’re here because we love listening, teaching, talking it through, bouncing ideas around, and learning. 

All of that energy, now that I’m not using it at conferences, can go into communicating within the company. “Hey, you remember that idea we had three months ago about an interactive demo? What do you need to make it work? How can I help?” Even if what someone needs is just a sounding board, I have the skills to listen hard and ask useful questions about where they want to go.

My job is also about listening to people and helping them find the right person to talk to. And right now, I can keep doing that. I can serve as the routing center to get messages from one team to another—in a way we didn’t have a formal structure for when we could run into each other making coffee. Without coffee, and that physical co-presence, I still have all those relationships and can help facilitate conversations.

Connecting
Another skill I use regularly is facilitating connection. I work closely with teams within my company to help them connect with the larger community. But as a person who is used to connecting in-person and remotely, I can help them rethink these experiences so that they’re providing engaging experiences.

Consider hosting a Meetup. It was perfectly reasonable to have a 2-hour in-person Meetup with three speakers, a panel discussion, and some swanky food and beer. It takes that much content on offer to get people to deviate from their routines and physically go to something on a weeknight evening. 

But in these new strange times when we’re only connecting through screens, maybe that’s too much all at once. People have already been sitting at a computer for a whole workday, maybe they don’t want another two hours of watching a screen. Perhaps a better option is a shorter session in the middle of the day. This is a welcome break and they don’t have to physically change locations to get it. 

Doing the same format of meetup, just Now Online! is coffee-world thinking. I can help my team think about what meets people’s needs where they are right now. 

Community
As a Developer Advocate, I’m not just here to sell you my product. If my answer to every problem you had was “Buy my stuff”, I wouldn’t be a very authentic or useful member of the community. Instead, it is literally my job to make the communities I’m part of a better place for everyone—more inclusive, more accessible, more useful and rich. I want to see your Code of Conduct, because as a speaker and sponsor, I have more power to demand that than an attendee. I want to add to the technical conversations. And I want to be a trustworthy human, someone that you can pull aside and ask for help if you need it.

I need to be able to do that for my company too, and the fact that I do it for strangers at conferences gives me a lot of tools to do it for my coworkers. It’s not about me being an authority of knowing things, it’s about remembering that we are all in this together, and I have the tools and time to reach out and pull people together in a way that nourishes them.

Strange times
I’ve been working from home productively for 15 years. This is not new to me. But this month has been a shock to the system, it doesn’t always feel like this. It’s distracting to be in the middle of a crisis, and you’re not going to be as sharp as you ordinarily would. 

I’m starting to see a way through it and it’s not just about trying to replicate the conference system online, it’s about trying to diversify our human connection portfolio. I bet heavily on conference connections, and it paid out for a long time, but that market is closed now, and will be for months. It’s time to take that same energy and find new places to invest it.

The post Developer relations in a coronavirus world: The same, but different appeared first on SD Times.

Built.io, a digital automation platform, is known for its integration tool Built.io Flow, which lets developers and non-developers connect with an API builder. Built.io Flow also gives developers access to a drag-and-drop UI and code editor for Node.js custom code. Built.io also offers two complemenatry products for content-management systems and back-end services as well.

(Related: Oracle to acquire API solution provider Apiary)

Built.io’s new community platform goes hand-in-hand with the Built.io product suite, tailoring to citizen developers, IT leaders and technical developers who want to work with like-minded experts on subjects like automation, the Internet of Things, bots, DevOps, and Built.io’s headless content-management systems and back-end-as-a-service.

This active program will help form a developer community outside of the organization, according to Built.io’s COO, Matthew Baier. He added that the company already has a strong internal engineering team, but the organization is looking to bring all its developers into one place.

“[These developers] are building all these cool solutions, and we want to provide a place for their community to network and interact and make the ecosystem richer around our tools,” said Baier.

He added that today’s development world has many buzzwords around APIs and integrations, and in the past, working with integrations used to be difficult, so developers needed additional training or special tools. Now, because of drag-and-drop tools, citizen developers don’t need all that additional training. And integrations are cloud-based, so it doesn’t take developers months or weeks to complete a task, according to him.

Baier said the need for a strong developer community also comes from the way in which developers work today. He said it is no longer the case where developers are building huge stacks; instead, they are using microservices to build solutions.

“All of that together is enabling a much bigger community of people who are now genuinely integrating and developing for their own needs,” said Baier. “It’s not just IT; it’s happening across the board, and we want to nudge that along.”

Besides the tight-knit community platform, Built.io also announced the Internet of APIs Awards, which is an integration challenge co-sponsored and co-judged with featured partners. Built.io plans on cycling out new parterns to judge each round of challenges, and the company is kicking off the first challenge with Cisco.

For the first challenge, developers will have to use Cisco Spark in a new way, said Baier. Previous use cases that Built.io has seen from the Cisco community include a tax-advice bot that was used with integrations from Cisco Spark and the IBM Watson platform, according to him.

The post Built.io sparks innovation with new Community platform and Internet of APIs Awards appeared first on SD Times.