Calling Them What?
And that is the question. If you are marketing to developers, you already know that there is no generic “developer.” Undoubtedly, your tool or service is meant to be wielded by a very specific developer persona. But thanks to DevOps, that persona may be employing multiple tools. So when your persona also identifies as DevOps, what does that mean? Why should you care?
To understand this, Developer Media posed a very simple question on CodeProject.com:
“Are you a DevOps engineer?”
Yes, But…
At least one developer responded, “Yes, but I don’t want to be one.” Harrr. But, seriously, the most interesting result was that 19% said, “Yes, but I didn’t realise it.” Besides the Canadian spelling of “realise,” what is striking is the fact that ⅓ of the developers have DevOps in their job description, making it sound like they were labeled DevOps after the fact. Meaning that they may or may not have moved to DevOps intentionally. More than likely, they were already doing it.
It helps to understand what DevOps means. DevOps is the practice of integrating operations and development together in the software development pipeline to create efficiencies in the entire service life cycle. Practically speaking, this means developers take on more responsibility for operations while they are developing, and operations makes use of many of the same techniques as developers. All of this means that the lines between operations and development start to blur. The advantage of working this way is that it avoids bottlenecks that can occur when IT operations is brought in only very close to the time of deployment, near the end of the cycle, which is typical for the so-called “waterfall” process of launching software products. Instead of waiting for a final blessing from testing and operations before delivery, with DevOps, developers can get feedback earlier in the development cycle, making it easier to fulfill the goal of continuous integration/continuous delivery (CI/CD).
So really, DevOps is a process, a production workflow, for creating software. It is thus less surprising, that of the 970 responses received in this poll run from 3 Dec 2018 to 10 Dec 2018, about 60% of developers said they consider themselves DevOps engineers, at least part of the time. And it is entirely possible that some production teams were already working in a DevOps mode before the term was coined.
Survey Results
| Response | # of Votes | % of Total | % Error* |
|---|---|---|---|
| Yes I am | 197 | 20.31 | 2.53 |
| Yes, though I didn't realise it | 183 | 18.8 | 2.46 |
| Sometimes | 213 | 21.96 | 2.61 |
| I was but no longer | 80 | 8.25 | 1.73 |
| No, but I wish I had the opportunity | 74 | 7.63 | 1.67 |
| No | 233 | 24.02 | 2.69 |
| Total responses | 970 | 100% |
So, what does all of this mean? It means that if you were targeting an IT engineer, that engineer may care more about things you associate with a developer (Hark! Could this be “Modern IT”?). And, the developer you are targeting may care more about operations (things like testing tools, cloud storage, and security operations) than you thought. It also means that while you may be marketing to the same person you have always marketed to, their job responsibilities have changed and are probably still changing. If they strove for a DevOps identity, or simply always behaved like they worked in DevOps, your target persona may have changed, even if the person didn’t.
DevOps-ification
What does this mean for your messaging?
- Your tool could be used by either a developer or an IT operations engineer.
Focus on function, not on role. Understanding that the idea of DevOps is to push functions that used to occur closer to delivery up the development pipeline, create material that helps developers and IT alike understand how your tool facilitates the process that leads to CI/CD.
- Identify process issues
Thought leadership content that speaks to implementation issues in what is supposed to be a streamlined process is key. However, you may not know what these issues are. It is useful to get the perspective of practitioners whose expertise and responsibilities vary within that pipeline. Have these practitioners outside your company shine a light on the issues they face and write about them, and ensure that your company benefits from the knowledgeable and authentic voice of the customer.
- Educate across the pipeline
Just because either a developer or an operations person is going to be the primary user doesn’t absolve you from speaking to both. The fluidity of roles and responsibilities within the so-called “DevOps” process is part of the challenge and the opportunity for everyone involved. Remember, as DevOps evolves, the tools evolve, and the primary user may change overnight.
That’s a Wrap
Persona is everything, even if the person doesn’t change. Take an honest look at your product and the development process it will support. Chances are that the process is DevOps, and your marketing materials should reflect that. Everything from documentation to tutorials to thought leadership pieces to education, and even product specs, should keep in mind the fluidity imposed by DevOps.
