Role of consultant/freelancer when co-worker/employee performs sub-standard work?

Question

I've begun a 4-month freelance software position, as a senior engineer. The team is me, a manager and one full time dev.

My question is, what should I do when the full time dev does things like;

• puts code in production with blatant security issues (e.g. API keys embedded in the HTML),
• refuses code reviews & pair programming. Tells me i don't need to create PR's
• avoids conversations in the open (project slack channel) in favor of personal messages (private slack channel),
• employs "worst practices" daily in his coding, such as;
  • littering his committed code to master with prints to stdout,
  • never refactoring or cleaning up code,
  • discussing "the unit tests" with the manager, but which I find are just an empty directory,
  • discussing "qa" tests with me as if they're real, but which I find out haven't been executed in years and all fail,
  • codes with completely inconsistent style from one file to the next. Rejects suggestion that we adopt a coding culture we can check/fix with a linter, "It's only the three of us."

I always go for direct communication first right when something happens, but one can only bring up a certain number of critiques in a day without conflict.

I want to find out what a consultant's mission and job is. I'm realizing that this scenario is extremely common. In fact, it's the norm once you reach a certain level of experience and compensation. Companies are in crisis; they've painted themselves into a corner, software or peopleware-wise, and they're hiring you to "level up the team", even if they don't explicitly say so.

This itself is a big anti-pattern. But it's so utterly common, I've realized I need to approach it as an engineer; and build a collection of techniques for handling the various dysfunctional scenarios.

My first action has been to drink a lot to reduce my anxiety and tension. My second action is to ask my hiring manager for weekly 1-on-1 checkins with him to confirm the situation, my findings, and how I can best contribute.

EDIT: I've begun reading How to Win Friends and Influence People, and viewing lectures on lynda.com about handling conflict and being assertive.

Answer 1

Schedule a talk with the manager. List the worst practices you've found, and ask him point-blank: "What do you want me to do about it?"

No need to name any names - Both you and the manager know exactly who you are talking about.

Make sure to tell the manager that you are not getting the cooperation you need, if he asks anything about your relationship with Mr. Individual. You've already talked to Mr.Individual, and you should have established by now that the way to open a can is with a can opener not with your bare fingers. Or your teeth.

Answer 2

Short answer: You need to flag it straight away as a risk to the project outcomes that you have been hired to do.

I have walked in to this situation in the past. I was hired as a "gun programmer" to work with an existing development team. When I walked in, there were practices somewhat similar to what you are outlining here.

What I did was to simply point out that the internal processes were making it impossible to be as efficient or effective as I should be, and the task would take me many times longer to achieve than it would if the team was functioning properly. It is rather remarkable how pointing out time and cost risks can suddenly get an organisation's attention :)

To answer your specific question as to what the role of a consultant would be, I would answer that as "A consultant has been hired to achieve the best possible outcomes within the organisation within the scope of what they have been hired to do. If there are internal blockages to that, then they need to be raised so they may be addressed." Often those within the organisation simply cannot see their own internal failings until pointed out from an external perspective.

Answer 3

Its easy to assume you've been hired to fix problems and turn the place around and all that, but chances are - you've been hired to solve a specific problem (some code or product change) and that's it. You are not an employee, you are not a senior engineer at that company, you are the hired help. You are there to do what they ask of you, get paid and leave.

Now, its quite possible they've hired you as a 'pretend' employee and they do want you to fix all the issues with the product overall. But now you have an interpersonal problem with the real employee. He's the guy who works there full-time, it's practically his code you're working with and in all cases where I've worked, he will still be the guy working on that codebase when your contract expires. You can change things all you like, but he'll continue to do his own thing once you've gone and will possibly even delete or mess up all your hard work.

So you need to have an informal chat with your manager, explain in friendly but polite terms what you think of the development practices, and explain that the other guy does need some help or training or more experience. Say that you're willing to help out as much as possible (this sounds good as it suggests you're willing to go 'above and beyond' your initial role) but that regardless of what you think you're there to support and provide the service he expects of you. If he says that he just wants the project delivery performed, and all the rest is unnecessary, then that's the way it will be – accept it.

I expect he'll be interested in improving matters, but he will absolutely not be interested in alienating his employee. That means you'll have to pick which battles to fight with the development practices, small steps work best where they solve the worst excesses showing real progress to the other guy – once he sees how to do it better, and it makes his life easier, then he'll be more responsive to other changes. For example, from what you said, I think just showing him how to debug the code without printfs would be great, putting a full set of unit tests wouldn't be.

Answer 4

I had to chime in because I'm a designer and I just ended an assignment with a situation that was similar to this (Worked on a team of three, with the other person working more hours than me, making mistakes that I had to clean up.) The Boss knew about this and either gave me his work to fix or would come up with excuses for it. Overtime, this boss revealed to me that this person was related to them and they had no qualifications to do their job (they worked as a Janitor prior to this). But that they were "organized" and that was why they were there. But even this was open to question, as the person often didn't even save PSD files of the work he created. I agree with what senior-dev said that ultimately, you're a hired contractor here and you're not being looked at to give a lot of input but to do the work, and unless they make it clear that your role is to "save" the department, you shouldn't presume that's the case. But more importantly, I want to also add that because you're a contractor, it's a possibility that the boss knows about this employee and doesn't have any intentions of fixing their problems or wants to look the other way. There's a good reason this person is there and you need to watch out. And because of that, you'll only be here to clean up after them until your assignment ends. Ultimately, you're going to be treated like replaceable labor anyway, so should you make an assignment that's short term your problem?

I implore you to not let this place affect your health as my assignment affected mine and to try to find something permanent outside of this.

Answer 5

Generally, I approach my client (slightly) differently depending on whether they are my 'direct' client or there is a third party involved, who regardless of the circumstances wish to maintain their long term relationship with the client.

However, the coding practices here are near-catastrophic, so not mentioning them would border on negligence.

Merely telling the client about the situation will probably not have any positive effect - as it has probably happened before. Any freelancer who engages in a war-of-words with a long-term employee (even an incompetent one) is likely to lose. Only if the client already suspects their employee is incompetent, will this have any chance of working.

Instead - if at all possible - you should visually demonstrate what better solutions exist; especially in scenarios where the benefits will be obvious to non-programmers. This might get the attention of management - but you will also very probably have made a new enemy.

Personally, I would attempt to demonstrate the bad practices. If they insist on staying in denial, I would inform the client that I cannot help them and negotiate an exit. If they surprisingly choose to actually bite the bullet, I personally find no jobs more satisfying than cleaning up a code-wasteland.

Answer 6

Quote: I want to find out what a consultant's mission and job is.

My background: I was a freelancer working in electronic systems in the 1970's and then computing during the 1980's and 90's, here in the UK. During that time my wife and I raised a family and we now own and live in, without mortgage, a modest three bedroom home in a good neighbourhood (Surrey Heath). Our home is currently valued at around £250,000 (EU: €351641.60, US: $387262.50 according to google). In the 70's I was a sub-sub-sub-sub-contractor which meant other people got wealthy, while I did all the work, but I digress... I retired, partly for health reasons, at age 50. The term used for us in the 80's and 90's was "Contract { Skill-level | Function }" e.g. Contract Senior Systems Analyst/Programmer or "{ Computer | name of language | Function ] Contractor" e.g. Computer Contractor, COBOL Contractor, or according to my accountant, Tax-efficient LTD (US: LLC) Contractor!

Takeaway: My points are: I may know what I am writing about. Be your own boss. This was some while ago (hopefully still useful to somebody). Other regions on Earth may vary, and... MOST importantly for this discussion... that somewhere along the line the emphasis on contract seems to have been lost.

Assuming that you have a contract with the company / corporation concerned then carry on reading.

You may wish to set aside your engineering approach to this issue (Shock, Horror! OK, just for a short while). View youself as a business person might see you. There are some subtle differences! I have never described myself as an engineer. I have been everything from shop (US: store) assistant through coder to Department head at a sub of a huge US Corp. I've been an employee, a contractor, and hired (and fired) both. I believe that your intellect, your qualifications, and a large measure of common sense is your best guide. Your mission is entirely your call and if you document it and and refer to it often, it will form a large part of your individual success. The job (that you do for the organisation buying your services) should be exactly as specified in the contract, no less, and no more. You didn't specifically ask about strategy, but that is very important, and again, that is your call i.e. you figure it out.

I learned some of the above the hard way from experience. I later realised that at least two out of three of a Personnel department's "Three Tells" for permanent staff can be applied to Contracting/Consulting:-

1. Tell me what my job is (Job description, as per your contract).
2. Tell me how to do it. (Training. Vital for permanent staff. Should not strictly be necessary if you're selling yourself as a professional, but it is great to get paid to be trained in new skills!).
3. Tell me when I'm doing it right, or not. (Regular reviews with your supervisor (aka Customer) are essential, both for YOU and THEM. That is your time and theirs. It should be used to discuss matters only affecting yourself and not be wasted trying to correct other people's shortcomings. As Jane S. wrote, "...[blockages] need to be raised...". Correct, but are you sure they are not "dating" or "an item" even? Imagine now what names you would call yourself if that was the reason for management's apparent head-in-sand approach toward this employee! and worse: the reason they chose not to renew your contract!).

If you wish to discuss your contract, then your accountant would be a good place to start. She or he may advise you to either "suck it up" for the remainder of your four months, or approach the appropriate person in the organisation for a review and/or update of your contract. That should be done anyway as the end of your contract approaches. If you don't have an experienced, qualified, accountant then you're not really a professional IMNSHO. A good one will save you more than you pay them, if not, get a different one.

Your performance (and possible contract extension/renewal) will be not be assessed on how often you implicitly tell your customer that he is doing his job wrong. It will depend on how well YOU work and fit in with what we called the "permie's" or "permie-burgers!", i.e. the permanent staff. It is unlikely to depend on how adept you are at office politics. As a contractor that 'skill' is best left unused.

Unless of course your contract includes provision of (cough) Management Consultancy service(s). {wink}. Never forget: You are probably worth more than you think you are. Don't sell yourself short, and ENJOY what you do..

That is probably more detail than needed, I hope it helps,

Mart ~
~