Scott Porad

This tweet caught my eye last night:

which led to a post by Antonio Rodriguez summarizing a keynote he gave at PyCon (i.e. a conference about the programming language called “Python”).

Rodriguez made three key points in his presentation, only one of which I’ll address here…he said:

I think every employee in a web startup— or in fact any company which depends on software in any meaningful way— should learn how to code. From the slickest sales guy to the most obstinate operations guy, from the laziest intern to the most professorial manager, if they don’t have their hands in the code, your startup is much more likely to fail.

I don’t disagree with this idea, although I terrifies me a bit. Rodriguez’ arguments for this are two fold.

First, it breaks down the false dichotomy between “business” and “technology”. I agree, in a web startup—the only type of place I’ve ever worked—the technology is the business.

Second, he argues that if everyone were able write code—even if it is just a marketing person updating the UI of an analytics report—”will tighten the loop and give you massive competitive advantage”.

I would add a third point, based an idea Joe Heitzberg mentioned to me the other day: in a web-based company, there are two types of workers: “work creators” and “work doers”.

A person who writes code is a “work doer”. A person who writes a spec is a “work creator”. (A person who designs web pages is a little bit of both.)

That’s not to say a person who writes a spec isn’t important…they play a crucial role in making the person who writes code efficient and effective. However, it takes another person (a work doer) for the value created by the spec writer to be fully realized.

The point isn’t that your company should be all “work doers” and no “work creators”. The point is balance…having an appropriate number of work doers versus work creators.

At a previous place I worked, I’d estimate we had 4 work creators for every 1 work doer. That was not the right balance.

On the other hand, toward the end of last year at Cheezburger we had the opposite problem; we had too many work doers and our ability to write code outpaced our ability to figure out what exactly to write.

Effectively, Rodriguez’ point is that everyone should have some work doing capability, even if it isn’t their primary job role. As a result, startups will have greater flexibility because they will be able to more fluidly maintain the proper work doer-work creator balance that is essential for success.

We were recently interviewing for a position at Cheezburger, and a candidate was describing a difficult situation at one of his previous jobs.  I asked, “How did you resolve it?”

“Well, I’ve never seen the world’s problems solved without communicating,” he replied.

I practically wanted to hire him on the spot.

—

One of the things I’ve been thinking about quite a bit lately is putting together good teams.  (Randy recently suggested a book called Beautiful Teams, but I haven’t had time to read it.)

More specifically, I’ve been thinking about when startup teams start to grow beyond the point where everybody can sit in the same room.  There are three dilemmas that have been on my mind.

Specialization versus Generalization

When there are only a handful of people, specialization is something that’s hard to afford.  Instead, a startup needs jacks- and jills-of-all-trades.

The thing about these jacks and jills is that they’re hard to interview for because most of what being one of them entails are intangible qualities: a good attitude for doing anything and being flexible, and the ability to figure things out on your own.

Ben is always suggesting doing some sort of screening or “testing” to find candidates with these qualities, but have yet to think of a screen or test that will find these types of people.  I would completely be open to your suggestions in the comments.

Organizations in Flux

Another dilemma has to do with building teams at an organization in flux.  One quarter your building widgets, but the next quarter you’ve pivoted based on the “product/market fit” and you’re building gidgets.

At a more stable company, or where you have larger organizations (and specialization), it’s much easier to say, “we need a widget stamper” and hire someone against that need.  But, at smaller companies you’re always looking for people who could potentially fill two or three roles.  “I need a widget stamper who could also manage the widget stamping team, and occasionally make gidgets.”  Again, this raises the degree of difficulty on hiring.

Functional versus Tactical

A functional team is, for example, the design team—all of the designers report into a design manager.  A tactical team is a “project team”—in this case, there is a cross-functional group that works together on a specific task.

In a startup, tactical teams are absolutely the way to go.  In a small startup like Cheezburger, we’re basically just one tactical team all working together.  But, as startups get bigger, having one giant tactical team is impractical.

This is illustrated by the following riddle: “If it takes 2 people an hour to dig a hole 10 feet deep, how long does it take 6 people?”  As anybody who has ever worked on a group project knows, the answer is not “20 minutes”.  At best, it’s “one hour” and more likely it’s “an hour and a half”.

As a result, the practical thing to do is split the group into multiple tactical teams.  Yet, there are two challenges I see with tactical teams.  First, is the obvious, “who reports to who?”  Is it realistic to expect a project manager to supervise a developer or designer?

The second has to do with actual quality: at some point, as you have more than one tactical team, there has to be someone ensuring the “quality of the craft”.  In other words, someone making sure that all the developers, designers, etc. are working to the same standards of quality across all the teams.

Typically, what ends up happening is that there are functional teams and tactical teams.  The official org chart has functional teams, but as a day-to-day matter people work on projects tactical teams.

The introduction of functional teams means hiring functional team managers, which adds overhead, both monetary and organizational.  A startup might be able to afford the monetary overhead, but it’s the organizational overhead that is the killer.

Why? All of the sudden, there are do-nothing-managers having meetings with other do-nothing-managers about what the actual do-something-workers should be doing.  In the meantime, the do-somthing-workers sit around and wait to be told what to do.  At this point, most likely, your startup stops being nimble and dies.

Square Pegs

These issues are murky and challenging and there isn’t a right or wrong answer.  These dilemmas have probably been around for generations—I bet the bible even has suggestions on org charts!

Yet, all of this confusion leads me to a final thought: earlier in my career, if there were a team member who didn’t fit—a person who was competent, but who was a square peg in round hole—my inclination was to replace that person with someone who is a better fit.  I regret some of those decisions because now, with more experience, I see that that as a mistake.

The biggest challenge in hiring people is finding someone who is a good fit.  Hiring for a startup is risky and hiring mistakes are expensive, both financially and organizationally.  As a result, these days my inclination is the other way: if your team has someone that is “good”…someone who is competent, who works hard and is committed to their jobs, who is pleasant to work with and willing to be flexible and learn new things…then find a place for them.

A startup is probably better off with these people than with the unknown of a perfect widget maker who probably has some other set of issues that, as a startup manager, you’ll have to deal with.  In other words, it’s the devil you know versus the devil you don’t!

Dave McClure recently wrote a blog post that everyone is going gaga over…here’s the money line:

Gradually we are discovering that the default revenue model on the internet should probably be the simplest one — that is: basic transactions for physical or digital goods, and recurring transactions (aka subscriptions) for repeat usage.

This is not new.  In fact, it’s the same shift that happened after the first dotcom bust.

When we launched drugstore.com, it wasn’t initially clear if the core of the business was e-commerce product transactions or health and wellness information (like WebMD) or an online health magazine.  But, when the economy tanked, the answer became crystal clear: e-commerce was the core of the business because it was the actual way to make revenue.

Now, we’re in Web 2.0 and we’re doing the same thing over again.  The economy has tanked, people need to make money, and…oh, look at that, charging for things is the best way to do it!

In other words, Web 2.0 is the same thing as Web 1.0, it’s just that the players and technologies are different.

There’s an old phrase, “those who don’t study history are doomed to repeat it”.  I’m not sure if this is “doom” versus the realization that every business cycle has similar characteristics and phases.  In another 5 years, this phase of Web 2.0 will shake out, and then we’ll be on to some new technologies and Web 3.0.  Rinse, lather, repeat.

From there, Dave goes on to explain who—as part of this great revenue realignment—is going to win.  His points on the winners and losers are interesting.  I can’t say one way or the other if his predictions are correct, but his trendspotting is right on.

I am on the board of a local non-profit.  Like the broader economy, and many non-profits, finances have been tight.  The good news is that our 2010 budget is looking pretty okay.  The not-so-good news is that our 2011 projections are not so rosy.  As a result, we met over the weekend to discuss and plan.

A pastor from a local church with a lot of experience in non-profit management and fundraising who counsults with other non-profits came to meet with us.  We had a long meeting, but he shared a few key thoughts on fundraising that somehow seemed applicable to the world of startups:

• Philanthropy directly correlates to volunteerism.
• If you need money, ask someone for advice.  If you need advice, ask someone for their money.
• People will not contribute to a non-profit because it has needs; they will contribute because it meets their needs.
• Fundraising is about having relationships…with people who make decisions about money.

How I word translate these to startups:

• Revenue from customers directly correlates to participation.
• If you need to raise money for your startup, build a circle of advisors to can guide you.
• Customers will pay for your service because it meets their needs.*
• Business is mainly about relationships, but revenue is about relationships with people who make spending decisions.

A final note on the item I starred (*): Kathy Sierra extends this thought in a way that I am fond of.  She says making great products isn’t just about serving customer needs…it’s about making them feel that they’re more excellent for using your software.

Twice yesterday I had conversations (one in person, one over IM) with entrepreneurs in Seattle who have ideas for startups.  One idea was related to helping bloggers better monetize and the other was related to providing cheaper services to cell phone users.

Both of them come from a product development background—one is a designer and the other a developer.  Both of them were able to eloquently describe for me the product that they wanted to create.

In addition, after a little inquiring, I was able to work with them to effectively articulate the market of people who would be interested in their product.  For example, with the second person it was “people who want e-mail alerts on their cell phone, but don’t have a smartphone”.

With the second person, I had some more time than the first, so I pushed further…here’s a part of our chat transcript:

Me: So, how do we reach these people?  That was the problem with your last startup…you had a great idea, but couldn’t find the customers, right?

Startupper: hmm, reach – I would suppose we’d have to sell it to a carrier, or get an article on Tech Crunch

Me: So often we think about how to make a great product, but often the product isn’t really the issue.  I’m sure, like your last startup, you could build this app great.  The issue is really how to get it in front of the right people.

To me, this seems like a pretty critical sequence of understanding for people who want to launch product companies.  Really a company is more that the product: it’s the product plus the customers.

• First, there is your product—what is it, how does it work, etc.  Most product development types can figure this out, and typically when you go out for drinks with them they have lots of ideas for products.
• Second, there is defining your market.  In other words, who would want this product and how many of those people are there?  I have a few killer product ideas, but there aren’t many people who want them.  That’s not to say they’re bad ideas…they’re probably just bad businesses.
• Third, once you know your potential customers, how do your reach them?  Effectively, this is sales and marketing.  Typically, product development types detest the marketing types as slick, do-nothing, blowhards.  But, it turns out, they have a pretty tricky job which is, “how do I put my product in front of my potential customers in a cost-effective way”.  Turns out this is easier said than done.

This reminds me of a few conversations I’ve had recently.  Yesterday, I was at coffee with Andy Sack and he made the comment to me that one of the most important things he learned as an entrepreneur is the importance of sales.

And, earlier this year I was having dinner with Jeff Sass who made the interesting comment that, paraphrasing, everything is becoming a commodity—hardware, development, even design…everything except marketing.

Finally, Eric Ries said to me over drinks last fall that that startups fail, not because they don’t have a good product, but because nobody wants to buy the product.  I would add my own corollary to that: many startups fail because they can’t find a way to get their product in front of the people who do want it.

Today I’m at Web 2.0 Expo NYC participating in the Lean Startup Workshop by Eric Ries.  Eric is an articulate voice for those of us in the web development world who have been innovating to find new ways to build web sites effectively and efficiently.

I really appreciate the work he’s been doing to get the message out.  We were talking before his presentation and he told me that he hasn’t been home since October 1st!

Literally, I’m typing this as he’s taking questions from the audience.  Here’s a few key highlights from the talk:

• Most companies fail because they build something that nobody wanted, not because they built something of low quality.
• The key to building what people want is “The Pivot”: changing direction while staying grounded in learning from experience.
• The unit of progress for waterfall development is advancing the plan, i.e. moving from requirements to spec to development and so on.  In Agile, the unit of progress is workable code.  In “Lean Startups”, the unit of progress is validated learning about customers and what will cause them to give money to your business.
• In his model, there are two cross-functional teams: a problem team (to learn about customers, their wants, needs and aptitude for acceptance) and a solution team (to create things for customers).
• The key to any lean transformation is learning to distinguish the waste from the value.
• “Customer development”—that is, learning about customers—it’s not about just doing what the customer says.  It’s about learning if the customer will accept your vision of the product.  [A-kin to what Marc Andressen calls product/market fit.]
• Typically, behind every technical problem there is a human problem.  Fix the human problem if you want the technical problems fixed.  [This is another way of saying, "software is just a reflection of the people and processes who create it".]
• When something isn’t working, it’s a signal that tells you something about your system.

That’s just a summary which doesn’t probably do Eric’s ideas any justice, so forgive me.  However, you can read more about Eric’s ideas at http://startuplessonslearned.com.

I was talking with a friend today about “working yourself out of a job”.  In many cases, there is a conflict of interest for someone to make their job more efficient, automated or obsolete because it will result in losing their job.  Only the most enlightened and noble of people are going to take one for the team like that.

This reminded me of a popular slide show going around these days from Netflix that outlines the culture they would like to develop.  In the portion where they talk about how they value high performing individuals, it says:

adequate performance gets a generous severance

In other words, adequate performers should be fired, so that a star performer can be hired in their place.  And, the generous severance* should be offered because, as CEO Reed Hastings says, “otherwise managers feel too guilty to let someone go”.

Combined, an idea was born: what if you told your employees that if they worked themselves out of a job that you would guarantee their employment for some period of time thereafter, so that they could find another job (in the company or elsewhere).

For example, say to your employees, “if you automate your job so that it’s obsolete, thereby saving us the headcount cost, we will guarantee your employment for six months.  During that time you can find a new job at our company, or look for job elsewhere.”  Obviously, the employees who succeed at this will most likely be retained by the company.  As an employer, these would be just the type of people I would want on my team.

Thoughts?  Do you think that would work?  What are the drawbacks to a policy like that?

* – Unfortunately, I haven’t been able to determine just how much severance Netflix offers, but I did find a document that says executives are paid for 9 months.

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.