There is a caste system in technology. It’s an engineering caste system, or at least that’s what I call it. A feeling of superiority developers have over their QA, IT, product management, and release management brethren. Software developers at every firm I have ever worked for – large and small – share a condescending view of their co-workers when it comes to technology. They are at the top of the totem pole, and act as if their efforts are the most important.

It starts in college, where software programs are more competitive to get in and require far more rigorous curricula. It is fostered by the mindset of programmers, who approach their profession more like religion. It’s not a 9-5 day job, and most 20-something developers I have worked with put in longer hours and put in more time into self education than any other profession I have ever seen. They create something from nothing every day; and with software, anything is possible. The mindset is reinforced by pay scales and recognition when products are delivered. Their technical accumen runs far deeper than the other groups and they don’t respect those without it. This relationship between different professions is reinforced when problems arise, as developers are the ones explaining how things work and advising those around them. It’s the engineering team that writes the trickier test cases, and the engineers who comes up with the best product ideas. Heck, of the last four organization I have run, to solve serious IT issues I had to assign members of the engineering team to debug and fix. They are technology rocks stars and prima donnas. Right or wrong, good or bad, this attitude is commonplace.

Why do I bring this up? Reviewing the marketing and sales collateral from several security vendors who are applying their IT marketing angles to software developers, I see a lot of approaches that will not work. When it comes to understanding buying centers, those who have traditionally sold into IT don’t get the developer mindset. They approach sales and marketing as if the two were interchangeable, but they are not. The things developers consider important are not the same things the rest of IT considers important. It is unlikely your “IT Champion” can cross-pollinate your ideas to the development team – both because your champion is likely seen as an outsider by the developers and due to internal tension between different groups. Development sets development requirements.

White box test tools? Web application assessments? WAF? Even pen testing? These all need different buyers, with a different mind set and requirements than the buyers of other IT kit – especially compared to network operations gear. The product and the value proposition needs to work in the development context. Most sales and marketing teams want to target the top – the CIO – and work their way down from there. That works for most of IT, but not with developers who have their own set of requirements over and above business requirements, and often neither fear nor respect upper management. They are far less tolerant of marketing-speak and BS and much more focused on getting things done easily, so you had better show value quickly or you’re wasting time. UI, workflow, integration, and API options need to be more flexible. When it comes to application security, it’s a developer’s world, so adjust or be ignored.