Four Characteristics of Startup Engineers, Product Managers and Designers

Startups are hard.  And hiring great technical staff members may be the most difficult and important challenge in a startup.

So how do we hire the right people? Start with the end in mind — i.e., have a clear definition of who you’re looking for before you begin. Most hiring managers start by trying to breakdown the technical “do-er” roles in a company (engineering, product, design) into lists of specific knowledge or behavioral requirements.  I don’t think it’s enough to just find people who can check the boxes of “knows Cocoa” or “expert with Photoshop” or “wrote Pivotal Tracker stories”.  Founders and early-stage startup team members need to have an extra dose of character because they’re not just building a product, they’re forming a culture. Here are four characteristics to look for in each technical role that has a direct hand in building a startup.

(Note: This post is a follow up and extension to with many thanks to Laura Klein and George Lee for inspiration and feedback.)


  1. Craftsman — pride and deep understanding of work
  2. Goalie — defender of the codebase, uses test-suite as a protective shield
  3. Macgyver — builds the minimum viable version quickly and then iterates forward
  4. Coach — mentors others and is coachable


Visual Designers

  1. Artist — weaves beautiful, delightful, enticing designs into and throughout a product
  2. Literalist — must get ideas/concepts down on paper or screen-pixels in order to understand and discuss them
  3. Eye of Sauron — notices 1px differences in baselines and kerning
  4. Toolmaker — creates guides, libraries, templates, etc. for other team members to follow


UX Designers

  1. Shortstop — covers all the gaps, thinks through corner cases and potential dead-ends
  2. Occam — cuts flows like a razor, down to the most simple path
  3. Empath — guided by deep caring and viscerally feeling the pain of the user problem
  4. WeebleWobble — absorbs input/feedback; bounces back from any knock, converting it into action


Product Managers

  1. Guru — customer use-case and domain expert
  2. Mad Scientist — sees the big world-altering vision, plots experiments to probe the path forward
  3. MC — confident and persuasive public presenter
  4. Logician — skillfully works the development process to deliver on-time, on-budget


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!

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”?

Two schools of thought on how to gain early traction for consumer-focused startups

I’m a co-founder of a startup and I’ve noticed that our advisors are beginning to form “teams” around two opposing schools of thought for gaining early user adoption.  These two philosophies are mostly mutually exclusive so I think entrepreneurs need to make a choice about which camp they fall into…   Which are you?

Read the rest of this entry »