Home : furfly : How We Do Things

How We Do Things at furfly

Getting the job

Since much of furfly’s value to you is bringing in work (otherwise you might as well work on your own and keep all the money), we handle talking to new prospective clients. Once the client has decided to go with us and is ready to talk about the details of their project, with the goal of creating a spec and/or an estimate for the project, we will bring the person(s) we intend to assign to the project in to the process, to meet the client and participate in the technical discussions.

When it comes time to set prices, we will ask you to provide estimates of how long you think each task will take. As much as possible we let you set these amounts; however, we will discuss adjusting them if we feel they are too high or low. The goal is to arrive on a mutually agreeable set of numbers, which will be used to derive the schedule and prices that are given to the client.

Since we find that most programmers are very optimistic estimators, including ourselves, we usually apply a “programmer always underestimates” multiplier of 1.5 to the adjusted time estimates before we use them to come up with the price for the job. This extra time/money is referred to as the “fudge factor” and will be discussed in more detail below.

Supervision, or lack thereof

As much as possible we hire people with lots of experience who can work unsupervised. That means you help us create the spec, we tell you which tasks are your responsibility, and you go off and do your work. It means that if you run into technical difficulties you are resourceful and can find help for yourself. It doesn’t mean you can never contact us about the project; if you find that there is a problem with the design as we proposed it, or you have a better idea, or you just want to bounce an idea off of someone, by all means drop us a line. The idea here is that you are able to get through your day-to-day job without needing help to do it.

Sometimes we intentionally hire someone who is young and/or inexperienced and needs a bit of extra help. Other times we find out after a project has started that someone isn’t as self-sufficient as we had thought they were going to be, or the current project is a bit over their head. These cases have to be handled differently:

• If we know we are hiring someone who needs to be looked after, we will tell them up-front that they will be paid a bit less. That money will be diverted to the person who will be supervising them, usually a more senior programmer on the same project.
• It’s a bit stickier when the need for supervision turns out to be a surprise. We can’t dock someone’s pay after the project has begun, and a person can’t be expected to magically develop resourcefulness overnight. So in that case we pitch in to help as much as possible with the supervising, and we ask that the other folks on the project do the same. None of us will be compensated for that extra effort, unfortunately, but it will ensure that the project is a success, which is good for getting more work in the future, so it does benefit everyone in an indirect way.

What we bill for (and what we don’t)

The client doesn’t pay for any of the time that goes into talking about their project and preparing an initial estimate. We try to get them to pay for the time it takes to create a spec, since this can be substantial, but we usually run into a chicken and egg problem – they don’t want to commit to having us do a spec until we give them a price for the project, and coming up with even a ballpark figure requires doing at least some of the work of putting together a spec. We have also found that clients are generally resistant to paying for the spec’ing process at all, but that is fading as our client list and reputation grow.

Most of the time we do fixed-price contracts, which means the amount you get paid for a job is pretty much fixed (except see the discussion of the fudge factor below). So this discussion is mostly about what should be included when doing time estimates and tracking your time.

The main thing you can’t include in a time estimate is time to learn something new that the client could reasonably expect us to already know. So if, for example, the client hires us to do an e-commerce site, and for whatever reason we assign someone who has never done e-commerce before to work on it (this is unlikely, and would never happen without an experienced supervisor, but bear with me for the sake of illustration), that person could not include time spent studying the e-commerce code in their time estimates. However, if the client asks us to, say, make their site run with Apache, and we tell them upfront that we will do it but none of us have used mod_aolserver before, then it’s ok to include learning time in the estimate.

We usually do include some amount of time in our specs for overhead, which is mostly communicating with the client, but the amount of time spent on this always seems to exceed the amount that’s reasonable to charge for. Don estimates that when he’s working full time he’s actually doing about 5 – 6 hours of billable work per each 8, mostly due to e-mail discussions between the persons working on the project. We generally expect that e-mail time will not be included in billable hours, unless you get approval ahead of time.

It is common for needs to arise once a project has started which were not accounted for in the original spec and estimate. These are handled differently depending on the situation. If it’s really a necessary feature, we may tell the client they need to pay extra for it or if we’re really ahead on hours we may go ahead and do it without charging extra. However, if it’s something you feel is important but we and/or the client are less convinced, we’ll probably tell you that it’s not billable; you can still do it if you want to, but you can’t include it in your hours. The important thing here is that you can’t just decide on your own to implement something you think is necessary, no matter what your role is on the project, and assume you’ll get paid for it; you have to come back to us to get approval beforehand. (this paragraph was added due to an incident we’d rather not repeat)

Most projects are billed at $200/hr, but the rate can go as low as $100/hr depending on the situation. You are never required to take a job, especially not one of the lower-paying ones, though it is probably true that those who are willing to do anything will end up getting the most work. It’s just human nature to go to the people who always say yes.

How we pay you

We currently have three pay rates:

• 50% - needs supervision to be effective
• 60% - works well without supervision
• 67% - supervises others and/or is a very senior contributor

In each case, the percentage is applied to the amount we take in from the client.

The first job a person does for us is usually at the 50% rate, unless we have personal experience with them and know that they can do better. This is done because it’s much easier to give someone a raise than it is to dock their pay.

We are generally accommodating of special schedules as long as they are factored into the schedule we give the client (ie, you can’t sign up for a class that takes your time two full days a week when we’re in the middle of a project cycle). And we aren’t strict about people working 8+ hours every day. However, everyone should understand that there will be times of tight deadline or site crisis when we expect to have all hands on deck bailing as fast and as for as long as they possibly can.

Because we are a small company with shallow pockets we operate by the following principle: you get paid for what we get paid for. What this means is that you only get paid for time spent on billable work. Additionally, if a client does not pay for whatever reason, you won’t get paid either. This has only happened twice; once we got stiffed for an entire job and once the client was only able to pay part of their bill. Over three years (at this time) that’s not too bad.

Some folks send in their hours via e-mail, and others send us official invoices. Either method works ok for us, at least until we move to an Intranet and standardize on reporting hours there. We will invoice the client at whatever intervals are specified in the contract, and as soon as their check arrives and clears our bank, we will pay you. Payments are made by check via US Mail.

Now, about the fudge factor. Deciding what to do with that money has been the most divisive issue to come up so far. Here is what we decided to do, in the interest of being fair to everyone:

You will always be paid for the amount of time you estimated for a task, even if it ended up taking only a few minutes If the task takes longer than you initially estimate, we will pay you up to (but no more than) the amount of the fudge factor, depending on how much time the task actually took.

So what this amounts to is that if you’re able to do it within the estimate, you get to keep any extra money up to your estimate and we keep the rest. If it goes over, we will compensate you for that up to the amount of the fudge factor.

Our reasoning for this is as follows: we know that programmers usually underestimate. We want to protect you from yourself, in a manner of speaking, by increasing the estimate. But this makes us less competitive (and yes, we do lose some jobs because we’re too expensive) because it makes our prices higher. Hence the compromise; you keep some of the money and we keep some of it, to compensate each side for some of the extra effort they’re putting in.

Obviously this system requires us to trust our people to an unusually large degree. So far it has worked out fine; if it stops working out in the future then we’ll change how we do things then.

Last but not least – since everyone is a contractor, we don’t do any tax withholding or other traditional payroll things. We will send you a 1099 form at the beginning of each year, if you worked for us during the previous year (and are a US citizen).

Where the next job is coming from

We usually don’t know where the next job is coming from. We don’t do any sales or marketing; so far prospective clients have been beating a path to our door. That may change now that arsDigita is nearly no more, and Philip’s book isn’t bringing in as many converts as it used to, but so far it is still working.

As far as you’re concerned, we need to make it clear up front that we don’t guarantee anyone steady employment. If we could, we’d be hiring full-time employees. The whole reason we use contractors is that we don’t always have another job lined up to start right away. This means that you are responsible for lining up your next job, whether it comes from us or from some other consulting firm. You are always free to work for other companies, and come back to us later; that’s the price we pay for not giving people full-time jobs.

Our philosophy

We need to come up with a snazzy motto/mission statement, but for now here is a list of our core principles, in no particular order:

• Always be honest with the customer, even when it’s embarrassing
• Admit mistakes before you’re asked, and be modest about working miracles
• Do your best work and don’t be afraid to ask for help when you need it
• Work hard, but also play hard
• Don’t forget to eat! (don’t laugh, it happens!) And get enough sleep; in the long run it hurts a project if people are too tired for too long.
• Above all, have fun. We’re doing a (usually) fun job for great pay and people all over the world get to use and benefit from our creations. What could be better than that?