Whether a solo consultant or part of a consultancy, what would you say a consultant's typical roles and responsibilities are?
For further actions, you may consider blocking this person and/or reporting abuse
Whether a solo consultant or part of a consultancy, what would you say a consultant's typical roles and responsibilities are?
For further actions, you may consider blocking this person and/or reporting abuse
Jimmy McBride -
Oliver Bennet -
Yan Levin -
Jimmy McBride -
Top comments (20)
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 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.
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!