The Core Tenets of Technical Marketing: Cody De Arkland (Part I)

InfoQ recently sat down with Cody De Arkland, Head of Developer Relations at LaunchDarkly, to examine what it means to be a technical marketer and the skills required to be successful in this role.  With the advent of DevOps, he describes some of the new ‘personas’ that have emerged in software development, market trends that he’s seeing around Kubernetes, serverless, and tooling, and the importance of community-building for ISVs.  

InfoQ: Hi Cody, can you tell us a little bit about yourself.  Can you tell us about your professional journey and how you ended up in your current role at LaunchDarkly?

De Arkland: It's been something I think a lot about. I probably think about this every day—the odd way we all ended up here. I know so few people that just went to college for tech, and ended up in tech and now work here. We’ve all had some interesting paths. For me, I started off at a utility company in the helpdesk, helping people create Outlook PST files to store their mail. That was literally where I started. It's just funny how things play out. As I've moved through that role, I ended up doing a lot of cloud-computing stuff. I eventually moved out of customer land and then worked at a major infrastructure vendor, where I worked on a series of events in technical marketing.

I really fell in love with the space of technical marketing. I felt like it was true to practitioners and was important for people who were actually using the tools. The role also aligned well with what the company was trying to accomplish, what it was trying to build, and the ways its customers were trying to use it. It really let me be creative and explore cool ways to do things. 

InfoQ: It’s generally understood in our space that the developer audience is ‘marketing averse,’ at least to overt sales pitches.  Are ‘technical marketers’ viewed with the same skepticism?

De Arkland: I think industry shuns it from a developer standpoint, because it has ‘marketing’ in the title; however, when I hang out with my DevRel friends, or my developer-marketing friends, they're like, "You get this stuff so well." It's interesting because industry perceptions of ‘marketing roles’ haven’t matured as much. We're so focused on someone’s job title that we create these preconceived notions of what that job is. 

Before coming to LaunchDarkly I had a number of tech-marketing roles at various companies. Each role was closer to the developer space, but it still was considered technical marketing.

At LaunchDarkly, I finally got the opportunity to ‘cross the chasm’. It might sound a little corny - but in a beautiful way - I got to bring the technical-marketing role underneath developer relations. In my developer-marketing team, I have developer advocates and technical marketing. They're very similar. They share very similar goals and OKRs, as we call them, and very similar overarching goals. The implementation is just a little bit different. I expect my tech marketers to work a little bit closer with sales and understand the problems they're seeing, and help build developer content off of there. It's still content for developers. On the other side, I expect my developer advocates to be more involved in public speaking, to be more external facing, gathering information from the ‘outside in’. We then come together inside to figure out the best way to move things forward.

InfoQ: What skills does a technical marketer need to be successful in the software development space?

De Arkland: It’s the hands-on stuff. I realize that’s a vague term so I’ll unpack it a bit. It’s about being willing to go hands-on and explore. There are technologies that you can dive into that make you well rounded. Playing in the DevOps space, getting into pipelining, and infrastructure as code, and automation, that's going to serve you well in tech and just universally across all teams. 

The biggest gap that I see is that there are a lot of technical marketers that understand the theory. They go and read a ton about theory, but they don't take the time to go and practice it, to try it out and to explore. I tell people that the best technical marketers that I know love to create engagement. They love to create content that makes people want to see the next thing. They're natural explorers. They spin up the demo account and take it for a spin, and they turn the knob and they ask, “Why does this do that?” They're messaging product managers to ask, “What was the thinking behind how this was built?”

I have a ton of respect for people who will just jump in and take a shot at it, even if they're asking 100 questions. I love when people ask questions. I encourage people to ask questions, but when they go hands-on and actually try it out, you just learn so much more. Right now, I'm building a lot of new-hire plans, because we're growing quickly. When I do new-hire staff, it's focused on getting them hands-on as soon as possible. I don't need you to create content right away. I don't need you to build anything huge or feel the stress of accomplishing a goal. I just want you to get in and feel comfortable with the ergonomics of how this works.

InfoQ: Market research is obviously a bit part of your role.  What are some of the key market trends that you're seeing? What should marketers pay particular attention to?

De Arkland: I think the tech space has always been a very trend-focused space. We see companies starting to adopt a technology, and all of a sudden everybody’s adopting it. After that initial spike of adoption, we eventually get to a place where the ‘path is righted’ and people start using the technology to solve problems. 

Specifically, in the cloud-native space, we saw a spike in people who were adopting things like Kubernetes, just for the sake of adopting Kubernetes, or even microservices, just because it was perceived as the right thing to do. From a trend standpoint, I think we're seeing the shift back to what I call ‘proper architecture’ or use-case driven architecture. We're starting to realize that some of the monoliths we built aren't bad just because they're monoliths. They're built that way for a reason, so we look at different ways to compartmentalize that app, and make it more developable in different chunks. There are ways that people can make that monolith still perform really well. 

At the present, people are moving away from saying, “I need Kubernetes because it's Kubernetes.” Instead,  they're saying, “I need Kubernetes because I need scalability. I want the resiliency aspect of it.” 

We're also hearing people say, “I can run that frontend in something like Azure Container Service, or Amazon's Elastic Container Service, because I just have a standalone container, a standalone system. I don't need it to be distributed with the weight of Kubernetes, because there's an operational cost.” A lot of these early adopters of Kubernetes have now been using it for a couple of years - and looking back - they’re saying the operational uplift to do this was really hard. Now the knowledge and wisdom is coming out, and they’re thinking, “maybe we should focus a little bit more on the ways people aren't using this.”

Other trends, like Lambda and serverless tech are starting to rise up again, but with less of an ‘over-complexity’ than there was before. We’ll continue to see their increase in importance. 

Finally, I think that tooling is starting to make a big comeback. This is a cycle that I see happen a lot: where we move into this ‘theory space’ of the way people work, the ‘people-process story,’ as it were. We focus on that for a couple of years, and when the ‘people and process’ stuff gets to a good steady state, we rotate back to tooling. 

I think we're entering into a tooling phase. Specifically, people are looking at tools to create scale. Infrastructure as code is a great example—ways that people can use these tools to impact many systems, and one administrator can now manage a global fleet of systems remotely. As part of the Great Resignation, people are moving onto new roles. Teams are smaller in some cases, so they need to scale. As a result, I think tooling is making a big comeback around. 

InfoQ: Even with tooling, there are usually different end users that expect different outcomes.  Is ‘Persona-based’ research an important part of your overall research efforts?

De Arkland: It definitely is. We tend to carve things up a little interestingly in the group. I'm responsible for the practitioner personas. There's a wide variety in there. That's something else we're realizing: it’s that the developer persona is no longer everything. That role has actually changed a bit; you have the developer who's like the traditional coder, "I'm building the app. I'm writing code." 

Then, you have the Site Reliability Engineer (SRE), who's making sure platforms are up and running and staying alive. They often get rolled into the ‘Developer’ bucket.  Finally, you have the DevOps engineer who's usually doing more enterprise automation, or building pipelines, or ensuring scale and things like that.

I tend to handle a lot of those practitioner-style personas. The research for these varies. A lot of times it requires conversations in the community. There’s a lot of legwork required from my developer advocates, attending and learning from conferences, for instance. 

The business side of LaunchDarkly does a lot of research on the “buyer persona”, and the type of stuff that ‘Directors’ are purchasing. Then there’s the feedback we get from market analysts.  In the end however, we are a little bit more biased towards the community perspective, trying to get a beat on what's happening on the street. It's never 100% right. There's a practice and a science to it that bounces either way from time to time, but I think we're doing ok.

InfoQ:  There appears to be this myth that with everything moving to the cloud, and presumably becoming ‘self-service’, that eventually, we won’t need operations teams anymore. In reality, it looks like just the opposite is happening: that we need more operations folks, those with the skills to manage a new kind of operational overhead associated with the cloud. Is that what you're seeing as well?

De Arkland: Absolutely. I think what's really cool to see is that a lot of those operational roles that used to be just the person hammering away in the data center, making sure stuff is running, they're becoming consultants now inside of the business, to help teams understand how to develop properly. 

I can't think of a better group than the SRE team who's been troubleshooting, monitoring, and managing platforms, to come into my application team and say, "Here's the most successful group inside of our company that does this, architects the system this way. Their system never goes down." 

That's the person that I want. I think we're seeing that operational roles are definitely more needed now than ever. There's that whole myth: cloud is going to eliminate the operations groups. It's just fundamentally not true. I think what's really cool is the way that these roles have become elevated inside of enterprises now. They become, in a lot of ways, developer advocates and advocates for good architecture inside of those enterprises. The number of projects I see where an SRE ends up as the trusted advisor is just incredible. 

InfoQ: For a while, it appeared as if Developers *had* become the new operations team. 

De Arkland: There's a lot of truth to that. I think we have to think of the path of how this happened. Developers started buying cloud because they created their code push. They were able to do their code push. A leader said, "You have a credit card; run it. Expense the cost, just get the platform up; we'll deal with the regulation a bit later. Get it up and running." 

Developers did. 

Now, we're needing to deliver things so fast, and there are so many ‘asks’ that developers are like, “I didn't realize my entire job was going to be managing an AWS account and Azure accounts, too!” 

They want to get back to building code and shipping code, and now cloud operations are getting moved over to SRE. Infrastructure teams are maturing into the ‘Cloud-Ops’ team. Developers want the freedom to use the cloud, but not necessarily the responsibility to have to operationally manage it. 

InfoQ: From the perspective of a software vendor, what constitutes community building? Why is building community important for developer evangelists and technical marketers?

De Arkland: I think that there's a harsh truth that you have a community in tech— whether you manage it or not, is the question—but you have a community. If you're choosing not to manage it, then people's opinions and what echoes down on the internet is going to be the truth of what people find when they search for you. 

We have a responsibility to do something there, or we should. I think a community is about investing in knowledge and information and accessibility for people who might be using your product and being present. I think it's a cornerstone of developer marketing and doing developer marketing. 

If you're ignoring the community in those roles, there's no positive outcome for you there. I think it's a hard thing for the business to always process because community building is an investment. It’s something you have to actively do. It doesn't have an immediate return, but it has a return over time.

Read Part II - Creating Content that Connects with Practitioners: Cody De Arkland