I've had a varied career, starting as a professor before becoming a researcher at RAND. I spent some time at Price Waterhouse and as an executive in various roles at Charles Schwab. I was CIO and VP of Engineering at Google, where I oversaw all aspects of internal engineering, including Google’s 2004 IPO (yes, it was as fun as it sounds)! I also spent a short period in the music industry as president of EMI Music’s digital unit before founding my current company, ZestCash. I’m the author of Getting Organized in the Google Era, a book on personal and workplace organization. Here, you can read my take on innovation and culture, and how the two coincide. Follow me on Twitter @DouglasMerrill

Startups: How You Can Build A Strong Engineering Team

At my company, ZestFinance, we have a very strong engineering team — it’s hard to get a job here! — but there are less than two score of them. Sometimes that seems like a lot to me — especially when compared to when the company started, with 3 of us, not so long ago.

However, we are constantly coming up against engineering constraints — we just can’t do as much as we’d like to. I have dozens of product ideas that can’t get implemented for months, simply because the engineering team is working like crazy on a different set of priorities.

This isn’t entirely a bad thing. Scarcity is a great way of driving prioritization; it’s essentially a way of doing price discovery, where the relevant price is in engineer-hours. All businesses should face scarcity, but, ironically, startups will almost always fail if they can do everything all the time.

// Side note: I’ll go into why I think that’s true in a later post, but that’s irrelevant just now. //

So, what do we do when there is just too much on the list to accomplish within our planning horizon? Enter third-party engineering firms. We have used various engineering firms over the years, and, while some have been really useful, others have yielded more mixed results.

We are a big postmortem shop. When things don’t go well, we try to analyze what led to the failure.

// Side note: Actually, we do this roughly every week in our retrospective process, but I’m talking more about the self-flagellation I like to do at the end of major chunks of work. //

So, let’s post-mortem a few of our eng struggles. At first, we got a fair amount of our technical, non-engineering work (think systems administrator, helpdesk) through Odesk. We had pretty poor results, overall. We got one disastrous system administrator (who threatened to shut the site down when my Odesk review of him was pretty negative). We got another one who was reasonably good, but when he didn’t know the exact answer to a question, he would just go dark — stop answering his email, chat, or phone — for days at a time. And he didn’t always come back from his self-enforced hiatus with the answer, either.

After these experiences, we decided to bring system administration and helpdesk work inside. Our hiring process is better at evaluating talent than the folks we found at Odesk (which, to be fair, might be my inability to infer talent from Odesk’s reviews). Our current team is a vast step up, luckily.

You’re barely waking –Howie Day, “Collide”

We also started building our site and tools with outsourced software engineers (SWEs). We found them through a friend of mine, a Google SWE that I’ve known for a decade.

// Side note: By the way, that great engineer works for Zest now — always worth keeping track of great talent, even when they aren’t loose in the socket at the moment! //

The pair of SWEs did really good work for us, and were part of our team for a long time. However, we got used to having them on staff, and didn’t hire internal resources. That’s a bad strategy, as we learned when the pair gave us 2 weeks notice to fire us as a client. Although we had a strong SWE (note, “a”), we didn’t have our hands around all of the code. There were some deep issues with the code (as you’d expect, we weren’t going for beautiful code, we were trying to get a company launched!), but since we didn’t have enough familiarity with the code, we didn’t really know where to begin looking for them. We didn’t even know how to push new code into production!

This taught us outsourced SWE lesson number one: Always have at least one internal SWE pairing with the external SWEs. The corollary to lesson number one is try to have every internal engineer spend some time with the outside resources. Sometimes this is a tax on the external resources — such as when a very junior engineer is pairing with a very senior SWE — but the knowledge transfer across the entire engineering team is critical.

Let me deal with one disagreement right here: I know that having an internal SWE pair with the outsourced SWE creates additional fixed cost — you have to pay your SWE’s salary. Early stage companies may want to avoid fixed costs, hoping for future flexibility (read: ability to reduce costs without doing layoffs). In that case, one can explicitly decide to trade future learning crises (when the full-time SWEs show up) for short-term flexibility. But, honestly, in that case, I’d suggest writing the code yourself — there are lots of easy to learn programming languages that can do lots of heavy lifting.

You are unlikely to succeed without a match of internal SWEs with third-party SWEs. We are regular clients of Pivotal and Carbon Five. Both have great engineers — we all regularly learn from them on our projects. Even so, we are careful to never experience our system administration problem — we don’t use firms that have engineers we wouldn’t hire. And we always pair as many Zest SWEs with them as possible, so we aren’t at risk if they ever need to fire us as a client.

Third-party engineering gives great flexibility, but it has a cost. You have to decide if the cost is greater than the benefits.

Post Your Comment

Post Your Reply

Forbes writers have the ability to call out member comments they find particularly interesting. Called-out comments are highlighted across the Forbes network. You'll be notified if your comment is called out.