If your developers aren’t enrolled in developer relations programs, they will grow old and stale. They will become moldy. They will pine for the Good Old Days and opine endlessly about the irrelevance of new tools, new platforms, new paradigms and new ideas. No matter their brilliance today, they will become obsolescent.

You can’t let that happen!

Developer relations programs are all over the map, literally. Some are focused on operating systems – see those from Apple and Microsoft. Some are about back-end platforms, like programs from IBM or Oracle. Some are tied to very specific products.

It’s hard to know where your developers will get the best value. Let’s take a very simplistic case. If you have a bright programmer who is working to integrate back-end Oracle databases with Windows servers, should she be a member of the Oracle Technology Network or MSDN? Likely both; it doesn’t hurt to sign up. But where should she spend her time?

It’s tricky to make that call, and it largely depends on both the developers’ self-starter motivation and your own corporate culture. Some developer programs are free, but others aren’t, with prices ranging from a hundred dollars per year to thousands of dollars. Do you offer to cover the costs of belonging to the developer program for each architect, designer, coder or tester who wants to sign up – or do they have to go through hoops that send out the message that the programs aren’t important (or that the employee isn’t worth the investment)?

Let’s say that you are running a Windows shop, and being a Windows Server guru is seen as essential for career growth. Clearly, your bright programmer should grow and enhance her skills as a Windows expert. While deep Oracle expertise is essential, it might be a secondary investment for her time.

Of course, if your team is seen as an Oracle shop, and the Microsoft aspect is seen as secondary, then she should invest her time in Oracle technologies.

The scenario above is too simple. There’s no reason that the bright programmer can’t participate in two developer programs. However, what’s a reasonable ceiling. Two? Three? Five? Ten? If developers spread themselves out too thin, it’s hard to gain deep expertise. To my mind, a developer should engage with 3-5 development programs; probably no more. Depending on the situation, though, perhaps only one or two would be appropriate. If you have a developer who doesn’t see any benefit in belonging to a developer relations program, look at where he or she is spending time. There may be local user groups that provide the same level of engagement. But if you have someone who doesn’t want to engage at all in the larger world beyond his or her team — who doesn’t see the value of building deep expertise in products or platforms — you should be concerned.

Early in 2014, the market research firm Evans Data Corp. conducted a study on developer relations programs. They asked developers, “What most motivates you to seek solutions from developer programs?” The answers should not surprise anyone:

  • 35.5%: Need to upgrade from existing, outdated technology
  • 24.3%: Present skillset is insufficient
  • 21.7%: Present toolsets are insufficient
  • 8.5%: Anticipating future problems
  • 6.3%: Need to match or beat competition
  • 3.8%: Other

I’d keep an eye on those who answered “present skillset is insufficient.” Those employees are investing in themselves — and they are going places!

Do you and your team belong to developer relations programs – and if so, which ones? Write me at alan@camdenassociates.com.

Alan Zeichick, founding editor of SD Times, is principal analyst of Camden Associates.