Android is for Work, iOS is for Play

I’ve been using a Nexus S (now updated to Android Jellybean 4.2.2) and an iPhone 5 (now at iOS 6.1.2) on a daily basis for a couple months now.  Much has been written comparing Android and iOS already, so I’m just adding my anecdotal experience to the wood pile.  I’ve found myself increasingly thinking of the Nexus S as a “work” device and the iPhone as a “play” device.  Here’s why:

Android for Work

  • Google integration — I rely on Google apps like Gmail, Google Calendar, and Google Drive extensively, both personally and for work.  It’s super easy to sign into an Android phone with multiple Google accounts.  Once signed in, all email, calendar events, contacts, and docs associated with your Google accounts immediately become available on the phone.
  • Voice dictation — Google-powered voice dictation is incredible.  I find myself often dictating entire emails now — it’s so much faster than thumb-typing on the phone!
  • Swiping keyboard — the swiping keyboard that’s built into the latest versions of Android is much more accurate (and fun to use!) than the regular touch keypad.  I discovered it accidentally when one of my fingers slipped across the regular keyboard once and haven’t gone back ever since.  Between swiping and voice dictation, the Nexus S has become my preferred mobile device for text-entry while on the go.
  • Google Now — a question I wonder nearly every morning is: “should I take 101 or 280?” to commute to work.  Google Now proactively figured out my commute routes and now one of the notifications at the top of the Nexus S every morning is an alert from Google Now that tells me which is the best route to take this particular morning.  I love that.  It’s magical and useful to have my mobile phone smartly offer assistance.
  • Portable wifi hotspot — the Nexus S’es built-in portable wifi hotspot turns on really quickly and has been a more reliable connection for me than the iPhone’s wifi tethering.  I’ve been using both devices on AT&T’s 4G network, tethered to a Macbook Air — the Nexus S would often provide hotspot connectivity in places where the iPhone would refuse to connect (for some reason, the iPhone refuses to allow tethering while in “4G” mode, not “LTE”).
  • Aggregated notifications — the way Android aggregates and displays email notifications in the “windowshade” is super useful.  I like being able to take action (like archiving an email) right from the windowshade.

iOS for Play

  • Camera and camera apps — the iPhone 5’s tap-to-shutter lag is barely noticeable and I think the native iOS camera app does a good job of handling light-metering by tapping on dark/light areas of the viewfinder.  The iPhone camera seems to take better photos and videos, in general, than the Nexus S.  Also, my favorite video and camera apps are all on iOS, too: Videokits, Facebook Camera, Manga Camera, Looker, Instagram, Snapseed, and Photosynth, etc.  I also really like the “swipe up” to go into camera mode
  • Shared Photostreams — my parents and in-laws have iOS devices and want to see the latest photos of their grandkids; what better way to share than with iOS’es built in Shared Photostreams?   I find that I share way more photos this way than I do through social-network sites…  I tend to pick and choose which photos to share on Facebook or Twitter because I don’t want to bombard online friends/followers with dozens of pics taken at, say, a kiddie birthday party.  But the grandparents are more than happy to receive all 50 photos in a Shared Photostream — they “like” every single one!  :-)
  • AirPlay — this is really the killer app of iOS for me: being able to AirPlay any content (whether it’s photos/videos from the camera roll, a YouTube video, a song from iTunes, or a Netflix movie) from the phone to a bigscreen TV.  The seamlessness of the experience is awesome.  I love how the iPhone has become an integral part of the living room experience.
  • Games — there are still just a ton more games and apps available in the iTunes App Store than on Google Play.  Most of the big titles from Rovio, Electronic Arts, or Zynga are available on both.  But many educational and kids games are still only on iTunes App Store.  That makes a critical difference on which device gets shared with kids on the couch.

So, net-net I’m using the Android device more for day-to-day productivity and the iOS device more as a media and gaming device.  In a way, this actually lines up with Steve Jobs’ reported focus on taking over the living room.  Both the iPhone 5 and Nexus S are beautiful devices with well-executed operating systems.  Looks like both Apple and Google are hitting their strides, respectively, though I doubt that they’d intended to segment the market for mobile OS’es by work vs. play…   Still it seems to have come out that way for me, personally!

Anyone else “dual-holstering” both and Android and iOS devices these days?  What are your thoughts?


Five Behaviors of Awesome Engineers

I recently joined TaskRabbit as VP Engineering and the experience has reinforced lessons learned from prior startups about the importance of having a systematic way to recruit, retain and promote great engineers.  One way to help recruit, retain, and promote more effectively is to identify and define a consistent set of behaviors that the company expects of engineers.  I’m constantly amazed at how many companies fail to do this for their technical staff.  

When it comes to defining explicit objectives or desired actions, it seems like many companies take the time to specify those kinds of expectations for marketing, sales, or product management team members.  But when I ask engineers at other companies how they know if they’re doing a good job, I often hear answers like: “we’re generally supposed to kick ass and ship code” or “we just do what PM’s tell us to do.”  IMHO, having a group of prodigious coders or friendly team-players on the engineering staff is a good start, but not sufficient.  And leaving engineers with ambiguous or undefined company expectations borders on neglect! 

I’d like to push more companies into defining clear, specific expectations for how they’ll assess engineers at all points in their career life-cycle — from being pitched as candidates, to being on-boarded as new hire, to getting rewarded as a high performer (or being counseled out).  Ideally, the way a hiring manager describes an engineering role to a recruit should match the role expectations that the company places on that engineer once they’re on board.  And the way promotions happen should further reinforce those behavioral expectations.

To give an example, here are the five behaviors that we expect all TaskRabbit Engineers to exhibit: 

  1. Culture Fit — TaskRabbit is driven by a very lofty vision and company values.  We take those really seriously and folks don’t tend to stick around at the company if they don’t visibly buy into the vision and values; even if they’re brilliant at their particular functional role.
  2. Craftsman — We want engineers to really understand the underlying mechanisms that their code relies on.  The majority of TaskRabbit’s codebase is in the form of Ruby-on-Rails apps. Mature Rails developers will appreciate just how easy it is to get yourself into hot water by including gems without really understanding what dependencies those gems are creating under the hood…  Whenever we can’t find a gem that does exactly what we want, in the way we want, we take pride in developing our own gems and contributing them back to the Rails community, e.g., makara, storehouse, sudo.js, and more
  3. Goalie — We don’t have a QA team, so our Engineers are the first and only line of defense against bugs.  We expect engineers to write their own feature tests and bugfixes, to deploy code only after integration and acceptance testing, and generally to think a lot about how code might break.  That kind of goalie defense against bugs and regressions is an important part of an engineer’s job at TaskRabbit.
  4. MacGyver — Like the TV show character, given a tight set of timelines and resource constraints, we expect engineers to be able to successfully identify the minimum-viable development investment that will make a meaningful impact for users.  This is really another way to say: we solve the classic Time-Quality-Features tradeoff by de-scoping/decomposing features.  We explicitly are unwilling to compromise on time or quality (i.e., we deliver on a pre-set weekly sprint cycle and we hold the quality bar really high for ourselves).  So, within a given sprint, we always focus on paring down to the smallest possible unit of customer value.
  5. Coach — TaskRabbit’s initial web and iOS apps came out of consulting engagements with Pivotal Labs, where we did a lot of pairing.  Coaching and mentoring each other has become an important part of our engineering practices and we really value people who are willing to actively teach their colleagues and learn from each other through 1-on-1 pairing as well as All-Hands meetings.  We specifically like to see engineers standing up in front of a crowd, talking about and demo’ing their work.

Every new recruit hears about these five expectations so they can make an educated decision about what they’re getting into at TaskRabbit.  Our engineering team members talk to each other about their jobs using these terms.  And these five behaviors are baked into our self-assessment and peer-reviews. 

By enumerating these five desired behaviors and weaving them all through out TaskRabbit’s engineering practices, I’m trying to create a more consistent and reliable way to recruit, retain and promote an A+ team.  

Feel free to borrow these if they’re helpful…   YMMV, of course, with transplanting these expectations into your company’s particular culture.  But I think the most fundamental point is to put some thought into defining a consistent set of behavioral expectations for your technical staff.

Thoughts?  Comments?  Let me know!


Structured Approach to Event Blogging

I like the “linkable assets model” in this SEJ post: http://www.searchenginejournal.com/effective-link-building-using-event-blogging/34104/

SeachEngineJournal's "linkable asset model"

It’s a nice, structured way to think about how to get inbound links for your event blog (if you’re an event blogger and care about that kind of thing)  :-)


The Language of Social Networks

Facebook and Mark Zuckerberg have established near monopoly control over the language that we use to talk about social networks.  Think about the words that we use to describe social network sites — terms such as “like”, “share”, “connect”, “transparent”, “more open”, etc.  I’m not saying that Facebook were the first company to use these terms and they certainly didn’t invent them.  But I do believe that Facebook have been the most effective and the most consistent at using those words to frame the conversation about social network policies and features in moral terms.

The moral framework they’re creating around their social network site is really key to focus on.  Facebook are saying: It’s *good* to be liked, right?  It’s *good* to connect to more people, right?  You’re a *better* person if you’re willing to share more transparently, right?  And, conversely, if you’re *not* willing to share a thought or action openly, then what are you hiding; are you doing something that you *shouldn’t* be doing?

Facebook have purposefully created this moral linguistic context for their service.  As Zuckerberg masterfully puts it:

At Facebook we have a deeply held purpose […] Our mission: “Give people the power to share and make the world more open and connected.” In the world we’re building where the world is more transparent, it becomes good for people to be good to each other. That’s really important as we try to solve some of the world’s problems.

Source: http://www.insidefacebook.com/2008/07/23/live-notes-from-mark-zuckerbergs-keynote-at-f8-developer-conference/

George Lakoff, professor of linguistics and cognitive science tells us that, in any debate, if one side manages to dominate the moral framing of the issues, then they’ve already won the debate before it even begins.  Facebook appear to have learned Lakoff’s lessons well.  By framing the debate about social network policies and features in their own moral terms, Facebook could be walking away with victorious dominance over the social internet without firing a shot!  Every other social internet company has been forced to define themselves using Facebook’s terminology of “sharing”, “openness” and “social graphs” (i.e., attempting to beat Facebook at their own game) or to contrast themselves against Facebook’s feature functionality (i.e., attempting to convince the world that sharing, openness, and transparency are bad things).  It’s a lose-lose proposition either way and that makes it really hard for other companies to market and differentiate themselves using the language and concepts that Facebook own.

What are your thoughts on how the social network industry should move forward from here?  I’ll jot down some thoughts in my next blog post.  Would love to hear your thoughts in the meantime.


Crafting Code Across the Stack: 3 Benefits of Cross-Technology Engineering

One of the engineers in my startup asked some thought-provoking questions in a hallway conversation today:

Should engineers own end-to-end implementation of features that cut across multiple layers of our technology stack?  Or should engineers focus/specialize on specific layers of the stack and collaborate with each other to develop each feature?

I’ve repeatedly observed that small teams of developers run circles around large teams in every company I’ve ever been in.  [Caveat: I focus on consumer internet software, so my observations will be biased towards that industry.]  I have a strong preference for company cultures that encourage individual engineers to develop as much of a featureset as they can on their own.  If there’s a front-end user interface to be created as well as a backend API required to support a particular feature, I’d like to see the same engineer coding it all.   Obviously this isn’t always possible for either technical or personnel constraints, but it is the ideal in my mind.

Today’s announcement of Facebook’s integration with Skype is a timely example of this principle in action.  I wasn’t a direct part of that integration project, but knew the folks on both sides.  With two big companies like Facebook and Skype coming together, there were dozens of people involved in the overall project.  Even so, it was really remarkable to me to see how much of the integration really hinged on two key individuals — one on the Facebook side and one of the Skype side.  Both of those individual engineers are really amazing “multi-lingual” developers who were able to make key coding contributions across multiple layers of technology ranging from Java applets and compiled desktop executables to in-browser Javascript and CSS/HTML to server-based API’s and cloud services.

Seeing that reminded me of the three main benefits of getting engineers to own entire featuresets, even (or maybe especially) if they cut across multiple technologies…

1. Motivation

When an individual engineer works on a feature that they know is going to impact large numbers of users, they viscerally feel the huge contribution they’re making to their company (and society!).  Nothing is more motivating than feeling like your work really makes a difference.

2. Quality

An engineer who really understands an entire featureset front-t0-back is able to grok critical dependencies between technology layers more effectively than a team of multiple individuals.   I assert that the ability to see the whole picture enables the single engineer to more effectively write test cases, identify likely breaking points, and ultimately deliver higher overall quality code that is defensively coded against future commits.

3. Iteration

This is a key advantage for individual engineers: the engineer who designed and coded an entire featureset on their own will be more likely and much faster to modify/iterate their designs when presented with market feedback from real consumers.  In contrast, a team of engineers who each only coded parts of a feature (and therefore relied on some other person, usually a project manager or a product manager, to provide a holistic view and integration guidance) will be much slower to collectively process market feedback and iterate.

Now, this may all be much easier said than done…   For one thing, it’s hard enough to recruit great engineers in any given technical area, much less a team of cross-technology superstars.  And in practice, there are significant friction points to the lone-ranger style of development.  E.g., if every engineer is a gun slinger they may unwittingly produce a lot of conflicting or redundant code that at some point needs to refactored.  Furthermore, even if an engineer is capable of contributing code across many different levels of a tech stack, that doesn’t mean they will always *want* to do so…

Even netting out those potential disadvantages, I think that cross-technology development has a strong positive impact; especially in the consumer internet space where companies actually have a decent shot at recruiting engineers who can effectively contribute code across the entire LAMP (or insert your favorite mobile or web development framework here) stack.  And even if your company doesn’t, in practice, hand over entire featuresets to a single engineer to execute, I think it’s still really important to foster cross-technology understanding.  It can only benefit your team if the javascript front-end wizard really understands the database impact that all her AJAX calls are going to produce; or if your backend API engineer really understands how often and how quickly his REST services will be requested by a mobile client; etc.

Have you ever worked in a company that had a policy of “single engineer owns an entire feature”?


How employees get screwed in private equity deals

learned a hard lesson from working with a bunch of rat bastards leading private equity firm, Silver Lake.  I joined Skype after the company was spun out of eBay  by SilverLake in deal valued at $2.7B and was recruited to help accelerate the pace of product development and make the Skype app more web-oriented.  I was at the company for just over a year in a product management role and felt like my team accomplished some important things along the way, including reduction of software development cycles from months down to 2-weeks and delivery of a whole new advertising revenue stream to the company.   It was a fun and challenging job, involving tons of international travel and I met some amazing people along the way.

Now despite the fact that Skype has a Palo Alto office and kind of seems like it would fit right in with Silicon Valley tech companies, it turns out that the employment terms for a Silver Lake company are *very* different from what most Valley high-tech employees are used to.  Here are three important things to watch out for if you’re thinking about joining a company that is being managed by a private equity firm or if your company gets taken over by a PE bank.

1. Lawyer Up

(image credit: http://weheartit.com/entry/5625871)

The most important lesson I learned from Skype was that compensation and stock policies in PE-owned firms can be very heavily tilted in the owners’ favor and against the employees.  Skype employees have 5-year vesting of stock options, for example, not the usual 4 year schedule that most Valley firms have.  Even worse, Skype’s stock option agreement had special clauses that the Board had slipped in that gives them the right to “repurchase” any vested shares for anyone who leaves the company voluntarily or is terminated with cause — effectively taking “vested” shares and making them worthless.  Here’s a nice letter I got from the Associate General Counsel of Skype that points out exactly how my stock options have “no financial value.”  (see lee.pdf).  Gee, thanks.

Now, I’ve seen my share of legal documents for tech companies.  I’ve worked in Valley tech companies for over 15 years, have founded startups, done VC financings, and invested in companies.  None of that prepared me for the kinds of legal shenanigans that the PE guys at Silver Lake pulled because I had never come across those kinds of terms before, let alone the fact that these clauses were hidden as one-liners in otherwise pretty standard-looking documents.  (see Stock Option Grant Agreement for Kuo-Yee Lee – signed)

So my first point of advice to anyone considering working for a PE-lead firm is to LAWYER UP — it’ll be worth your while to get an attorney to carefully review all employment documents so that you know what you’re really getting into.

2. The Bobs

Working with Silver Lake was my first opportunity to witness up-close-and-personal how a PE firm does its business of restructuring a company that they’ve just taken over.  And it was breath-taking.  The firm inserted itself into every level of the company.  At one point in my tenure at Skype, Silver Lake had representatives or consultants on the Board, in C-level executive roles, in technical leadership and operating roles, and all the way on thru the organization to the person actually running our software deployment schedule…   So Silver Lake put its fingers really deeply into Skype’s pie and they started rearranging things.

You can agree or disagree with the practice of re-organization, but I personally had never been part of a restructuring that ran so deep in a company.  During the year I was at Skype, the company:

  • hired and fired a CFO
  • gained a CEO, CMO, CIO, and CDO
  • created an entirely new product development org structure
  • eliminated every Project Manager role
  • fired, re-interviewed,  and re-hired Product Managers
  • created a two new business units
  • combined two business units into one
  • dissolved one business unit
  • opened a new office and hired several hundred people
  • the list goes on…
I mean, these are crazy changes for any company to go through over the course of years.  To have that all happen within a short number of months was staggering.  The conventional wisdom in Silicon Valley is that good engineers and product designers will always have job security.  Still, there were times at Skype when even really solid engineers and designers were asking me if their jobs were going to be safe from all the changes going on.
So, second major lesson learned: prepare your resume and get ready to re-interview for your job (or a different one) because organizational change is a major part of the private-equity-lead restructuring of a company!

3. It Ain’t Over ’til It’s Over

Even if an employee of a PE-owned company has avoided the legal beartraps and weathered the re-org’ing, they’re still not safe.  Even as Skypers were celebrating the huge potential of the Microsoft deal, the PE bankers were sharpening their knives and plotting which employees to fire in order to maximize profits and minimize payouts to non-owners.   Seriously, how greedy do you need to be to make $5B and still try to screw the people who made that value possible?  I mean, Silver Lake is trying to hyper-optimize their returns to the point that they’re trying to deny employee payouts that amount to less than 0.3% of the returns that they’ll get from the deal.  Srsly.  Really?

So, just be warned: Silicon Valley startup folks may think we’ve had hard dealings with venture capitalists…  But in my opinion, VC greed pales in comparison to the level of greed exhibited by the Silver Lake private equity firm.

And there you have it, my top three lessons learned from being raked over the coals by a PE firm.

Have your own story?  Leave a link or comment below!


Three user-generated content UX principles

Three UGC UX principles that I’m working towards in my products:
1) Fast — sub-200 millisecond response time to any user input
2) Assistive — give users something to react to; rather than forcing them to generate their own novel content
3) Learning — system improves with every user click or action

What are your top three?


Follow

Get every new post delivered to your Inbox.

Join 2,422 other followers