Scott Porad

I just gave someone admin privileges to one of our Cheezburger systems.  Whenever I grant someone admin privileges to one system or another, I always give them this little speech:

You’ve been given the power, now keep these two things in mind:

1.  Play nicely with others.

2.  Think before you type.

We all have admin privileges in our own lives, so in general, I think these are just good words to live by.

P.S.  I can’t take credit for this speech: it was a given to me by a sys admin named Trey Valenta way back in the olden times.

In the New World (the world of social media, the Internet, online, whatever you want to call it)…which is basically NOW…technical capability on the web isn’t really the limitation any longer.  I’m a web developer, so I hate to say it, but for the most part technology has become a commodity.

When I started doing this 15 years ago (“this” meaning, building web sites as a profession), that basically wasn’t the case: you had to have specialized skills to publish on the web.  Ward Cunningham had introduced the wiki in 1994, but very few people knew about it or understood it. Even so, it took technical skill to set one up.

Then, a few years later Dave Winer’s UserLand introduced Manila which, to my understanding, was the first widely available edit-in-the-browser blogging tool that was provided as an online service.

Now, just look at WordPress.com: 5 minutes and you have your very own self-published web site.

So, my point here is that once technology was the gating factor for simply being online, and the winners in the online marketplace were those who developed the technology the fastest (all other things, mainly quality and marketing, being equal).

But that is no longer the case.  Now, it’s not about developing the technology, but figuring out how to use it effectively.  In some ways, that’s where the New World is right now…searching to figure out the most effective ways to use these widely-available tools.

I remember the first time I looked up something in the c2 wiki, and, as a matter of fact, I am proud to say that I was a Manila user.  But, in both cases I didn’t know how to use them.  I mean, I knew how to operate the dials and make the machine whirr, but I didn’t know how to make the machine do something useful for me.  I didn’t know how to apply the technology.

Which brings me to my point: in the New World, it’s the people who figure out how to make these technologies do something for them that are going to succeed, going to win the race.  And, like any race, it’s the people who do it fastest that will win.

In other words, if you want to win in the New World–and you do want to win, right?–then the way to do it is to become a really fast and effective learner.  Get really good at testing and experimenting, and applying the results to iterate, innovate and improve.  And, get really good at doing it fast.  That’s the path to success.

All the widgets and tools and technologies are just a distraction at this point.  Implementing them, if they’re the right solution for your problem, is largely mechanical.  The name of the is learning as fast as possible.  Everything else is just commentary.

Our friend Jill made the most amazing gazpacho for Lisa and I tonight.  “Jill, this is hands down the best gazpacho that I’ve ever had!  How do you make it?!”  “Well, Scott, a little secret: the Barefoot Contessa.”  Of course, she followed a recipe.

Jill's Gazpacho

That reminded me of a conversation Martin and I had earlier today Cheezburger Inter-Galactic HQ.  I was stumbling through trying to explain some new tables in the database by way of a tortured analogy to abstract classes.  “Well, it’s a Decorator Pattern,” Martin said.

Martin’s smart like that: he uses tried-and-tested software design “recipes” (called “patterns“) when he builds stuff.  Likewise, Jill doesn’t waste hours trying to invent her own reciepe for gazpacho–she relies on a tried-and-tested cooking “pattern” (called a “recipe”) when making gazpacho.

It struck me that for many of the problems out there somebody has already figured out a pattern or recipe.  For some things, there is no pattern which is probably why you’re in business–you’re getting paid to figure something out that nobody has figured out before.  (Or, you’re getting paid because you’ve figured out a better pattern.)

Being able to determine when there is an existing pattern or recipe is important for companies big and small, but especially for startups.  As I’ve said before, startup resources are extremely scarce, so using them wisely is critical.  Effectively, by devising your own recipe for gaspacho when plenty of recipes are out there to follow means you’re overpaying for the gaspacho.  That is, you’re investing development dollars to develop something that already exists.

Or, to put it more succinctly: what value is there in reinveting the wheel?

You should sign up for my RSS feed which you can do by clicking here. Subscribing to my RSS feed will save you time by pushing my blog directly to you, and ensure that you don’t miss anything important.

I am a golfer.  The primary reason I golf is because nobody has invented a way to keep score in paper cuts.

But, I digress…

Last week, before our round, one of the guys in my foursome sent a link to the video below, The Peace Bubble.  I think he meant it as a joke, but I couldn’t quite tell, so I ended up watching the entire thing until the end.

The gist of the video is that you can’t succeed by focusing on the outcomes of your actions.  Rather, to succeed you need to focus on the process that creates those outcomes.  The screens at the end that described “outcome-based golf” versus “process-based golf” struck me because they could be applied to startups and businesses as well.

When I think of the startups I’ve been involved with, one of them was completely focused on meeting weekly budget numbers.  In other words, the outcomes.  Discussions about the business always started with the weekly numbers, and rarely on the processes created them.  That place was a completely unpleasant place to work, and only marginally successful.

Another startup, when it started, all the founders were thinking about was the exit strategy–an IPO, a buyout, etc.  That place wasn’t so bad to work, but it wasn’t very successful.

At Cheezburger, one of the cultural attitudes we’re working hard to develop is an emphasis on knowledge generation through a scientific approach.  In other words, we want to be methodical about testing what we do, so that we can learn from it, regardless of whether or not it succeeds or fails.

I feel like this orientation toward outcomes is actually process-based.  In other words, the outcome we care about is the learning–do we have a process for generating knowledge and learning–and not the the success or failure of the effort.

You should sign up for my RSS feed which you can do by clicking here. Subscribing to my RSS feed will save you time by pushing my blog directly to you, and ensure that you don’t miss anything important.

It is ridiculously hot in Seattle right now. We’re in the middle of a very unusual heat wave–I’ve lived here for the majority of my life and I don’t ever remember a stretch like this! Most people here aren’t prepared for hot weather–I’d say at most 5% of homes have air conditioning.

But, I’m not complaining. Since it’s so often cloudy and overcast in Seattle, I try very hard not to complain about the times when it’s uncomfortably hot. In fact, I think there’s a lesson to be learned from this heat that can be applied to developing a web site.

All-Time Record High for Seattle

When it comes to the weather, Mother Nature doesn’t always cooperate with what us hooomans, as the LOLcats like to say, have planned. We plan a wedding, but it rains. We plan to work, but it’s 99 degrees and there’s no AC in the office, so it’s impossible to concentrate.

In other words, there are things beyond our control, and accepting that is important. Learning to go with the flow is a very valuable skill.

One thing that’s beyond our control is knowing exactly how long it’s going to take to get a project done.

For example, we’ve been working on a project at Cheezburger that we’re going to be rolling out in phases over the next few months. Our plan was to ship the first phase this week, but it’s not ready yet. At that point, we sort of had some options:

We could be rigid, and have shipped when it wasn’t ready simply for the purpose of “meeting our schedule”. But, we’re just going to spend the next week fixing the things that we’re ready. The customers will be unhappy, the bosses will be aggravated, and the developers will be demoralized. This is a lousy plan.

We could beat ourselves up and burn the midnight oil, so that it “shipped on schedule”. While that may ship this phase on time, and make the dev team feel like heroes, it will likely result in a delay on the next phase because a) we will have burned ourselves out, b) haste makes waste (i.e. bugs) that we’ll have to spend time fixing. This is also a lousy plan.

Or, we could accept reality: it’s taking us between 3-7 days longer than we thought it would. (Rome wasn’t built in a day, as they say. But, I’m also pretty sure that when they started building Rome they couldn’t predict accurately how long it would take.)

Personally, I don’t see a lot of value in trying to bend reality toward arbitrary hooman schedules. Nobody wins with rigidity–it just creates a lot of extra effort and stress without much benefit. Just like we can’t always control or predict the weather, sometimes we can’t control or predict how a project will go either.

You should sign up for my RSS feed which you can do by clicking here. Subscribing to my RSS feed will save you time by pushing my blog directly to you, and ensure that you don’t miss anything important.

A lesson about business that Seth Godin learned by riding a bicycle: your best opportunity to improve your cycling performance is while riding uphill.  In other words, your speed has limits when you’re riding downhill, so extra effort doesn’t make that much of a difference.  But, when riding uphill your extra effort really counts.

Let me show you how this lesson applies to web development.  To do so, let’s ride our bicycle up and down the Hill of Traffic.  What you see below is a chart representing traffic on a web site over a period of time.  On side A, you see that traffic is going up, and on side B it is going down.

When your website or company is on Side A, then it’s Good Times.  Traffic is growing and everybody his happy.  On the other hand, Side B is Bad Times.  Traffic is falling and everybody is worried.

During the Good Times, there isn’t a lot of consequence when you slip a schedule, or ship a bug.  No worries…it’s Good Times, right?  But, during the Bad Times, the boss wants you to rush stuff out the door faster stop the falling trend, and is willing to take calculated risks on quality.  Big worries because if this doesn’t turn the tide…well, it’s Bad Times.

The lesson is that when you’re going up the Hill of Traffic, Side A, that’s when you’re extra effort counts.  During the Good Times, that’s when you have the opportunity to focus the things that make a development team great–test automation, solid operations and infrastructure, and planning, design, estimation, scheduling and delivery.

When you’re going down the Hill of Traffic, Side B–and inevitably you will, for a week, or a month, or a quarter–you won’t have time to focus on the things that make a team great.  All you will be able to do is run like mad and hope that you’re best efforts turn things around.

To me, this is relevant because Cheezburger is Good Times right now, and everybody is having fun.  But, that isn’t going to last forever, so now is the time that we’re going to re-double our efforts at being an awesome team.

Below is a recently popular video from Google that interviews people in Times Square.  The interviewer asks a variety of very simple questions about the Internet and receives corresponding variety of very, very wrong answers in repsonse.  For example, “What is a browser?”  Among people who work with the web and computers, the typical response is to think, “gee, what a bunch of idiots”.

But, I think that’s missing the point: never underestimate how much you know.

If you’re reading this blog, chances are you work with the Internet professionally and understanding the notion of a “browser” is less than Internet 101 to you.  But, you have to remember that compared to the average bear, you’re at least five standard deviations away in understanding of the Internet.

I am reminded of a conversation we were having in the office a few weeks ago.  Under discussion was the design of a new image gallery, and the debate was over whether or not each picture needed a link that said “select” beneath it.  One side said that it’s obvious that you need to simply click a picture to select it, and seeing 25 “select” links on the page looks bad.   The other side replied that even though it looks less streamline, we can’t overestimate our users, so we need a clear call to action.

I sided with the later group, and I call this the “lead a horse to water” school of web design.  For most users, you need to put the action right in their face in order for them to see it.  Especially, for broadly based consumer sites, where the user is far less skilled than you, as an Internet Professional, can imagine.

That’s not a knock on users.  I love users; they feed my family.  Rather, it’s a compliment to you: the detail and minutiae that you have in the dirt under your the fingernail on your pinky finger is greater than the casual web user has in their whole lifetimes.  I’m not saying they’re dumb, just that you’re very experienced.

Just how much you know is something very important to keep in mind when designing your product.  Remember that, and you’ll go a long way.

After leaving drugstore.com, and before I started working on Cheezburger, I worked on a startup with some friends.  After awhile it never quite “started” or “upped”, depending on which way you look at it.

We still have it going with one part-time developer, but I doubt it will ever amount to anything.  Which is really too bad because I think it was actually a pretty good idea.  In fact, all of our market research and dozens of potential customers told us it was a good idea.

I was struck just last weekend when I crossed paths with someone who was part of our initial focus groups and she was still enthusiastic.  So enthusiastic that she was eager for it to launch so she could pay us money to use it!  I had to ask myself, “with such a great product, why didn’t it ever get going?”

I think the answer is that there are ideas you are passionate about and ideas that are good, but for a startup to succeed your idea needs to be both.  In other words, a good idea that you are passionate about.

If you have a bad idea that  you are passionate about, then you’re just beating your head against a wall.  Smart people recognize this, so they’ll either quit or change their idea.

On the other hand, if you have a good idea that you are not passionate about, then you’re not going to have the energy or desire to push through the inevitable obstacles that come with starting up.  Passion is the irrational drive that keeps you going through good times and bad.

In our case, we had a good idea that we weren’t passionate very passionate about.  It doesn’t matter how many potential customers are begging you to ship your product, that isn’t the magic elixir that gets you up early and keeps you up late.  The magic elixir is passion.  Remember that, and you’ll go a long way.

This week I wrote about launching and swarming.  It wasn’t by accident that I wrote about both these topics this week–it was deliberate.

In Launching: The Only Thing That Matters, I made the point that your startup couldn’t realize the value they were creating without putting the product in front of customers.  In other words, if you don’t start the race, you can’t win.

Want to Get More Done? Here’s How: Do Less! illustrated how by focusing on one project at at time a team can deliver results more quickly while providing the business greater flexibility and eliminating waste.

Why did I write about them together?  What do they have in common?

The answer is if launching as soon as possible is a key to success, then the “swarm” method of project development is an essential ingredient.  The startups that swarm will launch more quickly and, therefore, have an advantage over those that don’t.  Startups are hard, so every bit of advantage is priceless.

I gave a talk recently about some of the development practices we follow at Cheezburger.  The structure of the talk was a series of questions, one of them being:

Why try to get a lot of stuff done when you could just do one thing instead?

All companies want to get as much done as possible, and most companies try to accomplish this by doing a lot of things.  Our experience has found that doing less things actually results in greater productivity.

We call our approach the “Swarm method”.  I don’t think we invented Swarm, but we’ve found success with it.  In a nutshell, Swarm says that you’re entire team should work on one project at a time until it is complete and has shipped.  Then, like swarm of bees, the team should move to the next project all at once.

What!?  How could this possibly be better than working on many projects at once?  Let me show you how:

• Imagine you have a team with 5 developers, or 25 dev days per week.
• Imagine you have five 1 week projects, or 25 dev days of work.
• In the “Do Lots” method each developer is assigned a project and they’re all done in one week.
• In the Swarm method, the entire team works on a project for a day and they’re all done in a week.

So, I guess there’s not really a difference, right?  Wrong.  What happens on Tuesday when the boss changes his or her mind about the project priorities.

• In the Do Lots method, no projects are ready to ship, so two days have been wasted.
• In the Swarm method, two projects are ready to ship, so a) something got done, and b) no days were wasted.

In short, the moral of the story is:

Being Busy != Being Productive

Furthermore:

Being Productive = Shipping Code

Shipped Code = Opportunity to Create Value

If you’re working in a dynamic, startup environment you cannot afford to waste your time; every moment of your time needs to be focused on creating value for your startup.  And, you cannot afford to be inflexible or you will miss opportunities.  Swarm solves these problems.

You should sign up for my RSS feed which you can do by clicking here. Subscribing to my RSS feed will save you time by pushing my blog directly to you, and ensure that you don’t miss anything important.