THIS IS WHERE I POST MY BEST THOUGHTS.

A few pieces from American abstract artist, Mark Rothko | What’s with the random art?

The insights mentioned in this article have been gathered from the 2019 GitLab Global Developer Report: DevSecOps. Because the report is comprised mainly of GitLab users, we can assume that data related to technology vendor preference and usage are skewed, because of this I’ve intentionally ignored those topics in this post.

Before we dive in, let’s quickly review why DevSecOps even matters to developer marketing professionals, after all, DevSecOps guys are IT right? Not quite …

With the emergence of infrastructure as code, the line between Dev and DevOps has become increasingly blurred. In fact, the majority of developer marketing and developer relations orgs will tell you that they group developer and DevOps titles into the same audience segment. For developers, this line blurring has enabled agility and increased release velocity, but it left something out … IT security. This is where DevSecOps made it’s debut. DevOps ensures rapid development cycles, but lengthy security practices frequently undermine DevOps initiatives. DevSecOps focuses on integrating security into the development lifecycle and automating it, removing the roadblock of IT/SecOps.

One thing that I really like about this report is that the team at GitLab broke DevSecOps into three separate components when surveying their audience (Development, Security, Operations) which I think removes a lot of the confusion and ensures that the responses are more accurate.

The first thing that really stands out about this report is that the definition of how an organization would ‘do’ DevOps, is not set in stone. For software vendors, this is really important to note. Many times as vendors, we assume that the majority of software teams conform to a specific workflow. In reality, most teams are a mashup of various methodologies and disciplines, not to mention the technologies they are using to enable those practices. It’s also good to know that DevOps is not universally viewed as having a positive impact on an organization, it also varies in degree of automation vs manual tasks. Developer Marketing teams should use the term DevOps conservatively, I would suggest clearly articulating exactly what you mean with the term DevOps and making it publicly available and referenceable to those consuming your content.

Second, deployment frequency and velocity is a major driver for teams pursuing a DevOps strategy and for developers it’s a major influence on job satisfaction and innovation. This by itself is not a new or interesting insight, until you consider security as the biggest roadblock for deployments. Removing this roadblock is why DevSecOps is gaining popularity, however, shoving the word Sec in the middle of DevOps does not make everything smell like roses. As the report states “Security is perhaps the most polarizing aspect of software development today…” Why does it matter for developer marketing teams? As marketers, we love our keywords and tag-lines. Security makes headlines and fear sells stuff, it’s easy to place a heavy emphasis on security in your product copy, but you should be aware that by adding mention of security features you don’t get an automatic thumbs up. This is another word that should be used sparingly and with heavy context, it should be noted that security measures vary from company to company and industry to industry. Though your product might be ‘secure’ for a small private sector company, it most likely doesn’t come close to meeting the compliance needs of an organization working in the federal space. Final note on security, early indication and automation is a big deal to software developers. They want to know that the tools they are using to write code will catch security issues, this goes back to contextualization of the term security in your collateral.

Third, 36% (the majority) of developers think that their organizations DevSecOps practices rank as ‘Fair’. This is credited and tied closely to how mature the organizations DevSecOps strategy is. Not surprisingly, when a DevSecOps strategy is mature, it is 3x more likely to discover bugs before the code is merged (see final point above). Teams that have a mature DevSecOps strategy are very happy with it, however, it’s a long journey and most dev teams don’t have a solid grip on it. For developer marketing and relation teams, this is a great data point. Developers are heavy consumers of educational content, DevSecOps workshops and talks will most likely be a focus area for companies looking to sell their solution into a developer org.

Final point, on the operations side of things, there seems to be much less ambiguity. This is because of the heavy focus on tools and automation. I would also argue that the industry as a whole has focused heavily on developing Ops infrastructure and practices, making it the most mature area of the DevSecOps trifecta. Ops has clear priorities and and structured workloads allowing them to easily measure their work. When we look at monitoring, CI, and deployment tools, there is no clear winner. For developer marketers this is important to note. When focused on Ops, don’t emphasize a one-tool-fits-all approach with integration partners. You should expect to gain search traffic that is focused on an organizations specific stack vs a methodology or practice.

Conclusion

Personally, I found this report to be informative and generally speaking align with what I see reflected in my own developer campaigns and audience behavior. There are a few takeaways from the DevSecOps report that I think will play a role in my upcoming marketing campaigns. Most importantly, on the DevOps side, it’s a good reality check on the maturity, adoption, and affinity to the topic. It’s very easy to assume that DevOps is a well established standard, but the reality is that it is far from that. Speaking of standards, standardization in general is simply non-existent. We have a long way to go with the DevOps topic and I will be reviewing my own content to make sure that I don’t make false assumptions about the readers understanding of the topic aka, diving too deep too fast. It’s fun to cater to developers on the bleeding edge, but ensuring that developers who are slow to adopt can still find 101-level content is important. Additionally, I’m going to be taking a close look at how ‘security’ is talked about, focusing in on the aspects that are integrated into developer tools like IDEs. I would encourage you to checkout the full report here.