Building an Effective Engineering Culture, from Startup to Acquisition
Enigma: We’re excited to speak with Gil Shklarski today to learn a bit about what makes him tick. To start off, how did you get to where you are today?
Gil: I joined Flatiron Health in 2012 as the second engineer. Literally, the first interviews I had conducted with other [prospective] engineers were done while I was still at Facebook, even running them on my Facebook laptop afterhours in my home in Seattle.
We grew very slowly in the beginning--it was just me and a very small tech team. I was setting up security and IT, which a CTO does at a small company. As we continued growing, and after we acquired another company [Altos Solutions], I started focusing on building an effective engineering team and culture--building the organization. It became less about me contributing to the tech.
Previously, I worked at Facebook for a couple of years, where everything is high-scale; I worked on data pipelines for fraud detection and for identifying “bad actors” on the Facebook website. When was the last time you clicked on a bad link in Facebook that led you to malware? Probably never. That’s due to the data collection, and automatic analysis and response mechanisms, that my former team was building.
My first role in the U.S was at Microsoft, which I joined after working on my PhD in Israel. The funny thing about my PhD was realizing that as my work became more specialized, it became interesting to fewer and fewer people. Whereas at Microsoft, I would write a small piece of code that would go out to 25 million people instantaneously. So that was an exciting transition for me.
Lastly, before my PhD, I spent 10 years in government with the Israeli Defense Forces (IDF).
Enigma: You have an interesting background. You’ve been vocal in the past about growing engineering and, several years ago, gave a talk on “Engineering Ladders as a Cultural Manifesto”. Describe the title’s meaning and if your thinking has changed as you scale and grow your team?
"Initially, my goal was engineering would never be the bottleneck for creativity in how we build a business."
Gil: Initially, my goal was engineering would never be the bottleneck for creativity in how we build a business.
But before I get into what I mean by that , let me define “Engineering Culture” which I took from Kevin Scott [CTO of Microsoft]. It can be defined along three axes: 1) “how we build technology,” 2) “how we operate technology,” and 3) “how we function as a team.”
When I think of using ladders as that manifesto for culture, I think of it as how we ultimately encode our craft. How do we signal what we care about? How do we define what “good” is? How do we measure engineering excellence?
An effective ladder can formalize behaviors that leadership wants to promote and be accountable for. So we asked ourselves, “How do we encode how we want engineers to solve problems?” And this is not something that I think is specific to engineers, but rather something important to all major functions.
Enigma: Flatiron has grown considerably and you’ve had the opportunity to flex those concepts as you’ve scaled the engineering department. Has Flatiron’s manifesto changed as its grown?
Gil: Our core values have not changed; we still care about providing feedback, being kind, and getting our hands dirty. But the way we demonstrate those values did change.
When we had fewer than 30 engineers, it was all about optimizing for iterating towards an MVP (minimum viable product). At 130 engineers, we need to think about scaling platforms. At both stages, there are different behaviors we want to promote.
For our more junior engineers, the ladder change was fairly limited. The majority of changes were with our mid-to-senior engineers. What does it mean to be a senior engineer? What's the role of a tech lead and manager? What does a director mean? How do our tenured engineers help guide and mentor our more junior engineers?
Enigma: One of my favorite dimensions of your engineering ladder is your “GSD” (“Get Shit Done”) metric. How does this metric drive a successful engineering culture?
Gil: We actually took the GSD metric from engineering ladders at Google, Facebook, and RentTheRunway.
Four years ago, GSD was pure and simple. It wasn’t about sustainable execution. It was about iteration. My focus as CTO was purely on short term business impact, iterating quickly on MVPs in many of our business lines and being able to test ideas quickly.
As we grew, we needed to be a bit more nuanced about GSD - it became more about ensuring the quality of execution--strong technical execution. It now explicitly encapsulates technical product management skills (embodying our “work on problems that matter” value) and stakeholder management (ensuring others can actually work off of what you’ve built).
Enigma: When did the need for this shift in GSD from MVP iteration to scalability become apparent?
Gil: The shift from startup to scaling was apparent from our business requirements given the increased scope and complexity of our products. The change in the ladder was a bit latent. We had multiple signals that called for this shift., At the 1:1 level, it was our engineers saying that they need guidance for their career - How can they grow? Where should they grow?
Another signal was in our performance review process; we have committees to calibrate reviews and promotions. We realized, many of those conversations were becoming ambiguous. Why should someone be promoted over another person?
This encouraged us to re-evaluate how we encode behaviors. What does GSD mean today at our stage? We actually call it now “Technical Product Delivery”...
Enigma: As a result, has morale or quality of happiness changed? How do people feel about the shift?
Gil: It’s recent, so we’ll see. Ultimately, it's about giving engineers and the team their due credit.
Enigma: Looking back, what do you feel has made Flatiron uniquely successful in implementing this culture?
Gil: Ultimately, there’s this recognition that we engineer towards business results. And startups take such huge business risks, that we need to build technology to support those risks. As we continue to move from startup to maturity, we can take more technical risks.
Looking back, we were thoughtful about our mentoring capacity. We were thoughtful about our team building. We were thoughtful about how we'd hire and bring more engineers in. That's the bottom line
Engineering was the earliest most established team at Flatiron. We brought in people that came from Google, Amazon, AppNexus, etc. We were standing on the shoulders of giants in learning from their cultures. So engineering became the incubator for much of our company culture today. We were the first to do performance reviews, first to pilot career conversations, manager trainings. Even our interview structure was based on Microsoft, Facebook and soon became the basis of how interviews are done across the company.
The other realization, which is not a natural tendency for those outside of engineering, is that our goal is basically…to be opportunistically lazy. You want to automate yourself out. It is a key for being more efficient and it is the key to continuing to working on new, more difficult problems. This is how you advance your career. So we hired and helped craft our culture to promote this “make yourself redundant” approach.
Enigma: You started your career in the IDF, then Microsoft, then Facebook. How have each of those experiences impacted how you manage Flatiron today?
Gil: At the IDF, I learned a lot about entrepreneurship. Elite tech units in the IDF are much more like startups then big companies. The atmosphere there is very entrepreneurial. And while there, I learned not to be afraid to attack problems I don’t feel trained for. I learned to not be afraid to learn a new domain quickly if you need to solve a problem.
It gave me the confidence to join this startup. It gave me the confidence early on when we had setbacks. It felt like I was an officer in the army. One of the trained traits of an Israeli officer is being able to solve hard problems by utilizing specialists on your team. How do you utilize the main expertise of others (when you are not that expert yourself)?
Later, my IDF experience reminded me to never be afraid to hire people who are smarter than you. Rather, do the opposite. Talent was enormously important in the IDF—elite units at the IDF are often the top one percent of the talent in Israel. The bar is insanely high. One talented team member allows you to make a dent in hard problems quickly.
Mission was my second lesson. I was in active service on September 11th, 2001, though not on anything specifically related to counter-terror--just working in a defense-related role in a western democracy. I felt less helpless than I could have felt working in the private sector. I felt that in a way my daily contributions were making a difference. At Flatiron, our mission feels just as valuable. When you think about it, cancer kills more people than Al-Qaeda. With this mission, you feel less helpless when cancer strikes close to you.
Lastly, at Facebook, I learned how to build towards excellence. We adopted high standards for code development from day one. Literally during first week here, just us two engineers, we installed phabricator (Facebook’s code review tool). I learned about structured interviews, engineering ladders, and how to grow and evolve our own culture from my time at Facebook.
Enigma: Gil, thank you so much for your time.