Category: Business

Freelancing vs. Contracting vs. Employment

Posted on by Eric F. Savage

I’ve been freelancing for a little over two months now, and already it has been an exciting, rewarding experience. I figured I would share a few observations.

What do I mean by “freelancing” as opposed to contracting. I admit there is no official differentiation of the two, this is strictly my own, and I apply it narrowly to software/knowledge work.

I see freelancing as the extreme end of transient employment. They may be hired on a per project basis, or a per day basis. There isn’t any implicit availability, they’re booked (and paid) or you’re not. They don’t go to meetings that aren’t very relevant, or get unwillingly reassigned. If there are no projects where you can offer expertise, you’re done. If a company tightens it’s belt, freelancers are the very first to go, with no notice, no severance.

I see contracting as provisional employees. They aren’t vested in the company, but they essentially perform like an employee. They probably go to company-wide meetings, fit into the normal reporting structure, etc. After the freelancers go, the contractors are next in line. Usually contractors are given time to “wrap things up” or have a planned end date.

Employees are, well, employees. They work for the company, and only for the company. Hopefully if the company makes a lot of money, the employees benefit, where the previous types don’t. Many people think employment offers job security, but short of official agreements like tenure or unions, I disagree. I define job security as the ability to get a job, not to keep one. I’m not cynical about fatcat CEOs laying people off for fun, I’m just realistic in terms of what employment actually provides.

The reason I choose freelancing is that I want to be intellectually promiscuous, at least for now, and I want that arrangement to be very clear to clients. I have a self-imposed 20 hour per client per week cap. This may sound silly to you, and it certainly hasn’t been popular with clients. It’s a tough sell, and it has cost me some otherwise good opportunities. I admit I haven’t really mastered it yet, but I think I’m getting better at it, and am grateful that my clients have been accommodating. On the other hand, I don’t think that I’d be nearly as stimulated as I am now, but that’s a topic for another post.

Choosing your Choices

Posted on by Eric F. Savage

A popular theory of the past few years that has worked its way into the web/business/usability spheres is that more choices are worse. Essentially the idea is that people get stressed out and balk at making choices. If you order a chicken salad and you’re given one, you’re happy. If they ask you if you want your chicken from California or Canada or Mexico, and your mayonnaise from Vermont or Cape Cod, you get less happy. The idea was largely popularized by the book Paradox of Choice, which I haven’t read but apparently goes over the theory ad nauseam.

The result is that many people posing as knowledgeable on various matters have latched onto this and now add “too many choices” to their canned list of “insights”. I don’t buy it, and others are going so far as to disprove it. I think the real lesson is that choices decrease happiness when you don’t understand them. Asking me if I want my chicken from California or Canada doesn’t mean anything to me if I don’t have strong feelings about those two places, but if you said “would you like your chicken from California, which tends to be more tender, or Canada, which has lower fat”, the choice is now very valuable to me. I’m going to happier than I was without any because I know that I got the tastier or healthier one and made a good choice for me.

You can, of course, have too many choices (televisions, CPUs, wines), and you can also have too few (cable/internet service providers, political parties). When you’re deciding what to offer your current and prospective customers and users, you need to decide what makes sense for your business and them, and most importantly, you need to articulate the difference. If you can’t do that, then you can say that you have too many.

What Startups are Really Like (Really!)

Posted on by Eric F. Savage

Paul Graham has issued another missive about startups called What Startups are Really Like.Obviously YMMV but based on my experience at StyleFeeder, he’s about 1/2 right, and 1/2 wrong, which is par for his course (the 1/2 right part usually redeems the 1/2 wrong part).

1. Be Careful with Cofounders

True. A piece of advice my dad gave me was that you should always try to avoid getting someone else involved if you can.

2. Startups Take Over Your Life

False. You can let it, you can also let a job at a billion dollar company take over your life. You can not let it take over your life. People at StyleFeeder have moved, had kids, done the normal “life” things.

3. It’s an Emotional Roller-coaster

False. You can let it be one, but you’re not really serving anyone’s interests if you are. You might succeed wildly, you might fail miserably. Your life could change for the better, but it’s only going to change for the worse if you’re dumb and you put yourself in that position.

4. It Can Be Fun

True.

5. Persistence Is the Key

True, but this applies to life, not just startups.

6. Think Long-Term

True. Keep in mind that long term means profitable. No matter what’s in the bank if you’re not profitable you’re dying.

7. Lots of Little Things

True. Details matter. Alot. Spend the whole day shaving 10ms off your average response time. Spend a night picking out a font. Argue with your designer over ridiculous things nobody else will notice.

8. Start with Something Minimal

True. Note, this doesn’t mean you should put out unfinished crap and call it “Beta”. Just get it to the point where it’s useful and cohesive.

9. Engage Users

True.

10. Change Your Idea

True. More accurately “be willing to change your idea”. Ideas are cheap and plentiful. I could keep a dozen people busy building things at StyleFeeder that are great ideas, but that’s not how we run things so we need to chart our course thoughtfully and constantly.

11. Don’t Worry about Competitors

False. Feel free to define your competition, but you need some or nobody will take you seriously. Then worry about them because they’re trying to take everything you have.

12. It’s Hard to Get Users

False. Users are easy to get, if you have something worth using. Probably not as many as you want, but that’s why they call it work.

13. Expect the Worst with Deals

False. Be realistic, not pessimistic. Most deals will suck, some will cost you money, some will work out, but without them, you’re likely dead.

14. Investors Are Clueless

False. They can be, but they can also provide valuable perspective.

15. You May Have to Play Games

True. You might, but you shouldn’t. If you’re weak on something, fix it or do something else. Don’t hide it.

16. Luck Is a Big Factor

True. Not everyone founds a company on the right side of a stock bubble and sells it for far more than it could ever be worth. Luck is also a reason not to be pessimistic about deals and opportunities.

17. The Value of Community

True. Overrated, but true.

18. You Get No Respect

False. I get the same or more respect as a key employee at a company trying to do something new than I did as a cog in the corporate world.

19. Things Change as You Grow

True, but if that’s surprising you probably shouldn’t be doing this.

“Unconsciously, everyone expects a startup to be like a job, and that explains most of the surprises.”

False. I’m actually surprised by how much like a job it is, just better.

Fire the user experience designer

Posted on by Eric F. Savage

This post makes a case for having a specialized “user experience designer”. The author makes the case that usability and interaction design is too complicated to be handled by someone responsible for other tasks. This is false.

If you are on a team responsible for a website or something similar, EVERYONE on your team should understand usability and interaction design. It’s not a special skill, it’s core competency, like communication skills and ethics. The real experts out are rare, and I mean “you’ll probably never even meet one” rare. Most people who specialize in it are just washed-up designers or coders.

You need your designers thinking about how people will interact with your program, or you’re going to end up with brochureware. You need you programmers thinking about it or you’re going to end up with a clumsy UI. You need your QA people to think about it or you’re going to end up with spotty test plans. You need your managers thinking about it to understand what’s important. You need your salespeople thinking about it to compare against your hapless competition.

Having someone responsible for it is a bad idea because not only are they probably going to suck at it, it’s just going to make everyone else lazy.

An Open Letter to Recruiters

Posted on by Eric F. Savage

Dear Recruiter/ Staffing Specialist/ Hiring Manager/ Headhunter/ HR Ninja,

Nobody's calling :(As you likely know all too well, the job market is red hot for developers right now. Getting a good senior developer to even return your calls is a challenge. You offer competitive salaries, have a nice benefits package, flexible schedules and relaxed dress codes. You’re doing everything you can, and the only responses you’re getting to your job listings are dummies and spammers. So what are you doing wrong? Well, I don’t have the complete answer, as I too am having trouble finding people, but I’d like to offer advice on one area, your job listing.

99% of developer job listings seem to look like this (this is a slightly edited actual job listing):

Description:
Super Recruiter Staffers has partnered with a progressive e-business and marketing company in Smallville, KS, and is seeking a motivated and experienced Java Software Engineer.

The successful candidate will bring a solid understanding of J2EE to an experienced development team with a strong technology background.
Responsibilities:

  • Analyze, design, and implement Java and Java EE based software applications
  • Participate in all parts of the development life cycle
  • Responsible for the complete life cycle development of major components and sub-systems
  • Leverage past development experience

Requirements:

  • Required Skills/Background:
  • BS degree in Computer Science
  • 2 years hands-on Java EE design and development experience in a professional capacity.
  • Experience with the following Java EE technologies; EJB, servlets, JMS, and JDBC
  • Proven experience with JSP, Struts, JDO, JPA, and Spring.
  • Proven experience using application server environments to build enterprise level multi-tiered applications
  • Proven experience architecting n-tier applications (Oracle 10gas preferred)
  • Excellent object-oriented analysis and development skills
  • Working knowledge of UML, XML, Ant
  • Self-starter with the ability to work both independently and as part of a team.
  • Ability to manage multiple priorities effectively
  • Excellent verbal and written communication skills

Other desired skills include:

  • Experience in performance tuning, load testing, deployments, and QA
  • Experience with full software development life cycle including functional & technical specification, documentation, QA processes, source control (CVS), maintenance, and deployments
  • Experience with Oracle 10g
  • Experience developing software for manufacturing industry

If you feel that you have the above qualifications and are interested in discussing this opportunity further, please apply today!

What’s wrong what that?, you ask. A lot, I say. Here’s what you’ve told me:

It’s a poorly defined position.

You listed a bunch of Java technologies, some of which I’ve used, some which I haven’t. It’s unlikely that all of these are needed, because you’ve listed typically opposing approaches like EJB & Spring, Struts & Servlets, etc. These can co-exist for sure, and maybe it’s part of a migration, but your shotgun approach isn’t tell me much. Also, you want “proven experience” in a technology that is brand new (JPA). I remember seeing job listings back in 2000 for people with “10+ years of Java development” (it had only been out for 5 years).

You aren’t being very honest.

You say that a BS in computer science is required. Of course it isn’t. Very few of the best developers I know have CS degrees. I’ve worked with people who had degrees in everything from Library Sciences to French to Math. If it’s not required, don’t say it is. What you really mean is “preferred”, but even that’s questionable. What this really tells me is that you just copy-and-pasted a boilerplate description and you’re not trying very hard, so why should I?

You want a Super Genius.

You want 2 years minimum experience. You also want someone who has “proven experience” in a wide array of technologies and can architect “enterprise level multi-tiered applications”. If you’re interviewing people with 2 years experience to architect enterprise software, you’re in trouble. And if you’re interviewing architects for a job that someone with 2 years of experience can do, you’re wasting everyone’s time.

I’d be part of a team of indeterminate size.

So I’d be part of a team, that’s valuable information, but it’s not nearly enough for me to gain specific interest. A small, agile, team? A large, influential team? What’s the purpose of the team? What department are they in? How many projects do they work on? Will I be a senior member or a rookie?

I’d be working for a company that does something, somewhere.

I’m either working for a manufacturing company, or for a company who has a manufacturing company for a client. That’s a fairly large distinction right there, and even if you answered that there’s other questions. What kind of manufacturing? Do they make DVD players or cinder blocks? If it’s a consulting firm, what else do they do? How big is this company? How long have they been around? Are they public?

How to fix it

Tell me exactly what you need done.

There are generally three types of hires:

  • You need to staff an existing or upcoming project.If this is the case, describe the project. This includes the team, the client, the goals, the timeline. “A new team building an e-commerce site for a Fortune 500 client” or “A small team developing a new medical billing product line for small practices”. I’ve worked on many types of projects for many types of clients, and I know what I like. If you hit some of my favorable notes, you’re much more likely to hear from me.
  • You want to grow your technology staff.For this one, tell me what I might be working on long-term. “We want to grow our retail software practice” or “We want someone to evangelize semantic web technology internally and to our clients” are good starts.
  • You need someone right now for a project, and you want a long term growth.This one is probably the most common, and is simply a combination of the previous two. Be as specific as you can, and if you can’t because it’s wide-open after the current project, say so.

Talk to the people this new hire will be working with.

You probably got your job description from a VP or director, with some input from a middle manager or two. Ask these people who they currently have that they want more of. Then go and interview these people. Developers generally abhor meetings and organizational details, but if they see their input having a direct effect on who they have to work with or for, I would bet they will be more helpful than you suspect.

Tell me about the company.

With so many choices out there, people can be very selective about who they want to sell a few years of their life to. The more companies that are hiring, the more info you should be giving. Is the company growing? How fast? Are there multiple offices? Do you keep pace with the market or exceed it? Do you invest in R&D? Is your organizational structure flat or deep? How long do people stay with the company? You don’t need to point out the flaws, but every strength you highlight is more bait on your hook.

This is just the beginning. The market is very competitive and the competition is very weak. Improving your ability to get people to answer your calls is not only valuable, but it’s really not that hard.

Sincerely,

A Developer

Alexa

Posted on by Eric F. Savage

Tikkataulu, a finnish (nordic) game that is similiar to darts.I’ve spent most of my career working with and for large companies and clients. I watched the 90’s .com boom mostly from the outside, and only recently got involved with the startup ecosystem. So far, I’m finding it exciting and appealing, but there’s one aspect that flat-out confuses me.

Alexa is, in brief, spyware. It’s not sketchy like Gator or any of the other horrible things nerds have been cleaning off their mom’s computers for years, but it basically tells a server which websites you visit. In return for this, you can view some meta-information about the site you’re on, find related sites, etc. It’s been around for a while, and is now part of Amazon’s otherwise benevolent kingdom.

I have never, ever seen anyone use it. Anyone who is tech-savvy with a modicum of concern for privacy wouldn’t even think about installing it. I’ve even experimentally explained it to some non-techy people in neutral terms, and gotten negative responses.

The thing that confuses me is that it seems to be practically gospel in the startup/VC community, especially those who sit in the bleachers and offer commentary about the sector. This is largely due to the fact that it’s the only way to compare traffic between two sites, but its results are more than inaccurate, they are misleading, and dangerous.

I have available to me (not shareable, sorry) the traffic information for two sites. Site A has a mainstream audience and no revenue. Site B has a somewhat more technically-oriented audience, and is barely profitable. Site B gets twice as many visitors (and far more traffic) as Site A. Site A’s metrics on Alexa are twice that of Site B. I don’t even think a margin of error this vast has a name in statistics.

So I guess what I’m trying to say here is don’t use Alexa “until something better comes along” or “just for another viewpoint”. Just don’t use it at all.