At a time when competition for technically skilled employees is peaking, your organization will win over more tech talent by becoming a place where developers can do more than grind out code. A rigid top-down IT strategy might scare them off.
Competition for tech skills is growing by leaps and bounds—because everyone needs it, but not everyone has it—so your organization’s attitude toward technology matters more than ever.
Today, associations need the technical resources of development teams more than developers need associations. In the DC region, for example, tech talent will have more choices than ever as the area preps for the arrival of Amazon HQ2 in the coming years. And tech professionals may be able to command larger salaries than associations can typically pay.
Which means that your mission might be the thing that gets developers in the door at your organization. The thing about mission, though, is that it only goes so far when there’s no context for technical employees—or one that fails to use their tech skill to their full potential in advancing the mission.
Is this something that your organization, if it has room for in-house development, is ready to counter? It might require some reflection.
Is Bottom-Up Innovation Needed?
Recently, TechCrunch had a great piece discussing the evolution of open-source software from modest phenomenon to major industry player—something highlighted by two major acquisitions from last year, Microsoft’s buyout of GitHub and IBM’s purchase of Red Hat. Both acquisitions were in the billions; the Red Hat deal was in the tens of billions.
That growth didn’t just happen overnight. The TechCrunch piece, written by Index Ventures General Partner Mike Volpi, breaks down exactly why open-source tools turned into juggernauts and the basis for many major companies. He lays out numerous reasons for this shift, but one that particularly struck me was the fact that open source crept up in many organizations—not dictated as part of a contract deal initially but as a result of developers finding or even building useful tools, running with them, and pushing them up the food chain.
(A great real-world example of this is the web programming framework Django, which was invented by a small group of programmers at a newspaper, the Lawrence Journal-World, only to be later open-sourced, where it gained broad popularity.)
If this sounds like “shadow IT,” yes, it’s along those lines—and I tend to think that allowing employees to play with new tools is actually a good thing from an innovation standpoint. But developers play a different role—they’re literally building the next iteration of the organization’s technical stack, and they need the flexibility to test and experiment.
“Open-source software permeates itself through the true experts, and makes the selection process much more grassroots than it has ever been historically,” Volpi writes. “The developers basically vote with their feet. This is in stark contrast to how software has traditionally been sold.”
This goes against the traditional procurement model often used in nonprofit and government contexts—the kind where big companies show off their wares in expo halls and conference rooms. But it’s also more direct and will likely lead to larger technical solutions, as the developers have a level of buy-in that they never would if they’re simply working on stuff based on someone else’s contract.
Are Your Developers Developing, Or Just Building Tinker Toys?
Now, to be fair, vendors are an important part of the association ecosystem, and they carry water in disciplines in which your staff may lack expertise. On the other hand, I worry that on-staff developers might feel boxed in if there are too many limitations on how they can use their skills, whether because of management edicts or technical silos.
To put this another way, hiring a full-time coder to essentially program a handful of widgets that plug into your existing software is likely a waste of your time—and theirs. If they have a skill set that shows innovative thinking, allow them to use that thinking! If they’re able to do more with their skill set than write WordPress plugins, take advantage of that!
And if you don’t have room to do it right, ask someone externally for help. Again, vendors exist for a reason.
(And there is a counterpoint to this, going back to the Lawrence World-Herald. The employees who built that web framework created something so impressive that the company for a time sold technology based on it—until the employees left for greener pastures, competition cropped up, and the development budget declined. Now the World-Herald runs on WordPress. It’s a saga that highlights just how hard it is to maintain a good dev shop when it’s not your specialization.)
Over the years, much has been made of Google’s famous 20 percent policy, freeing its employees to spend 20 percent of their time working on passion projects. Part of the reason for it is that skilled developers need mental space to come up with creative ideas that might help solve bigger problems.
If you’re putting your devs to the grind of serving only your existing needs, it might discourage them from seeing the future. Give them some room to breathe. It might help keep them around—and you might benefit from what they create.