Perhaps temper your working practices temporarily whilst still trying to gently lead the customer towards good practice.

Professionalism doesn't have to make you look pompous - if you explain why you adhere to certain standards, and explain what can go wrong if you don't, then you look like what you are - a skilled outsider with valuable experience to share.

I agree. I would not compromise my own integrity--personal or professional--to make a client happy. That said, I'm not sure it's an either/or proposition. I think I can remain professional but just present it in a way that is more comfortable to them...which, really, is part of being professional.

As an example...when I got there, we had a big meeting with me, K, and all the dev/tech people. K asked "is there any way that we can improve the accuracy of our estimates and/or development processes?" No one responded for several very long seconds so I put my hand up and started talking about Agile Development.

No one in the room had heard of it except one guy, their prime developer. He apparently has a mad-on about the idea, because he shut me down instantly.

I said "ok" and shut up. Then I started tracking my project in iterations, talking about velocity and user stories, etc. Other people are starting to pick up the language and adopt the concepts--and all without making anyone uncomfortable.

It's not that professionalism is bad, it's that nobody knows what that even means anymore. People now use it mostly to attack other people by saying that are "not professional".

I don't always agree that you need to make the client comfortable. They often have big problems which can be socially painful to fix, especially when they don't have the experience to know how to do it themselves (i.e. no dev machine, no sane testing process, and so on). They can feel threatened by someone who does know what they are doing, and they transfer that hostility to you. They fear change. It's just the way that some clients are.

When you think something needs to change, you need to find out why it's that way in the first place. There are probably some stakeholders in the group of people you are working with. Before you tell them how they should do it, find out why they decided to do it that way. Get names and history. This is really tough to do as a telecommuter since you don't have lunch or have other casual social situations where you're supposed to get this sort of information.

Once you have a better idea of the history, suggest small and easy changes, wait, and repeat. Your job is not to fix every problem right away. Feel satisfied if you can keep them moving in the right direction, even if it's not as fast as you would like.

You can't always give in to just get along either: you've probably been hired to fix things (not necessarily "shake things up" though). If you give in, you aren't doing what you were hired to do, and you have to figure out if you just want to do the job and get the paycheck or solve the problem.

It's not that professionalism is bad, it's that nobody knows what that even means anymore. People now use it mostly to attack other people by saying that are "not professional".

True enough. When I titled this thread, I was being a little tongue-in-cheek. I don't really think that professionalism is bad.

I don't always agree that you need to make the client comfortable. They often have big problems which can be socially painful to fix, especially when they don't have the experience to know how to do it themselves (i.e. no dev machine, no sane testing process, and so on). They can feel threatened by someone who does know what they are doing, and they transfer that hostility to you. They fear change. It's just the way that some clients are.

Hmmm...an interesting point. I think there's two levels of comfort involved. You can make the client uncomfortable on the "tactical" level--i.e., an issue that is socially painful to fix, as you put it--but on the "strategic" level they must always retain a respect for you and your competence. That strategic level is the comfort-zone that really matters, in the long run. (I think.)

When you think something needs to change, you need to find out why it's that way in the first place.

Actually, K told me (what he thinks is) the source of the problem: A, their chief technical guy, has had some bad history working at overly-formal ISO-9000-ish places and my formality was giving him flashbacks to that. That sounds a little simplistic to me...I suspect there were other factors as well. A and I have very different personality types; I very much doubt that we would ever be personally close. That said, I respect his technical skills--and I think he respects mine--enough that we will be able to work together just fine.

Once you have a better idea of the history, suggest small and easy changes, wait, and repeat. Your job is not to fix every problem right away. Feel satisfied if you can keep them moving in the right direction, even if it's not as fast as you would like.

Good advice. Thank you.

You can't always give in to just get along either: you've probably been hired to fix things (not necessarily "shake things up" though). If you give in, you aren't doing what you were hired to do, and you have to figure out if you just want to do the job and get the paycheck or solve the problem.

Heh. Not an issue. Sycophancy is not something I can do. :>

The last time I was paid by a company that was not ISO-9000 certified, I was working for the federal government of Canada. Over ten years ago. If I had one contractor like you ... my manager may have a small fit, but I'd be in heaven. Transparency, realistic dates, these would be awesome.

I'd like to point out that if you're going to be wrong on which direction to be formal, you've gone to the safe side. It is better to be more transparent and pessimistic than get management's hopes up and fail to meet the new hopes. You'll be blasted either way, but the alternative is significantly worse than what you're doing.

Not being in your shoes, it's really easy to say that you should explain your position to K - that the alternative could look even worse. Of course, explaining yourself is a lot easier said than done. I'm glad that my manager is the one telling me to do exactly that - overestimate rather than under.

Thanks for the support...it's great to hear.

I should have explicitly stated that K was not criticizing me. He was letting me know about a problem that existed, and making it clear that he did not have this problem. He was really appreciative of the transparency; his suggestion was that I continue to send the "transparency" emails directly to him and not to the members of the team who were being bothered by it.

K was also not just willing but eager to hear my suggestions for changes, and responded very positively when I made them--I told him I thought they should be using Subversion and, after I described the SV work cycle, he was ecstatic. K did me a good turn, letting me know about a potential issue early enough to address it, while also letting me know that I was valued and valuable. I have no complaints whatsoever. Just so that's all clear...I don't want to sound like I was slamming K.

Hm, I think one issue here is that they have different expectations as far as what a delivery estimate should be. They want to know when they can expect it: Mar 15, +/- 4 days. You're giving them the latest it will possibly be: before Mar 23.

Both are highly useful. They can know that they will not loose face with their client if they say it'll be done on the 23rd. OTOH, they can't know if they should start planning for what the people presently working on the project should be doing from the completion -- which is going to be on the 15th, more or less.

Like everything else, agree on your terms, or state them.

I'm going to have to agree with your gut instinct -- don't move the date up. Once everything's done and delivered, that's the date. If they want to move the required delivery date up, that's a change order. There are enough things that go wrong, especially when you start getting over cocky and promise it sooner. It's one thing to say 'we are on schedule to deliver early', and another thing to say 'We will deliver early'.

I'd stick with your guns, and do whatever it takes to feel comfortable, because when you're comfortable, you're productive. If they want to pay you more to do something you don't advise doing, then it's up to the two of you to negotiate what the equivalent price is for that discomfort.

I'd also like to restate your third point:

No matter how bad something is, don't suggest changing it until you've worked with the company for at least a month...maybe more like two, especially if you work remotely.

I'd prefer to say :

Don't suggest improvements without understanding the process. If something seems wrong, try to find out why it is being done how it is, as there may be parts of the situation that you aren't aware of.

The length of time that you've been working there may not have a direct correlation with your actual understanding of the process, and so stating a time period would be inappropriate.

I'd also like to restate your third point:

No matter how bad something is, don't suggest changing it until you've worked with the company for at least a month...maybe more like two, especially if you work remotely.

I'd prefer to say :

Don't suggest improvements without understanding the process. If something seems wrong, try to find out why it is being done how it is, as there may be parts of the situation that you aren't aware of.

The length of time that you've been working there may not have a direct correlation with your actual understanding of the process, and so stating a time period would be inappropriate.

That's a good restatement; better than my original. But I think it needs to have a follow-up point:

Even if you understand the process, you can't productively suggest changes until the client is ready to hear your input. This means you have to "pay your dues" in whatever coin their corporate culture requires--putting in the time, finishing a project, making a contribution, whatever--before you open your mouth.

Even if you understand the process, you can't productively suggest changes until the client is ready to hear your input. This means you have to "pay your dues" in whatever coin their corporate culture requires--putting in the time, finishing a project, making a contribution, whatever--before you open your mouth.

I would still argue that time is not a major factor. You have to wait until they are willing to be receptive to your comments, but it's amazing how that someone who has worked on the systems for 7 years as a developer / maintainer / user will be given less consideration than a contractor who has been brought in, and has spent less than 2 weeks looking into the situation, and doesn't even understand the technology involved. (where of course, you've been told that they're a subject matter expert on iPlanet Web Server, ColdFusion, Solaris, and Sun Cluster ... and yet they mention they had to remember those commands like 'mv' and 'cd' when you're in a meeting with them).

Some people are receptive to change, and some people aren't. Sometimes, you'll make suggestions in a meeting, and they'll be criticized, only for the same person who criticized you to bring it up a few months later, and try to present it as their idea.

In the case of contracting, it's an odd line -- you've been brought in to reach some end goal. Sometimes, you've given liberty to design the whole solution, and sometimes, you're just there to build something according to specifications that were made without your input. Your suggestion may provide benefit, but it may replace some other major change that is where the other person has made their reputation. Or, it may be that you've stated something so obvious that the higher-ups would have to wonder why no one else has ever suggested it.

Personally, I hope to never have to deal with these issues again -- there are too many people out there who are focusing on what's good for them, and not what's good for the company at a whole, or what's good for the customers of the company -- they're just too obsessed with running their own little fiefdom well, so they can get their next promotion / raise / whatever.

As a contractor, you must be professional.

Definitely. Know your stuff, show up on time, do quality work and get along with everyone else on the project.

You must be the client's idea of professional. This may or may not be the same as your own.

Well .. maybe. You have to get along with the people on the project. I would prefer to remain my own person, however.

No matter how bad something is, don't suggest changing it until you've worked with the company for at least a month...maybe more like two, especially if you work remotely.

You don't have to overtly tell the client that they're wasting resources doing it the wtrong way .. but you can educate them about alternatives that you know about that could offer them improvements.

Don't press to begin with .. if you have time to give them a very short demo, do that. If you're a consultant, one of the things that they're hiring you for is your expertise, your knowledge of the industry. If you can save them time and/or money, it's practically your duty to tell them about it.

If they choose not to take you up on your suggestion, that's their privilege .. and they may know thigns about the company which may not permit your suggestion.

You need to make the client comfortable. That means operating at whatever level of formality they use; less than that makes you look sloppy, more than that makes you look like a stuffed shirt.

Well .. maybe. This is like the second point -- you do have to get along with them.

If your people skills are so good that you can criticize someone for 40 minutes and, at the end of that time, they are chuckling ruefully and saying "thanks for telling me"...you have one necessary-but-insufficient attribute of an exceptional President/CEO.

Absolutely. That person deserves to be earning respect and big bucks.

Great post. Very interesting stuff. I love to hear stories from 'the front'.

By the way, the issue of picking the timing and manner for raising criticisms is important not just for contractors but for employees, trainees, interns, etc. as well. The main issue is not only that people won't give your views any credence until they know you better, or that it seems presumptuous to speak too soon after showing up, though those are both important. The main issue, in my view, is that until you have some real experience with the way things currently work in a particular operation, you're not in the best position to judge how to improve things.

This observation, and the amount of time you should wait, are both relative to the seriousness and obviousness of the issue. For example, a development group that plays with code changes in production because they have no dev/stage system is asking for a disaster. They should be advised of this pretty much ASAP, unless they have so few users in production, or those users are in sufficiently good communication with the dev team, that it isn't as big a deal. In that case, the issue is valid, but the urgency isn't the same.

To me, "professionalism" means that you are claiming (in a contractual manner) that you are aware of, and have accounted for, and will be responsible for all known ramifications of your actions ( or produced product) for your client. So don't confuse your "appearance or demeanor" with the contractual side of things. Thats why there are "recomendations".

Sadly nowadays, "professionalism" has been corrupted to mean "don't argue with me, I'm the expert". Futhermore, many "professionals" refuse to be held accountable for their mistakes. (i.e.doctors)

It's like the "suitcoat mentality", people have been trained to trust people in suitcoats, but there is absolutely no validity for doing that. Are you a "professional" if you show up, wearing a suit and carrying a laptop, and briefcase, but BS your way through the day?

All you can do is accept the advice the CEO gives you, or be prepared for "not having your contract renewed". It works both ways too, you can offer suggestions to your clients, or refuse all future contracts with them. </rant>