Each month we grab five interesting pieces of information for a five minute read from a founder, thought leader or member of the wider Movac team. This month, we caught up with the newest member of the Movac team: our CTO in Residence Jeremy Ginsberg.
Jeremy joins us after 17 years in the Valley. His last position was Head of Engineering & Data Science at Color, a fast-rising health technology start-up. Before that he was VP of Engineering at Twitter, and lead teams at Google focused on machine learning, search quality, analytics, and a novel disease surveillance project called Flu Trends.
1. Jeremy, welcome to New Zealand! You have worked for a bunch of awesome and quite different US companies in engineering lead roles. Tell us a bit about yourself and what you plan to spend time doing here.
Thanks, it’s an honour to be here! Let’s see, I’m still working on learning my proper pepeha, but my ancestors originally came from various parts of Europe, and I grew up in Texas before spending most of my career in Silicon Valley. My background is in software, and especially systems which use data in novel ways or discover interesting patterns/signals.
Many years ago, I was teaching computer science at Victoria University in Wellington, and was thinking I might try to stay and work towards NZ residence — but in 2003, I had the chance to join a fast-growing startup called Google and couldn’t turn down the opportunity. Probably a good call, in retrospect!
It’s taken a while, but I’m really glad to be back in NZ. Plans are still a bit open: I’m an Edmund Hillary Fellow and enjoying collaborating with Movac as CTO-in-Residence. I’m trying to meet as many NZ startup founders and CTO’s as I can, especially those working on hard software problems, and planning to spend a good bit of my time advising and broadly trying to help to grow the ecosystem.
2. Perhaps one of the most challenging hires for a founder/CEO can be the first engineering hires. What are your practical recommendations on how to size, hire and manage engineering teams?
The best situation, of course, is to have a technical co-founder on day 1 — especially if you’re pursuing a technically ambitious problem, or a solution where the technology is a key differentiator. Alternatively, plenty of startups can be built with existing services and platforms — you can get a lot done without writing code, especially if you have a great product designer on the team.
3. Actually this is something we are seeing more and more: startups getting out of the gates quickly because they are using a combination of great existing platform solutions. What are the biggest advantages and risks a founder/CEO should bear in mind for this approach?
The advantages are pretty straightforward: speed, cost, and often maintainability. Peter Norvig famously quipped that “all code is liability”, so the best software developers sometimes cheekily refer to themselves as “software prevention engineers”. It’s pretty rare that a startup finds product-market fit, a strong GTM strategy, and hypergrowth — but then fails spectacularly because of a shoddy implementation. Often it’s the other way around — an expensive custom implementation of a product that few customers truly care about. Twitter was notorious for its “fail whale” and had horrendous bugs and downtime in the early years, but users and brands/advertisers loved the service.
As a fast-growing “no code” company scales, it may decide to invest in building software in-house, and we’re back to your original question — how do you find great technical talent? No easy answers there, but at least now your odds are far better since you have a successful and growing product — I might start by talking to investors who are well-connected to software/product leaders.
4. What is the biggest piece of counterintuitive advice you would give to engineering leaders?
Don’t shy away from understanding the business and the customer — spend time with your product counterpart in the field, shadow the sales team, shadow the support team. Ask lots of questions. Stare at operating metrics, understand your conversion funnels and where the drop-off is. Without this kind of first-hand knowledge, you won’t have a very informed opinion on which projects are going to be the highest-leverage use of your time. It’s easy to lose leverage if you just build whatever sounds internally popular at the time, or whatever is being pushed for by some internal stakeholder.
5. You led a team of top tier software engineers and data scientists at Color as it evolved from a small company with one product offering to a more established and generalized population health platform. What is the single biggest learning from successes/failures over this phase of growth that you can pass on to us?
I personally love this phase of growth: going from 1 to N, when things are just starting to go really well and energy is high. Color’s engineering team had good instincts and had built a strong foundation before I joined, so initially, my focus was on helping the team mature and grow without oversteering. Navigating the tension between keeping what is working well and pushing the team’s comfort zone. I try to prioritize by thinking about what’s slowing the team down or making them less effective.
As Ben Horowitz famously put it, the hard thing about hard things is that they’re hard… there’s no magic recipe.
