Just read a GREAT interview with Seth Godin, who is about to launch a book entitled, “The Dip: a little book that teaches you when to quit (and when to stick)“.

For the record, I don’t think it’s time for Jobster to quit (or for me to quit Jobster). Recently, I’ve been asked to direct the product vision for our subscription recruiting application, which is used by hundreds of customers ranging from the enterprise on down. The application has evolved over a few years and has a wide array of features and initiatives. I’m eager to attack each of these with as little bias as I can to see whether they are providing the value we need ‘em to be. I think there are some features in our subscription app that need a little extra love and there are some that aren’t getting used that probably ought to get removed (with the ultimate goal of increasing our user’s value).

If a VC walked up to me tomorrow and said, “Here’s a pile of money. We need you to do something great in the recruiting space, and you’re going to have to compete with the likes of Monster.com,” I’d see that as a real opportunity. Monster and their ilk are well past the point where they are capable of startup-style innovation, and (more importantly) have a lot of revenue to risk if they shifted directions. And, beyond the competition that’s out there, there is an army of recruiters and small-biz hiring managers who are REALLY frustrated with the solutions that are out there.

While the opportunity is clear, it remains to be seen whether Jobster has the recipe to capitalize on that opportunity (though I’m pretty optimistic about it).

Jobster has some tremendous advantages over a “brand-new” startup. We’ve got a team of talented people already in place, solid infrastructure, and a lot of wisdom about the industry. And we have a pile of customers that are using our tools.

The one disadvantage we have is the same one that Monster and the more established players out there have. We have business model that’s bringing in revenue. We have years of legacy code that we have to deal with. We have tons of features, initiatives, and business processes in play, some of which are really valuable, but ALL of which demand attention and resources.

One of the key things that Jobster (and ALL startups) need to be willing to do is quit. We need to be willing to quit initiatives that aren’t working and quit ideas that no longer make sense. People can be adamant about holding on to their beliefs– Startup teams need to be doggedly agnostic about their beliefs (did you know that Flickr started out as an online game? How’s THAT for quitting).

And, most importantly, we need to be willing to quit ideas in a complete enough way that it frees up resources and eliminates the opportunity cost that Godin talks about.

“Smart quitters understand the idea of opportunity cost. The work you’re doing on project X right now is keeping you from pushing through the Dip on project Y. If you fire your worst clients, if you quit your deadest tactics, if you stop working with the people who return the least, then you free up an astounding number of resources. Direct those resources at a Dip worth conquering and your odds of success go way up.”

Great quote.

In the midst of house hunting in the Seattle area, I somehow have managed to launch a little marketing site for RescueTime (my current side project). It shows a few screenshots, answers a few questions, and allows folks to sign up to hear about it when we launch (via a quick-n-dirty PHP script).

I’d love to hear from folks about their thoughts on the site. Is the messaging clear?

I feel like we web geeks need to be constantly aware of the “curse of knowledge” we have about our own industry and the products we create.

The idea of the “curse of knowledge” as it relates to web geeks is one of the most compelling ideas I heard at SXSW, in a presentation by the authors of “Made to Stick“. I’m going to quote Harley Stagner, who has the distinction of being the #1 google result for the query “tappers and listeners”. Congrats Harley!

They told the story of Elizabeth Newton, who in 1990 earned her Ph. D. with an experiment involving “tappers” and “listeners”. In this experiment the “tappers” received a list of well-known songs that they had to tap out on a table to the “listeners”. The “listener” had to guess the song being “tapped.” Out of 120 songs only 2.5% were guessed correctly. What made this noteworthy was the fact that the “tappers” were also required to guess how often the “listeners” would guess a song correctly. The “tappers” guessed 50% when the reality was 2.5%. Why such a huge margin of error? The “tappers” had what the Heaths referred to as the “Curse of Knowledge.” When they “tapped” a tune it was impossible for them to tap it without hearing it in their head. Their prior knowledge of the song title made it impossible for them to imagine the “listener” having no such knowledge.

That 47.5% discrepency is the best damned illustration of the curse of knowledge that I’ve ever seen.

Sometimes I feel like even the best web UI designers are busily tapping away, confident that the users they are building for are “hearing” the same song that’s in their heads.

Anyhoo, if you get a chance, check out the RescueTime site and tell me what song you’re hearing.

(this post is prompted by 3 things. One, a friend of mine just dramatically shifted strategy on his 2-person startup… for the better. Two, Jobster is dealing with these challenges– and dealing with them reasonably well. Three, I just read some related thoughts on Andy Sack’s blog.)

My advice is this: If you’re going to scrutinize your startup idea, do it early and do it often.

Starting up a company is (as I’ve said before), pretty much laying down a bet on a hypothesis. As many startups learn, their hypothesis might be just plain wrong. Or perhaps their hypothesis isn’t nearly right enough to to justify the time, effort and/or funding that has gone into it.

So it’s time to punt on your idea and go with another one. This is one (if not the only) true advantage that a startup has over larger and better-funded competitors– the flexibility to change strategy and tactics at the drop of a hat.

The thing about shifting your idea in a new direction (whether it’s a big shift or a small one) is that it gets exponentially more difficult to do as your idea and company ages. Here are a few reasons that shifting is hard in a mature company:

-Codebase. Codebases have momentum, and they don’t often go away (or go in a different direction) without a fight. It’s oftentimes a lot easier to build something new than it is to shift a codebase in a new direction, but development teams are often loathe to give away their hard-won coding victories.

-People. People get passionate about ideas. The more people you have and longer you’ve pursued a given idea, the more likely you are to have someone importantly vehemently opposing going in a different direction. In short, any shift generally results in SOMEONE having their feelings hurt.

-Customers/Audience. Just because your product isn’t as world-changing as you need/want it to be doesn’t mean that you don’t have loyal and happy customers. If you’re going to shift direction, what do you do with your customers? How are they going to feel when your focus is (at least partially) shifted in a new direction?

-Investors. Investors and other shareholders know darn well that shifting strategy is ALWAYS expensive, even if it’s a relatively small shift. The more you’ve sunk effort, time, and cash into an idea, the more people will tend advocate for a “stay the course” attitude (even though it’s sunk costs).

-Cruft. Cruft is all the crap that your company accumulates that makes it go slower. It’s a database server that acts up from time to time. It’s a middle manager that schedules lots of meetings that never seem to lead anywhere. It’s slapdash code that a developer whips out and promises himself that he’ll fix down the road. It’s old hardware and old Windows installs that start misbehaving. Every day that passes, a little more cruft gets introduced that gums up the works.

All of these reasons get a heckuva lot more painful as a company gets bigger and older.

At Jobster, we’ve recently shifted our strategy in some new (and amazingly cool) direcions. Our attention is split between a few initiatives (which, in itself, is a challenge). While I think we’re moving forward at a brisk pace, I can’t help but ask myself “What if we started moving in this direction 2 years ago?” I’ve only been with the company for 10 months, but I tend to feel that the only thing keeping us from finding our muse earlier was a dogmatic attachment to the correctness of own ideas. We should have been more critical. We should have asked more questions.

We’re not alone in this.

Andy Sack, one of my favorite bloggers and CEO of Judy’s Book, has recently been blogging about his experience shifting his company from an online user-generated-review site to a local affiliate/shopping site (here’s his first post, here’s a longer and more interesting followup). Andy’s company is also about 3 years old and he seems to be experiencing similar challenges (and a few of the same frustrations) that come out of shifting late-in-the-game.

I’m sure Andy is wondering the same thing with the same 20/20 hindsight that I am.

“What if we’d shifted our strategy in this direction in our first week? Our first month? Heck, our first YEAR?”

About 8 months ago, a software idea hit me that I really wanted to work on. Like all ideas, it was based on a hypothesis. In this case, the hypothesis was “if understanding how you spent your time was braindead easy, you’d be a lot thoughtful about how you spent (and often wasted) your time.”

Unlike a lot of ideas, the feature-set required to test this hypothesis was simple enough that I (with a few friends) could set about to build it without interfering with my day job. So we did (should launch in beta form sometime in May).

One of the concerns as we moved forward was the perception that the executive team at Jobster (my employer) would have. Was I giving up on Jobster? Was I hedging my bets trying to participate in two startups at once? Would I cut-and-run the instant my side project took off? The answer is to these questions was an unqualified “no”, but I wasn’t sure I could count on the rest of the senior management team to feel the same way.

As I started being more aware of these concerns, I began to see that a lot of our heaviest-hittin’ technologists had projects on the side. Phil Bogle, our CTO, is the mastermind behind Beyond411. Morgan Schweers, one of our esteemed coders, has an ebay auction monitoring and sniping tool that has a dedicated following. Mark Swardstrom (though he recently left the company), works on a rails content management system in his off-time.

So, are side projects like these (and mine) a bad thing from an employers perspective? Absolutely not. Here are half a dozen from-the-hip-thoughts:

• It flexes muscles you probably don’t use much. Oftentimes, the larger your company, the more specialized your role. Coders spend all day coding. Worse yet, they often spend all day coding using a very small set of technologies. Have a side project and all of a sudden you are using a MUCH bigger toolbox. And, if your side project has aspirations of revenue, you all of a sudden start thinking about…. (wait for it)…. Business. Marketing. Sales. Design. While I think specialists are incredibly valuable, having a passing understanding of the tasks and challenges that other folks on your team face will make you better at what you do.
• It allows you to play with some bleeding edge stuff (if you want). You can try out technologies, interface ideas, and more without the risk you’d have in a more established company/product. You might just stumble onto something that would be valuable in the “real world”.
• It adds to your “shelf life” as an employee by keeping you from burning out. Seems counterintuitive, but it’s the truth. Web geeks love technology. When they go home, they futz with technology. If they don’t have a side-project of some flavor (ANY flavor, really), they will futz with the same stuff they futz with at work. Work on ANY project/technology for 14 hours a day and you’ll burn out quicker. Work on something new/different when you get home, and it keeps you fresh. Of course, ideally, people would find a different hobby, get some exercise, spend time with other people, etc…
• Side projects almost never “make it”. They almost never turn into a full-time job. Starting a company is extraordinarily difficult, and success is rare. Stats vary, but only about 20% of first time businesses last 5 years or more. This chance gets pretty close to ZERO when the founder is only working on it on off-hours. Most realistic people aren’t aiming for the home run when they dive into side projects.
• It might make a little bit of money. This is great for the geek– extra money is always fun to play around with. It’s also great for the boss– the more financially comfortable someone is, the less likely they are to start entertaining job offers based simply on the payscale.

As web technologies become cheaper and faster to develop in, it’s only natural to see more and more ideas fall into the “we can pull this off in a few long weekends” category. It will be interesting to see how many web geeks dive in… And how their bosses react.

Wow. Two posts in a row that link to Seth Godin. Does that make me a fanboy?

In his post “In praise of a blank page“, Godin is essentially saying, “if it isn’t REALLY good, don’t ship it and refuse to market it.” I’m interested to see if this stirs up a hornet’s nest among the “release early / release often” folks.

We at Jobster tend to subscribe to the release eary / release often methodology. Alan Steele, our resident Duke of Products, often uses the chainsaw metaphor– if an initiative isn’t going to be finished by our target release date, we need to start lopping off features/complexities until it will. This obviously results in shipping a helluva lot of software, but sometimes results in releasing software that isn’t quite ready for prime-time. With an iterative development cycle, this is fine– you can always come back to it in the next 6-week cycle… Though sometimes, if a feature is in the “decent-but-not-great” category, you DON’T come back to it.

At Jobster, we do a pretty decent job of having the discipline to iterate on our previous efforts. But with new initiatives in play, there is always tremendous competition for resources. Inevitably, some code that we promised ourselves that we’d rewrite doesn’t get rewritten. Some UI that we know is a little bit clunky doesn’t get rebuilt… Sometimes, a feature is “good enough for now”.

So which is better? “Release now” or “release something perfect”?

Urm, just read a great blog post by Seth Godin who managed to say the same thing I did in my previous post using only about 5% of the space. I guess that’s why he’s a published author! He writes a nice list of 15 ideas in a post entitled “The Realistic Entrepreneur’s Guide to Venture Capital“. I’ll snip-and-paste my favorite bits:

#3 – Investors want to invest in a project that’s tested. If you can’t make it work in the ’small’, why do you think it’ll work when it’s big?

#15 – The companies that VCs most want to invest in are the companies that don’t need their investment to survive.

To all of you folks out there hunting for VC, what do you think? You might think there are seed-stage investors out there who wouldn’t hold their investments to such high standards, but I’d wager that you’ll get MUCH better valuations if you satisfy these requirements.

I just re-read “Getting Real” over my most recent trip to New Zealand. If you’re not familiar with it (you should be), it’s 37Signal’s manifesto on making simple web software. They are simply fanatical about making software that is as simple as possible.

It’s delightfully amusing when someone counters with the inevitable response of, “Well, that’s just ridiculous. Simple doesn’t work for EVERYTHING. What about Fortune 500 Accounting Software?” Their response (I wish I could find it, but I couldn’t come up the search query to dig it up) is, rougly, “Then you shouldn’t solve that particular software problem. Go solve something else and leave the complex problems to some other schmuck.”

I *love* that.

When starting up a company, you truly have a choice of what problems you want to solve (other people aren’t so lucky). I wholeheartedly endorse the idea of solving simple problems (which allows you to stick to simple solutions).

I’ve recently been attending Seattle Tech Startups meetings, which has exposed me to lots of startups that are in various stages of their existence. With a few exceptions, most of them are looking for seed stage or Series A funding.

As I considered it, it occurred to me that solving a problem whose solution is dependent on outside funding is a choice as well.

Don’t get me wrong. Funding is valuable, and sometimes critical for success.

But starting a company is pretty much laying down a bet to test a theory. Maybe you’re betting that your formula can make a better search engine. Maybe you’re betting that users want to share video online. Maybe you’re betting that jobseekers want a better utility to help them with their job search. or maybe you think that there’s a small (but passionate) group of lifehackers out there who want a time management tool. Regardless of what problem you are solving, you are betting your time and your money that you have some sort of secret sauce that allow you to build a business. Unfortunately, you can seldom test your theory without adding some “fuel” to your new company’s tank (in the form of time and money).

I’m constantly astounded by the people who seek funding before they’ve managed to test their initial theory by building and launching the absolute simplest feature-set that would solve the problem they are hoping to solve. The side effects of going after funding too early seem downright painful:

• It’s a huge time sink. You have to write and iterate on a business plan. You have to deliver countless dog-and-pony shows. You have to deal with lawyers. All of these things distract you from executing on your idea.
• Without at least some demonstration that your users/customers are responding positively to your solution, you are long odds for an investor. Even a proven team has a 70% of outright failure, and only a tiny chance at tremendous success. Chances are, an investor is not going to be eager to give you particularly favorable terms if all you have is an theory that you’d like test out. Conversely, if you can show even the slightest growth and can hand your investor a pile of emails from people who are excited about your offering, his odds for a good return on his investment just went up.

I totally recognize that building your idea and vetting it with a small userbase (acquired through word-of-mouth or some clever guerrilla marketing) isn’t always easy. I also recognize that bootstrapping can be painful. And, of course there are a lot of ideas that cost a pile of money before you can ever know if they are any good (for example, if I thought I could run a cable tv company better than Comcast, I might need a few dollars to lay down the fiber).

But, the more I hear stories of crappy term sheets and overbearing VCs, the more I feel compelled to limit myself to ideas that are simple (a la 37Signals) and cheap.

[edit: a friend of mine mentioned that his initial response to this post was that cheap ideas weren't defensible. If you can build the idea without significant capital, what's to stop the next guy from doing the same thing? I'd offer two responses to this. First, I'm only saying that it should be cheap to TEST YOUR THEORY. The person who wins in a given space is often the guy who builds the better business. Once you've tested your theory, you'd better be willing to dive in with both feet (and more money, if necessary) to make it happen. Second, just because an idea can be easily duplicated doesn't mean that the business can. Digg was built in a weekend-- exactly how easy would it be to knock them out of their position of relative dominance?]

I’m a huge fan of tagging as a means to organize data. It’s powerful and flexible– and it oftentimes has some pretty exciting social ramifications.

If you aren’t familiar with tagging (and you want to be), you could get up to speed fairly quickly by checking on the wikipedia entry on Folksonomy. If you’re more interested in insight rather than information, you should check out what Josh Porter has to say on the subject (Josh is hands-down one of the most insightful bloggers out there IMHO).

As a guy who built a web 2.0 resume posting doohickey (chock full of taggy goodness), I’ve put a ton of thought into tagging, specifically in the context of UI. So it was with great interest that I attended the SXSW panel entitled, “Tag, You’re It!”. The panelists consisted of a lot of impressive folks– George Oates from Flickr, Heath Row from DoubleClick, Ben Brown from Consumating.com, and Thomas Vander Wal (the guy who evidently coined the term “Folksonomy”).

The panel was interesting but like a lot of SXSW panels, the more you knew about the topic, the less interesting it was… But, I digress.

The most interesting moment (for me) was during the (very short) Q&A session. A person asked the question, “How do you deal with synonymous tags?” It was obvious that this was not an uncommon question– George Oates had a canned answer for that question…. “You don’t,” she said (yes, George is a girl). “It’s perfectly okay and wonderful that 3 people might tag a single data object in three different– but really similar– ways.” There it was, case closed.

The panel was wrapping up, but I wanted to shout, “Hey WAIT A MINUTE. That’s GOT to be wrong!”.

As I reflect on it, it turns out that there are (at least) two types of tagging– one of which is clearly a winner. The other (which is the type we applied at Jobby and currently are dabbling with at Jobster) is doomed to failure unless we get clever about how we pull it off.

Tagging where the Selfish Motivation is Organization

Flickr and Del.icio.us are the tagging poster-children. They are wonderfully simple– they provide a storage repository for big chunks of personal data (photos for Flickr and bookmarks for del.icio.us) and give you a powerful means to organize them. People oftentimes tag in radically different ways. Some people have dozens or hundreds of tags. Others have only a few. As George pointed out, people oftentimes tagged things with very similar tags. One person might tag a resource with “rockstar”, while another might tag it with “rock_star”, and a third might tag it with “rock-star”. This is fine with Flickr and Del.icio.us… With the service they offer, it’s most important to allow users to label their data in the way that makes sense to them.

The core functionality is organization, and the ability to search/browse/find similarly tagged objects is serendipitous. As a Flickr user or del.ico.us user, you really have no huge incentive to have your data be found by anyone else.

Tagging where the Selfish Motivation is Improved Findability

The only panelist whose userbase was largely concerned with findability was Ben Brown, of Consummating.org. Essentially, his site (recently sold to CNET) is a site where geeks come and tag themselves so they can get matched up with other geeks so they can fall in love and make lots of baby geeks, presumably. This is not unlike the tagging model that we used at Jobby (and currently use at Jobster). People labeling themselves to get found by other people.

This is where the tagging concept starts to break down a little bit. All of a sudden, it’s no longer important what tags you’d use to describe yourself– it’s a hell of a lot more important what tags people would use in a search to find someone like yourself. There are a few unfortunate byproducts of a system like this:

• You are incentivized to lie. The more desperate you are for a date/job interview, the more likely you are to lie. Why not tag yourself “slender”, even if you’re not? Might get your profile a few more views and one of the viewers might latch onto one of your other qualities. Why shouldn’t I tag myself “Ruby on Rails”, even if my experience with it is woefully limited? Maybe some manager out there will find my resume as a result of that tag and just maybe he’ll be wowed by something else he sees.
• You are incentivized to pour on the tags. The cost of adding a tag is very low, and every tag will increase the likelihood that my resume/profile will be viewed. This creates a lot of tag noise. Instead of having a nice and concise list/cloud of scannable tags, you can start seeing tag collections that are less than manageable. A smart coder will tag himself as “coder”, “programmer”, “developer”, “engineer”, “software developer”, “software engineer”, etc.
• Synonyms matter. A lot. Ben used an example of his perfect woman for a search… He did a search for a woman who was tagged “coffee” and “cigarettes” (ew). The problem with tagging in this model is that Ben’s search simply won’t find a woman who is tagged with “caffeine lover” or “smoker” or “chainsmoker” or “coffeelover”.
• People who are tagging data need to be smart about the psychology of searching, which they never will be. In the SEO biz, there are lots of tools (some of them very expensive) to allow a person to understand what people are searching for (to allow you to craft your content and meta-data to map to those search behaviors). People looking for a date or a job don’t have the time or money to figure out whether hiring managers are searching for “programmer” or “developer” more often. If the tagger is sophisticated enough to even consider this problem, he’ll probably (to be on the safe side) tag himself with both.

So, are you screwed if your service has tagging to enhance the findability of your users? I hope not. Here are a few strategies we’ve used at Jobby and Jobster to keep tags from getting “spammy”:

• Suggested tags. This is the best thing we did with Jobby and (unfortunately) it’s a feature that is really buried in the UI on Jobster. With Jobby, we essentially took what data we had on the user and presented tags that seemed likely to be of value to the user. So if a user tagged themselves “HTML”, we could fairly reliably say (given how often the two tags went hand in hand for other users) that they might want to tag themselves “CSS”. This also has a nice side-effect of giving your users the ability to tag themselves with a click rather than by typing all of their tags. And, of course, it encourages people to use the most popular iteration of a tag (using “CSS” instead of “cascading-style-sheets”, for example).
• Add scarcity to your model. At Jobby, we allowed user to assign a skill level to their tags (beginner, intermediate, advanced). There was functionally no limit to the number of tags, but it makes it a touch more difficult to lie. A lot of fledgling web geeks might be comfortable saying they know JavaScript, but a lot LESS comfortable saying they are JavaScript experts. At Jobster, I think we’ve provided a more elegant solution. Users are allowed to have up to 5 Superstar Tags– basically, these are the skills/areas that you feel you’re best at.
• Add REALLY SMART suggested tags within your search UI. We did this (in kind of a clunky way) with Jobby, and people LOVED it. With Jobster, we’re JUST starting to experiment with this, but I think it’s critical for tagging to work (when findability is the primary motivation for tagging). You’re search experience needs to be smart enough to present similar and/or related tags. Further, it needs to be smart enough to give the user a sense of the popularity of given tags.

I’m still waiting to see a site that really manages to nail the tagging/searching experience when the motivation isn’t just for personal organization. I’d love to hear more ideas on how this could be pulled off.

The first day of SXSW was largely dedicated to picking of your badge (and getting a picture taken for it) and picking up your bag o’ schwag. The act of getting the badge involved standing in a HUGE line, riding up two escalators, standing in another line, getting my picture taken, and then waiting in a mob to hear someone call out my name. Then I had to go to another line to get my “big bag” (mostly advertisements). Once I got my badge, my friend and I looked up where we needed to go to find one of the two panels that was offered for the day (it was the panel on “Snakes on a Plane”). I believe the room numbers was 10ABCD. We dug around in the Official SXSW Program and eventually found a map (it was challenging– the advertisement to content ratio was pretty damn outrageous). We finally found the room where the panel was supposed to be and found that it was dead empty which, given the hordes of geeks at the Austin Convention Center, seemed suspicious. So, we hoofed back to the mail area.

The next logical step seemed to be to find a SXSW employee (there were a bunch of “volunteers” – I don’t know exactly why they’d volunteer). I approached a table marked information, where there were 4 people helping a single attendee. Well, to be honest, it was 1 person helping a single attendee which the three others watched with interest. I stood there expecting one of them to break away to see what I needed, but they never did. I was eventually told that the panel had moved to a different room than the one on the printed schedule that we had. Odd that they hadn’t bothered to put a note on the door. We finally made it to the panel (a bit late).

On any other day, it would have been an annoying way to spend an afternoon. As a guy who tends to be a bit of a usability zealot, inefficiencies and sloppy systems tend to really set me off. But the energy of the conference was overwhelming. I was thrilled to just be there and too excited about the coming days to get bitchy about the low level of service that I’d experienced.

That night I tried to get a full night’s sleep. Unfortunately, I’d just gotten back from a long vacation in New Zealand, so my internal clock was off by 6 hours… not just the three it normally would have been coming from Seattle. I slept terribly, woke up late, and rushed out the door.

And I forgot my badge.

After breakfast and coffee downtown, we headed to the convention center. I was confident they wouldn’t turn me away without a badge. After all, they’d made me wait 45 minutes the day before just so they could get my picture– they KNEW what I looked like. I’d registered early, so my name was certainly on file. And I had a pile of photo identification to choose from. But, turn me away they did.

I was pleasant. I owned up to the fact that it was MY fault. I mentioned the fact that I had just gotten back from New Zealand and was really hurting for sleep (true). I mentioned the fact that the hotel that my company had booked was 20 minutes and a $25 cab ride ($50 round trip) away from downtown (true). I expressed concern over missing the first panel session.

None of it phased the (bored looking) registration “volunteer”. “You’re out $350 [the cost of the conference] if you can’t find it.”

On the cab ride back to the hotel, the previous day all came back to me. All of the petty annoyances that I had happily forgiven started REALLY pissing me off. And, quite honestly, I was pretty slow to forgive SXSW for continued inefficiencies and annoyances throughout the rest of the conference. I still had a good time and I still learned a lot. But, like a powerful web site that has a crappy UI, it really tarnished the experience.

As I reflect on this experience, I think it really generalizes to a lot of aspects of software development and customer service. The cost of forgiveness is often very low, and a touch of forgiveness towards your users can go a long damn way.

Jobster is hiring! We’re having a devil of a time finding solid software developers (though we do have a new one starting Monday).

In my recent participation and attendance at Seattle Tech Startups meetings, our problem is not unique. I would say fully a third of the self-introductions I hear are along the lines of “Hi, my name is John Smith from backrubr.com [note: I just made that up!] and we’re looking for talented web developers!”).

A quick look into the Jobster search database seems to indicate about 1,200 jobs across the country with the keywords of “web startup jobs“… Given the challenges I’ve seen people have hiring web developers, this number seems low (though I’d wager that 75% of these jobs are packed into Seattle, Silicon Valley, Boston, and New York). With demand like this, it’s no wonder that there are sites that are totally dedicated to job opportunities with tech startups.

On behalf of all of the people who are suffering through trying to fill reqs for web developers, I’d like to publicly thank all of the people who (a decade ago) were telling all of the students who were considering web careers to look elsewhere (“Web development jobs are all moving offshore! That industry is doomed!”).