TV evangelist Jimmy Swaggart holding huge crowd spellbound, preaching at Flora Blanca Stadium. ... [+]
Software has its converts. When a software developer finds a particular programming language, development environment, toolset or service to their liking, they typically stick with it for life, or at least for a serious period of time. Because developers are so passionate about their likes and dislikes, or perhaps because adopting an engineering methodology or approach is a lot like finding religion, we use the term ‘evangelist’ to describe a person who promotes the use of a particular technology.
Sometimes known as advocates or developer relations specialists rather than evangelists, this role centralizes around explaining what a given technology can do for the practitioners who will use it and, consequently, what kind of end-user experience it might also be able to produce.
But this is a role that didn’t always exist.
When Aaron Ploetz, developer advocate at DataStax started his career in the late 90s, developer relations teams or evangelists were unheard of. In those days, enterprises had large contracts with vendors like IBM, Oracle or Microsoft (or more likely all of them) and C-level executives made the decisions around which technologies the software engineering would work with.
At this time (and throughout the decades before it) the resulting software toolsets made their way down to the individual coders and they had better like them, or else go hungry.
“As an engineer, what you got was what you got,” explained Ploetz. “For the folks having to use those products, there certainly wasn’t much choice in the matter. Nor was there really a whole lot of effort around convincing developers of the particular merits of the software tools or products themselves. The technology vendors involved had already sold their licenses to the organizations, so they were not incentivised to support how developers used those tools until the contract renewal came up in three years.”
Open source epiphany
But of course, the rise and wider proliferation of open source software around the turn of the millennium changed those previous dynamics. During this period we saw smaller technology companies start to vie with the larger enterprise behemoths and - in many cases - actually come to market with enterprise-level products that came with the support and maintenance needed by businesses.
This popularization of open source software was evangelized at a grassroots level, through conferences, special interest group meet-ups, webinars and so on. Some of the more prominent open source proponents (people like Richard Stallman and perhaps an early Scott McNealy) became the software rockstars of this era.
“From this rising tide of open source, a new career path emerged. As software companies began to formalize this process, the area of developer relations was born. These teams work to provide information to software developers that would explain how to use a software project or toolset, what it is good for and where it is going next. At the same time, the team will canvas the community to hear what should be coming next and where the pain points exist. By representing the community back into the companies or organisations that develop open source software, these projects can improve,” said Ploetz.
Where evangelism goes next
Given this brief history of evangelism, where can we see the whole practice of advocacy going next? From his work at DataStax, a company known for its cloud computing DataBase-as-a-Service (DBaaS) technology, Ploetz suggests that the focus can now encompass some internal promotion positivity. Having worked for a few large enterprises before, he insists that internal employee-focused (both across technical and non-technical staff), enterprise software evangelism can drive some good results.
But why is internal technology advocacy even worthwhile?
“Large companies tend to develop silos. Application development folks don’t talk to infrastructure folks. Even worse, sometimes teams within the same organization don’t talk to each other. That’s how you end up with things like the pricing team and the inventory team each having their own ‘source of truth’ database for product data. Teams may also build their own tools or code to solve a particular problem, unaware that another team has done exactly the same thing in a slightly different way,” clarifies Ploetz.
What we’re saying here is that internal product evangelism helps break down those silos and encourages communication. Once that communication link is forged, it can help to keep duplicate work and data storage wastage from happening.
Another reason this internal communications channel for IT evangelism can help is when teams have trouble working together. Perhaps the database team is not connecting with the data storage team, perhaps the application development team doesn’t connect well with the database team, perhaps all three are only barely aware of each other’s existence.
“In some cases, a more focused approach might be necessary. Maybe it’s enough for the database team to host a few learning sessions on how their data store product works,” enthused DataStax’s Ploetz. “Perhaps even a few alternative sessions might help folks who work at different times or in different locations. The most important element here is that teams explain their thinking, share their code and open up around their experiences so far. This should help teams provide constructive criticism and suggestions, or help find new contributors that want to get involved themselves.”
Demo day, show & tell
Taking this whole show & tell notion forward, DataStax has had marked success with what it calls its ‘Demo Day’ events. Almost like a conference where the attendees are drawn only from the company hosting the event (and perhaps select partners and trusted associated parties), this event sees employees set up their tables like booths in a large conference room (or hotel, or wherever) and welcome other employees to come and discover what each team or business unit does. The teams running the booths are essentially evangelizing for their work, informing folks on how their products or services drive value for the enterprise.
“This open, casual forum encourages individuals to see what other teams in the company are doing. It also provides a way for these technical teams to showcase their areas of expertise. Relationships forged during these events pay dividends later on, as teams now know some of the folks to talk to when they require expertise in a certain area. In the world of open source, we develop in the open and everyone can see the code - we can benefit from this within companies internally as well, even if the results never get shared with the world at large,” evangelized Ploetz.
One further lesson from Ploetz and team on developer relations and software evangelists is the long-term support and community development that should take place around projects. These individuals are looking to build communities and expand their networks - this also means looking after projects over time and keeping them current. Internal projects can build up technical debt in the same way as the big open source projects we use every day, so we have to force ourselves to counter this problem too. This can be harder when you can only draw from your own team, so finding more contributors internally - and externally too, over time – can only help.
A mantra for the future
While software evangelism may have emerged from smaller software companies, it has widely evolved to also function at a large business enterprise level. As it now straddles both levels and also finds its place in internal advocacy initiatives as explained here, it must now grow to become a new system of belief that enables us to execute software application development more prudently, more competently and with greater care for one another.
If that’s not a mantra to meditate on, then what is?
