This is the second piece looking at life as a contractor, when that
isn't your first choice of gig. The first part is here.
Please continue with me on this journey,
Contractor or Consultant?
Loads of people work as contractors and really like it. They like it a lot. Most of these chose to become a contractor at some point. Some have become full time employees of contracting firms. Of course, many of those firms prefer to be described as "consulting services." Whatever. There is a difference. I won't go on a rant about it here. Maybe later.
Having said that, part of the reason companies bring in contractors for software work is simple. They can be brought in for a specific purpose or task. They do the task. Then they go away - with money in their pocket.
They (well, me included when working on a contract assignment, so "We") are software mercenaries. Most folks don't like that description. I prefer "privateer." We get hired to do a specific task. We do it. We leave and go to the next engagement. Sometimes they want us to stay and do another specific task. Then the contract might get renegotiated. Or not.
Contractor? Consultant?
There is one thing I have not said about contractors, software mercenaries or privateers. If my contract is for a specific task - that is the task I do. I am not acting as a consultant. My primary purpose there is not to help them improve and make their world better.
Sometimes, if the contract is to be a ScrumMaster or "Agile Facilitator," that means my purpose is to act as a ScrumMaster and teach the team, or teams, about things "Agile" - or at least, Scrum. These contracts might be of a short duration, or fairly lengthy. They might get renewed - or not. Still, the fact remains - when the task is done, in this case, the teams are up and running and able to be self-sufficient so they don't NEED a ScrumMaster, I leave.
I tell teams I'm a bit like Nanny McPhee - "When you need me, you don't want me. When you want me, you don't need me." That is still a contract, although it does trend a bit to "consultant."
The difference is often rather mechanical.
Mechanical?
What does that mean?
An organization brings in someone for a specific purpose. For example, a person is on medical leave for a few months and the company needs someone to do the basic day-to-day tasks of the job so the wheels keep turning. That is a pretty typical temporary "contract" position. Fixed period and very specific scope.
Another company is getting bogged down in a software project and needs help getting it written and tested so it can be delivered on time. Maybe the same company needs a new automation framework to be developed to be able to more efficiently conduct testing for the same project. These are both typical "contract" scenarios. You have a set purpose, mission and expected end date.
The example from earlier, working as a ScrumMaster to get a team up and running within a Scrum framework. The task is to get the team to be working as a self-organized team, executing and delivering in a period of time. If they are reasonably well functioning to begin with, this can be very successful. If they are well functioning, this task will likely be impossible in a 6 or even 12 month time period. (This is one of the challenges using a fixed-date contract for a role like this.)
The contracts for these positions will usually define specific skills and abilities for the person filling the role, as well as expectations of what is needed. These will get circulated with various firms who will scramble to fill the roles - often presenting a slew of candidates in a short period of time.
Will there be challenges? Sure. Of course there will. Automation frameworks need to be weighed and balanced between several factors. Then designing the framework, and so forth. Completing these tasks takes a fair amount of effort and can sometimes be a challenge. In the end, however, the framework is fully functional and people from the client company can use it without considering how the framework was built.
In each of these, the important thing to the client is not that they understand how the thing was done, but that it was done. Because it was done, they can carry on with what they need to do.
It is likely you have encountered this before and have had contractors do work for you. Maybe not the huge, massive work like building custom designed house. More likely, bringing your car to an automotive garage for repairs or maintenance. Calling a plumber or electrician to fix a problem in your home is the same arrangement.
They are doing work for you - a specific task. They contracted to repair your vehicle or your plumbing for a given rate, normally within a given time frame. It is very mechanical.
But Consulting?
I know a fair number of people who do contract work and brand themselves as "Contracting Consultants." The challenge is, that is inaccurate for most of them. I know. People will point at specific things and say "See? I'm a consultant! Not a mere contractor!" Fine. Sure. One can use nearly any word imaginable to describe themselves.
When a consultant is brought in, the problems which need to be addressed are more open-ended and less well defined. There is a change needed, but what that change might be is often a vague idea in the minds of the client. It also might be completely inappropriate for what they say they want to address or achieve.
How is that different from contract work? I look at it like this.
A contractor will fix your car for you. A consultant will teach you about modes of transportation, find some that are most appropriate for your needs and then guide your decision making. They may also teach you how to repair your car yourself so you don't need to bring them in for automotive problems again.
They will help you become capable of determining what needs to be done then doing the work yourself.
A good consultant will lay the groundwork for future work, by satisfying their client's needs in a way that the client will turn to them for guidance and help in areas other than what they are brought in to address.
A contractor will help you "transition" your team to some form of "Agile" as you believe it is needed. A consultant will have the hard conversations looking at why you want to “do Agile.” They will help you determine if there is a reason to "do Agile" other than that is what everyone else is doing.
A charlatan is someone who comes in with a prepackaged solution branded with their company logo to fix your problems without knowing what those problems are. They excel at selling clients a bill of goods. All the while, they will tell you that this “solution” is right for you and they can help you implement it and get all the awesome goodness of “Agile.”
No comments:
Post a Comment