I'm a newly-minted (~1yr) contractor, providing specialist technical services (Machine Learning). I am on my second job; first one was great (more on that below) and in fact they referred me on to my new client. My current client is a technology start-up, with software developers but no-one else with my expertise. I am only 5 weeks in, but the new client is micro-managing the projects they set me despite a lack of understanding of the subject matter, steering the projects towards failure. I want to avoid this situation affecting my relationship with the first client, and ideally put my current job back on track. Any advice on how I could do it?

Normally, I would perhaps consider getting out of the project amicably and looking for something else, however the client is a company that has a relationship with my first client (they recommended me), and I am hoping for repeat custom from my first client.

How can I protect my relationship with the first client? I fear that if I push back or go away from the project, or alternatively continue as-is and not deliver as a result, that would adversely affect my reputation with the first client.

Besides, I'd rather do a good job with my current client, but my expectations here as low.

Examples of the difficulties I face:

  • The top-level requirements, scope or objectives of multi-month projects are changed weekly
  • My projects are micro-managed: the client insists that I work only on particular parts of the project (to first test viability). The results are good, but then the approach is canned because the client doesn't like the 'feel' of the approach (purely non-technical or non-business reasons), or it isn't a complete solution (as expressly desired by the client in the first place).
  • I am lectured on fine details of stochastic gradient descent or random forests and how they cannot possibly perform better than something my contact (a historian) thought up on his way to work. I then end up spending time resolving such queries, instead of furthering the project.
  • My work is discussed without me being present, and from what I gather, it is usually mis-represented, not out of malice, but out of lack of understanding. This affects the way the projects go, and ultimately my reputation as a problem-solver.
  • My suggestions of how to make more progress with more structure are heard with kindness, but not put into action.

Perhaps fault lies with me? Maybe I should behave differently in this environment? I don't have much experience of being a contractor, suggestions very welcome!

  • 2
    I changed "sabotaging" to "mis-managing", seems more appropriate in this context. Commented Oct 16, 2019 at 9:34
  • 1
    "The top-level requirements, scope or objectives of multi-month projects are changed weekly" if you are paid by results, rather than by time, this should require a material change to your contract
    – Mawg
    Commented Oct 17, 2019 at 6:46
  • 1
    "I am lectured on fine details of stochastic gradient descent or random forests and how they cannot possibly perform better than something my contact (a historian) thought up on his way to work." - run for the hills
    – Mawg
    Commented Oct 17, 2019 at 6:47
  • 1
    @Mawg - "run for the hills" - that's just too funny.
    – Justin
    Commented Oct 20, 2019 at 21:39
  • Or, as per Black adder. "Prince Edmund: They're coming! Run for the hills! Baldrick: No, my lord! They're coming from the hills! Prince Edmund: Run away from the hills! Run away from the hills! If you see the hills, go the other way!". The point here is "run away from the historian and all who consider him opinion of more worth than that of an expert whom they themselves hired for their expertise"
    – Mawg
    Commented Oct 21, 2019 at 5:55

4 Answers 4


You're working for a startup, probably delivering your work product to unseasoned engineers and managers. They micromanage you because they're anxious and inexperienced, and they think it's the best way to make their little company successful. (I know this: I have been that micromanager from a startup, and I have been micromanaged by startups.)

Their job is to get over their anxiety, stop thrashing around, and build some value. And, you're getting a brutal introduction to your job as a consultant to a startup: to teach them not only your specific trade, but how to make best use of consultants. You also have the job of educating your client (the historian) in the details of your trade.

Consultancy isn't just tech wizardry. It's helping your clients succeed at whatever they're trying to do.

Somebody at your first client referred you to these startup guys. May I suggest you contact that person and say something like, "Do you have a few minutes to talk? Do you have any suggestions about working effectively with this startup? From my perspective they're thrashing around a bit. Is there anything I can do to help them stay focused?"

(Don't disclose any trade secrets.)

This conversation will help you in several ways.

  1. People LOVE being asked for advice. You will build your relationship with your first client just by asking the question. Most people are honored when you treat them as mentors.
  2. The conversation will help you understand the startup situation. Hectic.
  3. You may get some good advice about the personalities in the startup, and how to work with them.
  4. You will be in control of the way the first client understands your consulting engagement with the startup.

This kind of thing, even though it's painful, is tremendously valuable experience for you.

Finally, keep in mind that it takes people time to accept advice. When you tell somebody, "you're wrong, here's why" they never smack their foreheads and say "doh! you're right, I'm wrong, we'll do it your way." Give them time. A few days later they will claim your idea as their own. For a consultant, that's the sweetest kind of victory.

  • Great response, thank you - changing the accepted one to this one in fact, as it most directly answers how to rescue the human aspect of the situation. Commented Oct 18, 2019 at 7:48

Well, that is a difficult client to handle. Here are the minimum things you need to try.

  1. Ask the customer for the most important requirements, in therms of QCT: the minimum mandatory description of the final product, the final deadline, the money they are willing to spend.

  2. Ask them to prioritize the requirements with regards to QCT.

  3. Assign time and cost estimates to requirements.

  4. Maintainan project plan, show them how the deadline is jeopardized by each sudden request.

If they react to this, you are lucky. You can go on, and build healthier project management practices with them.

You might be lucky to have someone to aid you, e.g. a boss in your company. That might prove a huge deal.

Study the contract you have with the customer and see the extend of what you can do to save the project. In which situations you can actually say "NO". Also, the maximum damage you can get in case of failure (of any kind).

Ask to have other people to aid you. While somebody does the rapid prototyping and viability, while someone else follows the healthy project path, to ensure at least partial success.

Perhaps fault lies with me?

Definitely NOT. I do not imply that you are perfect and there is no room for improvement, but what you are asked for is a total nightmare.

  • Thank you, this is helpful, I will try to phrase the project in these terms. I suspect they may argue that, as a start-up, their requirements and goals are somewhat fluid and project iterative - and that's OK by me. It is the amount of change and uncertainty that I'm struggling with. Do you think this approach would still work? Commented Oct 16, 2019 at 14:37
  • 1
    Upvote for fast/good/quick - I just had new business cards printed with that Venn diagram on the reverse :-)
    – Mawg
    Commented Oct 17, 2019 at 6:53
  • I changed the accepted answer to the one by O. Jones below, as it tackles more directly the tricky human aspect of the problem. This remains a great answer for forging a way forward, I am definitely trying this - thanks. Commented Oct 18, 2019 at 7:50

This may not help you resolve your immediate problem with this client, but I feel like you're (indirectly) learning an important lesson:

In any job, but especially as a contractor, you need to be aware of what type of work you've been hired to do. Generally, that means strategic vs tactical, or leader vs. doer. If you're being hired as a doer - someone who does tasks - you need to be OK with the fact that you can't control the leadership of the project. You need to be willing to work under someone else's direction. You may be an expert, and you may legitimately know better, but someone else is paying you to do what they want you to do.

If that makes you unhappy, you need to focus on finding projects where you will be placed in the driver's seat. Some clients will realize that they're not knowledgeable enough to control a project, and will be happy to hire someone who can make decisions and do work. The limiting factor with this approach is that you'll generally be stuck with smaller, less important projects, simply because once an effort gets large enough, you need multiple people segregated into different roles.

  • Thanks. Here I knew I'd be a 'follower' and that's OK by me, so long as I can deliver. My conundrum is that I'm asked to deliver X, working closely with the stakeholders, but they effectively constrain me so hard I cannot do what they ask me to do. Commented Oct 16, 2019 at 14:31
  • 1
    The thing is, if you're a "follower" then the ultimate strategic goal is out of your hands - you're being asked to do tasks, and the success of the project, or relevance of the tasks, is up to them.
    – dwizum
    Commented Oct 16, 2019 at 14:35

It seems like your client sees the contract as an unstructured prototyping exercise rather than a conventional SDLC project. They seem to be learning as they go, but may not recognise this, and they see you as a mere facilitator rather than the SME.

You need to persuade them that you are an expert in the field and get them to treat you as such. They need to be made aware that you have breadth and depth of knowledge. This may be difficult given the third bullet point. If possible, write things up (e.g. "activity x failed because of y and z, this is a common problem in this area and is usually dealt with by using method q"). If it isn't written down you are relying on the vagaries of memory.

Judging from the first two bullet points, they don't have an experienced project manager so you need to assume the role. Let them know about the risks and issues associated with the technical approaches they take (e.g. "I've seen this before and it doesn't usually scale up"). Again, do this in writing, preferably a formal RAID report.

It be that you don't like such an unstructured approach, or that you aren't the sort of person who wants to make a big fuss. That's fine, but in that case, the contract probably isn't for you.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .