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
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!
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
For example, responding to a bid on a large business
project ($500 +) with a bid like:
I can do it - accept my bid
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
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
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
A SIMPLE BID FORMAT
Your bids should always include the following
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.
1st 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.
2nd 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?
3rd 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!
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
Your goal when submitting bids is twofold:
Getting the buyer to respond to your initial bid.
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
Areas of Expertise
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
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:
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.
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.
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.”
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
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
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
Rule #3 – 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
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
The “Golden” Rule – The Client is always
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
Back to 'Articles for Coders'