Using contractors. (For our international readers: Although in the USA, “contractor” seems to mean someone who’ll knock down walls and put in a kitchen for you – possibly along with some new walls if pay enough, in the UK, in the context of a tech team, a contractor is a temporary employee paid on a daily – or sometimes even hourly – basis.)

We often get asked questions along the lines of “Do you know a contractor who’s an expert in X and can come and sort it out for us?” The request usually comes from someone outside the tech team. And the X that they are looking to get resolved is some technical “blocker” issue that’s currently slowing the company down. It could be anything from “AWS deployment” to “automated build systems” to “single sign-on” to “data encryption”. It all sounds terribly reasonable, doesn’t it? So why do we so frequently end up saying “You’re asking the wrong question”?

It comes down to thinking about whether the task really is a one-off piece of work on some free-standing part of your system – and whether your in-house team needs to understand how things work in this area. Sure, if you want to, say, migrate your email hosting from the Exchange server that’s been sitting in the corner of the office for donkey’s years across to Office 365 or Google Mail, then that’s a perfect task to get someone external in to do. (And, yes, we do know people who can help with this.) You’re migrating from a complicated system to a simpler externally-supported one. After the task is done, you won’t need all the details of how the transfer happened and you can securely wipe the old server (or taking down the firing range for a company team-building event).

But if you’re talking about setting up your build system or cloud deployment tools, you’re going to need to know how those things work – often at short notice when the dev team is trying to diagnose and fix some high-profile problem in your production environment. If they are relying on an internal system that stops working (because of some unanticipated edge case) and that nobody understands because it was built by a long-gone external contractor, then you’re going to feel a lot of pain.

At very least therefore, if you’re getting in contractors to work on your core systems, you’re going to want them to work closely with your permanent team and ensure things are properly documented and handed over.

But it’s more likely that you want to look at resourcing levels, training and prioritisation for your in-house team. A strong tech team is able to take on new technical challenges, and bring enough process to its architecture and testing to instil confidence (in the team and the wider company) that new things are understood, tested and working before they hit your production environment.

If you need outside help with anything from an architecture review to helping teams manage change, get in touch with us at Nimble Results.