Machine Learning and Digital Marketing: Melding Human and Machine

In digital, you can easily spot two opposing camps — the artists and the quants.

Artists are folks like the New York Times: Pulitzer prize-winning journalists use their intuition and skill — their unique talents — to create one-of-a-kind stories, and the judgment of the Chief Editor is pure gold. Artists create incredible brand value; true loyalty — lifelong fans.

human-man-and-machineshutterstock_250853188-620x615Quants are folks like eHow.com. They use Wall Street-style algorithms to identify long-tail Google queries that have weak competition, and pay amateur writers $5 to create short posts that address those queries. Queries like “how to remove gum from clothing.” Their quant models tell them that stories like this will make $7 on ads in the next year, so they pump out millions of such stories.

Both approaches have problems. If a New York Times writer gets hit by a bus, there’s no replacing them. Their talent dependency is not scalable. eHow stories — millions of them — inspire no loyalty, create no brand value. Let’s face it, it’s crappy content. No wonder Google did everything in its power to kill it. Continue reading “Machine Learning and Digital Marketing: Melding Human and Machine”

Are Your Company Values Just Empty Words?

values45463675I had a chance to interact with two companies recently: Homegrown and City of Bellevue Utilities. These two companies helped me crystallize the difference between “value statement on the wall” and “values that are coming through to customers.”

Homegrown’s tagline is “sustainable sandwich shop.” Their About Us page has the word “organic” mentioned 22 times. It says that “stores are designed to be as low-impact as possible… [using] reclaimed, recycled … building materials.” Their napkin dispenser asks you to think about the environment and only take as many napkins as you will use. They have metallic cutlery at every table. Clearly, owners at Homegrown are trying to project an identity that stands for sustainability and environmental awareness.homegrown-logo

Yet, when you order a salad “for here,” you get a single-use plastic container with a salad inside.

Continue reading “Are Your Company Values Just Empty Words?”

Full Price is for the Lazy, or Stop Financing Their Marketing

hard-work-pays-offIn life as in business, if you are willing to invest effort into something, you will do better – a lot better – than average. Today’s story is about a real-estate purchase – and how doing your homework makes a 10x price difference for services.

Did you notice that you just paid your agent $1000/hour?

Basic dynamics of a real-estate transaction: when you buy a $500k home, 3% of the purchase price goes to the sellers’ agent; 3%, or $15k, goes to your (buyer’s) agent. What exactly are you paying for?  Continue reading “Full Price is for the Lazy, or Stop Financing Their Marketing”

Handling “Scary” Interview Questions

I had a privilege of speaking in front of the Code Fellows class this week; as a part of the talk, I took “scary” interview questions from students and attempted to create a framing for answering them. Here are a few:

“What are your greatest weaknesses?”

 

“Do you have questions for me?”

 

What to do when you’re stuck or botched a question?

Why Are We Working on This?

why-shutterstock_126628475-600x709You’re a recent grad from a top engineering school. You come to a hot startup, and in your second week, you volunteer to implement an ambitious new feature. You slave away at it for a week, burning the midnight oil, trying to impress your new colleagues. You’re brilliant: you find an ingenious algo that solves the problem elegantly and with a lot less code than anyone thought was possible. You proudly check the code in, it ships to the site.

You’re proud of your accomplishment. You move on to the next big thing.

Spoiler alert: you screwed up.

Continue reading “Why Are We Working on This?”

Hire for Velocity of Learning

Let’s say you have an opening on your technology team: An urgent need for engineer that will expand your application written on top of the Spring Framework in Java. You use Puppet for deployment, and Jenkins for managing your builds. So naturally, you craft a job description that says “must know Spring, Jenkins, and Puppet.”

ImageYou look hard for a perfect dev for the job and find one. She’s been writing code in Java for the last 10 years; and Spring was at the core of a big project in the past. She has experience with Puppet. You proceed with the hire — and the new dev flies through the assignment and all is well. Continue reading “Hire for Velocity of Learning”

Dogfooding: Find a way to be your own customer

This article was originally published as a guest post on Geekwire; it is republished here for the readers of this blog. 

In early ‘90s, while working on Windows NT, Microsoft popularized an idea to make everyone on the team use early builds of their own software.

Back then, it was quite a painful request — imagine developing an operating system on a box prone to crashes, where your basic tools don’t quite work right. This setup undoubtedly causes loss of productivity and frustration.

Are you eating your own dogfood?
Are you eating your own dogfood?

And yet, what it gains is something more valuable: an immediate feedback loop, where bugs are found quickly, where there is healthy peer pressure to urgently fix issues that are preventing your colleagues from doing their work. Since the cost of a bug goes up the longer it lives in the codebase, this feedback loop — dubbed “dogfooding” — is a significant net gain.

Today, it’s even easier for most technology companies to dogfood, because most of us aren’t developing operating systems. If your internal build doesn’t work quite right, you can still do basic things – so the downside of dogfooding is minimal. Let’s explore some simple, natural examples:

  • Facebook rolls out most features to employees first, and only then to a subset of external customers. Employees, of course, already use Facebook every day and can provide instant feedback.
  • Everyone loves LOLCats. Employees of the Cheezburger Network are natural customers, as they consume their own content every day.

At my company, Wetpaint, we build tools for publishers to develop relationships with their readers through social media. We take dogfooding so far that we’ve built an entire media business — a very successful one — to be our own customers, and to test-drive our platform before our clients use it. This has allowed us to evolve our tools at record speeds.

But what if you’re working on a product that isn’t so easy to dogfood? You have to be creative and find a way to incentivize your employees to be users in order to get the information you need. One way to set this up is recurring competitions; here’s what I would do with these businesses, for example:

  • Redfin, Zillow, Trulia (real estate): Employees must find the best real estate deal in their area. Give them virtual currency. Have them use your products — and competing products — to make their virtual investment decisions.
  • SEOMoz (search engine optimization): Each team member sets up a blog and must use the company’s tools to make it rank the highest a couple weeks later.
  • Tableau (data visualization): A leader selects a data set, and everyone is encouraged to find gems in that data set; the fastest, most interesting insight wins.

Give real prizes to the winners. Set up a weekly beer gathering, get the winners to share their strategy. I bet some product ideas will come out of that. Make sure these events are regular, not one-off, to encourage employees to keep thinking competitively and creatively.

Dogfooding programs complement agile and lean development practices very well, because iterating with the rest of your team for a few days before releasing an experiment increases your chance of success. You’ll also get the obvious feedback out of the way early.

Think of it as a modern version of Joel Spolsky’s hallway usability tests: instead of having to interrupt a colleague to review your UI, you’ll overhear “Oooh” and “Ahhh” when your code goes up on dogfood. That’s the perfect time to ask – “Hey, what do you think about this new thing?”

Hackathons at Startups: Creative ‘Fresh Air’

This article was originally published as a guest post on Geekwire; it is republished here for the readers of this blog. 

Every now and again, we hear about hackathons: Startup Weekend, Facebook’s famed all-nightersHack Week at Dropbox.

However, in a startup, it’s so difficult to imagine how organizing a hackathon can be anything but harmful: “What do you mean, take a couple work days and drop what we’re doing? We’re in a race with competitors! There are holes in our product – and they’re blocking adoption! We can’t just waste a couple days!”

A scene from the recent Sports Hack Day
A scene from the recent Sports Hack Day

I know you’re under pressure. That’s the nature of startups.

And yet, allow me to ask you: how many times have you fought an issue for weeks, only to find an elegant solution that takes a day to implement? Have you ever built a feature that nobody ended up using? Have your employees begun talking about the “grind,” the soul-crushing 80-hour-week pace where bugs never end?

If so, hackathons can help with each of these. They let folks take a step back, concentrate on the big picture, and apply their passion – usually where it hurts the most.

Allow me to share a story from Wetpaint. In summer of 2011, we were struggling with our data warehouse system; we’ve had all the symptoms from the list above. This system was so unreliable that our internal customers didn’t trust the data. Engineers were burnt out from every-Saturday-is-a-workday routine. After a couple months of treading water, we realized that we needed to change something structural in our approach.

One key change we introduced was a framework for open-ended innovation. The intent was simple: all participants drop their day-to-day tasks for a couple days, and work on whatever is exciting for them, as long as it has something to do with our overall business. No top-down mandates. Work alone or with others. The only requirement is to show – demo, not PowerPoint! – your results to everyone else at the end.

We called this framework “hack days.”

I was amazed by the results. Initially planned as a morale-boosting exercise, there were somany great ideas that came out of it. One engineer’s 2-day project disposed of the majority of the issues we were having with the data warehouse. It took a completely different approach to the problem, challenging some of the foundational assumptions that no one ever doubted. Another engineer built a mind-blowing prototype of a tool that we ended up building over the next three months, and that tool had a significant impact on our bottom line.

Most importantly, this breath of creative, fresh air gave a sustained boost to everyone’s output, even as we re-entered regularly scheduled sprints. We made these hackathons a recurring activity – every quarter, coinciding with company-wide business reviews. Everyone in the company is invited to the debriefs now – and they walk out energized and motivated by the ingenuity of their peers.

Moreover, folks outside of engineering are adopting this framework, too. Our social marketing team, for example, drops their best-practices playbook for a couple days once a quarter, and encourages each team member to try their craziest, riskiest ideas. We’ve seen great results from it.

Give it a shot in your startup. Hackathons can become a “startup factory” in an established company, too. If you’d like help setting up a hackathon, send me a tweet, I’d be happy to help.

Measuring interruptions: How to keep your team in the ‘zone’

This article was originally posted as a guest post on Geekwire; it is republished here for the readers of this blog. 

When you look at productive output from a software development team, there’s one factor that almost always predicts problems. You can have top talent; an outstanding idea; great agile process. And yet, if you don’t treat interruptions as a significant source of danger, the progress will be slow and painful.

5368292088_37f5fce714_n[1]We all know and love the feeling of “flow:” You’re in the zone, coding away or deep in thought on a financial model. There’s plenty of research that suggests that we do our best work in this state. We are also happiest at work when we are in the zone often.

But far too often, this state is broken up by a tap on your shoulder or a phone call. There’s a small, innocent question – and it takes you five minutes to answer it. But when you come back to your original task, the inspiration is gone. The “zone” is gone. You need a half hour to just bring back all the variables back into your mind. Or worse, you may not catch the sense of “flow” again that day at all.

That’s the scary thing about interruptions – they typically only take a few minutes to handle, but then bring a trail of a scattered state of mind.  What’s worse, it’s easy to embrace this interruption as a good thing – hey, I just solved a problem, unblocked a customer, made someone’s day better. And yet, for an organization, more often than not, this interruption was a net negative.

Technology startups have a key property: if they stagnate – stay with the status quo, spend too much time on sustained engineering – they die. Time is of the essence; competition is fierce, someone else is going to win that customer, build a better product, hire stronger talent. So only the time that you invest into important AND non-urgent things is bringing you closer to your vision. Troubleshooting is a necessary evil. You must make your current customers happy. And yet, if you spend all of your time on it, you’ll never make it.

So I encourage you to take a systematic approach: actually measure interruptions and create goals to reduce them to a reasonable level.

Create a mailbox connected to your issue tracking system. Every time someone has a question or request outside of the current sprint’s priorities, have them send an email to that mailbox – or do it for them. There are, in fact, two mailboxes: one for emergencies (ex. site’s down) and one for regular issues (ex. data in the analytics DB doesn’t add up). At the end of each week, count the chickens.

Categorize each interruption by component. Draw a graph over time. Discuss it with your senior engineers.

You’ll be amazed. I sure was when we did this at Wetpaint. When we started this practice, we noticed that we had an average of 60 interruptions a week for a product development team of 15.

This, coincidentally, was a time when we were seriously struggling as an organization – we had a hard time moving the product forward. We dug into the root causes and noticed that most of these interruptions were triggered by two systems. We invested time in two sprints to systematically address these issues, and the interruption count dropped to 10-15 a week. Not surprisingly, our productive output shot up.

Morale also improved significantly. Folks felt like they are working on features that move the product forward, instead of constant firefighting.

An important factor in our setup: we established a rotation program to triage interruptions –and only placed managers on this pager duty rotation. Some interruptions are 3am emergencies that must be dealt with immediately; when managers have to be the first line of defense, root causes tend to get a systemic resolution surprisingly quickly.

Another positive side effect of being systematic with interruptions is that nothing falls through the cracks anymore. An internal customer would find an issue and send one of the devs an email, or just chat with them in the kitchen about it. Sometimes, requests like this would be lost – or delayed far enough to get the customer concerned. After we set up this rigorous interruption tracking, every client knew where to look up the status of their issue.

The movie Social Network has a magical moment. A loud house party is going on. And yet there’s a guy in the middle of the room with headphones on, coding away. People walk around him, careful not to disrupt – nobody dare interrupt his flow!!

Do you know how many times a week your product development organization is interrupted today? Can reducing that number take your crew to the next level of productivity?

Facebook: The personalization engine for all of the Web

This article was originally posted as a guest post on Geekwire; it is republished here for the readers of this blog. 

Facebook and its third-party applications today know a hell of a lot about each us: what content we read (Washington Post Social Reader); what music we listen to (Spotify); what movies we watch (Netflix).facebook-opengraph

Facebook opened up a green field for the game creators, too: games with friends are just so much more engaging. However, while Zynga and Electronic Arts fight for the attention of the social gamer, the only party that is guaranteed to win is Facebook – they gobble up data from ALL of the apps to compile a multi-dimensional data set that will ultimately allow them to build the best personalization and ad relevance engine on the web.

This strategy of Data Dominance – knowing more about each user than any competitor – is executed through a set of API’s that Facebook calls Custom Open Graph. Each micro-interaction in the vertical universe of a game, a social reader, or a music app is a way for the app to drive traffic; it is also a way for Facebook to learn more about each user.  It’s a powerful data mining operation that aligns the interests of all parties involved: the consumer, the app creator, and Facebook.

But how will Facebook use this data advantage? No matter how addictive Facebook is, consumers still spend six out of every seven minutes on other sites. To extend its data dominance to the rest of the web, Facebook should offer analyzed data up as a service to other sites – driving value for third parties and revenue for itself.

In fact, Facebook has already started down this path with its ad products. While Facebook started out by targeting ads on facebook.com using only their own internal data, they recently made the smart move to integrate insights from other publishers’ sites through Facebook Exchange. This was the first step toward an external ad network, and a direct challenge to the eternal enemy, Google, on their AdSense home ground.

With personalization, however, Facebook has been playing it close to the chest: the famous EdgeRank– the ranking algorithm behind the newsfeed that judges what content from your friends will be interesting to you – is so far available to Facebook only. No third party can leverage its great insights. Facebook made a weak attempt to unlock some of its power with the Recommendation Bar plugin; it was a move in the right direction, but the execution sunk it. Instead, Facebook should offer personalization as a cloud data service – and they should charge for it.

Imagine if The New York Times could tell if you’re going to like a particular story – and recommend you a different one if you wouldn’t. Imagine if an online store could know – based on your Facebook profile – which product you are more likely to buy. Both of these businesses would flourish. And Facebook could take a cut of the incremental revenue.

Let’s examine Outbrain, a premium syndication provider. Fundamentally, they are in the relevance business – given a piece of content, they suggest several other pieces of content a reader might like. Facebook could solve this exact problem a lot better – they have more data to base the recommendation on.

Facebook is in a position to unlock incredible new revenue for a whole slew of merchants, if only they allowed partners to tap into the personalization engine directly.

I work at Wetpaint, where we’re building a quantitative platform for audience development. Today, we use Facebook as an efficient content delivery channel to build loyal audiences. We’ve developed ways to run statistical experiments to learn about the audience’s interests, and this analytical approach has driven extraordinary results for us.

And yet we are only scratching the surface of the multiplier effect that is available through the world’s greatest optimization laboratory.  Facebook today is mostly a black box; but if Facebook were to open up its personalization engine, publishers and brands would be able to create far deeper and more engaging relationships with readers and customers.

We’re on the cusp of a personalization revolution in publishing.  Facebook, with its strong advantage in Data Dominance and its equally strong incentive to make the online experience more personalized (for both users’ and advertisers’ sakes), is uniquely positioned to take us there.

Offer a Conversion Path!

I’ve had a curious experience with Amazon EC2 recently, and it made me think of a the process of adoption of new systems and services. In short: it doesn’t matter how good your product is, if it’s too hard to switch from the old way of doing things to your new-and-revolutionary gizmo. Let me share two stories.

Microsoft Word vs WordPerfect, 1991. Out of the gate, WordPerfect is a giant with almost 50% market share. Microsoft just released a “better  mouse trap”; they also know that the competitor’s product has massive adoption, and Word will hit a big wall because of the incompatibility of the two document formats. If a customer buys Word, they can’t open their old WordPerfect documents:

“No matter how good Word is, I have to buy WordPerfect anyway to have access to my old stuff. Damn, I already spent money on one word processor.. Why do I need another?..”

Microsoft does the smart thing: they write adapters for WordPerfect import AND export. Now, if you are an early adopter of the new-and-amazing MS Word, you can still send documents to your dinosaur friends. The barrier has been lifted, the purchasing decision is now to be made only on merit; with this single move, they were able to wipe away most of the network effect advantage of their competitor.

Fast forward to 2012. VMWare and on-premise virtualization providers are under attack by platform-as-a-service vendors, first and foremost, Amazon EC2. Amazon has built a cost-effective, scalable, very advanced mouse trap. It’s not a perfect replacement – but it’s better in many ways. Lots of Amazon’s potential customers today are using various on-premise virtualization solutions. And yet, 6 years after the launch of EC2, there is still no way to take my VMWare Linux box and upload it – seamlessly – into EC2.

No wonder that only under 5% of top 5000 websites by traffic are using Amazon EC2 today.

Influence of Your Work on the World

As I was finishing school, I had a dream – I wanted my job to maximize my influence. I wanted the product of my craft to touch, in a meaningful way, as many people as possible, helping them in small and large ways. It’s mostly pride and desire to maximize the control over your environment: isn’t it awesome when everyone around you knows what you’ve been working on?

“You work on the search engine at Google? Wow, I use that every day!”

“You’re at Boeing developing the new 787? So many people are going to fly on that!”

A beautiful quote from a Microsoft engineer on this subject:

Very few projects at Microsoft have “small” impact. Everywhere you turn, the projects people are working on are likely to be used by thousands or millions of people. You have the opportunity to earn, save, or cost the company millions of dollars through your work. It’s an awesome responsibility, but an awesome chance to create widely influential software.

I’ve found a hole in this logic: it’s missing a key variable. It’s not just about the number of lives you touch. It’s also about the number of people that are working on this same product. The logic is simple: if there are thousands of people working side by side with you, your individual contribution will be lower. You will own and contribute to a smaller part of the puzzle.

Moreover, for technology projects, I’d argue the number of engineers working on the product has an even stronger, quadratic effect on each person’s influence. Ancient, yet so contemporary book Mythical Man Month makes this point well.

Here’s my attempt at quantitatively measuring your work influence number as an engineer in a high-tech company:

Let’s look at some examples:

  • Microsoft Office is one of the world’s most used products; yet there are quite a few engineers touching it. Spread-out, shared ecosystem of Office Shared services that own cross-product components and installation, as well as groups that own localization and documentation, makes the denominator in the equation above quite high.
  • Facebook is famous for having a restriction on the number of engineers that can work on a given product; I can’t find references to the exact number, but anecdotally, it’s under 10. So let’s say 10. Let’s look at the example of the Timeline: with Facebook’s 900M users, influence of an engineer working on that team is 900M/100 = 900K.
  • At Wetpaint, there are 3 engineers working on the wetpaint.com website. Last month, we had 12 million readers. Influence of each engineer = 12M / 9 = 1.3M.

If you’re looking for your job to have influence – right out of the gate – work in a small, isolated team that has full control over its destiny. Startups are by definition structured this way.

Bet on Yourself

How comfortable are you with the idea of relinquishing control over something important to you to someone who doesn’t really wish you well? How about relinquishing control over your career? Over your family’s livelihood?

Whenever alignment of interests isn’t present at the workplace, that’s exactly what employees are doing – they’re relinquishing control to the manager who has completely different incentives. If you’re working in a big company, your career success – your next years’ bonus, your promotion – are in the hands of someone who has no rational reason to wish you well.

Don’t give me the empathy argument. Don’t tell me that your manager wants to help you because it will make him/her feel good inside.

Incentives rule the world. People optimize for the way they are rewarded. The manager will optimize for what will make them get their next promotion. When it costs them nothing, they might even invest in you – if they’re what we consider a “good manager.” But do not kid yourself – there’s no incentive for them to systematically make you better off. You’re just a cog in the machine. A stepping stone.

… How comfortable are you with the idea of gambling? Of betting something valuable to you on a phenomenon with relatively unpredictable outcome? 

I’m not much of a gambler; the idea of having zero control over the spinning wheel of the roulette gives me a heartache. Someone else throwing the ball… Someone else programmed the roulette… Just standing there with my fingers crossed makes me feel powerless. A victim of the odds. A fool that disrespects the probability theory.

But what if you could change the game? What if you could be the one throwing the ball, programming the roulette, training for hours on how to beat the odds? What if after months of training, you were presented with a chance to make a bet – on yourself, on your own skill – and be the one playing your own game, with so much under your control?

That’s what startups are about.

You’re gambling – yes. You’re playing against the odds – most startups fail. But you’re betting on yourself – your own skill, your training, your intellectual horsepower. You’re creating a new world – every day. Your hunger inspires you to do more than humanly possible. You’re riding a roller-coaster – but it’s your own path.

Moreover, people around you – your manager, your peers – are all in exactly the same boat. If you don’t pull your weight, you will hear about it; others will jump in to make you better. If you’re doing well, your leaders have a purely logical incentive to get you the recognition you deserve – because it will make THEM succeed. Because it improves the odds of the startup succeeding. Because you personally are contributing a big, noticeable chunk to the bottom line of the value of the startup.

The most important factor here, of course, is the ability of every employee to make a meaningful difference on the company’s bottom line and having a share of the gains. This is what changes the incentives for everyone.

The wise Glenn Kelman says that “startups are the most intense way to live.” I couldn’t agree more. The thrill of a bet on myself – combined with the responsibility that it brings – is making me feel alive more than ever.

Shining the Spotlight on the Audience, Not the Stage

This article was originally published as a guest post at Digital Quarters, and is republished here for the readers of this blog.

Every day, we go to our favorite news outlets and get our fix. We land on the same familiar sites. We seek out the kind of news that fits our fancy. We casually share the most interesting news with our friends – over dinner or online. And, tomorrow, it starts all over again.

Why? What motivates us to watch the daily news, read an opinion in a magazine, and come back to a favorite TV show? For content creators and distributors, it’s easy to think that it’s all about the content.  This view is based on the notion that people desire the intrinsic value of content, such as the knowledge hidden in a report, or the laugh they experience from a comedy sketch.  But this idea is too flat, and it ignores a more powerful force that’s at work, and that drives the tremendous confluence among target populations when it comes to what they read.

Indeed, in many cases, a deeply human driver is far more valuable than the information itself. And that driver is the desire to be a valuable, appreciated member of a group.

As the graphic below shows, this desire maps directly to Maslow’s pyramid of human needs – the need for esteem.

ideas-pyramid3-blogspan

(diagram from NYTimes – http://ideas.blogs.nytimes.com/2010/07/16/revising-maslows-pyramid/)

After taking this pyramid or hierarchy of needs in, it becomes clear that, as publishers, we must pay attention to the amount of influence, respect, and social value that audiences are able to earn from their friends after consuming content.

Let’s look at a few examples.

For World of Warcraft geeks, a news article on a long-tail site that covers the latest artifacts is true gold – because it will help them be the most informed in the eyes of their guild.

For fans of Bachelorette, watching the latest episode is very much about having a water cooler conversation about it next day – and the potential social connection that brings.

For Politico readers, it’s about exerting influence on their Facebook friends after they share a controversial editorial.

And, for Lolcats readers, it’s about making their friends laugh for the umpteenth time with a new, undiscovered photo.

Each of these examples is about social influence and social esteem.

Here’s the take-away for publishers in all of this: a key component of the value of the 21st century media company is about helping audiences gain the attention of their social circles.

This represents a radical shift from what we’ve seen over the past decades.

Instead of trying to capture and direct the reader’s attention (“Look at my 100-year-old brand! I curate the world and know best what you should look at!”), the publisher becomes a back-stage prompter, helping readers utter the words that will make them the center of attention among those they care about. The reader can then become an even stronger influencer, or taste-maker.

Every time a friend consumes something that you’ve read, you’ve successfully directed their attention. Your social bank account just became more valuable. And every time publishers help make this transaction seamless and smooth, they are helping you earn some social gold.

This is why Washington Post Social Reader and Yahoo Social are such smashing hits.

Readers want to consume content within these apps, because of the feedback loop from their friends.  (“Hey, I saw you read this article, and I read it, too.”) This is a self-reinforcing pattern that creates social value for all the participants. These publishers, and Facebook’s timeline apps, put audiences first; and, in the process, they generate an ever-increasing amount of social value for readers.

Note that curation and brand very much play into this the social value generation; nobody wants their friends to be misinformed or displeased by media that they endorsed. Content is still king.

If, say, the Washington Post wanted to take this experience to the next level, it could make curation even more personalized. Instead of telling readers that they must care about the Russian presidential election via a big front-page photo – completely ignoring the fact that sharing this knowledge will drive zero social value to its readers – the Post could cater to the unique values of each reader. To do so, it could measure the social response from the reader’s audience – and then personalize the content based upon this response. It’s essential to point out, however, that the reader’s interest – and the response of his or her audience – are not mutually exclusive; a smart personalization algorithm will take both of these factors into account.

That said, in the end, publishers must awaken to the fact that social influence and social esteem are key matters for their audiences today.

How to tell whether you’re a visionary or a lunatic?

For a while now, I’ve been asking myself: if you are pursuing a dream that nobody else can see, how can you be sure – after a while of trying – that you’re not crazy? That you’re a visionary, and not a stubborn lunatic that keeps believing in something that’s obviously not going to happen?

Only now I’m realizing that even phrasing a question this way is already a mistake. If you’re this far down your path and you have no proof that your idea is right, chances are, you’re up for a big, unpleasant surprise.

My favorite radio show, “This American Life,” had an episode a few weeks ago  with a story of a guy running his family’s well-being into the ground over 3 years, all while trying to launch his own TV show. He had essentially zero traction. He kept getting himself further down the hole since the day he started.

Rand Fishkin, a wise and successful man, gave an outstanding speech about making mistakes at a conference this year. He showed a graph of his net worth – falling through the floor for several years in a row. He kept doing the same thing with the same sad result. And only when he realized his mistake, his career turned around.

It’s curious how our culture romanticizes perseverance, sticking with the ideas once things go sour, and pushing through all the obstacles. There’s certainly a healthy dose of stubbornness that is necessary for an entrepreneur to succeed. But all too often, I see this idea taken all too far – instead of healthy tenacity, the belief of the founder turns into arrogance, and no fact in the world can change their mind.

Einstein said this best: the definition of insanity is doing the same thing over and over again and expecting a different result.

Stop sticking to stupid ideas, dammit. At the very least, accept the fact that you can possibly be wrong. And search for proof – quantifiable, objective proof – that the assumptions your idea is based upon are indeed correct. Eric Ries makes a powerful pitch for this concept in his book Lean Startup: formalize the foundational assumptions of your business; then, systematically test them – as quickly as possible.

In other words, if you have a smart idea, don’t bet your entire farm on it. Hedge your bets. Accept the fact that you can be wrong. Bet a little bit of time/money on your idea; prove out its most salient points before you mortgage your house and quit your day job. Why? Because too many ventures result in

 “achieving failure”: perfectly executing a flawed plan.

You might argue that true visionaries like Steve Jobs or Bill Gates kept pushing even when nobody believed in their ideas. I will challenge you to fact-check: Steve Jobs had an order for 50 Apple I computers when the company was in his parents’ garage; Bill Gates famously sold IBM something that he didn’t have when he was 25 years old.

What are some of the ways to validate the assumptions in your technology startup?

1) Use non-code methods. Find a way to replicate the core of your idea – even at 50% efficiency – using a human being. Make it a point to write ZERO lines of code. You’ll be surprised to see that you have a great amount of data just a day or two later.

2) Use statistics! Just because option A did better than option B in your survey doesn’t mean that your customers prefer that option. Learn about statistical significance (you’ll be surprised how non-trivial these concepts are!) and run real A/B tests in both human-process and technology experiments.

3) Walk a fine line between “explore” and “exploit”: in optimization theory, there’s a well-known issue of a local minimum: if you exploit what you know about your problem space too much, without a healthy dose of open exploration, you’ll likely end up with a sub-optimal result. Keep your eyes open for possibilities in the nearby spaces; openly experiment in areas where you aren’t strong. Continuously invest time into exploration.

Use these methods to continuously validate your own ideas – no matter how great they seem at the outset – and never find yourself wondering 6 months into the effort: “am I even on the right road?”

Line-Drawing Fallacy and Accountability

There’s a beautiful logical paradox, a line-drawing fallacy:  it’s difficult to tell when quantity transforms into quality. Which of the cuts killed an elephant?.. Which of the thousand-dollar checks made a company go bankrupt?..

It’s so difficult to tell when an incremental, continuous process turns the corner and radically changes its character, and a temptation – a very pragmatic temptation – is to allow for wiggle room and ignore the little deviations. Meh, just another check. Our company’s big and strong, and our success depends on macro efforts – who cares about a thousand dollar check for paper clips?.. Let’s concentrate on something bigger!

I’m typically not a fan of idealistic, black-and-white / cut-and-dry judgment philosophies. I try to look for the trade-off curve – if we give up a little bit here, can we win a lot there? I usually find that an obvious decision is typically not so obvious, that for each radical judgment, there’s a set of counter-arguments that deserve to be explored.

Yet, today, I found an area where a hard-line view – a view that doesn’t allow for a gray area – is extremely important. That area is about managing accountability. I had an amazing conversation with my CEO, Ben Elowitz, and he crafted a very convincing argument – I know that it’s one of those that will be pretty transformative to my leadership style. Here it is.

There are two ways to run an organization.

One is the way of the pragmatic.

Have flexible standards – we ship when software is ready; we are OK slipping a little bit. We value commitment, but we value flexibility as well. We are reasonable – we don’t create a panic around a missed expectation unless it really cost the business.

The other is the way of commitment.

Draw a hard line: EVERY commitment that we make, we keep. Our organization does not tolerate a single hour worth of slippage. Create symbols of accountability: generate gigantic, loud, visible stinks every time a tiny expectation is not met. Don’t do it to be an asshole – do it to prevent the tiny little bit of a creep.

Oh, it’s OK to be a day late. It’s just a day…

And then we’re three days late…

How is five days late bad? It’s almost the same as how we did last time (four days late), and you, our fearless leader, seemed to be perfectly happy with the results?..

And then when you have a deadline that your team must meet, how can you expect them to deliver – with this kind of culture?

Ben argues that there are three elements to high accountability, which he equates with high performance:

  1. High standards: we set difficult goals, and hit them every single time. I don’t care that it’s 5pm on a Friday. You said that it’ll be done by the end of the week. Get to work. 
  2. Symbols of these high standards: as leaders, we celebrate victories and are VERY, very upset when any commitment is missed.
  3. Reinforcement – rewards and punishment – is immediately tied to the performance management / review process.
A couple related materials if you found this topic curious:

A Sense of Urgency

I’ve had a curios revelation in the past few days. My CEO, Ben Elowitz, said something really curious: the granularity of your estimates has a GIGANTIC effect on the effectiveness of the organization. If you take a task, and commit to getting it done by next week, you’re essentially setting a WEEK as an atomic unit of time. If it’s behind by a day – oops. A day seems so insignificant comparing to the week that you allotted for it. Oh well, late by a day. It’s only 10-15% over the time allotted for it. No big deal, right?…

Even worse, if you commit to get something done by “the next meeting of this group,” you’re about to experience  Parkinson’s Law – people tend to do stuff at the very last moment before it’s due – it’s only natural and efficient:

Work expands so as to fill the time available for its completion.

If instead, you commit to getting it done by Tuesday 1pm – refusing to be bound by the timeline of meetings, instead giving a precise estimate in terms of hours of work – you’re in a much better shape from the get go. Tasks end up taking less time – all because you’ve framed the timeline differently.

Next time you’re thinking about whether to estimate dev work in days or hours, think about this.

The Next Chapter

I announced my resignation from Microsoft today. I’m joining a startup. Here’s a snippet of the mail I sent out:

Almost seven years ago, I walked into the largest software company in the world knowing basically nothing about software development. You taught me everything I know today. You taught me about ambition; about relationships; about due diligence; about customers. It’s been such a great privilege to learn from you. Thanks for this amazing experience.

I look back and think of the infinite patience of my managers – and feel so, so grateful. I vividly remember the day when Josh Bell, my first manager, told me that we don’t fix some of the bugs that we find in our products – knowingly! What?!? No Santa Claus?… I recall the heart-to-heart chats with my colleagues, where we found truth and challenged each other to be better. I can’t help but feel nostalgic. Thank you again. My brain got bigger, which obviously caused most of my hair to fall out in the process, but isn’t that what growth is all about?

Today, my path leads to me a startup – just across the water in downtown Seattle. I’ve taken a role of director of PM at wetpaint.com, a startup that aims to revolutionize media. My last day at Microsoft is July 14th.

Leaky Clouds

Joel Spolsky has two timeless pieces – Fire and Motion and The Law of Leaky Abstractions that are cornerstones of what I’m about to preach in this post. Please take a moment to read those articles by Joel – they’re almost 10 years old now, but are as relevant as ever.

My field, software engineering, is young and filled with changing winds. Client-server! No, web-based!.. Win32! No, PHP! No, Cocoa! No, HTML5 / JavaScript!.. Mainframe! No, rich client! No, thin client! No, mobile client!..

Entire industry moves like the trees under a powerful wind. I’ll stipulate that there are two factors in play here:

  1. Psychology. The nerds that are in IT leadership positions are still very much gadget nerds. They love new stuff. They love playing with new stuff. They get the fanciest gadgets available on the market today. It’s not the Patek Phillippe crowd – they won’t go after a 100-year-old watch. They’ll go after a released-1-day-ago iPad v7, stand in line for it for hours, and pay through their nose. Just because it’s new – and new stuff is really exciting.
  2. Incentives of market movers. Large technology vendors – particularly those in the leadership positions in their markets – want to keep customers in the spot where they want to buy again and again. Yes, we sold you a solution to your problems yesterday; but wait, now we have a NEW, MUCH BETTER way to solve that same problem! Yeah, you haven’t yet figured out half of the benefits of the old thing, but the new thing – it’s SO MUCH BETTER!..

Abstractions are an outstanding concept in science: instead of dealing with a bunch of low-level concepts, we create building blocks – and juggle those instead. It’s much easier to build a house if you have bricks; it’s much easier to perform a surgery if you don’t have to make a scalpel from the iron ore yourself.

Perfect abstractions require zero knowledge of how the building block was created. Such abstractions don’t exist – even the surgeon needs to know a little bit about the manufacturing process and chemical composition of the scalpel. For example, the scalpel has certain melting temperature and certain chemical characteristics (hmmm, I guess I shouldn’t put it into hydrocloric acid..).

In software, most abstractions are actually pretty bad. We like to think that the operating system hides away most of the complexities from the users – but it doesn’t. With Android, unless you know to kill apps that are running in the background, your battery life will be abysmal. Even with the famed iPad, you have strange artifacts like “zoomed mode” for old iPhone apps – total weirdness from the end-user point of view.

ORM (object-relational mapping), one of the most famous abstractions, is probably one of the worst (most leaky) – it will make you *think* that you don’t need to know SQL, but my god, that’s a horrible lie.

And yet, for system designers, these abstractions are frequently natural. As software engineers that build those abstractions, we are tempted to design for ourselves. In the end, we’re developers that build on top of those frameworks, too! “How am I not the target customer?..” That, of course, is a horrible mistake that causes unusable abstractions and frameworks that only their creators can understand.

Enter cloud computing. The latest excitement of our industry. The premise is really simple – instead of investing into technology upfront, pay as you go. Have someone else host that technology for you. That someone has vast economies of scale. Increase your investment easily in response to demand.

Sounds like a dream come true to the enterprise, right? I have 50 servers that are each utilized at 3%; I have IT staff of 10 to maintain these technology solutions; that’s really expensive. Instead, I come to a cloud vendor and pay a fraction of the cost.

Also sounds like a dream come true to an independent software shop, right? With my Find Touch project, I used to need a server in my garage – maintaining hardware, network connectivity, software stack, everything. Instead, the cloud promises to solve all of the same issues at a fraction of the cost.

With cloud computing, the situation is even worse. The field is in the “new and super hot” realm – just like those pesky iPads – and early adopters are discovering that the promise of “just move your existing application into the cloud” isn’t quite working.

The lower the level of the service that you’re moving to the cloud, the easier it is to map to what’s in your datacenter. The higher you go up the value chain, the harder the migration becomes.

If all you’re getting from your cloud vendor is hardware, everything is pretty easy from the technology standpoint. The problem, of course, is that the value add of such a service is pretty low. Yeah, I can spin up more machines and I don’t need to wait for DELL to bring those machines to my doorstep.

If, on the other hand, you want to move a VB6 application into the cloud.. And gain the benefits of deployment, scalability, billing, and all the other goodness of SaaS.. Good luck. You’re in for a treat. Get ready to essentially rewrite your software. Oh, you no longer are in touch with the vendor that wrote the source code?.. Too bad…

Moreover, the further you go from technology towards business aspects of cloud computing, the harder the cloud becomes to understand.

Recently, I worked on moving my web-based application from a standard hoster (1&1) to a cloud platform. I chose Amazon EC2 for my experiment. MY GOD, even as a technologist, I was at loss to understand what the costs for my migration are going to be. My old platform offered a pretty large VPS; they screwed up with customer service, so I was looking for a new home. All I wanted was an apples to apples comparison of price and major features. I didn’t expect major demand spikes – even though the ability to respond to them is nice. All I saw was myriads of instance types and datacenter options and pre-pay versus pay-as-you-go per minute of usage and my head was spinning after an hour.

My god, can’t you just tell me how much I’ll pay for the load I *know* I will have? A stupid little calculator for idiots like me that will tell me how much I’ll pay a month?.. To see if your service is worth it?..

Hosting vendors have this down to an art: show just three options, with a clear feature matrix; highlight the middle one with a tad more features than most people want; help upsell that one.

Cloud vendors? We have EC2 and S3 and fancy queues and monitoring with a cool name and you need to learn all of those proprietary acronyms and oh my god am I going to have to have my IT staff relearn everything?.. Cuz my CEO sure isn’t going to like this..

Seriously?.. You call that an easy switch to the cloud?..

I’m not saying the cloud is a fad. I am, though, saying that the cloud is in a state where it’s “hot and sexy because it’s new” and it’s primarily driven by technologists – not the business leaders. I want to see cloud vendors lead with value proposition – and better abstractions – and not with the newfangled technology “fire and motion.”

I want to see someone who’ll take my PHP app and will put it into the cloud – for the same price for a single VPS as my dumb old hoster. Using the paradigms I’m used to. I want my app to *not change at all* in order to adapt a cloud-based billing service. I want my storage to work just like I’m used to. I don’t want my IT staff to learn anything new – I want the framework to adapt to THEM.

Let’s greet the cloud – and hope that it grows up from the infancy it is in now.