IndyCoding

The value of hard questions

Avonelle Lovhaug — Thu, 21 Aug 2014 12:17:20 GMT

Sometimes freelancers avoid asking difficult questions, like:

Is there a budget for this? What is it?
I know you love this feature. But does it really make the product better?
Can you really be successful with your experienced nephew in charge of security for this product?

We might be afraid of the answers. Or maybe we’re afraid of the impression the customer will have of us after we ask the question.

But we’re doing ourselves and our clients a huge disservice when we avoid the hard questions.

We need to stop trying to be friends with everyone, and instead focus on the outcome we are trying to achieve. We want the customer and/or product to be successful. By not asking the difficult questions, we are increasing the potential for failure. Why should anyone hire us if we make things riskier?

What hard questions are you asking your clients today?

Short term clients are better because I’m too chicken to say “no”. WHAT?

Avonelle Lovhaug — Mon, 13 Jan 2014 17:36:27 GMT

Today I read a fellow freelancer suggest that short term clients are better than long term, multi-project clients, because they don’t come back and ask him to do boring projects he doesn’t want to do.

Huh?

Look – every time a client asks you to bid on a project, you can say no. What ever gave you the idea that you couldn’t?

I agree it can be harder when you have a relationship with the client, but it certainly isn’t impossible to tell a client that their project doesn’t fit with your business model. Even if it is similar to something you have done in the past, just tell them that your interests have changed.

He said: well then they probably won’t come back to you.

Yes, that is a possibility. But so what? If their work really is unappealing to you, go and look for a long-term client that has more interesting work. And not all repeat business is automatically boring. Why increase your sales/marketing costs by having to find a new client all the time if you don’t have to?

Bottom line: if you have trouble telling a client “no” for your own purposes, I have difficulty believing you’ll be willing to say “no” to them when they want to do something stupid and you have no skin in the game at all. A good freelancer will tell customers the truth even if it hurts a bit. Bad ones shrink from honesty and hide in “the customer is always right”.

CVCC: How to make ASP.NET Web Forms Suck Less

Avonelle Lovhaug — Sat, 02 Nov 2013 20:52:33 GMT

Here are the sample VS2012 solutions and slides from my Chippewa Valley Code Camp 6 talk.

Slides and Samples

All networking is not created equal

Avonelle Lovhaug — Sat, 14 Sep 2013 16:46:23 GMT

I get invited to networking events a lot. Women’s networking events, chamber networking events, technical networking events, speaker networking events. Sometimes I get invited and I have NO IDEA why.

I rarely accept these invitations. Since the invites usually come in email, ignoring them is sufficient, but sometimes I decline in person. Since I suck at lying, I try to explain why I’m saying no, which usually ends badly, because these people don’t understand.

Example: I will say “The people who attend that event are not people who will buy my services. They ARE business owners, but they typically don’t need custom software and are too small to afford it anyway.”

Their response: “We get people from a lot of different businesses, and besides: they probably KNOW someone who would buy your services. You never know.”

True. But….

That still doesn’t mean it is a good use of my time. I am a freelancer. I have limited time to market my services AND actually provide value to my customers. If I went to every networking event I was invited to, it would take at least 20% of my time. Time I wouldn’t be programming!

But even more importantly: the argument is flawed. Just because other attendees might KNOW someone who needs my services doesn’t mean they will every have a conversation about me. Do you tell your chiropractor that you are looking for a programmer for your business? And even if you did, would you trust whoever they recommended?

Pretty unlikely.

Now if you are selling website redesigns to small businesses, then attending these events makes perfect sense. Your customers are there.

And I’m not saying don’t go to networking events. I recommend doing it to get out of the house and practice interacting with non-technical people. But just be realistic about what to expect. For many of these events, you are unlikely to drum up any work.

And consider other types of networking rather than random events, like lunch with former colleagues, or events that aren’t branded as networking but where you are likely to meet potential clients. My chamber holds a monthly legislative breakfast where you can meet local politicians and hear about laws that might affect your business. I am much more likely to meet a potential client at one of those events than a typical pass-around-the-business-cards event.

How to Make ASP.NET Web Forms Suck Less

Avonelle Lovhaug — Mon, 12 Aug 2013 20:43:04 GMT

For those who attended my That Conference session on making ASP.NET Web Forms suck less, you can download the slides and sample code from here:

How to make ASP.NET Web Forms Suck Less

Is your only value your technical skills?

Avonelle Lovhaug — Tue, 23 Apr 2013 17:05:34 GMT

I’m betting you have more to offer a client than just your amazing coding skills. So why are you only promoting your technical experience? Here are some other attributes that many if not most customers will also consider important:

Reliable with deadlines. Consultants who consistently achieve deadlines are unusual. And valuable.

Easy to connect with. Some programmers go into a rabbit hole or never answer their phones/emails. If you aren’t one of those, why not remind prospects of that?

Business or subject matter expertise. You may be able to advise your client on more than just technology.

Provide additional services. Are you great at user documentation or training? Can you provide mentoring to others? Are you willing to provide detailed status reports and cost breakdowns? These are just a few examples.

Indycoders often forget to promote their non-technical skills. What non-coding attributes do you talk about to your prospective clients?

Don’t be afraid to define a narrow target market

Avonelle Lovhaug — Thu, 18 Apr 2013 15:41:56 GMT

When I describe my target market, people wonder if it is too narrow. It is important to realize that some criteria may not be automatic deal breakers. Here’s what I mean. My target market includes small organizations of 25 employees or less. Does that mean that if a prospect has 50 employees I automatically tell them I’m not a fit? No. But I use that information as one of the items for identifying if I think I will enjoy working with this client. The larger the client, the more cautious I am.

On the other hand, some projects do have automatic deal breakers. A current client asked me a few years ago to consider a Silverlight project they were staffing. I realized pretty quickly that Silverlight wasn’t something I was interested in, and so I declined.

So what’s the point of spending time defining target market specifics if you may ignore some of the criteria anyway?

1) It helps you to better evaluate potential opportunities if you have really thought through what kinds of projects and clients are enjoyable to you, and what kinds aren’t. If you haven’t spent time doing that (and revising it occasionally), then you are more likely to agree to something that will make you miserable.

2) It helps you to write marketing copy (Google Adwords, website text, etc.) that is more likely to attract the kinds of clients you want.

3) It helps you describe the kinds of clients you are looking for to referrers.

Remember: you control who you work with. You can decide later that an 80% fit with your perfect project profile is good enough. But if you don’t take the time to define your target market at all, you’re suggesting that everyone is the right kind of customer for you. You don’t really believe that, do you?

Is this a good project for me?

Avonelle Lovhaug — Tue, 16 Apr 2013 13:58:25 GMT

I've written previously about the importance of figuring out what kind of projects you really want. Here are some questions that can get you started:

Do you care if you are maintaining existing code (even your own)? Or do you only want to be working on new projects?
Do you prefer working with a team? How large? What role do you want on the team?
How long do your favorite projects last?
What technologies are most interesting to you? Are there any that you don't want to work with?
What tools, processes, and methodologies are "must have" for you?

What criteria do YOU use for determining if a project is a good fit for you? You are using SOMETHING, aren’t you?

The vicious cycle of crappy projects

Avonelle Lovhaug — Fri, 01 Feb 2013 14:22:23 GMT

Whenever I meet someone who is IndyCoding and working on a project they hate, I feel sad. And a little confused.

Being a freelance programmer is not the easy solution for most people. You can’t just be a programmer. You have to also be a business person. A sales and marketing person. A project manager. Many programmers are not up to that challenge.

And there is quite a bit of uncertainty in the freelance programming life. Where is my next project coming from? What if they don’t pay me on time? These are not easy things.

So why, Why, WHY would you do it if you weren’t working on projects that you love? Why do it if the customer sucks, if the project is uninspiring or something else makes you unhappy to work on it every day?

I’ve had people tell me that when you first start out, you have to take whatever crappy project comes your way.

No.

This is how the crappy projects never stop. You take them on and you are so busy trying to live through them that you can’t find the time to go out and get the good projects. And building a relationship with a client who you don’t want to work with in the future gets you nowhere.

Do some analysis and figure out what you really WANT to do and who you want to do it with. Be thoughtful. Be specific. And then figure out the best way to find those clients and projects. Where will they look for development services? What will make you attractive to them. Then step up your marketing efforts. Make sure your next project isn’t a crappy project.

Monthly support rules of engagement

Avonelle Lovhaug — Sat, 14 Jul 2012 13:51:20 GMT

One of the things I offer my clients is fixed-fee monthly support. This is a great option for my clients, because they can easily budget for hard to predict problems, and it is useful for me because it guarantees me regular income every month.

Support is easier to offer if you have experience working with the client. On occasion, I’ve been asked to quote support for new clients for apps I didn’t write. I’ve declined because this works best if you have a history of working with the client and the application. You know where the danger areas are, how likely the client is to encounter bugs, and how emotional they will be.

Without that information, you are likely to greatly underbid or overbid.

If you decide to offer this service, you should establish these specifics in your agreement:

Supported platforms or browsers. This was probably established when the app was first written, but of course different versions become available over time.

Response time. How quickly will you respond to their requests? I’m careful with what I promise. I can’t guarantee that I will fix a problem within a certain time, but I can promise to start looking at it within a a day or two.

Support hours. Do you offer off-hours (i.e. nights and weekends) support, or only regular business hours support? If you offer off-hour support to a customer, don’t forget to charge a premium price for it.

Cancellation rules. What happens if the client doesn’t want support any more? Or perhaps you want to move on. I usually establish that cancellation requires 90 days written notice by either party.

Contact rules. I prefer my clients contact me via email, and that’s the way I offer support. I don’t want to get phone calls in the middle of the night.

Scope. Typically what is covered in my support agreements are: email questions, troubleshooting, and bug fixes. Occasionally I have also included small, cosmetic enhancements in my support agreements.

Some other thoughts:

Don’t offer support to clients unless you like working with them.
Review your support agreements once a year to determine if things need to be changed. Maybe the customer rarely uses it, and you can drop the price a little for them in the second year. Or perhaps they seem to want quicker response than what you offered. Do you want to ask them if they want to change the terms for an additional fee?
If you offer support, make sure you don’t consider yourself to be 100% available for other projects. You aren’t.
Decide how many support clients you can successfully maintain. I currently have 3 support clients. Personally I wouldn’t go any higher than 4, otherwise I could easily have a problem providing the support I’ve promised.

Fixed fee monthly support can be a great service offering for your IndyCoding business.

Everything is harder without trust

Avonelle Lovhaug — Wed, 23 May 2012 14:57:18 GMT

Do you trust your clients? Do they trust you?

There is no reason to work with people you don’t trust. If you suspect they will not pay you or treat you badly, you shouldn’t be working with them.

Some Indy Coders act like this is inevitable, that many customers will be untrustworthy and they are stuck. I disagree. In my more than 9 years of being independent, I have never worked with a client who I didn’t trust to treat me fairly. And their behavior suggests that they trusted me, too.

I spoke with a colleague recent who is struggling with a trust problem with their vendor. The vendor has repeatedly behaved in an untrustworthy manner – missed deadlines, poor communication, bad implementation. Now that the project is nearing completion, the customer fears they won’t get all the source code as promised and that they will be held hostage for future changes. That’s a bad situation for everyone.

Software development is hard enough. The last thing anyone needs is a relationship where each side suspects the other is trying to mess with them.

How can you tell if your customers trust you? Here are the ways my customers demonstrate trust:

They ask for my opinion. They may ultimately go a different direction, but asking shows they value my input.
They regularly pay on time.There may be an occasional snafu, but this is the exception not the rule.
They don’t try to renegotiate the price. They may ask questions about the price, but they don’t ask for a “special deal”.

If your customers don’t trust you, you are doing something wrong. Here are some of the things that I do to build trust with my customers:

I make some small changes for free. I always let the customer know I would normally charge for them, but that I want to be reasonable and fair.
I deliver source code with every build. My agreements say they are entitled to the source. Yes, they could take the code to someone else. I’m not afraid of that.
I communicate clearly and in a timely manner. I don’t let issues pile up. Even bad news (like a problem with an upcoming deadline) is better to communicate immediately.
I am professional. I treat customers how I want to be treated.

If you are reasonable, most clients will be reasonable too. If this isn’t happening for you, then you are working with the wrong clients!

Twin Cities Code Camp 12

Avonelle Lovhaug — Sun, 15 Apr 2012 02:51:05 GMT

Thanks to everyone who attended my session on estimating. Lots of great participation.

For those who asked, here are the slides.

They’re stealing our jobs–NOT

Avonelle Lovhaug — Tue, 06 Mar 2012 14:28:40 GMT

Last week I was perusing a forum for freelancers and I saw this:

It's a shame with the 3rd world folks stealing the jobs away with low prices.

This is seriously flawed thinking that will hold you back.

First: they are not STEALING the jobs. They are competing. And yes, there are plenty of price sensitive customers who will gravitate to low cost alternatives. But just because they are using the advantages they have (low cost of living) to compete doesn’t make them thieves. You aren’t OWED this job.

Second: There are other ways to compete. If your big benefit is that you are cheap, maybe it is time to come up with something else. Maybe you can compete on service – if you are in the same time zone as your client, it might be easier to be responsive? Or you might understand them and their end users better than someone in another culture. Or perhaps you just provide a better product. There are lots of ways to distinguish yourself besides price.

Don’t be an Indy Coder who is afraid of the competition. Instead, focus on the value you add to the client, and figure out how you are unique. (And for goodness sakes: stop chasing clients who choose vendors solely on price. You don’t want to be in a race to the bottom.)

Learning is an investment. Invest wisely.

Avonelle Lovhaug — Tue, 21 Feb 2012 17:00:34 GMT

Being an Indy Coder means you don't have unlimited resources. There are only so many hours in the day for working, learning, and marketing. Don't waste hours learning things that you can't or won't leverage other ways.

But learning new things is always useful, right?

No. Not really. Here's an example.

A couple of years ago I invested a LOT of time learning how to interact with a third party enterprise CRM. It was a request from a regular customer, and meant 100s of hours of business for me.

But looking back, it wasn't a very smart decision. Customers of this CRM are outside of my target market. Learning its quirks was great in the short term for helping out this customer, but I can't leverage what I learned with other customers unless I completely abandon my target market and chase other businesses.

In the meantime, my customer has also decided to walk away from this CRM. So now that knowledge isn't even useful to them.

You can't always predict the future. And in technology we often learn tools and techniques that are supplanted by others as time passes. But choosing to invest time in learning something new should be a thoughtful decision, not solely driven by a single customer's request.

How to be unattractive

Avonelle Lovhaug — Mon, 13 Feb 2012 13:25:44 GMT

There are two components of any marketing efforts:

Attracting the right clients
Repelling the wrong clients

This is obviously a tricky game. You want to make sure you are appealing to the clients you want to work with, but while doing it you want to seem unappealing to the worst clients (or at least those who don’t fit your target market). Here are some ways you can accomplish this:

Use a company policy

As Indy Coders, we tend to think that saying we have a company policy is foolish. But having your own business means deciding on your own policies. It isn't foolish at all - it is responsible business.

In my business, I want to work with established companies - no startups. Unfortunately, I still get the occasional call from new companies looking for a freelance programmer. I ask those companies a series of questions designed to quickly determine if they are worth my time, and one of those questions is if the business is a new venture. If the contact responds that yes, they are a startup, I usually say "I'm sorry, but it is my policy to only work with established companies. My business model is such that I provide the best value for organizations that have stabilized and have been turning a profit for several years."

Use language

The language you use in your marketing copy can be a great way to subtly make yourself unattractive to the wrong prospects. Is your target market individuals with a technical background? If so, you can use technical terms to turn off non-technical readers. Avoid using language that makes you sound cheap – this can attract prospective clients who are tire-kickers and not true buyers.

Be difficult

To be unattractive, you must sometimes appear to be difficult to work with. You can do this in ways that don't make you seem personally repellent. For example, most larger organizations prefer working through a reputable middleman - a consulting firm or studio who finds resources for them. Since I don't want to work with large companies anyway, I make a point of avoiding working through middle men. This makes it harder for those companies to find me.

Other things you can try:

Require a significant down-payment before any work is done.
Require the use of an issue tracking system you specify.
Charge a significant fee for rush work.

What techniques to you use to be unattractive to the wrong prospects?