Assimilation vs. Differentiation
My engagement with the folks at Counsyl was a bit unusual, stretched out for almost a year due to how stock options were handled at Square. Like most companies at the time, Square had options that expired within 90 days of leaving the company, which meant that if I chose to leave I’d be stuck with the hefty exercise cost plus a massive tax bill. These golden handcuffs were eventually removed just before the company’s IPO, and I’m glad to see more companies—such as Affirm, my current employer—provide better structures for employee equity1.
Anyway, I went into the Counsyl as their first external engineering manager hire. As I’ve gained better understanding of the role over the years, I’ve come to appreciate the riskiness of hiring an outside manager; even with rigorous interview processes, it’s still extremely difficult to tell how well a new leader will work with the rest of the team. This is, of course, only amplified when you’re the first instance.
Whereas junior and mid-level hires learn from their new environment, senior hires are expected to bring something to the table and leverage their past experiences. This inversion of expectations should not have been surprising, but I should have nonetheless seen it coming: a former colleague2 at Square had quipped that “all we’d need to do from here on out is take the things that worked well here and reapply them to other places”, and there is some truth to that observation. On a number of occasions, I was asked to compare an ongoing situation to past experiences, not only for a well-trod path forward, but also as reassurance that these problems aren’t unique to the team and company.
For software to eat the world, it needs to cross-pollinate and subsume other industries. The entire benefit of automation is to more efficiently perform specialized tasks, which is only possible given sufficient background and context. That is, software can only model a domain if its developers intricately understand that domain.
There are two ways to bridge this gap: either teach software engineers new domains, or teach domain experts how to build software. The latter actually gets at the heart of the “everybody should learn to code” line of thought, with some arguing that coding is the functional equivalent of literacy in a computerized world, though not without plenty of pushback.
Within the tech industry itself, the prevailing school of thought is that technological disruption is best accomplished by onboarding engineers into new domains. In fact, most of the <prefix>-tech (e.g., fintech, edtech, etc.) subindustries are trying to apply software—via throwing software engineers—to domains which have thus far resisted extensive technological solutions. Most of these companies assume that their engineers can pick up the necessary areas of expertise, or at least work against a well-defined product spec.
With healthtech, I saw the limits of how much software engineers can accomplish without a complementary medical background; in Counsyl’s case, the ideal specializations would concentrate around genetic testing. Though this was not true of every system that needed to be built and maintained—e.g., there are websites and frameworks encapsulating the business logic on top of databases that can look like any rote CRUD application—being able to draw from the underlying science and biology just makes development so much easier. I found that some of the most productive and passionate folks on the team didn’t necessarily have computer science degrees, but came to software development as a means to further their interests in the biological sciences.
Through the Good and Bad Times
Beyond dealing with the familiar project, product, and personnel issues, people managers need to support major company events. When they’re positive—funding rounds, office expansions, product milestones—managers get some credit simply by association, and a rising tide easily lifts all boats. When things get less pleasant—particularly when dealing with decisions handed down from above—it’s a massive challenge just to stay afloat. Troublesome times separate the good managers from the simply mediocre.
Counsyl went through a few layoffs during my time there. Like most layoffs, my colleagues lost their jobs through no fault of their own; it’s the shifting company strategy that necessitates the reduction. And while the folks leaving are rightfully given the most thought and focus through the process, how managers handle communications to both affected and remaining employees makes the difference between a painful detour versus an undesired, prolonged contraction. We weren’t perfect by any means, but I was proud of my teams for their mature if somber response.
Revisiting an old friend
Realizing that healthtech wasn’t really going to be something I could fully immerse myself into, I decided to go back to the familiar territory of financial services and technologies. Even before the hype around cryptocurrencies elevated the entire fintech space, I liked the idea of accessible finance via technology as a democratizing force, an equalizer of opportunity that tries to unlock technological—instead of capital—efficiencies of scale. Of the various evolutions of the mission statements at Square, “Make commerce easy” was the most resonant.
So I was very fortunate to have found my next job in Affirm, where we try to build financial products that improve consumers’ lives. Startups at our stage of growth—some would term it hyper-growth—certainly aren’t for everyone, but it can be exciting and invigorating, both from the perspective of accelerating product momentum but also opportunities for personal development. Sheryl Sandberg has made it into a cliche, but there’s a good amount of truth behind the notion that getting on a rocketship accelerates the career paths of ambitious people.
And that takes me to the rainy spring of 2018, where after 14 years of software engineering, I’ve went from a novice C++ programmer all the way to a director of engineering at a promising startup. If you’re still reading at this point, then I thank you for your attention, as I’ve certainly enjoyed my time in putting my thoughts to long-form prose3.