Scott Porad

I had breakfast last week with someone who works at a relatively big company.  He has a front-line job, and was telling me how he was reprimanded recently for spending too much time inquiring about the roles of his peers and the overall strategy for his department.  His boss, he said, told him that he just “needed to put his head down, stop asking questions and do his job”.

This got me to thinking about my earlier post on Managers and Executives.  One thing that went unsaid in that post was the importance of internal communications.  Almost everywhere I’ve worked has underestimated how important it is to constantly communicate to the team the goals and strategies of the business, and how the day-to-day projects that various teams are working on tie into them.

Jazz at the Preservation Hall, New Orleans

Internal communications are especially important in a world where executives are acting like executives, and managers like managers.  Without executive micro-management, managers are making decisions independently and need to have clear direction on how to guide their teams.  Likewise, employees make dozens of independent decisions each day, so without micro-managing mangers they need clear direction to guide these daily choices.

The bottom line is that managing–either for executives or managers–is a bit like jazz.  The band leader has to outline the framework of the song (i.e. the key and time), but the players have freedom to work within that framework.  Some songs (i.e. some companies or jobs) require the framework to be tighter and more coordinated than others, thereby the players have less freedom.

As a manager, it’s a really, really critical part of your job to make sure the players in the band know the framework, so that they can use their creativity and talent to play the best music possible.  As I said, I believe the value in this is widely underestimated, so I make an effort to regularly communicate to my team the path were on and how the project they’re working on fit into the plan.

My friend Cody lives on the top very large hill outside the city of Seattle with an absolutely spectactular 270° view.  On Sunday, we were out on his deck enjoying a bottle of wine, discussing how things were at our respective companies.

As those of you who are regular readers know, I work at Cheezburger which is a very small little company and where just about everyone is a jack-of-all-trades.  On the other hand, Cody is a vice president at a Fortune 100 multi-national corporation.  It was interesting discussing the contrast in our jobs and companies.  This led to my better understanding the different roles that exist in a company.

View of Seattle from Somerset

As we saw it, the job of a manager is to direct resources toward completing a task or tasks.  Executives set goals and strategy, and communicate those to managers so that the managers are working on the right set of tasks.

But, the job of an “executive” does not stop at setting the goals and strategies.  In fact, that’s only where it begins: the real job of an executive is to have a system for constantly evaluating and adapting the goals and strategy to the customer marketplace.

As we discussed our most positive and negative work experiences, this distinction became clear by noticing the behaviors of executives, especially in times of crisis.  We saw that in times of crisis, low-quality executives tended to act like managers.  That is, in times of failing goals and strategy the response was to jump in and direct resources.  In part, we speculated, because most execs worked their way up the ranks as managers.

Another way of looking at it is to say that the lower quality executives did not have the skills, or had not implemented systems, for evaluating and adapting strategy.  When business was good, this issue was masked by success.  But, in times of crisis they substituted strategic planning with resource management.  In other words, they winged it.

Interestingly, this realization helped clarify my own thinking from The Peace Bubble post:

At Cheezburger, one of the cultural attitudes we’re working hard to develop is [being] methodical about testing what we do, so that we can learn from it, regardless of whether or not it succeeds or fails.

In other words, to be more successful we want to ensure that we have executive skills in addition to manager skills.  Methodical testing of performance is one type of executive skill.

Yet, in a small company, like a startup, these are not jobs that belong to a specific person because there just aren’t enough people.  As a result, I think it’s healthier not to think about these as jobs, but rather capabilities of the team.

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.

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.

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.

I was inspired to write the Launching is the Only Thing That Matters post based on an experience I had with a client over the weekend.  Let me start the story by telling the ending:

In web development, a launch is not the finish line.  Launching is the starting line.  Not only is it the start of a business, it’s also the start of the next phase of development.  I think the people I advise are a lot more comfortable launching quickly when the realize launching is just the beginning.

The clients I was talking to are trying to launch a relatively straightforward online retail toy store.  The design is beautiful, the product selection exquisite.  But after a year of developing the site (read: one year equals paid lots of money to a web dev shop) the were not very close to launching.

I explained that they needed to focus on launching their site and the way to do that was “strip out everything that is not absolutely 100% essential”.  Like many people launching a web site, they had a million features and loved everyone of them like children…they could not imagine living without any of them.

One of the beautiful things about a web site is that you can regularly and incrementally add features to the site.  It’s not like building a house where it all has to be done at the same time.  For a web site, you can easily build the essentials (kitchen, bathroom, bedroom) then add on the remainder (living room, dining room playroom) later on.

Agile has an expression that I let guide me often: do the simplest thing that could possibly work.  Pause for a moment and think about that: what’s the the absolute minimum necessary?  I wrote to them:

In my opinion, it’s this: home page, product list page, product detail pages, shopping cart, contact info page.  That’s the minimum amount you need to launch an online store.  I would pare it back to that, and launch.

Will that be the most robust and amazing online toy store ever?  No.  Will it work?  Yes.  Does it allow you to start creating value?  Yes.  Does it put you in a position to start learning about your customers?  Yes.  As soon as you launch, can you begin work on some of those amazing toy store features?  Absolutely!

In my view, when you see launching as the beginning, it becomes clear that launching as quickly–even before your product is fully complete or finely polished–is the most logical path to success.

The most dangerous pitfall for a startup is to waste resources–time, energy, and money–on things that don’t matter.  I mean “don’t matter” in a relative, not absolute sense.  In other words, spending resources on things that “don’t matter now“.

When I advise startups I return to this theme a lot.  And, there is one piece of advice that I find myself repeating over and over again: the absolute, number one most important thing is to launch.

Let me repeat that because I can’t emphasize it enough: strip out everything that is not absolutely 100% essential and get your product, feature or site in front of real users or customers.

Why?

In most cases, you are trying to create value with whatever you are launching.  It is impossible for that to occur if you haven’t launched.  Simply put, whatever you are trying to achieve cannot happen until you launch.  Period.  To share the wisdom of a former co-worker, “you gotta be in it to win it”.

Equally as important is that the only way can start learning about what works and what doesn’t is by having real customers use it.  You may think your users or customers want a widget or gidget or flex capacitor, but you just don’t know for certain.  Until you know for certain you’re putting your resources at risk.  The surest way to find out is to get your product in front of the users and learn.

At the end of the day, launching is the name of the game…focus on it like a laser beam and you will succeed.