While the word DevOps was coined around 2008, the term ‘shift-left’ was used as early as 2001 and is considered by many to be a superset of DevOps. The theory behind shift-left is pretty simple and is based on the concept that faults are a lot easier and cheaper to fix when they’re found earlier in the software development lifecycle. When you talk about shift-left today, however, it’s about a shift in focus towards ensuring developers either have the right tools for the job or the freedom to choose their own.
Developers certainly don’t own the budget and may not even have the last word when it comes to purchasing, but their blessing often contributes to 90% of decision making. A survey on a group of about 750 developers in November 2018, revealed that over 30% regularly shoot down or reject tools recommended by management while another 30% get to choose their own tools. In fact, only 12.7% of the respondents suggested that their opinions were not considered on the subject and that they lacked the freedom to choose.
Developers are the builders of the enterprise and empowering them not only increases productivity but also gives you a better quality product. The shift-left movement is all about giving more trust, ownership, and responsibility to the developers so they can build and innovate with more ingenuity, speed, and efficiency. As part of this movement, organizations are increasingly looking to developers when it comes to decisions pertaining to which services and components of code are ideal to procure.
Developers will pick the tools that work best for them in the current situation, as opposed to tools that make sense from an organizational point of view. This is why teams that get to choose their own tools are a lot more likely to build robust, cross-platform DevOps toolchains that are highly customized to their specific needs. In addition to increasing job satisfaction and productivity, this also keeps developers involved and engaged, which is a critical aspect of this approach.
Keep it Complex
Unfortunately, it’s not as simple as changing your pitch to make it more appealing to developers, this is a whole different animal. As opposed to skimming over the complexities and getting straight to the bottom line, as you would in regular B2B interaction, developers want details and lots of them. This is where you unload as much relevant documentation as possible, preferably with lots of use cases and usable scripts, avoiding fluff like the plague.
Developers have first-hand knowledge of the environment, current implementations, system capabilities, compatibility with other systems, and all the other issues that are faced on a daily basis. This is why when developers read documentation, they read everything, including the fine print, and will call you out or bench test a claim at the drop of a hat. Additionally, they ask more questions, require more specific answers, and are highly resistant to traditional marketing and hype.
When marketing to developers, it is important to give them a chance to see, use, and feel the tools that you’re trying to sell them, in action. This often takes the form of a free trial or a “freemium” version that’s free forever, but where you have to pay for advanced capabilities. This gives developers a low-risk environment to play around with, as well as a chance to get a feel for the interface, albeit at its most basic.
In the case where your tool is all about complex capabilities and a freemium version just defeats the purpose, self-service product demos are another option. These are fully functional versions where users can try advanced capabilities in an environment set up with dummy data. This helps you show actual examples of problems you have either solved or are promising to solve, which works a lot better than just listing the capabilities of your software. In the developer world, seeing is believing.
In some cases, developer marketing is only half the battle, and the other half can often involve teaching them how to market. This is where engagement plays a critical role in arming them with enough traditional marketing content, actual product trials, statistics, and figures that will help them sell your product to the non-technical buyers in their organization. As opposed to functionality, this pitch needs to be primarily about cost and technical debt.
Organizing events like hackathons, virtual Q&A sessions, or even just making your developers available on platforms like Slack, are great ways to engage developers. Building a useful developer community, or joining one and teaching them something new, are both great ways to get some instant street cred in the developer world. Additionally, compelling blogs, surveys, conversations, and feedback are all highly recommended if you wish to keep developers engaged and interested.
Winning over developers is now a critical step to selling software. Developers purchase differently, and it’s not easy to generalize since no two developers have identical roles. Developer marketing requires specific marketing campaigns pertaining to specific individual use cases. It also requires trials, tutorials, demos and documentation to all be available before developers even consider making a purchase. Finally, developers prefer software accompanied by information that’s rich in technicalities that will not only help them make informed decisions but also help them sell those decisions to the higher-ups.