After 18 months as the SVP at Blink Health I've wrapped it up.
It was a fascinating role.
A key criteria in choosing a role is the opportunity to learn and do something new, and Blink delivered. Below I try to quickly get down some of the things I learned working in Blink's particular context, and address a couple of the more common questions I get about what's next.
I'm still a novice to the healthcare space, but if I walked away with a single insight, it's that the problems of the US healthcare system are very tractable. The high cost and mixed results are unique to our system. There are incumbents fighting fiercely to maintain the status quo, but no more so than in other industries that technology has overturned. The regulatory environment is complex, but again not uniquely so. There are industries where one has to dig to find the problems that technology is well suited to solve, but US healthcare, an industry that communicates via fax, is not one of them.
Of all those varied incumbents I came away with the conclusion that the employer-based insurance model is the most insidious and problematic. It fundamentally misaligns incentives to provide healthcare for close to actual costs. Pricing becomes a game of arbitrage. Just to focus on prescription drugs, the area that I became most familiar with at Blink, the incremental cost of the overwhelming majority of medications people take is functionally zero and yet more and more people fall into the “in between” zone of not qualifying for the assistance they need nor having gold plated insurance. It doesn’t surprise me in the least to see Amazon and Apple experimenting in the employer provided healthcare space as a point of leverage on the wider $3 trillion dollar industry.
The shape of the engineering challenge was also intriguingly different. It wasn't just that the OODA loop was different, but there were wheels within wheels. (Also managing the product and design teams in addition to engineering for bulk of my time at Blink probably influenced my experience of the work -- I appreciate everyone who shared their wisdom and patience with me during this time)
We needed a team that could absorb an 18 month BD cycle and then ship a feature in 2 weeks (over Christmas) without it being a fire-drill. Healthcare is characterized by very large slow moving incumbents, difficult enterprise sales cycles, and increasingly fierce competition. Very early in Blink's life we needed to be able to deliver the rapid experimentation of a consumer startup, the data sophistication of a vertical ecommerce play, the maturity of a major infrastructure player, and the security of a modern healthcare company. (a task, it hopefully goes without saying, that would have been impossible without an amazing team -- engineering and engineering leadership are both team sports)
To achieve these goals we went hard on cross functional teams as our primary working unit, what folks might call "squads", though we called them working groups. In a modern organization like Blink cross functional doesn't mean "includes front-end and back-end engineers" or even "includes product, design and QA", but also explicitly leadership from departments like marketing and customer support who were were members of the working groups from day 1.
Very little kills momentum like uncertainty. It would be easy to allow a dynamic environment to undermine momentum. Instead our rule was to be clear about communicating the certainty we had, not the certainty we wished we had. An example of this were working groups were only commissioned for relatively short time windows, with the understanding that they might be renewed indefinitely or burned down. Similarly the roadmap was planned for a rolling 90 days, revisited monthly (a practice we also followed in Etsy engineering for a few years).
As most organizations have found that followed the methodology of organizing around what you're trying to accomplish rather than what you do, we found we needed a parallel structure around individual disciplines. We called these practices. (though other people have called them guilds, etc) They met regularly, membership could be aspirational (especially true of the Security practice, a topic people always seem to want to know more about), they were lead by the people best qualified to lead them irrespective of titles, and ended up being cross functional across different lines than the working groups. (e.g. the Data practice included data engineers, data scientists, and analysts).
This dynamism also made being synced as an engineering leadership organization important. Most weeks we met twice weekly. Monday to talk tactically about management, and Friday to talk broadly about an engineering leadership topic in a meeting not limited to managers. Jason Wong has written about some of our leadership practices in his Bootstrapping Inclusion series.
It was also notable what things weren't different. Removing barriers to shipping is still the secret to velocity. People with more clarity make better decisions. Simple beats clever. Treating people like people still pays dividends. You can never talk to your customers enough. And so many more of the basic lessons we seem to keep learning over and over again as a practice.
"What’s next?", is everyone’s first question. (or sometimes, “Are you going to go back to that coaching/teaching/being-a-stay-at-home-Dad-thing like when you left Etsy?”)
I’ve always said I went to work in healthcare because I couldn’t find a high leverage way to solve climate change. (as an aside: I firmly believe you can improve the world’s problems by removing people’s basic anxiety about their survival). So if you’ve got a high leverage project to solve climate change that needs some software engineering leadership, hit me up.
Barring the above, finding a role that optimizes for learning and positive global impact is always a journey, and I expect it will take a while to figure out what's next.
In the mean time I’m reverting to just doing some of the parts of the job I enjoy the most. Coaching engineering leadership, and helping debug the interface between the business and the technology organizations. If that’s a thing that sounds like it might be interesting to your organization, get in touch.
I've applied to a Recurse Center programming retreat. I still love programming. Software development has changed dramatically in the 25 years I've been doing it, but programming fundamentals have barely changed at all. What has changed dramatically is how people learn programming, a constant and ongoing task. Recurse is a community that takes learning very seriously, and I'm looking forward to it. (assuming I get in, wish me luck. I have to do a pair programming interview, aka one of those practices that came along after I got set in my ways!)
Finally, the family and I are thinking about blowing out of here for some unspecified amount of time and exploring New Zealand (and environs?), so if you have tips, they’re appreciated.
Onward!