You’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.
Alex Weinstein (@alexweinstein) is the head of product development at Wetpaint and the author of the Technology + Entrepreneurship blog where he explores data-driven decision making in the face of uncertainty. Prior to Wetpaint, Weinstein led technology initiatives in Microsoft Live Labs.
Photo via Shutterstock.
