Is It A Goal, or Is It A Wish?

In my self-appointed role as an effectiveness fanatic, I often ponder the process of setting goals for a project, or for my personal life.  Setting goals is tough.

“Wait a minute” you think.  “What’s tough about goal setting?  You state a desired outcome, and BAM!  You have your goal.  Right?”

Wrong.  If all you have is a stated outcome, you have a wish.  Not a goal.

Let’s think about this from (surprise!) a software development standpoint.  Suppose a client calls me up and asks for an application that will manage their bonus compensation process.  Since I’ve done that sort of work before, I could plop right down and put together a pretty handy application that does just that.  But will the application I put together be the same application the client saw in his head when he asked for it?  Probably not.  The reason is that simply stating that you want a bonus compensation management system does mean that getting a bonus compensation management system is a goal of yours.  At this point, it is simply a desire – a wish.

How do we move this client request closer to the realm of “goal” and farther from the realm of “wish?”  Well, for starters we can clarify the request – what exactly IS a bonus compensation management system, anyway?  Does it need to store stock grants?  Will it be storing full employee information about each person receiving bonuses, or just their SSNs?  Will it print checks, or will it need to export the financial data to Great Plains?  I can think of at least 100 questions that could be used to clarify the original request.  The problem with a client asking a developer for a “bonus compensation management system” is that it is not measurable – you have no mutually agreed-upon way to tell if you’ve built a management system for a bonus compensation process or a balloon ranch on Mars.  So the first step in having a goal is to make sure it is well-defined enough to be measurable.  In software terms, this would be a requirements document.

Now that we’ve got a measurable desired outcome, the next thing to do is figure out when it can/should be accomplished.  Features dictate dates.  Hopefully the process of clarifying things into measurable terms has provided sufficient detail to make an estimate – if not, more analysis can be done to determine a deadline.  If you’re working on one of those projects that was promised for delivery on x date before anybody even knew what they were actually building, then I feel for you.  I’ve been there and it’s not fun.  Luckily, this item is being written based on a “perfect world” assumption, and in a perfect world you could look at what is required of you first, THEN provide a realistic completion date.  So the next step toward a goal is a deadline.  How much time is needed to make your measurable stated outcome a reality?

Now it’s time to drill down a little deeper.  We know what we want to accomplish, and we know enough to set a realistic date for accomplishing it.  The final piece of the puzzle is to figure out how to pull it off.  What things need to happen – and in what order – in order to go from having what we have now to having what we want to have, within the set time frame?  In software terms, we need a project plan.  Part of this will be taken care of by the analysis done to make sure we can measure our relative success or failure – it’s nice to have that kind of overlap.  More work will need to be done to plot it all out like a project schedule.  Step 1:  Gnarfle the garthok.  Step 2: Foo the bar.  Step 3 . . . And so on.  What actions have to be taken to move us closer to the goal each day, arriving (more or less) precisely at our goal on (more or less) precisely the date we wanted to arrive there?

This is nothing groundbreaking, but it IS frequently overlooked.  Everyone states desires – in fact, we do it institutionally in the form of New Year Resolutions.  But to take your desire – whether it is to write a bonus management system or to lose 100 pounds – and turn it into a goal, it must:

  • Be measurable
  • Have a deadline
  • Have clear steps to make it happen

Think about your projects.  Think about your life in general, for that matter.  Are you putting sufficient thought into things to make them concrete goals?  I can tell you from experience that wishes do not translate into good software, a slimmer waistline, more money, etc.  But goals do.

While you’re thinking about it, head over to and publicly commit to some resolutions for 2005.  Make them specific and give them dates!  😉

High Hopes For 2005

2004 has come and (nearly) gone.  I can’t say I’ll miss it much.  Not that 2004 was a bad year – but it was a trying year.  Growing a business is hard, solitary work sometimes.  I’m starting to see my company’s growth curve start to take off, and I am looking forward to the new projects and experiences that 2005 will bring.  Suffice to say that I am excited about the future.

If there were only one thing that I learned during 2004 that I could share with colleagues and clients, it would be this:  slow down.  The earth will not open up and swallow you whole if you devote a little time to planning.  Mafia goons will not break your kneecaps if you take 20 hours to do a high-quality job instead of rushing it out in 12 only to find obvious, rookie mistakes in the project.  Despite the old saying, you do not have time to do it over, but you do have time to do it right in the first place.  Nobody is going to fire you for taking the time to do a good job on something.  Note:  this is not to be used by would-be software artistes as an excuse to justify endless noodling on minor details under the guise of doing quality work.

The longer I work in technology (11 years and counting now), the more convinced I am that we – developers and users – create the majority of our own problems.  Whether it is the developer who builds a $5,000 solution to a $5 problem and delivers everything late or the user who refuses to view his job in the larger context of how it benefits his company, we all make things hard on ourselves.  There continues to be a widespread failure to find the “friction point” between cost, timeliness and features.  Add to that the false mantra of efficiency and speed and you have a recipe for a situation in which everyone is working as fast as they can at accomplishing very little.  I can’t speak for you, but I don’t find that very satisfying.  I believe people – in AND out of the technology field – need to have a bit of a craftsman approach to their work.

In other words, 2004 taught me what I already knew.  😉

Things to look for in 2005:

  • My company, Cogeian Systems will announce the pending release of a software product by year’s end.  I am committing my company to spending the first half of 2005 researching product concepts, and the second half developing a prototype, if not a beta release.
  • More articles.  Many more.  And perhaps longer ones.  Consider 2004 a warm-up for the articles I’ll be writing on in 2005.  I intend to continue scolding the duller practices of the industry and praising the virtues of effectiveness and common sense in the development trade.
  • I might bring back the highly-neglected discussion forum.  Or I might not.
  • As always, I will continue to take a “business value first” stance on technology projects.  In the profession of software development and project management, one either creates or enables value, or it’s time to hit the bricks and find a new line of work.

In closing, I want to thank every visitor to my site – 31,000 this month – for reading, linking, eMailing, etc.  Compared to some of the more popular software industry blogs, my traffic stats are nothing to crow about.  However, I still find it immensely rewarding that anything I write resonates with any number of people.  My aim is to spark thoughts and conversations that lead to the betterment of the profession.  Hopefully I’ve made a decent start of it.

So on behalf of myself and Cogeian Systems I say:  Happy New Year, and may you achieve all the success and excitement you desire in 2005!

Joel Backs Down; Claims Misunderstanding

To his credit, Joel Spolsky has clarified the harsh comments he recently made about one-man consulting businesses, revising the sentiment to be more accurate.  In his discussion forum, Joel writes:

It serves me right. By now I should have learned not to post in the discussion groups, because off-the-cuff things that I say without the full-blown multi-page article full of careful hedging and defining my terms invariably gets misunderstood.

So, I will make an effort not to post in the discussion groups any more.

But anyway, what I was referring to in that brief off-the-cuff comment was the kind of one-man contractors who do sequential long-term programming gigs.

SEQUENTIAL: not multiple clients at once, just one client at a time, 40 hours per week.

LONG-TERM: for the purpose of avoiding nitpicking, shall we say, 6 months or more. If you do 1 week gigs you have my permission to call yourself a startup. If you’re a plumber, ok, you’re in business. But if you work at the same big company in the same big department sitting at the same desk and reporting to the same person who treats you like an employee without benefits and you do the same kind of work for six months straight, that’s not entrepreneurship, that’s a job.

I did a gig like that at Viacom for a couple of years and never pretended that I was “Joel Spolsky Consulting, Inc.” or an ISV and I didn’t subscribe to Inc. Magazine. If you’re doing sequential, long-term programming gigs and you’re imagining that it’s entrepreneurship, there’s nothing wrong with what you’re doing, it’s just that you’re not building a business, you’re doing a job. That’s all I meant.

In my original post I used the words “one-man consultant” when I meant “one man serial long term gig contractor,” because it was a quick post on a discussion group and not a thoughtfully edited Joel on Software piece (which, incidentally, takes a week or more to write and edit), and now all kinds of people are accusing me of dissing all one-man independents, people are writing elloquent thoughtful essays implying that my arguments are tantamount to racism or homophobia (ooo! you got me there!).

My inner cynic wants to tell me that Joel meant exactly what he originally wrote and that this clarification includes a certain amount of back-pedaling meant to get him out of trouble with the community, BUT – whatever the motivation, he is making an effort to soothe hurt feelings, and I can’t help but applaud that.  So on behalf of all one-man consulting operations, I say :  thanks, Joel.  It’s good of you to provide a response; you certainly could have turtled and ignored the whole thing, but instead you chose to face the heat.  I can’t help but regard the revision of your statement as a victory for the little guy, but all in all there are no hard feelings.

Handshake?  Hug?  High-five?

P.S.  For Pete’s sake, don’t stop posting in your own message forum.  That’s just drama talking.  Remember, you designed the forum to lack an edit button specifically so people would be thoughtful when they posted – just follow your own design and you’ll avoid having guys like me coming after you with fangs bared.  😉

Joel Spolsky Insults The Little Guy

I’m not one for public bickering, but I simply cannot let this pass without comment.

Joel Spolsky posted an opinion in his discussion forum yesterday regarding one-man consultancies like mine.  Here’s the paragraph I take serious exception to:

I think that being a “one-man consultant” is not entrepreneurship, it’s not starting out on your own, it’s not MicroISV-dom. It’s just having a job. Another job like everyone else. You’re not independent. You’re at the bottom of the totem pole wherever you go. You are constantly selling yourself and trying to find the next gig. The only reason you might consider it superior to a full-time job is if you get bored easily, and you’re welcome to the lifestyle of perpetual job hunting if that suits you, but do NOT tell yourself that you’re a “startup” or an entrepreneur if you’re a one-man consulting shop.

Now, Joel is never one to shy away from stirring the pot for purposes of self-promotion, but there is a certain venom and dismissive quality to his comments that I take exception to.

I’ve heard people using a similar argument to Joel’s on subjects such as sex, race, class, politics, etc. to the effect that “people who do/have x are the real [insert some noun here], whereas people who only do/have y are only pretenders.”  These kind of arguments have been used to devalue women, devalue people of color, devalue gays, devalue the poor, devalue the kid wearing the non-name-brand jeans to school, etc.  I have zero respect for this kind of thinking.

Bear with me as I indulge in some of that annoying line-by-line refuting that is so popular on message forums.

First, we’ll address Joel’s claim that “being a ‘one-man consultant’ is not entrepreneurship, it’s not starting out on your own, it’s not MicroISV-dom.”   I’ll stipulate that an independent consultancy is not a Micro-ISV (although many consultants use their consulting practice to fund the launch of an ISV).

According to Merriam-Webster’s Online Dictionary, the word entrepreneur comes from the old French word entreprendre, which means to undertake.  The full definition is listed as “one who organizes, manages, and assumes the risks of a business or enterprise.”  Hmmm.  Let’s take a look at your typical one-man consulting shop – it is certainly organized to some degree.  The consultant himself manages both his affairs and whatever affairs of his client that he has been engaged to manage.  Assuming risk?  Don’t work, don’t eat – is that risky enough for you, Joel?  And regarding the “business or enterprise” portion of the definition, is not the exchange of value for value the very definition of business?  And if a one-man shop is not “starting out on your own,” I don’t know what is – there is nobody who can assure the singular operator’s success, save for the operator himself.  In what way is this NOT going out on your own?

Joel’s assertion that “It’s just having a job. Another job like everyone else. You’re not independent. You’re at the bottom of the totem pole wherever you go” is as correct as saying that owning a small ISV is a job – it’s a meaningless comment, really.  Everything anyone does for a living is a job.  That’s not much on which to base this kind of attack on independent consulting.  As far as not being independent, again I say that being an independent consultant is about as independent as running a small ISV – if your customers quit buying what you’re selling, you’re done.  True, a business like a small ISV has a model that means money is flowing in even when you take a day off, but any smart independent consultant is going to have some sort of ongoing support contract in place for every app he delivers, ensuring a steady revenue stream when the custom work slows down.  So there’s another attack premise shot down.

Regarding the claim that the independent consultant is at the bottom of the totem pole, perhaps Joel was at the bottom of the totem pole when he was at MCS or when Fog Creek Consulting was young, but I have not had a similar experience.  When my clients bring me on to a project, they do not bring me on solely as a pair of hands that can type things the client’s own hands cannot – my clients want my active input on how they can run their businesses better with the help of technology.  They want my input on how the technology will impact the way they manage their people, how their process will improve, what the most effective practices for getting a desired result are.  I have rarely – if ever – been treated as a low-on-the-totem-pole lackey.  Clients don’t pay today’s consulting rates just to get cannon fodder – they are much smarter than that.  If they wanted a simple minion to serve as surrogate hands, they could get one for $15 an hour form the local junior college’s Introduction to Programming class.

Joel continues that “You are constantly selling yourself and trying to find the next gig,” which is the only truly defendable statement in the entire post.  There is en element of constant selling when working as an independent, but at a certain point even an independent can find that his marketing efforts have generated enough market pressure that the leads come in on a regular basis and work is able to be booked well in advance.  So now that I think about it, perhaps this element of Joel’s comments isn’t defendable after all.  An ISV can no more afford to stop marketing than an independent can.

Joel’s argument against independent consultants concludes with “The only reason you might consider it superior to a full-time job is if you get bored easily, and you’re welcome to the lifestyle of perpetual job hunting if that suits you, but do NOT tell yourself that you’re a “startup” or an entrepreneur if you’re a one-man consulting shop.”

I’ll take this opportunity to remind Joel that businesses come in all shapes and sizes, from the small-town handyman in Montana to the behemoth corporation that makes name-brand products in every country of the world.  That is one of the things that is so interesting and so fantastic about living in a country where so much is available to so many – the diversity of opportunities to engage in commerce, small or large.  I think I can speak for every one-man technology consultant when I say this to Joel:  We are in business, whether you like it or not.  We provide value to our clients, whether you like it or not.  We are growing, we are learning, and we are becoming better at what we do every day, whether you like it or not.  Some of us will even grow up to be big businesses.

We are entrepreneurs as much as you are, Joel.  We have skin in the game and we take our chances, just like you.  Don’t you think it’s rather classless to tear down an entire segment of small businesspeople just to reassure yourself that you are in a “real” business and therefore better than us lowly independents?  That kind of thinking is reminiscent of a small child building a fort and then tacking a sign on the front of it with “no girls allowed” scrawled in a number of Crayola colors – it is false, it is elitist, and it is exclusionary.

You’re a smart guy, Joel.  You should know better.