Whether a solo consultant or part of a consultancy, what would you say a consultant's typical roles and responsibilities are?
I've seen a few types of consultants.
One type, to borrow from Ken Blanchard, are "seagull consultants" who fly in, make a lot of noise, dump on everyone, then fly out. You'll often find them flocking around ERP and CRM implementations. They come in, insult the staff and leave without really doing much.
Another is the body shop consultant. This usually happens when a company wants to put the "Mythical Man Month" to the test by adding more developers to a project that's already behind. Here you'll find a lot of underpaid H1B workers and those willing (aka desperate enough) to take a low paying temporary gig with toxic management.
Both of those are the usual result when management has become frustrated with their in-house team. But there are positive ones...
The utility consultant is someone brought in to fill a role temporarily. For example, a legacy application might need support and maintenance while a new application is developed. It's not a bad gig if you don't mind working with older tech (like VB6 or Powerbuilder) and if the original system isn't a horrific mess.
Project consultants have a similar role. They're used to complete a specific project that the current in-house team doesn't have but the company doesn't want to hire someone perm to do for one reason or another. For example, a company that has an iOS app might bring in an Android consulting team to do a conversion.
Expert consultants are typically engaged when a business needs someone to coach their team on a particular area they need help with to move forward. For example, a team moving from desktop to web based applications might need someone to help them get over the initial learning curve.
A good list, but I'd add one more:
The Scapegoat/Punching-bag consultant is someone who can come into a team locked in a stand-off between management and the rank-and-file to make the "unpopular" decisions. This can be anything from recommending a large-scale reorg, killing-off a project, or (in the worst case) layoffs. By bringing in a consultant to do these things, management gets to save face while the rank-and-file blame the "damn consultant".
I briefly worked as a "strategy consultant" it's amazing how much people will pay not to deliver the bad news
I'm currently a consultant working at a big technology consultancy. It's funny you ask this question because I've found that just when I think I understand the entire scope of what being a technology consultant entails, I transition to another project and my roles/responsibilities change drastically. With that experience in mind, a consultant's responsibilities are to be flexible, adept at anticipating client needs, capable of guiding clients to solutions that are best for their overarching business goals (even when those conversations are difficult and may cost the consultancy work), and very competent at reading whatever markets they operate in. The hard skills like programming, systems engineering, and a solid grasp of DevOps concepts are important when you're talking about technology consulting specifically. However, I find that the soft skills are the differentiators across different types of consulting. If you acquire and fine-tune those skills then you can accomplish a great deal.
In my experience, the job of a consultant is the exact same as a full time Software Engineer job at the company, just using loopholes (well, they're illegal, so not really loopholes) to pay me and others less, give less benefits, lock us out of the "fun stuff", etc. I would love to be an actual consultant. lol
The job of a consultant is to help a client deliver on their own goals and commitments. It is to advise them on the best way to reach those milestones in order to be successful.
Sometimes this means a consultant jumps in and writes code. Sometimes it means talking to an executive team about iterative development can transform their business. Sometimes it is just listening to the problems folks are facing.
A consultant is not an escape hatch, but a partner.
I've been a consultant and I've been a dev who's worked with consultants. Typically consultants(usually a team) are devs who know how to get things done, including coding, setting up the best practices, adopting agile methodologies. They get the requirements and help move things in the direction to production. They bring in expertise on all areas, not just dev but also product management and everything.
When I worked with consultants, we had a lot of things that needed to be set up and planned for production. We brought in consultants. They helped us, set things up (technology, stack, practice), enabled us in everything and once they left we took on a steady pace.
Pivotal, ThoughtWorks have some of the best consultants. They're engineers who are hired by clients for their expertise, or at least that's what I think. The catch is you'll never know how they will sync well with your team. I've worked with some amazing consultants and some shitty consultants as well.
I once worked at a "DevOps" consultancy. I was just hired labor and "staff augmentation". Like most jobs reality rarely matches up with the ideal. Ideally you'd go in and fix problems so the client could deliver value to their customers. The reality is that you just end up mired in internal politics at the client site, internal politics at the consultancy, and the ultimate customers ends up getting less for their money.
A slight digression from the current post but Spotocles looks pretty awesome! When are you planning on launching?
Thanks for the compliment. I'm dreading implementing the AWS integration because I've done it before and their APIs are not pleasant. My plan was to start this weekend on the control and allocation logic.
Hey, at least their documentation is crystal clear :). Would love updates as you make progress. Also, check out Computes. Seems like something you may be interested in and not sure if you've heard of them!
I consult and I typically like to consider myself as an outside perspective. So many companies create a bubble and start to think more about how they've done things in the past compared to the learnings of other companies. Especially the companies outside of their industry...
I come in and offer an outsiders perspective that belongs to no "bubble" and has experience in helping people see the bubble they're in.
From what I've noticed, a lot of companies I worked with don't care to keep up with the outside world when it comes to development. They rather just grab a consultant to bring them up to speed and repeat the process in 6 years.
As far as responsibilities, whatever your core competency is.
I've been a software developer consultant, as an employee for Analysts International Corporation. I was not an independent consultant.
I had five gigs placed at various companies while I was there. Each one was to work on a specific project.
The reason for each of those companies to get a consultant rather than have or hire an employee work on the project was (in my assessment) due to not having an available employee, or not wanting to add staff.
Effectively, I was used as project spackle for a relatively temporary position (under a year). And, in my opinion, that's an appropriate use of a consultant.
I enjoyed working on a variety of technologies: PickBASIC on PickOS for accounting and inventory software, C on DOS for a train & track control system, C++ for ISDN on OS/2, built a server application using a C API to run an automated telephony routing system, and form creation software in C++ w/MFC on Windows.
The train & track system was stressful, because a bug in the software could have dire ramifications. The lead developer / architect had designed a beautiful system: the C code was well structured, well documented, well thought out, and well refactored. That was the only application I worked on that I was on a team, and had 3 testers to every developer.
The form creation software gig was the most aggravating, because I was working on printouts without a computer to compile, run, test the software for four months. When the computer they ordered me finally arrived, another employee co-opted it and I got his old machine. That was okay by me, his old machine was completely adequate for what I was working on -- but a month later he was laid off (I was not privvy to the details). And that did not sit well with me, since my values is a company gets rid of consultants when it tightens its belt, and keeps employees. Not vice versa.
I left consulting mostly because (to use an analogy) I did not enjoy always feeling like a guest in someone's house. My preference is to be part of the family.
The thing I miss most about being a consultant is that you could focus on the project, and did not have other company demands on your time. As an employee, I find that I have team meetings, planning meetings, review meetings, department meetings, division meetings, company meetings, offsite meeting, training, HR required this-and-that, all of which cuts into project productivity time.
I'd like to separate a few concepts in my response.
I think there are two types of consultants: Real ones, and contractors using the word consultant.
Real consultants get paid because they leave their clients better than they found them.
Contractors work with a defined solution (Sometimes without a problem) within scope, time, and budget constraints.
Both sets have to manage their execution, budget, and scope of their work. They both also have to cope with invoicing and hand-offs.
Differences appear in how contractors focus on building a solution, and consultants focus on the problems. You hire a "Consultant" to migrate you to the cloud and you'll have things in the cloud. Maybe it'll all work, maybe it'll be something the company can use and manage. Maybe not. If you hire a consultant, they'll understand the desires and needs behind the request. Seek alternatives, and only then move towards a solution that fits the client's desires and reality.
The contractor style has a surprisingly high chance of achieving technical success while simultaneously being a disaster. The contractor style claims victory because the scope was satisfied and invoices paid. A consultant can only claim victory if the client was satisfied and invoices paid.
I have a simple test that I use on myself and others. The test is a simple question: What is keeping you from offering a money back guarantee?
The more I focus on being a real consultant the less troubled I feel about offering such a guarantee. The more contractor style and others who work like this think the proposition is insane.
People underestimate how much the purpose of hiring consultants from firms is to fill out a development team temporarily so that those people can be fired without the company having to report it. If a significant number of employees lose their jobs because a project ends, it makes news and signals problems to investors. If consultants lose their jobs with a client in the same way, nobody cares.
"A consultant will borrow your watch and charge you to tell you the time", or so goes the joke.
I've been a consultant with one of the largest professional services firms in the world. I think the single most valuable thing they can bring is an outside perspective.
Sometimes a company is so deep in their problems that they cannot see the wood for the trees. The people within the organisation may have the answers to the problems, but the company is structured in such a way that they cannot or will not listen to input from their own people.
An effective external consultant can come in and bring a fresh point of view to the executive level decision making process and effect change right the way through the organisation. Sometimes this is with new ideas and new ways of thinking, or sometimes it is with the same thoughts and ideas that people within the company have held themselves but for one reason or another have been unable to bring to bear on the organisation as a whole.
As mentioned elsewhere, there are different levels/types of 'Consultant':
Not to be flippant, but I'd say that there's really no such thing as "typical" roles and/or responsibilities. Roles and responsibilities are as individual as the organizations seeking services and the problems needing to be solved. Worse (ironically?), one of the biggest problems that frequently — possibly even usually — needs to be solved is understanding the actual problem to be solved. If the customer fully doesn't understand the problem (and what constitutes successfully solving it), there's pretty much no way they can engage a consultant/consultancy and reasonably expect success.
Helping the client make the right decision for them.
Not the easy decision, or the choice of least resistance in the organization. Not the quickest fix or coolest new tech.
The right choice, for them. That's sometimes the hard choice. It's sometimes saying "This has to be re-done, there's nothing salvageable" and sometimes saying "Let's experiment with this!"
It's helping them understand what you understand, so that soon they won't need you.
I haven’t worked as a consultant yet, but We have had consultants working for us in my company. We had consultants who worked on site and remote as well.
We generally choose consultants if we want to get some thing done in a short period of time, one time activity.
I can throw in two examples.
One where we wanted to setup and train our team in Android Open Source Project for our custom built devices. We hired a consultant who has done Google Developer Expert Certification and who teach a popular course in Pluralsight. With that credibility we initially had our rough patches with them for couple of weeks where we were complained about the build environment, practices etc., However once we got past that obstacle, the team really jelled and worked closely with him and get the project done. All we wanted was to finish the initial build setup and train us in customizing. He got it done in about 3-4 months. We have had no troubles since then. One thing I should mention is that his hourly rate was outrageous and literally close to 2-3 full time developers hourly salary.
The other example is where we hired an iOS developer as consultant for re-designing our existing app with in 4-6 months duration. He was working remotely, and comes to on-site twice a month. The first one month, we got daily commit notifications, weekly reports of the progress. And then onwards it started decreasing and we broke the contract in the third month as we didn’t receive any updates and we couldn’t reach him at all. He came back after 6 months but my company wasn’t interested in hiring him again.
Lessons that we learnt,
P.S: Right now we have two consultants working for us in a legacy project. One on-site person and another person working remotely (Both has great work ethic and we love working with them).
let's start another SEO oriented post
let's start another SEO oriented post
dev.to, not even once
Considering I'm someone who's considering doing accessibility consulting...Stalking this thread haha
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.