On 'Resources' vs 'People'

All too often we consider developers a commodity. We don't use the term 'developers', much less 'people'; we use words like 'resources', 'bodies', or 'headcount.'

One of the things I dislike the most is hearing people say, 'offshore resources'... as if we don't know where they are or who they are.

For us at least, they're people and they live in India.

The fabled off-shore land

I'm not saying it's management's job to acknowledge and consider the details of everyone's lives. I know there is a bottom line and there is work to be done. However, some middle ground would certainly be nice. When you start abstracting that your coworkers are people who are living a life, and only look at them for what they are capable of producing, I think it's you that's lost your humanity.

This goes for contractors too of course. There's tendency to only think of contractors as someone there just for a specific purpose. And to an extent, that is the deal. You're hired purely for the skills you have and to do a specific job. The employer isn't expected to consider you as a person; one with aspirations and goals. You're basically just an interchangeable part that the organization can swap out as they see fit.

Of course this makes it easier to find talent and get the users stories moving across your Jira board. But where it breaks down is when you rely long-term on contractors. And I think it's not only doing a disservice to the individuals, but to the whole team and ultimately to the organization itself.

Most of my team are contractors, some of whom I have worked with for years. We rely on them heavily to get our day-to-day work done, and without them, our entire project would come to a screeching halt.

There's a natural tendency, after a while, to want to change roles or move forward in your career. And I think that should be encouraged. The best people are the ones who strive to improve and want to have a greater impact.

There have been a few occasions where contractors I've worked with for years have wanted to either convert to a full-time employee, or move to a different role. I know not every request can be fulfilled: sometimes there just isn't a full-time position available or an opportunity to switch teams. But I think we should make a greater attempt to encourage people to grow their career. We should enable them to take on new challenges and accept new responsibilities.

If we don't, they won't stick around. They will search for an opportunity elsewhere and they will take all the knowledge of the industry, team, code base, and how to work within your organization with them. As the void left by them is attempted to be filled, it will slow your team down. It doesn't matter how talented their replacement is, there's always a period of on-boarding before they can really expect to be productive. I've found this to be, on average, measurable in months.

How long do you think it'll take to learn your code base

In short, it's in your best interest to see your resources as people. You should expect and encourage their development. Hopefully you'll have a place for them, but if not, you'll be better off having a system in place to handle the inevitable turn-around and keep your team running smoothly.