Secrets of Effective Communication for Coders

By Michael Sharp

Rent a Coder Top 10 Coder

I first joined Rent a Coder on August 27, 2001 as a coder, with the intention of picking up a few extra dollars to offset the cost of my ISDN connection, which is rather expensive in Greece.  Since that time (17 months later), I’ve completed 147 projects and more importantly, I have a substantial list of terrific buyers that I work with again and again through RAC.

If you’re new to RAC or even if you’ve been around for a while, I’d like to share with you my thoughts on how I’ve accomplished this so far. There are no great secrets to doing this – it really comes down to one thing: Communicating effectively with your buyers!

FIRST CONTACT

Projects are won or lost in an instant; and most often it hinges on the first impression you give the buyer. This does not just include the amount of your bid, but rather in how well you present it, as well as yourself.

For example, responding to a bid on a large business project ($500 +) with a bid like:

I can do it - accept my bid today!

is a sure way to lose the project.  A buyer who’s about to spend $500 or more with you is going to need a lot more information and what you just did is tell them you don’t make much of an effort on the things you do. 

While the response above might work on a project bid at $5 or $10, when responding to a bid request, it’s always a good idea to repeat back portions of the request such as:

The file handling routines will not present a problem but we should discuss the details of your printing specifications.  From your description I think we may need to use a third party control. Please contact me to discuss the project details at your convenience.

The paragraph above shows the buyer that you’re interested in the project and willing to discuss it before actually being awarded the project.  Not surprisingly, I’ve won many projects simply because I made the extra effort to discuss the project via private messages before being awarded the project and buyers have repeatedly told me that other coders won’t do this!

Next, it’s important to present yourself in a positive light – don’t use strong, demanding or negative words and phrases such as I expect, you must, you will, I won’t, etc.  Although you may not mean anything in particular by it, the buyer may feel that you’re too demanding and look for a coder they feel is easier to work with.

If the bid request asks for a sample, then provide one – if the buyer wants to see a sample of your work and you don’t provide it, there’s almost no chance you’ll get the project, period! Why? Because you’re telling the buyer that you can’t be bothered to follow even simple instructions and even worse – that you’re uncooperative!

Based on some of the bids I’ve reviewed when I post projects as a buyer, let me also suggest that you never criticize the buyer, especially about their bid request.  The buyer is typically using RAC because they lack the expertise or resources to do the project themselves; given that do your best to politely ask for clarification about anything you may not understand – but never, ever criticize!

Always remember that the ball is in the buyer’s court – they don’t have to choose your bid no matter how low it is, nor do they even have to respond to your bid.  You should also consider that the buyer may be posting a small project to “test the water” before posting a substantially larger project.

A SIMPLE BID FORMAT

Your bids should always include the following information:

Salutation – This is simply a greeting such as, Dear Mr. Sharp, Hello Michael, or, if the buyers screen name is impersonal, even a simple “Greetings,” can be effective.

Right away, this tells the buyer that you’re a cut above the others because you’ve taken an extra moment to personalize the bid.  You’d be amazed just how important this is!

Avoid using “Dear Sir” unless you are 100% certain the buyer is male – no point in offending a buyer because of their gender.

1^st Paragraph – Think of the first paragraph as an introduction, in other words, briefly tell them who you are and what it is you’ll be discussing in the bid request.  For example:

My name is Michael Sharp; I’m an experienced web developer located in Greece and am interested in bidding on your project. I’ve reviewed your bid request in detail and downloaded your attachment as well. I’ve recently completed 3 projects that were similar to what you’ve described in your bid request. Based on my own experience with this type of Internet project, I have a few questions to ask as well as a couple of suggestions to offer.

Right away, I’ve told the buyer who I am, where I live (sometimes this is very important) and I’ve briefly mentioned my experience in the area covered by the bid request.  I’ve also mentioned that I have a few questions and would like to offer advice to the buyer.

2^nd Paragraph – This is where you go into the detail of bid request, i.e.; ask any questions and provide and suggestions to let the buyer know that you’re interested and that you’ve actually read the bid request.  For example:

First, I’d like to ask if your site is hosted on a Windows or Unix server.  If you don’t presently have a host, I can recommend a low cost one that I’ve used in the past. Next, I see that you would like a Flash introduction.  I’ve designed several appealing flash sites – may I send you some samples? 

3^rd Paragraph Forward – Try to group your topics into logical paragraphs – for example, talk about design elements in one paragraph and database functions in another.  Use as many paragraphs as needed, but the size of your proposal should be commensurate with the size of the project.  In other words, don’t write twenty paragraphs for a $30 project – that’s really overkill.  Conversely don’t write just two sentences for a $500 project – that’s ineffective.

Summary Paragraph(s) – Briefly summarize what you’ve written about the scope of work; acknowledge the deadline, the bid amount and any closing comments.  For example:

All things considered, I think your project goals for somewebsite.com are achievable in the timeframe you’ve indicated.  Adding flash as I mentioned will really make it an attractive site.  If you have an opportunity to reply to my questions I can refine my bid, which will be in the neighborhood of $500.

Signature – If you review any of my past bids you’ll notice I always sign them something like this:

If you have a few moments, I’d also like to ask you to review my online resume and past client comments regarding my performance on their projects.  If you have any questions, please don’t hesitate to contact me through RAC at your earliest convenience. Lastly, I want to wish you the best of luck on your project and thank you for using RAC!

Best Regards,

Michael Sharp

I use my full, real name because quite simply it’s a more professional presentation of myself.  When I first joined RAC I was using a screen name, which was counter-productive; people who are spending money want to know whom they’re spending it with.

This is your chance to set the tone right here by letting the buyer know that they are dealing with a professional.  Remember too, that not everyone automatically accepts the lowest bid – buyers are more receptive to a person than they are to an Internet identity; would your rather take a chance on a Michael Sharp or a vbExpertFromMars? 

RAC recently implemented the signature feature which I find to be very useful – I actually made a table that contains my signature and a number of incentives that I offer each buyer; take advantage of it to save yourself time while maintaining the quality of your bids.

Because RAC is a blind bidding system, it’s not necessary or even really desirable for you to follow up or “hound” the buyer about your bid.  If they’re interested, they’ll contact you – don’t risk annoying them and losing the project by sending multiple bids or pushing them to accept your bid – you’ll most likely just “push” them into accepting someone else’s bid!

YOUR RESUME

Your goal when submitting bids is twofold:

1.      Getting the buyer to respond to your initial bid.

2.      Getting the buyer to review your resume.

If you followed the bid outline in the previous section, you’ll take care the first item, and now your chances of getting the project can be increased dramatically by having a good resume for buyers to review. 

You may not think of your resume as a communication tool but it is and it’s an extremely important one.  Your resume is a personal statement about yourself, your experience and your abilities.  If you don’t have a resume online at RAC or if it’s sloppily written, then you risk giving the buyer the impression that your work is sloppy or carelessly done!

Your online resume at RAC is broken down into two sections:

1.      Areas of Expertise

2.      Resume

RAC allows the use of a number of html tags to “dress up” our resumes and you should take advantage of them.  Firstly, in the Areas of Expertise I recommend making a bulleted list of your skills.  Emphasize any item that you’re certified in to give yourself an edge. 

Approach it logically but don’t overdo it; except for other “techies” a lot of the arcane terms and acronyms you’ll use are meaningless to many buyers.  List the obvious ones and what you’ve done or can do in those areas.

Also, consider this; if you just sort of lump all your Areas of Expertise into one long sentence, you’re really not showing the buyer that you can manage to layout even a simple html page for yourself – that’s going to hurt you when you bid on web projects.

Next, you need to go back to the basics when it comes to the actual resume portion – list your education and/or qualifications and then any work experience you have.  Follow this with a personal statement about yourself.

Unlike traditional resumes, in my own case, I’ve chosen to not list my education and past work experience in lieu of a series of personal statements about who I am and what I will do for the buyer on their project.  There are several reasons for this:

1.      My guess is that, like myself, a substantial number of coders at RAC have earned either a bachelors or masters degree in some area of computer technology or engineering so it’s really a moot point.

2.      Since our clients are located all over the world, the particular university you graduated from is probably not going to mean much to a given buyer – mainly because they have no way to verify and compare this to university standards in their own locality.

3.      The same thing really applies to your past work experience; if you were the Director of IT Services at XYZ Company in Greece for example, it’s a good bet that no one outside of Greece has ever even heard of it before and again it cannot be compared to companies within their own locality.

However, because a resume is really a personal overview of who you are, you may choose to follow a more traditional approach – there’s nothing wrong with doing this at all as long as you present the information in a manner that’s consistent and logical.

If you review my resume, I speak briefly about myself and sort of “roll up” my experience in the first paragraph.  I use the next couple of paragraphs to highlight what I will do for the buyer on their project and then, I leverage an advantage I have as an English Teacher. 

That may seem unusual for a programming site, but if you review my past projects, you’ll find that I’ve completed a number of documentation projects that I might not otherwise have been awarded.  This is a good example of emphasizing a skill that stands out from other coders to give myself an edge.

After my signature (again, using my full name), I’ve written a few personal statements regarding my clients, Rent a Coder and also asked the buyer to review my past projects and client comments.

Lastly, take advantage of all the space RAC provides to give the buyer as much information as possible.  Although my own resume is quite simplistic, many buyers have commented to me during private bids that, “I’ve looked at your resume and was really impressed.  I think you’re exactly the sort of person I’m looking for.”

CUSTOMER SERVICE

Obviously, your prior client’s comments are important to how prospective buyers view your work experience with RAC.  Although you may think that you have little or no control over these comments; how those comments are written are entirely up to you as I’ll explain below.

Another way to look at effective communication is to think of it as just plain old-fashioned customer service.  I can pretty much guarantee you that the primary reason my repeat clients come back to me has far less to do with my coding ability than it does with my customer service skills!

Over the years, I’ve learned some important rules concerning how to deliver customer service to my clients and they’re really common sense.

Rule #1 - Treat every client as if they are your only client!

If you’re working on ten different projects, quite honestly that’s your problem and not any particular client’s problem.  They’re paying you to work on their project and they deserve to have you focus on it.

Rule #2 – Always view the project from the client’s perspective!

Odds are, the client is not a technical person (or they wouldn’t be here in the first place, right?) so you have to put yourself in their shoes.  What does the client really want?  The biggest mistake coders makes is to automatically assume that they know what the client wants better than he or she does.

A project should always be discussed in detail with the client; I see our role as one of guiding the client to help them achieve their goals. 

Rule #3 – Communicate, Communicate, Communicate!

In the global village of the Internet, we’re fortunate that we have the most powerful tool available to us for effective communication – email.  Unlike with traditional business models, we can communicate with our clients 24 hours a day, 7 days a week about their project and receive immediate responses to our questions.

A client should NEVER have to track you down to find out how their project is going.  I am continually amazed (when I post a project as a buyer) that many coders to not use email effectively. 

For myself, I spend approximately an hour a day sending emails to my clients to keep them apprised of their projects.  As I get to know each client, I make sure that my emails contain the amount of detail they want to receive.  Even if the client is not responsive, I still do my part.

Rule #4 – Keep the client involved in their project!

As the project moves forward, follow rules 2 and 3 rigidly!  Ask the client questions, show them samples or screen shots and suggest alternatives to them.  Remember its their project not yours – and they deserve to have their say in how it proceeds.

Rule #5 – Tie the ribbon on the project!

Ask yourself what else you can do to go the “extra mile” for your client to show them that you’re a cut above the rest.  For example, providing a simple help file, or a custom logo for a splash screen (at no extra charge) will demonstrate this to the client.

Explain the project in as much detail as the client wants.  Answer any questions or provide support for technical issues promptly.  Follow up the project with an email a month or so later to find out how things are going. 

The “Golden” Rule – The Client is always right!

You’ve all probably heard this one many times in the past but the truth is, few people follow it.  The bottom line is that the client is paying you to deliver a product or service that you’re obligated to deliver the way they want it and when they want it!

Given that, advise the client an guide them as best you can, but ALWAYS deliver what they want and not what you think it should be!

WHAT LIES AHEAD?

Sometimes I get the distinct impression that many coders aren’t thinking beyond their current project or about how their work on a given project affects other RAC coders. 

If you’ve won a project and are working on it, you should be thinking about future projects with this same client.  The best way to accomplish that is to simply do the best job possible for them.

Also, you may want to consider a few other things as well.  For instance, I just checked at RAC this morning and there are 611 open bid requests posted at the moment.  Now, realistically, there’s no possible way any one of us could take on all of those projects – in other words there’s plenty of work for everybody, if we work together. 

How can we do this? You might not realize it, but your performance on a given project affects every single coder at RAC! If you do an excellent job and the buyer returns with a new project, there’s always the chance that another coder can work with them (especially if the project is outside of your particular area of expertise).  Doing a great job also lends itself to the client speaking positively about RAC to their friends who may ultimately become buyers themselves.

Conversely, if you do a really bad job you’ll end up driving the buyer away from RAC, which hurts all of us.  And it’s not only the loss of a buyer – that buyer is going to tell 10 of his or her friends about their bad experience and those ten people will tell two or three others about it.  Even worse, those 20-30 people will have a bad impression of RAC without ever having experienced it firsthand for themselves!

Although we are not employees of RAC, we should think of ourselves as an intrinsic part of a large, successful organization.  This means that in addition to promoting ourselves, we also need to promote RAC – the more happy buyers there are, the more work there will be for all of us in the future.

Each of us has a responsibility to do our absolute best, not only for the buyer but for RAC as well – we owe it to ourselves and to each other to do our part to continue to keep RAC as the premiere freelancing site it is!