Your Constraints Define your Success

Recruiting good developers is hard.  In my own experience hiring developers, One of the things that was the hardest thing for me to learn is that who I worked for and our toolset defined what cross section of developers would apply. I ended up rejecting all the candidates that came across my desk because I didn’t understand that fundamental rule:

Your constraints define who you can recruit.

In my particular case, I worked for a government contractor that worked on a Winforms project for a large government agency.  Our build system was TFS.  The best thing we had going for us was that we were working in C#.  A secret clearance (or the ability to get a secret clearance) was necessary just to step in the door; and that further limited the programmers we were able to hire.

Looking back, it’s really hard to believe how naive I was about this.  Think about today, if someone wanted to hire you for the following:

• Large Government Contractor
• A Winforms Project that uses .NET remoting
• Version Control and build system is TFVC and TFS
• Bug tracking system is some enterprise software you’ve never heard of
• You need a secret clearance
• The project itself is uninteresting
• 3 month release cycle

Would you take the job?

All other constraints (benefits, pay) being equal, you probably wouldn’t.  In fact, let’s say you had to choose between this job at 120K, and the following job at 87K?

• Small, private company that has worldwide brand recognition and a has purpose driven mission.
• Working on many different projects across languages and frameworks
• Whatever tools you need to get your job done
• A polyglot platform shop
• Git for version control, Octopus deploy / Fabric for releases
• You pick your developer set-up
• Agile; continuous delivery

For me, at least, that jump is worth it.  Being well paid but working in a dead-end technology and not having the ability to learn new things just doesn’t compete.

More-so than ever before, our developer tools are evolving at a rapid clip. Just a few years ago git was still used only by the bleeding edge of developers; and now it’s being used by multiple teams at Microsoft.  Microsoft even included support for Git in early 2013 for TFS.

The quality of developer you’re able to recruit is inversely proportional to your constraints. If your environment exudes an atmosphere of “We can’t change”, then you won’t attract good developers; at best you’ll attract developers who are comfortable with your toolset (unnecessarily limiting the talent pool).  The lower the constraints on what your developers are allowed to use, the broader your talent pool.

Today, Webforms is already out of mainstream popularity, .NET 3.5 is falling to .NET 4.5, and TFS  even loses to Github for teams that work at the company that made TFS!  If you’re still targeting your team to what was popular in 2011, you’re going to miss what’s next.

If you’re the manager of developers, you may not stay up to date with the latest trends. That’s ok, because developers are pretty ornery creatures. We’ll tell you when we think something is broken.  If your developers are complaining about your tool chain, that’s a sign that the tools don’t meet their needs.  Instead of doubling down (because of sunk costs), ask them why, and be prepared for the answer. It may not be the cheap answer, but it is what they believe.  If you give your developers the latitude to fix problems in code, why not give them the latitude to fix problems in their tools?

Your Constraints define who you retain.

I’m not saying you should chase technologies, for instance the JavaScript framework de jour, but you should keep an eye on trends; and where the broader programmer community goes, you should as well.

Staying current with tech trends isn’t just about recruiting and retaining your developers, it’s also about making sure they’re staying up to date with their peers.  As the story goes, a CFO asks the CEO, “What happens if we invest time and money to train our people and they decide to leave?” To which the CEO responds:  “What if we don’t train our people, and they decide to stay?”

There are some things you just can’t change: If you work for a large corporation or government contractor, you can’t change that.  What you can change is your internal developer culture. Keep it fresh.  If you’re still using Perforce or TFS and your developers are complaining, consider moving to Git. Both TFS and Perforce support git now (I wonder why that is?).  If you hear complaints about your work item tracking system, consider moving to something less painful, like Trello.

The more core a technology is to your system, the harder it is to change.  The great thing about your toolchain is that unless you have a pretty messed up work flow, they’re not core to your business. They’re tools. They can change (and they should be able to change pretty easily).

Your constraints define how well you can compete.

If your business isn’t willing to change to embrace new technologies, your competitors may be willing to. While you’re dealing with branching and merging issues with Perforce or TFS, your competitors are easily able to deploy new features and handle complexity.  Every moment lost because your toolchain doesn’t meet your needs is another moment you lose to your competition.

If you want to recruit the best developers, keep your best developers, and compete in the marketplace, remember, your constraints define your success.