“The Core Value of a Good Leader is Humility:” Sam Schillace, Box Engineering SVP

SamSchillace_Headshot

I first met Sam Schillace when we were both product leads at Google. It was clear that Sam was a builder – and one who combined maker chops with thoughtful management. Now as SVP of Engineering at Box, he’s had the chance to scale their engineering team and help take the cloud collaboration company public. Earlier this month, I was at an event where Sam mentioned he writes a letter to his Box engineering team every Sunday. Here’s some more detail about that practice and other ways Sam approaches leadership.

Hunter Walk: Ok, is it fair to call you the “Father of Google Docs?” I don’t think many people know you started the company (Upstartle) that built the product (Writely) that Google bought in order to launch Docs.

Sam Schillace: Well, there were a lot of people involved with that success, but it’s true that people often refer to me that way. I was one of the founders of Upstartle, had the idea and wrote the first version of Writely (I was interested in experimenting with what was then called AJAX and some new browser capabilities around text editing). At Google, I was the engineering director responsible for Docs and I created and led the teams that built the powerpoint replacement, and the drive interface (though it was just web based then, and I did have the early drive team working for me). My team also did the Google Apps/domain builds/integration. There was a team in NYC that built the spreadsheet app (they were another acquisition), and that team now runs all of GDocs today.

HW: Since Google you’ve moved on to lead Engineering at Box. How large was the team when you came over and how has it grown since? What do you look for in a “Box engineer?”

SS: We don’t talk about specific numbers of engineers (public company, yay!). The team is about 5x as big as it was when I started. It’s been a lot of fun to grow it.

We’ve learned that one of the most important things to look for is someone with a high emotional intelligence who contributes to the culture. We look for people who are flexible, passionate, and have a sense of responsibility and playfulness at the same time. We care deeply about our customers and we care deeply about being a great team of engineers that builds software that works for both enterprises and for end users. So we want someone who is a very solid engineer, who cares about customers, who wants to be in a startup environment, but who also has a strong sense of engineering quality and skill. We test for both engineering skill and the softer skills.

HW: You told me the other day that every Sunday you write a letter to the entire engineering team. When did this start and what’s the motivation behind the practice?

SS: It actually started out as a personal accountability exercise – I think it’s very easy to fool yourself as a senior leader about your effectiveness, so I was trying (in Google snippet style) to just document my goals and accomplishments each week, in a transparent and accountable way. The problem was that so much of what I do as the leader of the org has some aspect of either confidentiality (like HR or M&A) or context that’s hard to explain (perhaps the early stages of a new product or technical direction), that I wound up eliding most of it. So I shifted over into some more personal and cultural thoughts, and it just sort of took off from there. I’ve been doing it since the very first week I joined, and I’ve only missed a few – and even then I always have one of my folks write it instead.

HW: Can you tell us a bit about the contents of a typical letter? Or maybe a not-so-typical one – for example, what was the letter like the week Box went public?

SS: I’ll typically talk about something I’ve noticed during the week that I can apply generally. Lots of them are about growth – I explained some things like Dunning-Kruger and how it relates to impostor syndrome, sometimes I’ll talk about design philosophy and how to think about what needs to be done first (we had a long conversation about “first things first” at one point). Sometimes they’re more practical – I did a long one on liquidation preferences and how they inflate valuations, right before Sam Altman wrote his blog piece on the same thing. I’ve written a lot about the value of humility in leadership and how that manifests, and sometimes I’ve used them to take ownership of mistakes I’ve made or challenges I see in the organization. They generally have some personal aspect to them as well, because people have asked for it and I think approachability is very important as you get more senior in an organization. So I walked through my recent winemaking season, for example, and I often talk about my kids or my cooking in a small section at the end.

For the IPO, I think the update was mostly sharing what the experience was like – I had to wear a tie for the first time ever professionally, so I joked about that, and I talked about how the NYSE treats you (very well), and what it was like to go through the process and be on the floor. I also did the obvious conversation about how it’s the starting line not the finish line. More recently I’ve written about some research on stock performance post IPO, and how our experience is fairly typical.

HW: You’ve been building companies and teams for a while now. Engineers who are taking on manager responsibilities for the first time – any advice for them?

SS: Don’t do it for power. The core value of a good leader is humility. It manifests in many ways – being confident enough in yourself to delegate to others and let them shine instead of taking the spotlight, for instance, is an example of humility. Not being afraid to admit mistakes or change course in public, giving credit to others, being able to be vulnerable and ask questions or ask for help – these are all marks of a good leader and are all manifestations of humility. Also, engineers transitioning into management always feel that they aren’t adding value once they stop directly producing code – this is normal and you have to let go of it – think of it as going from writing code with ten fingers to writing it with ten people.