Insights | Insights

Top 5 CTO Tips: Hiring & Retaining Engineers & PMs

June 20, 2016
Screen Shot 2014 02 20 at 1 42 18 PM

I’m here at the Bowery Capital CTO Summit 2014, which we’re hosting at Bloomberg SF. We’ve got a great crowd assembled and a laundry list of tech & product leads from companies like Google, Twitter, Sailthru, Flurry & Ooyala to take us through a day of tactical chats and panels.

We just kicked off with a quick intro on Bowery Capital and our thesis with Mike, and then moved to our first panel: “How To Hire, Retain, & Let Go Product Managers & Engineers.” Managing engineering teams is an incredibly difficult question-set that we run into frequently with our portfolio companies (and the considerations are never quite the same for each founder and startup). The viewpoints we assembled to help us answer the question are equally diverse: Arvind Gupta is the VP of Product Management at Vungle, previously with Microsoft. Randy Meech the CEO of Mapzen, previously with Brewster and AOL. Michael Borohovski is a Co-Founder and CTO of Tinfoil Security, previously with ManTech and Apple.

So, for all the tech and product managers out there, here are the Top 5 CTO Tips around tech & product team management from our first panel of the day:

1) Have A Strategy Before You Start Hiring

Begin by evaluating three things: (a) Functional domain expertise needed, (b) Likely ramp up time for those, and (c) Existing skills in your startup. This is most important when hiring your frontline team to fill very specific roles (which you should do first). But don’t approach hiring generalists loosely either. Once you know those, you’ll know what your timeline is and how aggressive you need to be. In any case, don’t commit to an unrealistic decision structure (hiring unanimity can become difficult, for example).

2) Think About Designers Differently

Specifically for thinking about potential designers: the proliferation of “Steve Jobs Test” on hiring designers (is she as good as SJ) isn’t productive. All designers in particular have different strength areas; know which is most important for your product and focus on those. While design can often be a subjective thing, it’s up to the management to ensure that design matches both culture / attitude (form) and UX / UI / technical requirements (function). Usually behavior is more important than aesthetic, so try to be results-driven.

3) Make Full Use Of Your Talent

As a part of onboarding, ask new hires for a list of the smartest people they’ve studied or worked with. You hired these people so what would be a better target list for future hires than these people’s own all-star call outs? Always encourage side projects amongst your engineers, and ease up on the oversight as long as core work gets done. Encourage participation in open source projects. Find overlap between your engineers’ passions & your team’s mandate and fuel them proactively. You never know when these turn into new products (and that happens a lot at the organizations that handle it properly).

4) Ask: Are We Creating A Monoculture?

“Enthusiasm” as a criterion has pervaded the valley but can turn into a sort of Bro Culture that ignores the importance of rule #1: hiring the best and most talented people possible. That said, especially as a startup grows above 10-12 people, personal intra-startup relationships can cause issues if you ignore them. Be cognizant of team characteristics / attitudes and be careful to create a unified culture. Culture influences how teams work together, how they manage projects, how they think about surfacing new opportunities, how they talk about the startup to the outside world, and is even an implicit hiring qualification (better-fitting candidates can only “self-select” if culture is distinct).

5) Don’t Drag Your Feet On Recognizing Lack Of Fit

Most technical leads at startups would tell you that it’s fairly clear when a new hire isn’t a fit from a skills or cultural perspective. Once you recognize an issue, there’s no benefit to ignoring it (though that happens often because it’s uncomfortable to broach). If you aren’t seeing these problems ahead of time, revamp your performance review strategy: company wide works up to around 20 heads, and weekly 1:1s make sense thereafter. Work together actively on their issue for a set period. Approximately 30 days is often enough; putting someone on a “plan” that’s too long isn’t beneficial for anyone if the fit isn’t there. Actively helping people move on to a better fit is a value-add for everyone.

Thanks much to Arvind, Randy and Michael for joining us! I certainly enjoyed it and hope I’ve done a decent job absorbing and expanding upon the insights our panelists shared. To anyone that wasn’t able to join us in person today, keep an eye on the blog here: we’ll continue to share CTO and CIO insights from today’s Summit over the next week or so.