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.

You thought that you were done when the code was checked in and shipped.

Not even close… It turned out that the feature you so proudly shipped actually didn’t make a difference for the business; it didn’t improve customer experience in a meaningful way, didn’t move the bottom line for the business at all.. Your hard work didn’t bring value to your company. All of that effort to make a beautiful algo was a waste. That’s because you cared about the code, the “how to solve the problem,” not the “why” behind it.

Peter Drucker famously said that “There is nothing quite so useless, as doing with great efficiency, something that should not be done at all.”

Next time a feature is assigned, consider asking: “Why are we doing this? What value do we expect this to bring to our business?”

It might sound like a challenge to your boss or to your product manager — it actually is not; their primary job is to make sure that every engineer is working on something that moves the business forward. They’ll happily explain the intent.

When you find out the “why” behind a task, it is much easier to make sure the implementation gets to the heart of it — without any extraneous effort. Maybe the task you’re assigned is just an experiment — with a super high business risk, and it doesn’t matter whether it’s scalable at this phase. Or maybe — just maybe — you will have a better idea on how to solve this specific “why” than what’s in the work item.

If you want your work to have an impact on the company you work for, you have to be an entrepreneur, not just a coder. Challenge the assumptions when you’re given a task; find out what metrics are expected to move as a result of this task being done; instrument your code so that you can actually know.

Don’t start the work until you have an objective way to judge whether it’ll have a positive impact on the business. Don’t stop until you see that your work made the business forward. Look at the data after your feature ships, share your findings with your team, suggest iterations.

Let’s explore some examples.

 —A task is to change the layout of the signup page.
Why? To improve our conversion rate and make more money.
What’s the actual objective measure? Conversion rate over time.
How do we know whether it’s successful? We need to have an objective measure of conversion rate before and after the layout change.

—A task is to fix a bug in the retry logic for Facebook Insights data collection.
Why? So our customers should always have stats about their Facebook activity.
And why does that matter? So that our customers could judge the effectiveness of their campaigns and use that knowledge to make more successful campaigns.
How do we know whether this work made our business better? We’ll see improved stats of Facebook campaigns that our customers initiate.

—A task is to fix a rare crash of our iPhone app on old versions of iOS.
Why? Crashes create really unhappy customers.
No really, why? Because a handful of folks that use an ancient iPhone get really angry and leave 1-star Apple Store reviews.
What’s the measure of success for the business? Number of 1-star reviews of our app that mention crashes and old iOS is down.
What’s a good proxy of this metric? Actual number of crashes — you need to be capturing crash stats for your app and monitoring it over time.

Eric Ries created a fun term: “achieving failure” – perfectly executing a flawed plan. He talks about this phenomenon happening on a large scale (entire startup), but it happens all the time on a small scale, too (individual work items).

By asking “why are we doing this,” you help insulate your group against it, and also remind the group of its shared purpose, bringing the team together.

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

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.

Six months later though, you realize that your current Spring-based stack isn’t scalable; that you must switch over to Hadoop and HBase. That your front-end needs to be redone in Ruby on Rails or you won’t be able to evolve it to keep up with your competitors. So you switch.

But that dev you hired is struggling in the new environment. She’s really uncomfortable with Hadoop, and a few months in, still asks others for help with basic tasks.

You made a bad hire.

What? She was perfectly qualified for the task at hand! She did awesome in the beginning!

Exactly… in the beginning. She was doomed to fail from day one, because you hired for specific skill, as opposed to for the ability to pick up new skills.

In this day and age, there’s only one thing that’s certain: technologies of tomorrow will be radically different and dramatically better than what we use today: Postgres will outshine MySQL; NoSQL databases will trump relational in many scenarios. Hiring a full-time narrow specialist – someone who’s worked on exactly one technology stack throughout their development career – is a recipe for disaster if you expect your environment to change, either form a business or a technology standpoint.

So I invite you to hire for demonstrated ability to learn, versus specific skill in a technology-area-du-jour that you happen to have in your stack.

Wait… what are you saying? If I have a Ruby on Rails app, I should hire someone who’s done Django and PHP and C++ but no Rails over someone who’s been doing Rails their entire career?

Yes. This is exactly what we did at Wetpaint: most of the developers we hired had no or little experience in Rails.

Yet we are a Rails-based site with 100 million monthly page views and a significant codebase. We hired folks who’s experience has shown that they can pick up new technologies quickly. So they picked up Rails quickly; and then when we needed to do Hadoop, they picked that up too. And responsive design. And machine learning. I have little doubt that we’ll do great with the fancy new technology X that surfaces next year and revolutionizes the industry – because high velocity of learning is a core competency of the team.

How do you interview for the ability to learn?

—Look for radically different technology stacks, roles, company sizes on the resume.

—Ask the candidate about how they learn; those that have picked up a lot of new things in the past will be able to describe a thoughtful approach to learning and give an example of something they learned recently.

—Inquire about interests outside of work. A good sign is broad, diverse interests: those that enjoy learning get good at it over time.

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

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.