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!