Some Consulting Wisdom I Picked Up

I did a consulting gig for a few years at a very large government institution and I picked up some wisdom about how to best serve the customer (even sometimes in spite of themselves), how to remain sane, and how to maintain your scruples while doing it all.  I typed these up on Twitter awhile back and then forgot about ‘em. Several people encouraged me to blog them, so here goes:

Rules of Consulting

1st rule of consulting: Don’t expect the customer to be rational. If the customer didn’t have problems, they wouldn’t have needed to hire you.

2nd rule: ABS – Always Be Solving (problems). It’s better to solve a problem 80% correct and revise the 20% than wait for a 100% plan.

3rd rule: If you don’t know how to solve a problem learn or hire some time from someone who does.

4th rule: Never make yourself critical path as this will quickly end your engagement and resentment among your customer will ensue. Deflect glory to your manager — that’s a big reason why they hired you.

5th rule: Never complain. They have enough of that, that’s why they need you. You’re their machete in the jungle of red tape.  If you can’t take it any more, try to affect positive change or leave. There’s no crying in consulting!

6th rule: They don’t care that software is done right so don’t argue semantics, just do it right. Find a way to sneak in success. However, you should always be able to explain why these things are important and justify their use.

7th rule: Be a yes man in meetings and then do what’s right behind the scenes (clarification: Be positive and always on the side of getting things done and solving. Avoid confrontation in a meeting that might embarrass your customer. Defer arguments and confrontations until later).

  • Example: When the customer asks you to ‘filter all TCP ports through email packets’, you ask ‘what color would you like the background?’
  • Then later, come back into his/her office and suggest that in order to accomplish this you’ll need to [insert more rational feature suggestion here].

8th rule: If at any time you’re asked to compromise principles, find a way to avoid it or quit. Remember: Integrity is your main asset

9th rule: No one is ever served by job-protectionism thinking, especially yourself. Expect it from the customer (remember, that’s why they need you), but always resist it in yourself.

10th rule: You can’t win ‘em all. Solve what you can in your time and leave things better than how you found them. That’s really all any of us can do.

Other Bits of Wisdom

  • Never assume that management actually wants your project to succeed.
  • Not everyone in your group has an incentive to succeed (or to help you succeed).
  • The best way to ensure career security is to do your best and never, ever do anything that would put protecting you job over doing the right thing.
  • If, during a consulting engagement, you start taking on a employee role/mind set, quit right away or hire on full time. It won’t end well otherwise.
  • If your customer is hinting they want to hire you, you need to nip that quickly, don’t string them along in that thought.
    • Unless, of course, you’re entertaining the idea, at which point you’re no longer independent and you’re now operating unethically. Leave or join and do it fast.
  • You’re never as critical path as you think. Life will go on, maybe just not as well.

Related Articles:

    Post Footer automatically generated by Add Post Footer Plugin for wordpress.

    About Chad Myers

    Chad Myers is the Director of Development for Dovetail Software, in Austin, TX, where he leads a premiere software team building complex enterprise software products. Chad is a .NET software developer specializing in enterprise software designs and architectures. He has over 12 years of software development experience and a proven track record of Agile, test-driven project leadership using both Microsoft and open source tools. He is a community leader who speaks at the Austin .NET User's Group, the ADNUG Code Camp, and participates in various development communities and open source projects.
    This entry was posted in Consulting. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
    • Dan

      A nice summary of attitudes that will go a long way to ensuring success.

      Here’s another list I like that has a lot of detail:

      http://www.unixwiz.net/techtips/be-consultant.html

    • Rohit

      Some of the best words of advice for people in this line of business. I have practiced some of them myself and some I haven’t. Nobody is perfect. But I agree 100%. Thanks for the wisdom.

    • md aych


      ‘filter all TCP ports through email packets’, you ask ‘what color would you like the background?’

      That was brilliant. Thanks for the post.

    • martin

      I agree with most of these points, but I don’t know what you mean when you say “critical path” as in: “4th rule: Never make yourself critical path…”, and “You’re never as critical path as you think..”.
      I’ve been a freelance IT consultant since 2000 and I thought I know all the jargon. I thought it was a typo until you repeated it.

      Other thought I had on this article:

      I agree with rule #7, but not the first example:
      “When the customer asks you to ‘filter all TCP ports through email packets’, you ask ‘what color would you like the background?’”

      I think it’s a huge mistake to mislead just to avoid having to tell the customer they have no idea what they’re talking about. Tell the truth but don’t patronize, and resist the urge to express impatience or superiority over the client for their lack of knowledge.

    • http://www.par-4.org business

      So obvious but so right.

    • dillon

      @martin: I’d think something like “indispensable” — don’t ascribe yourself too much importance or you will get a reminder. Everyone can be replaced :)

    • http://Bryan.ReynoldsLive.com Bryan Reynolds

      Great post!

    • VISH

      GREAT !!!! I already follow many if them …..

      Be part of the solution and not the problem !!!!

    • Brushy

      Very useful tips – reinforcing what is always available but not always accessed!

    • http://www.girldeveloper.com Sara Chipps

      Nice to see that everyone runs into the same problems consulting. Words of wisdom.

    • Tone

      Wow, we had a consultant that broke many of these rules. Especially rules 4 and 9. It did not end well for sure. I am currently an employee but if I ever become a consultant I will review these first thing.

    • http://www.e-Crescendo.com jdn

      “1st rule of consulting: Don’t expect the customer to be rational”

      Oh, my, yes.

    • http://z0ltan.wordpress.com Timmy Jose

      Excellent article. I have no experience in consulting but I get the impression that the points that you put forth are borned out of good experience. I especially appreciate the lack of bilious, biased arguments that I have seen in many consultants.

      Thanks for the article mate.

    • http://bembengarifin-tech.blogspot.com/ Bembeng Arifin

      Great Post indeed!

    • http://shellshadow.com Jon Hancock

      the 4th rule: Never make yourself critical path
      can be tough when you are hired to code the harder problems. Doing the heavy lifting is of course is why you get hired and sometimes you feel there is no resource around to learn what you have coded.
      If at all possible, do identify someone “in-house” to learn what you are doing. It usually helps to alleviate the resentment problem.
      Great post and is a nutshell of my feelings from many years as an on-site “hired-gun”. I highly agree with your lessons learned.

    • http://www.jjude.com Joseph

      Wow what a list. Superb

    • http://coder.cl/ Daniel Molina

      I disagree with the rule 7th in your proposal. I think that one must be honest with the client.

      Many times when the requirements are taken the analyst is bypassing the technical feasibility, in this case you can’t be a “yes man”, and never.

      Some days ago, I’ve seen a project proposal to create a Java based Sparc simulator in less than one month terms, with many “yes mans” saying yes to that project proposal…

    • http://blog.donnfelker.com Donn Felker

      I agree with Daniel, I disagree with item #7.

      I’d rather tell the client their wrong in their assumptions of a project than say “yes” and work 90 hours a week to try to try to meet the project plan/spec/stories.

      I feel that its a waste of time to say “yes” in a round-a-bout way when you could easily cut them off at the pass and identify the problem up front.

      But then again, everyone is entitled to their opinion.

      Good post though. :)

    • http://chadmyers.lostechies.com Chad Myers

      Yeah, I knew #7 would be controversial and I should’ve been more specific, but I wanted to keep the list short.

      What I basically meant is: Don’t sit there and argue semantics in a meeting with the customer where you might embarrass your manager, etc.

      If you’re in a one-on-one, by all means try to drive towards specifics, but in a meeting with other people, avoid confrontation and drive to specifics at a later time in a more productive context.

      I say this from experience because if you bring up an argument over requirements in a meeting with more than one other person, it will quickly descend into a slap fest where everyone takes an opportunity to pot-shot/snipe at other people and rarely does anything productive come out of it.

      It’s better to go to each individual later and talk with them one-on-one and then drive towards sane requirements.

    • http://devjargon.com Adam

      The problem with #7 is that other people will think you are implementing it one way and will become confused if you do it another. I generally just find a graceful way to agree and disagree (and do it my way).

    • http://www.opgenorth.net Tom Opgenorth

      Good list. I’d add another very important point:

      #0: Humility. Clients typically don’t want a consultant coming in and making them feel small/stupid/insignificant.

    • http://blog.troyd.net Troy DeMonbreun

      Excellent list!

      I only take issue with the literal statement of #7, but I think I now understand the meaning behind your statement.

      Keep up the great posts!

    • dennis

      I agree with #7. Many times, its hard to convince your users upfront, especially when there are many people in the same meeting. But they are much more receptive when you go to them and explain things 1-on-1. Keep doing it enough times and you’ll eventually get them to accept your inputs on how some issues should be handled or to ask for added resources (manpower, time schedule, money, etc). Its even possible to have that requirement dropped if you push the right buttons.

      Just sharing my thoughts and kudos on the very informative post!

    • jlockwood

      @Chad

      This is a wonderful blog entry! I’ve been consulting for about 3 years now and have learned many of these rules through trial and error. The most important one were learned before moving over to consulting, which I think has been key to success. In fact, many of these rules should also be practiced by full timers.

      #7 seems to have stirred up a bit of controversy, but think about it guys, when has publicly embarrassing team members of managers ever paid off? The spirit behind #7 is “don’t get in pissing matches during meetings”. If a proposed solution is rejected during a meeting, let it go. AFTER the meeting determine why the proposal was rejected, adapt the proposal to address any concerns, sell the merits of the proposal to key stakeholders (or obstacles), then present it again (this time with some backing).

      #1 has been difficult for me, but I’m learning and I agree with it completely. Consulting can be ridiculously frustrating. If you can’t keep your emotions out of the picture then find some fulltime position. Getting angry with the client does no one any good. You’ll never create your little utopia on a contract, you simply find what works for the client, do your absolute best, compromise fundamentalist attitudes, then move on to the next gig. If you do well they’ll call you back for more work in the future.

      There is only one thing that I would add. Before I took the bold leap into the wild world of consulting Michael Feathers gave me what was probably the best advice to date (it regards personal finance). He told me to be carful not to change my lifestyle when I start seeing the bigger paychecks that consulting offers, but so pay myself when the checks come in and put the rest away. Contracts (especially subcontracts) can disappear at any time, often for reasons completely unrelated to performance. The “six month savings rule” applies especially to the contractor. If you don’t have the discipline to save stick with full time positions…you’ll find yourself hungry when the market dips.

    • db

      As a former tax preparer I agree with the last item stated by jlockwood (pay yourself and save the rest) except I would say “Pay the government, then pay yourself and save the rest”. When my husband and I were consultants I insisted that the first 30% collected (at a minimum) went into a savings account to pay our taxes. My husband was horrified by the amount that we sent in each year when we did our taxes, but at least we had set it aside. I saw many a contractor who did not have money saved to pay their taxes and they got into trouble with the IRS that they could not get out of.

    • http://hanson.gmu.edu Robin Hanson

      So why bother to have a meeting with more than one person if you can’t talk about anything useful there?

    • http://chadmyers.lostechies.com Chad Myers

      @Robin:

      In my experience, most meetings had nothing to do with getting things done, they were excuses to show off, score political points, bash/blame someone else, etc. So getting to brass tacks in most meetings was pointless and dangerous. You can usually tell when you’re in one of these meetings because there is more than 3-4 people in it (usually 10+).

      The meetings were the real decisions happen are usually one-on-one with your manager or in a meeting with just technical people (your team + manager).

      Even then, sometimes, the meeting isn’t about what it’s supposed to be about, so navigate carefully.

    • ralph

      As to the last, yes: In my experience, most meetings are for concluding business in public that has already been agreed to in private by the appropriate parties. A good meeting is designed to clarify what everyone agrees as part of a public ritual. There are other good meetings, such as those in which the agreement is about what is wrong or lacking. The result of my view, then, is that Chad is basically right as rain: in poorly designed meetings (the usual ones for consultants), try to be constructive and polite and non-confrontational and then meet the appropriate people individually. Once youv’e got straight with them, bring them all back into a meeting to restate what everyone thinks is best and attribute the success of that agreement to them. :-)

    • http://www.facebook.com/people/Deborah-Smith/100002400274841 Deborah Smith

      Hmm it looks like your blog ate my first comment (it was super long) so I guess I’ll just sum it up what I wrote and say, I’m thoroughly enjoying your blog. I too am an aspiring blog writer but I’m still new to everything. Do you have any recommendations for novice blog writers? I’d definitely appreciate it. Russian Food