Everyone looks for an edge in recruiting the best talent. In my opinion, there is a simple thing you can do to help your organization bring in top tier technical talent – update your technology stack. If a job candidate asks what version of Java you are using and you say Java 6, do you think that has helped or hurt their opinion of your company?
As of right now, if you are running Java 6 you are way behind. Java 7 would be a reasonable answer, but if you could say you have everything updated to Java 8 and have been enjoying the new features, you’re showing the candidate your commitment to technological innovation. That could definitely help sell top tier candidates, who can see how the company’s continuous improvement culture can translate to a personal development culture, making your company the right position for them.
Your technological state is especially clear on the Microsoft stack since Visual Studio versions are named with the years in the version; it’s the same for SQL Server. People asking for experience with Visual Studio 2008 quickly give the impression that they probably don’t care as much about building good software as people running Visual Studio 2013 or 2015. New versions may require a slight learning curve to pick up new functionality, but the improvements are worth it if quality is your highest priority.
Starting a new project from scratch you want to pick technologies that will have continued developer interest, mindshare, and a talent pipeline. Lots of people would look at those factors and choose something safe. However, new projects are the best opportunity to try something new. If you do what you’ve been doing just because “it’s the way we’ve done it before,” you risk eventually becoming a laggard. Top talent isn’t going to be interested in working for a company that isn’t showing an interest in new ideas – top tier talent is ideally interested in developing and presenting new ideas.
Image Courtesy Wikipedia
I’m not saying you need to become an innovator, or even an early adopter, but you have to be willing to try a new technology to see if it’s right for you. If it isn’t, then you have an articulable reason to give for why you are using a more dated, but more appropriate tool. Testing out a new tool doesn’t need to be on a big project, but the new tool should be something that is the right fit for something specific that you are doing. You shouldn’t force a tool on a project because it seems interesting, if the specifics of the situation won’t give you an honest chance to evaluate it. No need to engage in résumé-driven development.
In addition to the big tools and frameworks, most projects use lots of smaller tools and libraries. These can be a great benefit to developers, and give another opportunity for small-scale innovation and flexibility. But, each of these tools/libraries version independently and need to be kept up to date; even a small tool still creates overhead and a certain testing burden to keep up on any libraries you pull in. Examples include nuGet on the MS stack, Maven/Ivy on Java, and RVM/RubyGems for Ruby. Tools can help keep the little libraries up to date and organized, but then they themselves add yet another tool that should be kept up to date. And that’s a benefit too for a company. Think of each update to a small library or tool as a practice run at updating a larger library. You have to find appropriate ways to push out a new version of the library or tool to everyone, and have the testing infrastructure to say that there is no problem with the new version. You decide to make the change, regress the system and then push it out to everyone else. The scope of the tool or library being upgraded doesn’t really matter, other than determining the size of the impact if there is a regression.
If your organization is struggling to try new things or keeping up on updates because you’ve been “too busy” and you are considering hiring, try and see if you can use this line of argument to prioritize updating your tools and libraries to put your best foot forward for your candidates.