This episode is part of a recruitment mini-series; where I will be focusing on various characteristics that I believe are important in recruitment. And while I believe many of these themes are universal, I will of course be focusing on software development. In this episode I ask the question if traditional recruitment, a permanent employee, is the right thing for you? While the first inclination maybe to advertise and recruit for a permanent employee, it may not be the right way of getting that extra help. And with the rise of the gig-economy and a shortage of skilled software developers on the market, sometimes you may have to look at alternatives. I'll also talk about the alternative options such as using contractors or outsourcing.
Or listen at:
Published: Wed, 12 Feb 2020 16:36:19 GMT
Transcript
First off a disclaimer;
I've been working as a contractor now for over 4 years. My primary mode of putting food on the table and paying the mortgage is finding, performing and then being paid for that contracting work.
While I obviously personally favour a contracting way of working for myself, I fully acknowledge that it is not the correct approach for all businesses requirements.
Contracting, and indeed outsourcing, have their place - and I'll talk more about that through this episode.
Possible as a surprise to my preferred way of working AND the title of this podcast;
In most cases I would advocate permanent employees.
If you think back to my discussion on product thinking rather than project, that should make sense.
I believe the best ROI is achieved when we consider our software on its full lifetime - when we consider it as a product.
If you consider the software a long lived product, then it makes most sense for the team operating it to be long lived as well.
A team that understands the software and has a focused interest in the long term benefit of the customer.
And that team is best made up of permanent employees that both embody the historical decisions AND are actively engaged in the long term future.
This is in direct contrast to thinking about software in terms of projects.
Projects by their very nature are finite ... They have an end.
Treating software as a project drives a focus on the immediate goals of the project ... Which can often be at odds with the long term ROI.
So, is there every a good reason to look for anything other than a permanent employee?
Yes of course there is.
Generally for me, it comes down to a Skills Shortage - either in the team or the market.
A skill shortage in a team will be a skill that the team simple doesn't have available to them.
A skill shortage in the market will be a lack of skilled permanents available to be hired.
A skill shortage in a team should generally be addressed with training.
Be that through formal training or by brining a contractor in to "upskill" the team.
You shouldn't be brining the contractor in to do the work and just leave. Doing so can actually causes considerable problem.
Not only does the team still not have the skill in the future, they are untrained in how to maintain the work that the contractor did.
"give a man a fish and you feed him for a day; teach a man to fish and you feel him for a lifetime"
By ensuring that the contractor is "upskilling" the team - the team are in a position to support the work and be able to perform the skill again.
This is an approach I also advocate anytime the desired skill is outside of the team, but within the organisation. Use those with the relevant skills to "upskill" the team rather than become the bottleneck as every team will be after that same individual.
A skill shortage in the market however is generally harder to fix.
For the last few years software development skills have been in short supply in the market. Especially those individuals with the experience to derive business value using those development skills.
Unfortunately demand continues to outstrip availability.
This will often make it difficult to get those permanent employees.
In these situation, I'd definitely advocate using the contract market to "fill the gap" if it is truly urgent. Using the contractors while you continue to source permanent employees.
This approach can help to take the urgency out of the situation and thus avoid the expensive mistakes of employing the incorrect people.
So that's contractors. Let's take a look at outsourcing the work.
I've have numerous experiences working with outsources in my career. Some very good …. Some less so.
I’ve worked with outsourced teams – both located locally and remote. I’ve managed some. I’ve introduced some to organisations. I’ve even worked for one during a transition phase of outsourcing an entire operation.
I’ve had the pleasure of working with some wonderful, capable individuals.
I’ve also felt the pain of dealing with a faceless organisation where the staff are treated as little more than interchangeable component parts.
Hopefully by now it shouldn't come as a great surprise that for me, the individuals – the people – are the key to the success of an organisation.
There are two main models when working with an outsources;
Labour supply and Service provision.
Labour supply is largely not much different that taking on a contractor. The Individual(s) will work with you as if they are part of the team. I've had success with this where the individuals where based with us for the long term and to all intents and purposes act and behaved like permanent employees.
Service provision however is something that can seem very attractive, but for me is largely a discredited model.
I find that the service provision model falls foul of many of the same problems that I find with traditional project management work. Generally a lot of waste due to misunderstandings and poor hand offs between teams.
For me, that is doomed to failure.
I remember talking to an ex-colleague who has previously worked for large UK pharmaceutical about his outsourcing experience. He described a dysfunctional mess where the outsourcer would work solely from written requirements. His team would then receive the work to validate. More often that not his team would then have to re-write the entire work for it to be suitable.
I personally doubt that the fault for this lay with the outsource - rather I would expect the process itself to be the primary culprit.
I can understand that if you don't consider software development to be a core competency of your organisation that it would be attractive to hand this off to a "professional organisation".
And in some cases it maybe the only practical option available to you.
But for me, the success of any organisation will be based on just how capable they are at working with technology and bespoke software development. Not having that competency will ultimately be a limiting factor.
One last thing I wanted to touch on in this episode is the rise of the "gig economy".
There are those in the software development industry that expect it to become much more "gig" based. Effectively with the majority of developers acting as contractors on a project by project basis.
This would cause me some level of concern as, even though I operate personally as a contractor, the "project" based work is prone to poor quality and low value - as I have discussed previously.
If the industry does move to a predominate "gig economy", I think it will need to consider how it balances that dipping in and out working behaviour with those a professional engineering culture.
In this episode I've asked the question "is a permanent employee the right thing for you?"
I've provided my reasons behind why I think that permanent employment is likely to be the best long term path for a software product.
I've talked about situation in which using short term contract resource can assist a team.
I've then talked about outsourcing and my own personal experiences with labour supply and service provision.
And finally I touched on the potential future of the industry as a predominately "gig" economy.