There’s 3 common roles that software engineers will commonly be engaged in, and it tends to be a progression. The words are sometimes misused though, and the distinction between them is very important!

Employee is the easiest to understand, and most common. You are employed by a business, you are on their payroll, and you probably work fairly exclusively for them. There’s usually some kind of management structure, you’ll usually have some kind of objectives linked to your pay and bonuses. In this kind of role, you are part of the company, and while you can hopefully influence policy and processes it’s not usually your main purpose.

Contractor is a particularly murky one. You are technically independent, and not on the payroll of the company you spend your time helping, usually through either an umbrella company or your own company. The role of a contractor varies hugely. Some businesses draft in whole teams of contractors, and treat them essentially as short term employees, to put “bums on seats” to try and get something done. Some will bring in contractors for specialised knowledge, which becomes almost like a consultant role, where encouraging change is a bigger part of what you do. Generally though, a contractor is there to do a defined thing, in the way that the business want it done.

Consultant is very different; you are here explicitly to help (not to do), and explicitly to help the company work out what to do, guiding strategy. A very common mistake, especially among consultants who have only recently changed from contractors, is to be too passive, and to operate as though they were employees/contractors.

There’s a 4th category, which is common, but often mis-labelled, and that’s the “consultant team”. A large part of the playbook of the big “consultant” companies is to bill per person per day, and to put whole teams into their clients businesses. The name “consultant” here can be a mis-fit. Often, there are some true consultants in these engagements, who mostly guide strategy, but the more “consultants” are on-site, the more likely it is that they will act or be treated like contractors or employees. That’s really not good!

The key difference is this: If the business know what they want done, and how they want it done, and aren’t expecting much change, then a contractor is a good choice – they will come in, do a specific job, and go. If the business want to change, because they know that what they’ve been doing hasn’t given the results they’d really like, then they need to bring in a consultant, who acts like a consultant, and treat them like a consultant. A consultant is there to tell you what to do, and how to do it – and that advice is how they add value, to what you do. A contractor or employee is there mostly to do what you want them to do, how you want them to do it, although good ones will suggest improvements and listening to these is wise.

If you are brought in as a consultant, and find yourself being seen as a contractor/employee, then you are in a dangerous situation. You won’t be able to do what you are there to do as effectively as you could if the role was seen correctly, and while it might not be entirely your fault, it will reflect on you! Remember that you are there to help a client achieve a transformation, and this is what your success is scored against.