You guys think we could start a social network about awesome hair?

I think Google really does “get” social. They just don’t know it.

Recently there’s been a lot of talk about Larry Page’s decision to tie Google’s bonuses to the company’s overall social strategy, and whether Google can actually “do social.” Skeptics could credibly argue the company won’t be able to make the switch, perhaps using the following arguments:

1. Google’s history shows it doesn’t understand how to build a social application. Google Buzz isn’t Facebook, Dodgeball never became Foursquare, and Google Wave is…well, what the heck was Wave even supposed to do?
2. Google is trying to buy its way into something that fundamentally doesn’t map to its core — which is, specifically, search.
3. Google isn’t as innovative as other companies anymore. It didn’t invent Facebook, it didn’t start Twitter, and it couldn’t even buy GroupOn.

But personally, I disagree. My feeling is that, while Google certainly has its share of problems, I think Google very much does get social in a more basic sense. They just don’t know how to position it as such:

1. Google Search is social because it fundamentally recognizes that, no matter how good an algorithm could be, there is no way it can truly succeed without incorporating the work done by hundreds of millions of people. PageRank doesn’t sound like a social algorithm, but asking the entire web to make suggestions and recommendations based upon what they feel is appropriate enough to link to sure does.
2. Google Advertising is social because it was built on an idea that, no matter how good an advertising agency or media channel might be at estimating an audience, it was unlikely they could do a better job than simply outsourcing that whole process out to the buyers themselves and letting them work out the implicit price through an auction.
3. Google Maps is social because Google always encouraged others to extend it, build upon it, and embed it into other web sites and applications. Whenever I think of the phrase “mash-up,” what immediately springs to mind is the idea of “Google Maps plus something.”

But one could certainly ask, well, is this really social? Isn’t the real social about people posting status updates on Facebook, micro-blogging on Twitter, and checking-in on Foursquare? I believe the breakthrough contribution of these apps is that they’ve defined social as lowering the barrier to entry for people to participate in the web. But if you look at Google Search, GMail, Docs, and Maps (not to mention YouTube), whether by in-house development or through acquisitions, isn’t this what Google has been focused on for years?

I think the real challenge is whether Google can cross-over from viewing its audience as semi-techies who understand a little HTML to a much broader audience: those hundreds of millions (or billions) who have so incorporated the web into their lives that they don’t even see it as “the web” anymore — it’s just simply a part of what it means to go through their day. They’re not “participating in the web” so much as just chatting with those people who are important to them. And if Google wants to build participatory tools that actually work, they’re going to have to recognize this fact. But if their fundamental DNA is to empower people at scale, then at least they have a shot.

So this lowly blogger thinks Google can do it, but only if they recognize their own core values a little bit more strongly and perhaps adhere to a few small tweaks to their approach:

1. Quit chasing Facebook. Trying to “make a Facebook that isn’t Facebook” is like a movie studio trying to “make a Star Wars that isn’t Star Wars.” As Yoda might say: knock this off, you must.
2. Leverage Google’s core assets. Hundreds of millions still use Google to find things, and in doing so contribute to what John Battelle so cleverly referred to as the “database of intentions.” Additionally, despite the rise of Facebook and Twitter, GMail absolutely remains a killer app, and I don’t think a day passes that I don’t check Google Maps for something. Lowering the bar for participation in any of these apps seems like it could pay off. I don’t love the “+1″ approach — seems like a rip-off — but at very least it’s lowering the bar.
3. Consider hiring a liberal arts person or two. Google’s culture of outstanding engineering is a core strength to be sure. But social tools tend to take as much from the gaming industry as they do from productivity tools, and games require all those nuances that humans (not computers) tend to love: aesthetics, design, wit, charm. Warm and fuzzy can live in harmony with hard-core engineering. Look at Apple. It can be done.
4. Keep encouraging experimentation. Google Buzz was a bad mis-fire because it essentially cheated the old “don’t be evil” value. Don’t do this again. But despite its (terrible) positioning, Google Wave was actually an intriguing idea, as are a lot of ideas that Google throws up against a wall (no pun intended there.) True innovation always requires taking a few chances.
5. Stay true to your core values. For the a long while, Google always hung its hat on that “don’t be evil” mantra. Build open systems. Don’t push advertising down people’s throats. Focus on speed and simple, clean user experience. These things still apply to social systems. (Just ask Facebook about the terrible Beacon idea to see if they don’t.)

I started this blog primarily as a way to help me organize my own thoughts about what it takes to build a successful software team, and so it’s this last idea that I’m the most preoccupied with: recognizing your core values, and then applying them to new challenges as you go.

I think Google really does have some fundamentally solid DNA. If they are able to utilize that to develop their social strategy, they can succeed. I for one would like to see it.

Heck yeah it's a rocket boat.

The premise behind Jelli is to allow people to influence and control what they’re listening to on the radio — a great idea whose time has definitely come. Jateen is clearly passionate not only about the service he is building but his people and his team as well. If you’re an engineer interested in this space, my advice: go talk to him. Cool stuff.

What’s really great about Jateen’s company is that they are focused on taking something that, let’s face it, is terrible (radio) and they’re attempting to make it better. Or, in other words: Jelli is taking a thing that sucks, and they’re going to try to make it not suck.

Now, because this is a pseudo-professional blog in which I get to randomly interpret ideas I think about and break them down into parts, I’ll now randomly interpret this idea I’ve been thinking about and break it down into parts. Ready? Hoorah.

So, technically-speaking, what’s the best way to take a thing that sucks and make it not suck? Well, seems to me if you run a product design or engineering group, there are three things to keep in mind:

First, in order to make things not suck, you have to recognize one key fact. Everything sucks. Really. Everything. Our toothbrush bristles gets all ratty after, what, a few weeks? Our paper coffee cups from Starbucks leak sometimes. Our politicians occasionally think it’s a good idea to blow things up. This is not good. (And, by the way, yes, I love Mr. Jobs too, nobody can pull off the mock turtleneck like that guy. But my iPhone can’t make a phone call, and if I get a scratch on my iPad I have to buy a new one. So, yes, things that start with “i” also suck. Sorry.)

On the flipside, however, for those of us who work in the tech world, we’re lucky because our job is to play with these amazing, uber-powerful, kick-the-crap-out-of-everything toys that can actually change the world faster than bloggers can write dubious metaphors about how technology can change the world. Or, to put it another way, it’s almost like if you were stranded on a desert island, but in addition to the requisite palm tree with two coconuts, there was also a rocket speedboat factory on that island and you happened to be trained in building rocket speedboats.

So then, of course combining these two ideas will lead to some great results. In fact, if instead of having more of an software-oriented bent, this blog were more of a blue-shirt-and-khaki-pant-MBA-type site, we might even say this is a situation where “1+1=3,” although that of course is not actually math. But, hey, we’re talking e-powerment through synergistic solutions here, people. So we’ll put it together this way. If everything sucks, but you have essentially unlimited power, then the only thing left is to pick the biggest problem you can find and go solve that. Because nothing is off-limits. Not even a hundred-year-old technology with decades-old business models.

I’m a big music fan: seeing live shows is a thrill to me. Finding a great new band is a thrill. Hearing someone I’ve never heard before — even if they’re not quite great, yet — is a thrill. And radio is supposed to be a way to hear great music. Except, well, it sucks.

So kudos to Jateen and team for tackling a big problem. And to all the other great rocket speedboat-makers out there.

Some tests will yield more insight than others.

Test-Driven Development (TDD) — the idea that you write tests before you write any code — is one of those killer ideas that we just keep coming back to.

At a technical level, most experienced software developers understand the inherent value in TDD: delivering a suite of automated tests alongside your code just feels a heck of a lot better and (it is definitely true) results in many fewer bugs. Years ago it seemed that very few firms adhered to this approach, whereas today it feels like a great number do.

What I love about the TDD approach, however, is that its value goes beyond the technical and into the organizational: it helps to address issues that somehow arise in every project. For example:

• There always seems to be time at the beginning of a project to talk about new features, but somehow there’s never enough time at the end for testing.
• Requiring that a suite of automated tests be created upfront tends to drive a design that contains a number of technical goodies (like well-defined, documented APIs and the decoupling of back-end systems from front-end user interface.)
• Testing at the end of a project can be drudgery, whereas at the beginning of a project testing can actually be fun.

What’s that? Testing can actually be fun? Right, you might say. About as fun as sitting on the beach in the rain. What is this guy smoking?

Somehow the software industry has evolved into a strange beast where testing and QA became a second-class citizen. I’ve worked places where it  was just understood that software design was for senior engineers, while QA was for junior employees — maybe a stepping stone (perhaps) to getting to actually create stuff yourself.

While I don’t agree with this approach, I would accept it if it worked. But, the thing is? It doesn’t. Large numbers of junior people — whose sole job it is to catch things downstream —  are never as effective as senior people who catch issues early in the process. How early? Well, ideally at design time — before the code is actually written.

Yeah, sure, you say. But how does that make it any fun? Well, I know of at least three ways:

1. Designing tests before any code is written requires a lot of strategic and creative thinking. When you’re trying to design your testing strategy, you’re not trying to catch one bug, you’re brainstorming about what types of tests would catch a whole raft of bugs. In other words, QA design is software design. It requires you challenge your skills to try to write not just a few tests, but to really envision the entire problem space and think about where you can get burnt downstream.
2. Designing tests is a good team sport. At this level, testing isn’t just for “QA people,” nor is it even only for software engineering. Involve everyone you can think of — product designers, marketing people, you name it — and ask the question: how would you break this? I’ve frequently been amazed at how clever people can be at inventing tests that I never thought of — but that, once created, make the system stronger.
3. It gets everyone thinking about quality upfront — together. Nothing is worse than having to be the lone “whistle-blower” developer who shouts out just before shipping, “but it’s not ready!” Participating in designing automated tests upfront helps get everyone involved in the process of creating something of high-quality.

For some great resources on how to get better at not only TDD but thoughts on how to build great tests, check out a few of the excellent books over at The Pragmatic Bookshelf.

Hmmm, feels like a lot. Can we make it smaller?

Let’s take this in baby steps. I find myself saying that phrase to our product team a lot lately. In other words: “let’s think of the smallest possible feature we can build that addresses our customer’s need, and then let’s see if we tighten it up even more.”

Working on things one-tiny-nano-step at a time helps us make sure that:

1. things work
2. we like them, and
3. we’re on-target.

The great news is that if we’ve only spent one day on something and it doesn’t work, we don’t like it, or it feels we’re off-target, well: we’re a little bit smarter, and we’re out a day’s worth of work. Whereas if we get caught up designing something really big, and we run into trouble, it’s a time-consuming lesson.

Not everything works this way, of course — but I think for a lot of things it’s a pretty good model to follow.

• Do upfront design through specs
• Adhere to test-driven development (TDD)
• Commit to awesome uptime

Now, in the early days, we didn’t necessarily need to do these things. We had, give-or-take, about zero customers, and as a result, if our system went down, I’m pretty sure exactly nobody would have noticed. Well, not nobody. We would have noticed.

When you’re just starting out, if there’s a way of doing things that’s important to you, just start doing it even if you don’t need to. For me, I had worked on software projects in the past which contained legacy code that wasn’t well-documented, was buggy, and which crashed — and I hated those things. They drove me nuts.

Your way may not be everyone else's way.

And so we figured, since we were starting from scratch, we’d design and document everything upfront, write unit tests to keep our bug count low, and put monitoring tools into place from the start to ensure we almost never went down. We knew we needed to do these things eventually, so we just figured we would do all those things from the start. Worst case, we figured things would be more fun since we could spend more time working on features and less time fixing bugs.

Years later, we still do all these things. We have a brand-new developer who is part-way through developing a new feature. The feature started with a detailed 23-page spec, has 139 unit tests written so far, and will be monitored on a 24/7 basis from the first moment it’s pushed to production. What’s interesting is that we didn’t even really talk about any of that. Rather, we’re doing things this way mostly because “that’s just the way we’ve usually done it.”

Inertia is an amazingly powerful force in software development projects. If you’re building a product or engineering team, I think the key isn’t to fight that force, but to leverage it — the earlier, the better. Put a process in-place that you would like, for yourself, and make it so that “that’s just the way it’s always been done” is how you think it should be done.

Top speed of 209 mph. Glove box is a little small.

Geoffrey Moore gave a terrific talk at last year’s Business of Software conference (go sign up now for the next one, it’s a great event) about the concept of “core vs. context.”

It works like this: every company or team has a “core,” the thing that sets you apart, the thing you love to do. If you designed cars at Porsche, for example, your core would likely be around performance and handling.  Context refers to everything else you need to do to complete your car so that someone will actually buy it: the glove boxes, the cup-holders, the trunk. You need context — nobody wants a car without working doors, no matter how fast it goes — but context isn’t what makes you special.

Every engineering project includes elements of both core and context. If you’re working on your core, you try to make it as good as you possibly can. That’s what defines you. But if you’re working on context, then you only want to make that particular work good enough so that you can then redirect your resources back onto your core. Your job is to continually re-orient your resources so you are focused on your core as much as possible.

Fair enough, right? Except that if you have great engineers, there’s a paradox. Because they’re great, they will always try to make everything as good as it possibly can be. So if you ask them to make the Porsche go from zero to sixty in, say, negative four secconds, they will find a way. And if you ask them to build a glove box, well, by default they’ll start thinking about how to make it amazing: not only will it hold your papers, it will detect when you have a date in the car and automatically spring open James Bond-style with a bottle of Champagne and two glasses after you turn off the ignition.

And while, yes, I want one of those glove boxes too, unfortunately this approach backfires, because you end up spreading yourself too thin. Because everyone on your team is trying to make everything great, you end up with a resource problem where nothing is as good as it could be.

So, what’s the solution? Well, if you have a team working on your core, then don’t hold back: invest as heavily as you can to make that set of features absolutely world-class. But if you have resources working on context, you need to be clear that for this particular feature of your product, you need only something “good enough.” Because once that’s achieved, you want to try to re-allocate them back over to your core.

If you’d like to watch the entire (one-hour) talk, check it out. It’s well worth it.

(Side note: I think I actually saw the old Champagne-in-the-glove-box trick in a James Bond movie once, but I can’t remember which one. If anyone has the answer, please let me know.)

On the other hand, of course one day the robots will probably turn on you.

At the Silicon Valley Code Camp last weekend, I saw a very interesting talk put on by Adam Rosien and Eishay Smith over at KaChing, a startup in the financial space, entitled “5 Minutes Commit to Production: Continuous Deployment.”

Essentially the philosophy these guys espouse is one in which, until your code is in the hands of your customer, it’s basically “going bad” – almost like like unused inventory in a warehouse. So, what to do? Get it up there! And so their approach is to reduce that time from build-to-deploy to only five minutes.

These guys spoke about some terrific ways to do this at a technical level, but what I liked the most about the talk was that they spoke a little about how to do this at a cultural level as well — and engineering culture is always something I find interesting. A few takeaways:

• Ops and QA is every engineers’ responsibility. It’s not a job you put on someone else’s shoulders, it’s your job too.
• As engineers, you can always create something better (write a script, create an app) to improve the process.
• A team of engineers who think along these lines will make themselves more and more productive by continually adding automation tools.

I love automation. Love it. Whenever I see a suite of our unit tests go “green-green-green” or I bring up one of our uptime-tracking reports that verifies that some little boxes somewhere are waking up every few minutes and pinging our servers, I get a little charge in my geeky-reptile brain. If our machines are cranking away for us, then that means we’re productive even when we’re sleeping. And given that it’s the 21st century and we still don’t have flying cars (seriously, 1950′s-lookin’ Popular Mechanics guys, could you at least give it a shot?) at the very least I expect that some sort-of machines of ours should be cranking away while I sleep.

The reality is that automating those tasks end-to-end — from build-to-test-to-full-deployment — means you can move more quickly than almost anyone. And of course, speed of development means lots of opportunities to create. So kudos to Adam and Eishay for pushing this idea.

Being cute will only get you so far.

In the early days of a project, when you and your team have a nice, warm, fuzzy idea for how your McWidget 2000 is going to completely blow the doors off the entire McWidget industry, it’s pretty easy to get caught up in the details, especially when it comes to the user interface. “Hey, Tommy, wouldn’t it be cool if, when you hit the ‘Publish’ button, it made a giant “kapow!” sound indicating its seven levels of awesomeness?” “Yeah, but first it should turn light-green with mauve highlights when you mouse-over the button, indicating just that hint of kapow-ness, you know? And then when you actually push the button…”

Avoid this. Avoid this like you avoid opening that container in the back of the fridge that’s been sitting there quietly making penicillin for the past three months.

The trouble isn’t that you’ll chase down bugs around the interface (which you will), or even that you won’t come up with some great ideas during this process. The trouble is that you’ll begin to like these ideas. And that’s where the danger lies.

Because, in just a little bit…just over that horizon there, past the first prototype and just before the next little phase…a little monster is lying in wait. That monster is called your early customers, and they’re going to have a few ideas of their own — that might be in-line with what you’re building, but more likely won’t be, and then you’ll be forced to decide: should we start building something new, something the customer actually wants, or should we, maybe, hang on a bit to what we have here?

If what you have is only one fugly little prototype, something you knew was just the first draft, it will be easy to adapt. But if that first draft is something you’ve really become attached to, well, then the process is going to feel a bit more like how Old Yeller ended, and who wants that?

Measure using whatever tools are handy.

Most software product managers know their days are filled with a set of seemingly neverending decisions. Since you’re in the middle of everything, you get asked a lot of questions: this mockup or that one? This technology or that? Build or buy? Launch this week or the week after? Chocolate or peanut butter? Air Force One or the presidential helicopter? For me, I love the entire process, but there are some days when that list of questions can feel a bit…long.

But putting some simple, measurable numbers on things tends to go pretty far — not only because it makes it easier to manage things, but because the numbers become great shorthand for communicating what’s really important.

For example, here’s a few numbers that we’ve spoken about at my company over the past couple months:

• Our product designer and I decided that a feature would be “done” when people spent an average of 20 minutes using it during each visit. So “20 minutes” became sort-of a shorthand number for making the feature useful.
• Everyone involved in technical operations for us focuses on 100% uptime — and so we put all sorts-of things into place so we can track that. And so “100% uptime” becomes shorthand to us for being reliable.
• We’re always trying to focus on making our customers happy — and in the SaaS world, this is easy-to-measure, because you can look at renewal rates as a proxy for how happy they are. We’re still trying to figure out what the “right” number for this should be, but for the moment we thought we’d put this number at 97% — and so 97% becomes our shorthand for great service.

But what I think is really neat about using these numbers-as-shorthand is that simply putting the measurement in-place makes us get better at the thing itself. For example, 100% uptime was a very early goal for us — and so we knew that we needed to put automated systems in-place to track our servers, which in turn forced us to talk a lot about how to build reliable systems, which — in fact — actually led to us delivering a very reliable system. And setting a “20 minute average visit” goal for a feature forced us to study those apps which were “sticky” — in turn, making us smarter about what traits make features the most to useful people, and leading to (I think) a stronger feature. So by simply deciding to measure our goal, we actually got closer to achieving our goal — a mysterious “quantum mechanical” effect that just seems to work.

So, lately, whenever I get into murky waters — whether that be exploring a new technology, thinking about a new feature, or figuring out a way to manage a new process — I find myself trying to “find the number” that will inherently lead us to getting good at it.

Tells time, serves artisan cheeses.

1. Who am I creating this for?
2. How are they hurting?

Focusing on people and pain helps you define why you building what you are. And understanding the why can help answer a lot of questions throughout the development process.

However, many discussions in the software industry instead focus on the what. What are we making? What is that competitor doing? What features should we add to the product? What is the most important?

There are billions of whats in the world. Whats are easy to find. A search engine is a what. A web browser is a what. A word processor is a what. So too is a pair of sunglasses, a teddy bear, an airplane, a coffee cup. If all you want to make is a what, no matter your industry or interest, the list will be never-ending.

The problem with whats is that there are literally millions of variations of each of them, and so you can find yourself creating something that tries to be all things to all people.

If you say “I am building a car,” someone can ask you for a big trunk, another for lots of horsepower, and yet another for the ability to squeeze into a tight parking space. And because you don’t know why you shouldn’t do one thing or another, you will eventually create something that is poorly-received by everyone, takes a long time to build, doesn’t sell, and won’t be fun to create.

By redirecting your focus to the who and how, however, you will find the why. And whys are much more interesting, and much more fun.

If, instead of saying “I am building a car,” you say “people living in dense San Francisco neighborhoods hate spending 45 minutes searching for parking,” you know know exactly who it is who will use your product and how they are hurting.

And now you can build a SmartCar or a Cooper Mini — but you are not going to build an SUV. And when people ask you, “can your car have four doors, four wheel drive, a big trunk, and a giant engine,” you can easily answer why it cannot, but why it can come with a special refrigerated area for storing produce you purchased at the Ferry Building farmer’s market. Because you  aren’t spending all your time trying to be all things to all people, you can use that time to try out some creative ideas that just might appeal to the people who you are helping. The why can help you understand not only what you cannot build, but also what you can.