Melissa Leffler

Early interests and stepping into management

Hello, my name is Melissa Leffler and I am currently the VP of Engineering at Drift. I graduated with a double major in computer science and English from Boston University. Even in high school, I had always been a computer person who also liked writing. I worked as an engineer through school, and my first, full-time job was at a database company.

After that, I started to work at Lotus and ended up staying for eight years because it was such an amazing place to grow as an engineer. They asked me to be a manager at a very early age, around 24, but I wanted to work at more of an architect level and get that technical grounding and learn more about object oriented systems. However, I ended up needing to step up to do it and became a manager pretty early on in my career.

I was also a manager at a very successful company called eRoom, but unfortunately we were about to go public right as the dot-com bubble burst in 2000. We were eventually bought, and even 20 years later, when I was at a recent speaking engagement, someone came up to me and told me they still use the eRoom product. It’s amazing to have been a part of a company that built a product that people are still using and talking about decades later.

My biggest personal learning from eRoom is that I’m happiest being around the engineering teams and those who are building the product. I love managing teams and building the product, so I’ve chosen to work at smaller companies to be at that level instead of only being around execs. I love product, engineering, building from scratch, and learning new things every day—there is something so interesting and exciting about being fully immersed in the process more than just overseeing it.

Transitioning from backend engineer to leadership

When I look back at the transition from working on the backend of a product to managing teams of engineers, I was lucky I got to do it at excellent companies like Lotus and eRoom. eRoom was also an amazing company to make that transition because I got to ease into building a team while concurrently working on the technical aspects. eRoom was SaaS before there was SaaS, and it was exciting to be a part of a SaaS company when the concept barely existed. We used an ISP that was literally on the pink list at one point, so we had to meet with them and tell them how to manage their applications. They ended up getting bought by Microsoft and not going out of business, but it’s crazy looking back at it now because there were no ISPs, no uptime, no SLA of liability, or anything, really. We just had people managing our servers somewhere. Being part of figuring out what that meant when it was uncharted territory was inspiring.

Hiring by fostering mutual learning

I like to think of hiring as being one of my superpowers, and I'm always very interested in how we bring in talent and look for the right qualities. Hiring security people when I worked at Carbon Black was always really hard because it’s such a competitive market. Knowing this, I devised a method for interviewing technical candidates that fostered mutual learning and helped showcase the candidate’s thinking and problem solving abilities. The cornerstone of this process was called the “Tech Talk” (brochure featured in appendix). We would tell the candidate about it beforehand, and all they had to do was choose something they knew a lot about and come talk about it—that’s it. It’s not done with a PowerPoint or necessarily any architecture, it's all about getting to see how you think about your work.

We wanted to see how candidates think and problem solve and what kind of team members they are. For example, if they spoke about something they built, we wanted to know why they picked those technologies, if they talked to customers, if they ran into any scalability issues, what they would do differently, etc. Another perk of this was that they could see me and the others in the room discuss and banter back and forth throughout the talk to get a feel for what it would be like to work with us. The “Tech Talk” was so popular it ultimately spread to other parts of the org and roles.

Working on small teams

At Drift engineers are grouped into small, autonomous teams made up of three people. I was initially concerned about this, because you read so many articles about the perfect team size being about a certain number of people and such, but now it feels like magic. I love the three-person team because it provides everyone with agency when it comes to what he or she is producing. Each team has one tech lead and two engineers, and we also have a product manager, a designer, and a customer advocate that spans these teams. Being able to say “this is yours, so figure it out” without it being so many people that work gets lost in the shuffle, always outweighs any logistical issues that may arise with a smaller team.

When I was at Carbon Black, we had much bigger scrum teams which led to a lot of dependency on those in leadership positions, and trying to manage each group could be crippling. At Drift, even though we have about 25 small teams, we don’t have these types of problems because we are able to identify areas of ownership. As Drift has grown, we’ve developed new ways to help all of our small teams scale alongside.

Milestones: scaling up and setting goals

At Drift, we are experiencing more cross-dependency work as we move into the enterprise. My latest project was incorporating milestone tables that each team uses to keep track of goals and projects. I met with each team and did a mini-training on how to develop effective milestones, and each team’s milestones were collated into a Google Sheet to track the progress.

The only rules I gave people were to put everything down in their team’s Google Sheet, talk about it at your weekly meetings, and then present the results at the team’s biweekly meeting. My goal was that 13 out of the 22 teams we had at them time deliver their milestone on or close to their date, and right now we have exactly that number, so it’s worked out well. Next quarter it will be more! It's a smart way to both give teams autonomy so that they feel like they're choosing what they work on and overseeing it in a good healthy way.

We have also been doing a lot of research into the concept of guilds and squads so people can focus in areas that transcend their team. For the guilds, which are organized around topic, we have done surveys looking into things like how often to meet, how many topics to have, etc. From that we organize into squads because, like startups, we also organize around the use case which can span multiple teams. Making sure the teams have the right connecting points to cohesively build the software is something we rely on the squad for. For now, we’re currently figuring out how we operate specifically at the guild level to ensure our small teams can still have ownership of their own work while depending on each other.

Scaling and reliability

As we’ve been scaling, we have been bringing our process to the next level. We have an incident management “guild” at Drift in charge of coordinating incident resolution and leading RCAs afterwards. One team member recently implemented a monthly incident review, modeled after the medical M&M (Morbidity and Mortality) conferences.

As someone who has been in SaaS since before it was called SaaS, I have a good amount of experience with reliability practices. My time at Carbon Black was fascinating because it was my first time dealing with SaaS and reliability at scale. Carbon Black has security software that gets installed on everyone's computer, endpoint, or build system, so the sheer amount of information we had coming in to on-premise servers and cloud servers is wild. Plus the bar was high given the sensitivity of the information being handled.

The kind of reliability problems and incident management that we had at Carbon Black were usually between our multi-tenant system and between our containerized customer system. We hosted our on-premise servers ourselves in the cloud as a managed service, and every customer had their own area. The challenges we had in building that cloud business while maintaining high reliability were that we had to roll out updates across every customer and build an orchestration layer like I’ve never built in my career. It wasn’t the days of container and prepacked solutions, so we had to build it all ourselves. We needed an extensive set of checks, but needed to protect customer data, which was the end goal.

The Boston startup community

What I love about the Boston tech community is its size and smallness, and that wherever you are, you find other companies at a similar stage to you who always open their arms and share learnings and advice. My participation in the startup community is very relationship-based. I love helping engineers who have worked for me in the past, individual founders, VCs needing technical diligence. I am more isolated now that I'm at Drift, because I tend to put my head down and I’m always busy. But what's amazing is that you can put your head down and be busy, but then pop up and the community will always be there for you.

Appendix: Tech Talk Brochure

Melissa recommends

The book that I've read in the last year or two that impacted me the most was The Coaching Habit by Michael Bungay Stanier. The reason The Coaching Habit is high on my list is the AWE question: “And What Else?” Often people bring an issue to me, and because I am a problem solver by nature, I can jump into advice mode. But really digging to find out what the real issue is—and helping them to see it—means they can figure out what to do about it. I need to coach others, and not solve problems myself, and build that practice in my leaders.

On an unrelated note, I’ve also loved a Ken Follett historical fiction series. So far, I’ve been through World War One and World War Two and I just started the third one, which covers the race riots in 1968—very timely. It’s my way to refresh myself on all the world wars and what happened across the world. I was also an English major, so I love how good the writing is.