Working for an engineering company I’ve heard myself uttering this sentence quite a lot in the past years. The reason being my fellow colleagues not quite understanding how dealing with external development partners feels from a customer’s point of view. Note, that there is not “one” view here, but at least two:
- The customer’s management who brought you, the external developer onto the team to help.
- The actual team of your customer.
Note that these are actually two distinct groups that may or may not have aligned conceptions of what an external developer should and can do.
Why do companies hire external developers?
As I’ve been on the other side of that gap I’ve had the experience first hand: In a lot of cases management will bring on external developers for one of the following reasons:
- Progress is too slow
- There’s too much work to be done
- A new technology must be introduced and there’s nobody around with experience with that tech.
- Very specialized knowledge is needed for a short amount of time (e.g. writing a driver for a custom chip or similar)
Now, if we look at these points, and try to figure out the meaning that is communicated to the customer’s team (or, more to the point, “what the team is likely to understand”), something like “Hey guys, we’ll bring in external developers, because you’re not up to snuff” might come to mind. And this is – quite frankly – what happens a lot, although few people will realize this – in fact I’d go as far as saying most people will not notice that they have a bias against the external developer.
Now, how does this fit together with this article’s tagline? The tagline is obviously a strong exaggeration to get the point across, however: Given, that the code an external developer produces for the customer will mostly be worked with by the customer’s team, that probably has the mentioned bias, the external developer will have to produce code to a higher standard of quality than the internal developers. If the code we, as externals, produce, does not exceed the customers quality bar by some margin, our use will be limited to coding something to spec, just as the “regular” coders. Even worse, our code will be constantly scrutinized to a much higher degree, and there is a real danger, that the customers team will question the value, that is created by their engineering partner. This will of course at some point reach the customer’s management which spells bad news for our relationship to the customer.
This whole situation is actually a tad bit worsened by the fact, that an external developer will usually neither have the same degree of domainknowledge that the customer’s team has accumulated over the course of years of working with the respective domain, nor will the external have in depth knowledge of the codebase he/she is tasked to work with, which will inevitably lead to mistakes and bugs in the delivered code. This is especially true as few companies (especially medium sized ones) have requirement processes mature enough to be able to actually lead an external team efficiently (I’ll write another article on this topic).
SNAFU?
The situation seems bleak, the odds are stacked against us, so what should we do?
As stated before, our homebase should be, to deliver quality that surpasses
the quality bar set by the client’s team. However: There are a couple of techniques that will in most cases remove the bias a customer team has against us:
- Communicate: Ask questions. A lot. Asking the customer teams questions will show them, that you care about the code that has already been written (if you manage to see past the inevitable skeletons in their closets). Stay humble – these people have built a living at your customer, they may even have designed the code you’re struggling to understand, so bitching about that code will not win you any friends, as we all grow attached to the things we designed, even if it has three arms and some very hideous warts).
- Socialize: Don’t just be the guy that is from the other company, be visible, make sure, the rest of the team knows a face to the name. This makes a world of a difference in people’s attitude towards you.
- Own up to your mistakes. Mistakes will happen, probably quite frequently in the beginning. Trying to weasel yourself out of them will paint a bad picture of you. Be a pro, accept your mistakes.
- Never ever compromise quality. Not even if the customers project leader asks you to do so. It’s not the PL who has to live with the “hack” you might feel compelled to write, but the team. And they will be mad if they git blame the respective part of code and the name of an external shows up. If you really really have to have some kind of hack, consult with the team and document the decision.
These points seem simple, but can pose a challenge, given that software developers tend to not be very talkative.
TL;DR
Know that your customer’s team will not necessarily welcome you, and that you will have to actively work towards being accepted by delivering high quality code and by making yourself visible/audible.
Image Credits : Power Digital Marketing