Freelancing
I’ve been a freelancer/consultant/contractor/mercenary for many years now. However, until now, I used to do that on the side. Few months ago, after thinking a lot about it, I finally decided that freelancing was what I wanted to do. I left my job and started my own adventure.
The first reason for this switch was a desire to be more involved with my clients' projects and accept bigger projects. Then there was the obvious flexibility brought by this new position (I can now work wherever I want, usually on my deck). Finally I have to admit that financially things are better now.
This post won’t be about helping you deciding if you should freelance or not. I’m just curious to know how you work, how do you deal with your clients, deadlines, payments etc… So instead of simply asking, I’ll explain how I do it and I hope that you will share your ways of doing it.
How do I do it?
Choose a client
Clients are the heart of your business. At first, you might be worried not to find enough work and you will take any project. WRONG! this is the worst thing you could do. You would not take any job just because they are willing to give you a salary, would you?
I. find a match
Personally, I believe in Agile methodologies, regular code release, iteration planning, daily stand-ups, test driven development, continuous integration… This is what I call my ‘work values’. If I see that a potential client’s ‘work values’ are opposite to mine. For instance, he might like the waterfall approach, writing a lot of documentation before we start coding, doesn’t see the essential need for a good test suite, then I know we would not be a good match.
It doesn’t mean that I’m right and she/he’s wrong. It simply means we don’t work the same way and that a work experience together might be frustrating for both of us.
A lot of clients don’t know how to approach software development and they might not have strong ‘values’ yet. In this case, I explain how I work and I try to read their reaction. Sometimes, you can agree on a ‘trial period’. Being freelance, you are more than likely free to quite whenever you want. However, you’ll find out that is not a good experience for neither of you.
II. Check on the project
My first rule when it comes to choosing a project: if it doesn’t interest me, I don’t take it.
It’s very simple: to do a good job, I need to be passionate. If the project is boring or simply doesn’t attract me, I know I won’t be able to serve my client the best I could.
Second rule: Code review
Often, you might be contacted by people who already started a project but for some reason need you to take the project over. That happens often when a client tries to save money by taking the cheapest guys around (often overseas) and realize it doesn’t work for them. Or maybe, your client’s main developer had to leave and they need your help. Finally you have the case of a project growing and they simply need more people to work on it.
I always ask for a code review before I accept a job. Why? Simply because a CEO can tell how much he believes in Agile software development, that he has a portrait of David Heinemeier Hansson above his bed and that he knows getting real by heart, a quick look at the code will reveal the truth. It will also tell you a lot about the other guys who worked on the project.
-
testing suite: do they have any? Rspec? Unit test? Selenium? What’s the test coverage? Do the tests pass?
-
test readability: Did the developers try to be clever and the code is very obscure?
-
best practices: Did the team follow most of the best practices? Why not?
-
reinventing the wheel: Did they make a proper usage of plugins/gems.
-
living on the Edge: Are they running on Rails Edge? Would it help?
I usually don’t worry much about how they deploy, since that can be changed easily.
Looking at your code review I try to evaluate few things:
-
what’s the team’s tech level?
-
what kind of pressure the administrative people put on the tech team?
-
what do the teach value?
-
do I need to rewrite a lot of code?
-
do I seriously need to improve the test coverage?
-
is it a real mess and I’d better give up before starting?
A few months ago, Jade Meskill recommended I read “the dip” from Seth Godin. If you haven’t read it yet, get a copy. It’s a very simple and obvious book but it explains very well why and when you should give up and when you keep on struggling. And that’s exactly what we are trying to do. We want to evaluate the effort needed to succeed (if it’s doable).
III. Build a relationship
Business is all about relationship. Both your client and you have needs. By creating a relationship you will try to fulfill most of your needs. Let’s look at an evaluation of my professional needs:
-
I need to be challenged
-
I need communication
-
I need guidance
-
I need deadlines
-
I need results
-
I need to be valued
And here is what I cam up with when I tried to estimate my client needs:
-
he needs business value
-
he needs to feel special
-
he needs to be reassured
-
he needs to keep control over the finance
-
he needs to make sure he doesn’t waste money/time with me
-
he needs to plan the future
There we go, we have the base of our relationship. As long as most of our needs are fulfilled, the relationship should be strong.
As you can see by looking at the list above, the client needs to be convinced that I am the perfect fit they were looking for. On my side, I want them to realize that we are lucky to work together and I want them to value me.
Money makes the world go round, especially in a business relationship and especially in the Western world. Your rates are a simple way to say, this is what I’m worth. If you are willing to pay my rates, you are valuing me. Obviously rates can be negotiated but be careful, somehow they will always represent your value.
So how do I build this relationship?
- be frank, open and transparent.
I don’t want my clients to feel that I’m hiding things from them. For instance, I’m always running two projects at the same time and I make that really clear at the beginning before I start working on a contract. My client A knows that I will work 17-20 hours a week on his project and 17-20 hours on a different project. If I have to miss one of our stand-up, I usually explain why.
Trust is very important when you are an outsider and even more when you work remotely.
- Provide visible business value on a weekly basis.
At least once a week, I have a quick demo with my clients and if possible their co-workers. This demo is really important for a client since he can then visualize the business value added to his product. He will feel in control, reassured and will be able to evaluate the situation and plan the future of the product. Usually clients who worked with other developers/methodologies also feel special since they would usually only see business value at the end of the project. By the way, the demo is usually done on the production application so we are talking about real business value.
- Make the client the center of the decision making process
In my usual process, we have a special meeting every monday. During this meeting, we plan the work for the coming week/iteration. I simply help the client breaking down his tasks in small chunks that we could handle in a week. During this meeting we also agree on this iteration priorities. In general we already created a queue/backlogs of tasks that need to be executed. I simply let the client make his choice to what is really important. In general a client wants everything done right away exactly how he has it mind. Well… the reality is really different. A client doesn’t have to understand the concept of polymorphic association to make decisions. Actually, he doesn’t care how you do it as long as it’s well done. However, your client should know how to prioritize things, he probably already does that all day long. Converting the technical details into simple concepts that make sense to both you and the client will seriously help the project. I don’t have to worry about delays, I don’t make these decisions, my client does that for me and he likes having control over budget/time line.
To sum-up, I believe that by choosing a client that matches my view of software development, a project that sounds interesting to me and building a strong relationship, we will have a good end result and a win-win situation.