From The Ground Up

Fwd: Engineering, startups and life

How To Build A Productive Engineering Team

leave a comment »

No easy answers. Every start-up or technology outfit tends to have its own unique engineering culture. Being exposed to these various cultures and working with smart, hard-working, passionate teams is in and of itself very rewarding. But I think there are some core strategies that can be common to all engineering teams that increases productivity of individual engineers and subsequently the entire team.

1. Emphasis on the stack. Any given engineer will have his/her strengths working with specific technologies and specific domain knowledge. And no doubt, engineering specialists are necessary to be successful. However, specialists should also have working knowledge of the entire technology stack. Being able to code and deploy a prototype from javascript to mysql on one’s own time, and not having to use or interrupt other engineering resources, is a powerful thing. Facebook employs this criteria when hiring. Having top-to-bottom skills empowers each individual to ideate and build. These types of hacked prototypes are very often the source of innovation and lead to new features or even entirely new product lines.

2. Ship code early. This point is directed towards teams with new engineering hires. New hires want to make an impact as soon as possible. The best way to do this is to get them to ship production code within his/her first few days. Just going through the process of checking out, executing, modifying, checking in, and deploying code and seeing that code run live, will jumpstart him/her right out the gate. The new/modified code doesn’t need to be an entire feature or a complex algorithm — it could be as simple as a minor bug fix (no such thing!). Gerry Mckenzie, VP of Engineering at Etsy, has new devs ship code on day 0. Awesome. In addition to “early“, I also add “often” whether or not a team member is new. We’ve heard of CI and CD, and there is a wide range of ways to commit to these concepts — the important thing is to put a plan in place and practice it and stick to it religiously, tweaking as the team sees fit. CI/CD is a culture more than anything and fostering this culture within the team takes time, patience and resolve, not just lip service. Continuously adapt and improve your processes.

3. Sandboxes. Related to both points above, in addition to deploying production code, we want to experiment. All startups, regardless of size or product roadmap, should have a clean delineation between production and development environments (ideally in addition to a stage environment). Sandboxes are just that — not a chaotic free for all, but a structured environment that makes sense moving forward. Make it easy to use servers or to launch instances (AWS) that come locked and loaded with centos/tomcat/apache/php/java/mysql/[standard internal tools of choice] so that developers can spend their time focusing on exploring that new web framework, or benchmarking the latest NoSQL platform, or deploying the new-fangled prototype. By removing the friction between Point A (idea) to Point B (getting-productive-work-done), in the short term that initial inertia is dispersed and known milestones are reached faster; in the long run, engineers will be more apt to dream a little bigger and innovate at a faster pace.

4. Measure, measure, measure. We want to know which features (i.e which lines of code) are being used, how, and when. This information empowers developers to focus on and improve one set of features, while pulling resources back on or deprecating another set of features. While prototyping and experimentation is necessary, building out technology for engineering’s sake is neither productive nor encouraging in the long run. Measuring customer usage metrics and feedback is vital to the health and growth of the team and the product(s). The process of building out the necessary instrumentation to measure and monitor performance/usage/engagement requires methodically stepping through the codebase and use cases and is therefore itself highly informative and useful to the team.

This is an ever-evolving list guided by my experience working on a few different engineering teams. I hope to improve upon this list while learning more about myself and people working in the controlled (or all-out) chaos that is startup life.


Written by Girish Rao

January 30, 2011 at 21:09

Posted in Uncategorized

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: