Jobster alumnus Mark Maunder has put his travel blogging startup on hold for a month or two to pursue his muse… Which, in this case is (drumroll please) inline blog comments! It would be irresponsible of me not to mention Mark’s wife and biz partner, Kerry– who is quite likely the only reason that this thing has gotten off the launch pad…. Kerry is a seasoned QA manager and has almost certainly kept this thing from being a bug-ridden pile o’ PERL code.

It’s in “soft-launch” phase and they are working out a few kinks, but I think it’s a pretty exciting idea. So try it out here, head over to Linebuzz.com and bury Mark and Kerry in feedback and bug reports.

Before I got involved with product development a few years ago, my entire career was spent owning and running a small (10-20) person web app consulting firm. Clients (ranging from mom-and-pop operations to Fortune 100 megacorps) would come to me with a problem and I would assemble a team to solve that problem with some sort of web application. 99% of the time, the size of that team was somewhere between 1 and 4 consultants.

When I started a little Web 2.0 company, it seemed natural to keep the team to 2 people, with me doing some design, PR, marketing, and biz related stuff, and Brian doing the assorted geekery required to make a web app go (server and client side coding and a bit o’ sysadmin work).

When our little company got bought by Jobster and we relocated to Seattle, one of the things that truly blew me away was the SIZE of the product development operation at what most Jobsterites felt was a lean operation. There were literally dozens of developers, a few designers, a mess of program managers, and a small army of offshore QA folks. I don’t have the exact count, but I think that somewhere in the neighborhood of 35 people could honestly say, “My job is to build software” at Jobster.

So why the discrepancy? The little teams that I had worked on for most of my life weren’t solving tiny problems. Sure, we had an occasional brochure-ware client, but a big slice of our time was build applications that were pretty darn complex and sophisticated. There are two very legitimate reasons that software teams get big:

• First off, some web software is just big/complex/ugly… and it has to be. Enterprise software tends to be bigger, more complex, and have lots of integration points which get pretty complicated. The “two guys in a garage” theory doesn’t really work for such things. The more I play in the world of web development, the more adamant I am about not wanted to play in the world of “big” software. Big projects might have merit, but they are certainly a helluva lot less fun.
• Some teams are really a bunch of smaller teams working on different things. Jobster was (and is!) definitely engaged in several different initiatives. So the team of 35 people were really (depending on how you slice it) working on two or three very different problems.

Unfortunately, the list of reasons for team bloat goes on and it gets pretty ugly (note: some of these are paraphrased from Parkinson’s Law)

• People make work for each other. Certain people are REALLY good at creating LOTS of work for other people. Some of this work is valuable and productive, but much of it (excess documentation, “here’s what I’m up to” meetings, etc) is not.
• The amount of work on a team ebbs and flows. Sometimes there’s a ton of work, and an undisciplined (or over-funded) team will seek to get bigger rather than just suffering through the peaks.
• People like subordinates. Oftentimes, a manager is measured by the size of their team. Bigger teams mean bigger budgets and more responsibility, and that looks good on a resume.
• Work, like water, spreads out and seeks to fill the nooks and crannies of an organization. If a 10 hour task for one person spreads around to involve 4 other people, it’s likely that the manpower spent on the task will explode to something well beyond 10 hours.
• An individual’s tasks will expand to fill the time alloted to accomplish them. This seems like the other side of the “necessity is the motherhood of invention” truism. In the times where people have more time than they need to accomplish a task, they’ll find a way to stretch it out. This includes surfing the web or (much more dangerous) adding complexity/oversight to the processes involved in completing the task (creating a longer term “bloat”).
• Communication paths grow exponentially with the size of the organization. With two people, there is exactly two possible communication directions. With a team of 10 people I have 9 other people that I have to communicate with (and who have to communicate with me). This dramatically increases the chance of miscommunication, confusion, excessive questions/clarifications, and (everyone’s favorite) office politics.
• Low quality team members can hide in the herd. If a team member loses their motivation in a two person team, it becomes pretty evident pretty quickly. On large teams, low-productivity members can lurk for months without any problems.

Of course, there is some value in larger teams. And, in my opinion, there is simply HUGE value in growing your team from 1 to 2. Two brains are most certainly more than twice as sharp as one. Beyond a team of two or three, however, I think that the added manpower offers asymptotically diminishing returns. While I truly believe in the Wisdom of Crowds, I think the best way to harness this wisdom in software development is by collecting thoughts and opinions in a one-off kind of way (usability tests, focus groups, consultants and the cheaper alternatives of asking peers, friends and family for their opinions).

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”?