What is the difference between a DevOps Consultant and a DevOps Engineer? This question recently came up and I wanted to add my thoughts on the topic.
lets address the fact that consultants are almost always hired to work
on a specific project or to address a specific issue the company is
facing. As such, the role of a consultant will probably always be
different than that of a regular employee. The regular employee has to
deal with the mundane job of ensuring the lights are on, email, ongoing
projects, operations, regular development tasks. The list goes on.
a lot of ways, consultants are free from this type of scenario, and can
focus on the one task or 5 tasks at hand. As such, sometimes
consultants can get more done than a regular employee that has other
responsibilities. Also, and because they are seen as experts in their
areas, sometimes, the views of consultants are more highly valued or
taken to heart by upper management.
that out of the way. There is a difference. The article does stress the
teaching, part. I am not sure that it really stresses the transformation
part as much. A devops consultant, if they are good, will pair up with
people at the company and help teach how devops works, and how to
successfully transform a company and a group. They are brought in to
look at a situation with fresh eyes, and potentially help shift the
entire way that a group is doing things.
does not mean that there is really a difference in skill sets between a
devops engineer and a consultant. But if there is one, I would say it
is around teaching and the ability to focus. There is also the other
part, and that is the business acumen that consultants learn because
they tend to have to deal with people from all levels of the company.
the other hand, consultants, unless they are on a long assignment, may
find that while they are making high level changes, do not always have
the chance to get their hands dirty. This depends on the company they
are working with, and what the job entails. So, a devops engineer, can
end up having more time developing solution, whether it be configuring
CICD, infrastructure as code, automating application deployments,
automating error responses. Because of this, consultants sometimes have
to dive deep on side projects to ensure that their skills are staying up
to date with what is currently going on. Tongue in cheek, but sometimes
it is just the opposite, and they are scrambling to learn the tool that
the customer is using so they can help with that project.
other reason people bring in consultants is because there could be a
skills gap. Company A, realized that they are not moving fast enough and
need to change. They go to the IT guys and that group says, “Not my
job.” In that case, they bring in consultants because it is quicker to
hire consultants than it is to hire full time people. And, unless you
are just going to run your company with consultants, you should be
bringing on full time people to learn from them or to be filling those
roles as the consultants leave.
A bit long winded, but I hope it helps. Ping me if you have any other questions. I have been on both sides of the fence.
Oh. and travel. Consultants normally have to travel.