Location: New York City
Current role: Director of Engineering at VTS
What’s your background and how did you get into management?
I come from a software engineering background, but I’ve always had a passion for product and business. I’m a serial entrepreneur: I co-founded BillMonk in 2005 (tracks informal debt between friends, like roommates splitting bills; company was sold to Obopay) and the I co-founded Precision Polling in 2010 (self-serve IVR phone surveys; acquired by SurveyMonkey). At SurveyMonkey, we created a new business called SurveyMonkey Audience. This is a market research tool that lets you find the right people to take your survey, e.g. 350 responses from 18-45 year-olds who rent their home and own a dog. I coded the first iteration from scratch, then hired and managed a Seattle-based team to own this business unit as it grew into a 8-figure annual revenue business.
In a couple of years, I’d like to be able to confidently lead a software organization as it grows from 10s to 100s of engineers. I realize that I still have a lot more to learn about management and scaling to get there.
I recently moved from Seattle to NYC (my partner started a PhD program at NYU). After talking with several interesting companies, I decided to accept a director role at VTS, a commercial real-estate platform. I chose VTS because I was impressed by the business opportunity (it’s always good to be at a place that’s winning and growing!), and the leadership team showed a commitment to make itself continually better through transparent, ongoing feedback and process improvements. I feel like I’m still on the steep side of the management learning curve.
What are the biggest challenges you face?
Hiring senior engineers is our biggest challenge – in particular, keeping the top of the funnel full with sourcing and qualifying leads.
It’s a common theme with other folks you’ve interviewed, but as our company grows it takes ongoing attention to stay on top of communication challenges, especially around staying aligned on business product strategy. We’re trying to be much more deliberate with our process by holding regular strategy team meetings with all key stakeholders (engineering, product, design, marketing, sales, customer operations, etc) at the table to hash topics out; and at the tactical team level, we also want there to be regular stakeholder meetings that can bubble up any decisions that need to be made.
What is your approach to hiring?
Hiring is the single most import thing I do. Each new person has a potentially huge impact on the organization (positive or negative!). Here are some key lessons:
- Everyone should take interviewing extremely seriously, and ask for as much time and training as is needed to make good decisions.
- The default hire decision should be “no-hire.” We’d rather make a mistake and pass on a good candidate than make a mistake and hire a bad employee.
- Always “raise the bar.” As a string-of-words that may sound trite, but in practice, it’s a big commitment that each new hire will be better than your median employee. This means you need to mentally stack-rank your employees as e.g. [A, B, C, D, E] and only give job offers to people who are better than “Person C”. Your team only ever gets better, but hiring gets harder.
- Everyone who interviews a candidate must emerge from the interview with a vote: hire or no-hire. There is no middle ground of not having an opinion.
- Look beyond CS degrees; they’re not necessarily a predictor of job success.
- Make sure your interviews include at least 1 hour of active coding, and at least 1 hour of going from vague business goals, to a reasonable product definition, to a viable technical execution plan.
- Before an in-house interview, circle up with the team. Talk about the candidate, review phone screen notes, strategize who-asks-what.
- There should always be a debrief after and interview, even if it’s a clear no-hire. In addition to giving everyone a discuss the candidate, it is also an opportunity to debug the interview process itself and swap interview tips.
- Be alert and sensitive to unconscious interview biases. This is a whole other big area to dig into, but for now I’d point out that the exact same answer to a question could be interpreted as “self-assured,” “arrogant”, or “timid” depending on who the candidate and interviewer are.
What’s your advice for managers who are just starting out?
Spend your first two weeks doing nothing; watch and listen. Resist the urge to jump in and fix things. Learn that things tend to work even without you.
The worst thing a new manager can do is manage. You can’t ever really manage creative people; you can give them goals, you can inspire them, but you can’t demand creativity happen right this moment.
Your job is to let your employees work. They were hired because they know what they’re doing, and you need to learn how to trust them. You’ll find that your teams do need direction and context; there are logistical hurdles you can help clear; and a bit of coaching and support is helpful. But often the best thing you can do is get out the way.
Whats your work day like and how do you manage your time, emails, etc.?
I work 9am – 6pm on weekdays. Outside those hours, I rarely check email or Slack. When I vacation, I make it clear that I won’t pay attention to work stuff. I’m explicit and broadcast that these are my rules of engagement with work. I’ve never gotten pushback that, by setting these boundaries, I’m working too little. I’m trying to model (I hope) that’s it’s OK to not work all the time.
I carve out an hour on Fridays to plan my calendar and to-do items for the next week.
I tend to schedule meetings in 45-minute blocks, starting fifteen minutes past the hour (like 1:15-2pm). If I’m scheduled in back-to-back meetings, it’s nice to have those few extra minutes between meetings to wrap up tasks, finish notes, or use the restroom.
I keep to-do lists (Trello boards) for my short-term memory of things I just said I’d do, and projects I’m actively working on. No list should get more than 8 items deep or else it’s a sign I’m spread too thin and need to delegate or cry for help.
What’s a personal habit that contributes to your success?
I make getting plenty of sleep a priority. When I’ve had a good night’s sleep, I make better decisions and I get more joy from work and personal interactions.
Another habit is to keep my plate clear of tiny tasks. If something will take less than 5 minutes I do it right away, even if it’s low priority or not related to work (like scheduling a dentist appointment). This frees me from the mental overhead of having to be reminded about a myriad of small things and lets me focus on bigger tasks.
Share an internet resource or tool that you can’t live without.
I’m pretty low-tech. For my day-to-day management, I depend heavily on a handful of to-do lists (action items from 1:1s, leadership tasks, operational issues, a couple of others). I’ve tried managing these lists in a notebook, various mobile apps, text files in Dropbox, or in personal Trello boards (this is my current approach). These approaches are all pretty much the same in practice, so I wouldn’t say there’s any one tool I’d find irreplaceable; the important thing has been making sure I give myself time to regularly review the things that are currently on my plate, clean-up as needed, and have an opportunity to think.
If you could recommend one book to managers, what would it be and why?
“Managing the Unmanageable” (2012, Mickey W. Mantle and Ron Lichty) is the best overall guide to being an effective software manager. It covers all the areas a manager needs to think about, and gives specific and proscriptive advice; no fluffy business-management-book BS here!
“Scaling Teams” (2017, Alexander Grosse and David Loftesness) gives very real-world, well-grounded advice about the practical problems a team will run into over time. If you’re at an early-stage startup or massively growing team, this is required reading.
“High Output Management” (1995, Andrew Grove) is a terrific read from the point of view of the business owner – a perspective that’s often sorely lacking in management books! He has a great perspective on what matters when you want a group of people to efficiently produce things of value.
Finally, I find that a lot of my professional work involves writing (emails, specs, slides, blog posts, etc). Stephen King’s “On Writing” (1999) is well-deservedly quite famous for both its advice for authors and King’s unflinching self-examination. It’s honest, it’s useful, and it encourages reflection.
Where can we go to learn more about you? (LinkedIn, Twitter, GitHub)
This series asks engineering managers to share their experiences with the intent of helping other engineering managers learn and improve. Have someone you want to see featured or questions you think we should ask? Contact me.