Achieving Operational Excellence Through Small Teams, with Melissa Leffler

Melissa Leffler is the VP of Engineering at Drift, a chat software and conversational marketing platform based out of Boston that has grown a ton over the past few years. In the past 5 years, they’ve raised $107M in funding. They have 75 developer on staff and are showing no signs of slowing down in the next few years.

In this episode, we discuss how Drift changed Melissa’s mind on the power of small teams, how she uses incident response to guide her team, and the one question she asks to unlock the biggest problems in her department.

‍

‍

Listen to the Full Episode Here:

‍

‍

‍

Full Transcript:

Wes Winham:
Melissa, thank you so much for joining us today on Scaling Software Teams.

Melissa Leffler:
Thanks for having me Wes, I’m excited.

Wes Winham:
What is the most important inflection point that got you where you are today in your career?

Melissa Leffler:
Probably when I helped start my first company. Before that, I was at a company called Lotus. I went to a smaller company and I realized that leadership at any company that size really, really matters. I went to a company where things were not totally great and then I decided, I’m going to start something with a set of people that have the same values, and we’re going to do it well. That’s what we did. We started a company called eRoom.

Wes Winham:
You knew your values going in, and you were able to hire folks with those right values from the beginning. Is that what I’m hearing?

Melissa Leffler:
That’s exactly right. We came up with operating principles, just like Drift has leadership principles now. We sat down and talked about what our goal was, and then we built a team. This was a long time ago, this was in the ’90s. We ended up selling that company to Documentum, and then EMC. 25 years later, the product is actually still being used. It was a great experience. I learned a lot.

Wes Winham:
That’s your first experience, not a lot of values alignment at the big company. What was different whenever you’re able to start that way from the beginning with eRoom?

Melissa Leffler:
When you’re giving the message and when you’re recruiting people in, if they can be part of something, part of a team and they know what you stand for, and that resonates with them, I think that’s incredibly important. We don’t want to just hire great engineers, we don’t want a whole bunch of contractors, and especially if the team is distributed, which Drift isn’t very distributed, but nowadays, lots of teams are distributed. Having that shared fabric that really helps you build a team, is, to me, the most important thing.

Wes Winham:
With a strong set of values, have you found that you maybe scared off some candidates that didn’t share those values? Is that something you’re concerned about?

Melissa Leffler:
Not concerned, but we’ve updated our process to make sure that when that happens, it’s for the right reasons. I’ll move forward to Drift. Drift has a set of leadership principles that are really important to us. They’re on the web and actually, they came from inspiration from Amazon. Many of them are, some of them are the same as Amazon.

Drift has leadership principles, and we want to make sure that when people join, those leadership principles get them excited and really resonate with them. If there’s not a great fit, it’s not going to be great for anybody. For example, put the customer at the center of everything you do. If you’re a developer who wants to build your feature and that’s it, and you don’t want to look at the metrics, let alone possibly even talking to customers about how it’s going, you’re not going to be that happy.

Extreme ownership, if we basically say it’s yours to figure out, how can we help you, you own it, and by the way, if you fail, it’s okay. If that’s scary to you, you’re not going to be that happy here.

I think that building a company around those principles and then making sure that we make that clear in the interview process, so that people understand what that means and can get excited about it or opt out, is important.

Wes Winham:
That makes a lot of sense. If they’re going to be unhappy in any way, might as well opt out before all the expensive training and maybe they move and all that.

I would love to go, if you’re okay with it, go more down that list of principles. I love those examples, how those principles apply to being a developer. Would you be up for doing some more of those? I’ve got the list right here.

Melissa Leffler:
Sure.

Wes Winham:
You have a bias for action and deliver daily results. How does that reflect an engineering role?

Melissa Leffler:
Have a bias for action and deliver daily results is the core of what we do. Again, if you go to Bezos and a lot of what he says, until you get something out there for the customer to start using it, you don’t actually know what it has. This can be a scary thing for people, releasing an MVP, and what does that mean? It’s not good enough. What’s good enough?

At Drift, what we do is, that is the most important thing. The bias for action is get it out, don’t worry about everything you could possibly worry about, get the feedback and then iterate on it. On the technical side, we do, actually, I probably shouldn’t even say the number, we do lots of deploys a day. In fact, new engineers will deploy something on their second day to production. Our CICD pipeline is fantastic. Our ability to rollback is also fantastic, and we have to have some quality guardrails and things to make sure that works.

What we want to do is we want to ship something and get feedback and make it better. That is the centerpiece of everything.

Wes Winham:
Definitely sounds like daily results. Another one is, seek feedback, not consensus. How does a developer seek feedback rather than consensus?

Melissa Leffler:
I think part of that comes from the fact that we have small teams. Our teams have only three technical people on a team, one tech lead and two developers. Then you could have squads of multiple teams that have a customer advocate, a designer and a product manager. The seek feedback, not consensus means that, that small team owns its destiny. Sometimes, you work on something that affects other teams, but you don’t stop and have all the teams sit down and have a meeting and do a study for a month.

The way you communicate with each other is kind of crisp. Again, a lot of people are actually in the office. We don’t have a distributed team, and that’s a real advantage to the small team focus. you basically understand the implications, let people know, but move forward with your decision.

Wes Winham:
I would love to hear more about the team structure. That sounds really interesting. If I heard right, you got maybe two teams of three developers on a squad, or are there more than two teams on one of the squad, which includes support from design, product and customer?

Melissa Leffler:
Yeah. One team is three developers. Obviously, that can change a little if we have an [inaudible 00:07:28] or something like that. A squad is generally comprised of two teams. As we continue to evolve our product line and what people are doing, and where we need to focus for our product strategy, that changes every quarter. We’re on a quarterly cadence, where we figure out the business priorities and what the goals are, and each team is responsible for coming up with their goals.

The concept of the squad comes in because, sometimes there’s certain teams that overlap with each other, and then sometimes you’ll make a decision, does this team do this work or does this team do this work? That’s where the squad comes together.

Wes Winham:
Are these teams … You got team of three, squad of, sounds like nine-ish … Do you do daily stand-ups right now?

Melissa Leffler:
Dev process is a great topic at Drift. I’ll say that, I have a lot of experience in different companies, in different Dev processes, including lots of certifications and things. When I came in, I thought Drift would have a whole bunch of problems that we’re not having. All these small teams, how are we going to scale given the fact that we have 70+ engineers, how are we going to work on some of the larger technical debt or larger initiatives that span things.

A lot of the problems that I thought were going to happen, did not happen. For example, this concept of a squad is not actually that critical to how we’re doing things. We found, if you really break it down to the level of what you’re delivering for the customer, that squad-ness doesn’t matter. Each of our small teams just owns and does a ton of work.

For example, we have a team of three people working on integrations. They released Salesforce and Part-Up with one person working on it last quarter. That ability to really focus on what’s important and own it, and not have to go check with eight other people or three other teams, is one of the things that I think is unbelievably special that I didn’t realize how much it helps us execute and deliver daily results.

Wes Winham:
What I think I heard is that, the squad is actually not that important. It’s really that three person team. If there’s a daily stand-up, it’s those three people, not the larger organization or the larger squad?

Melissa Leffler:
Yeah. Back to daily stand-ups. We don’t do scrum here, we don’t do scrum, we don’t do kanban, we don’t do scrumban. What we are is, we’re an agile organization. We have a one-week cadence. The one-week cadence means every week, in different ways, the team checks in, everyone pretty much has a kanban board, and we have priorities, like I said, they come in from the customer advocates. We have voice of customer stuff, we have escalations, we have new product work. The team together gets together and decides that.

Guess what? That meeting’s usually pretty quick, because the team’s pretty small. By the team, I mean PM, design and customer advocates as well. We have a one-week cadence-

Wes Winham:
The one slice of a squad. it’s like team plus the support-

Melissa Leffler:
Correct.

Then what happens is, however you want to do it, you decide. When I say we are agile but we’re not scrum, we have a one-week cadence. We don’t make you do grooming, we don’t make you do story points, we don’t make you do retros, we don’t have the same ceremonies and artifacts that come out of a more traditional iterative process. We let the teams figure that out, and different teams do different things, and we’re okay with that, as long as they follow the high level process, which is, we have a customer advocate top three, and like I said, we have the weekly cadence.

Every two weeks, we do a check-in with higher level leaders. I go to a bunch of half-hour meetings. The team presents what they did and how they’re doing against their goals in a video format. Then at the end of it, there’s questions for discussion. We all watch the video together, which is usually three to five minutes, and then we have the next 20 minutes to talk about anything the team wants to, so they can provide visibility, they can get feedback, they can understand how what they’re doing fits into the broader picture.

That biweekly cadence has been incredibly special for me, because it allows me to see what’s going on with the teams, and remove barriers and give context where it can help.

Wes Winham:
You’ve got 20 teams doing those 30 minute meetings?

Melissa Leffler:
23 teams.

Wes Winham:
Okay. You’re doing, every couple of weeks, that’s most of your week, is in those meetings, talking about priorities and progress.

Melissa Leffler:
Yeah. I spend 12 hours a week in those meetings. Some of them, we’re trying something new this quarter, because what we do at Drift is, we have this concept of an engine. We run a process. We do an RCA on it, and then we make changes. This quarter-

Wes Winham:
An RCA is?

Melissa Leffler:
Oh sorry, root cause analysis. We basically, at Drift, we have this concept of engines where we run a process, we run a root cause analysis, and then we make some changes, and then we see how that goes. Just like we do when we release our product. This quarter, which just started, we’re actually changing the biweekly meetings a little bit, and I’m optional, and we’ll see. There’s some team meetings that I’ll absolutely probably always go to. There’s other ones, it depends.

I have to tell you, I love these team meetings. Being able to interact with the team and see what they did and be part of that conversation and remove any obstacles, is the high point of my week. It’s amazing.

Wes Winham:
You start off the meeting with a three to five minute video, is that inspired by the six page memo Amazon starts meetings with, everyone sits down and reads a memo together. Is that related at all?

Melissa Leffler:
I wasn’t here, so I don’t take credit for this process. I wasn’t here when we started it. I think that’s a great practice by the way, to make sure people know and they’re prepared. It’s fabulous. That’s a huge thing that comes out of that.

I think one of the things that happened is, it really forces everybody to not just start interrupting and talking. Hearing the whole story, getting the same information together. I think it used to be like, you’d stop on slide two, you’d stop on slide three and say, wait a minute, and then go off and talk about escalations or talk about the monitoring not working, as opposed to just, share the whole story, and then come back.

I think we were providing ourselves with that discipline to have better conversations.

Wes Winham:
That sounds like a great meeting. Everyone has shared contacts before we start jumping in.

Melissa Leffler:
It’s great.

Wes Winham:
I am fascinated by this team structure. You got three person teams. Presumably, the three people rotate the pager whenever their service goes down. Are you currently in a monolith setup, or have you split out the services yet? What’s that look like?

Melissa Leffler:
My answer to that is yes.

Wes Winham:
Both.

Melissa Leffler:
We have stuff that’s too big and we have a bunch of services we’ve split out. The way we do incident response is pretty cool also. We have incident commanders that are, and we always have two, so that there’s a backup, and then we have incident responders. We basically rotate that amongst a large set of people. It’s not just a couple devops people.

We have a very small devops team here. We all own the deployment pipeline. Basically when an incident comes in, the incident commanders figure it out, and the responders jump in. We have a whole process that kicks in where we then do a postmortem.

We’ve been recently doing some really cool stuff around service-level objectives, and having a golden path service, so that if for example, you go through our checklist and do the right things to make sure you can get the reliability you need, we have a 35 list checklist, where depending on your service, some things are incredibly important, then you can actually get out … You could put your service into the general incident response pool, once you meet a certain criteria.

It’s a real incentive to not always be on-call for your service. Many of our services are in the big pool. Also, as you said, we have a lot of services, but we still have some things that are too monolithic. Those things are part of general on-call as well.

Wes Winham:
If you just stopped growing so fast, you’d be able to catch up with technical debt.

Melissa Leffler:
I know. We’re growing a lot.

Wes Winham:
What I heard is, you’ve created an incentive for teams to follow the golden path. If they do, and they meet all the requirements, then they don’t have to handle their own on-call responsibilities necessarily. Did I hear that right?

Melissa Leffler:
You got it.

Wes Winham:
That is a really strong incentives, to follow the golden path.

Melissa Leffler:
It doesn’t get stronger than that. That 3:00 a.m. page.

Wes Winham:
These incident commanders, are they mostly routing to the responders? It’s like, they’re the first line and they say, oh that’s a problem with X, so let’s go to send it to person one?

Melissa Leffler:
Yeah, we always have responders on-call too. The incident commander is the person who’s responsible for assessing the priority, figuring out if anyone else needs to know, making sure that all of that happens. Right now, incidents can be created by our monitoring, or they can be created manually in Slack.

We have a command and it spins off, it creates a special Slack channel called War Room, with the number of the incident. It Does a whole bunch of stuff automatically. Then the incident commander is the one who’s responsible for figuring out the severity and what else needs to happen, in addition to the technical resolution.

Wes Winham:
That’s awesome. I talked to, Will Larson is the head of infrastructure at Stripe, and his position is that you really need eight engineers to have a con-call rotation that doesn’t wear people down. I’ve had this tension in my head, I believe that, I’ve been on-call. I know it’s a little like five, it’s kind of horrible. I also have seen the power of small teams, and I’m trying to figure out how you square those two things. It sounds like you all might’ve figured something out.

Melissa Leffler:
You brought up a really good point, which is, we have a bigger team. On a smaller team, I’ve done things where people are generally on-call for a week. You have one person who’s on-call, and then that person has a week rotation, and then sometimes, they have to switch a little time with someone else.

Here at Drift, it’s actually a much shorter time that you’re on-call. It’s a day, two at most. I’ve asked people if they like that, and they do. The scheduling seems to not be a problem. I’ll also say that our incidents that happen off-hours are not massive right now. We certainly get monitoring alerts that can wake people up at night, but I can’t think of any incident that started in the middle of the night.

Wes Winham:
That speaks to the power of that root cause analysis, to figure out how to avoid having events like that a future. Otherwise, they don’t go away.

Melissa Leffler:
Yes. Although the more we’re working on monitoring, like right now, we have noisier monitoring. Again, huge incentive to make that no false positives, because nobody wants to get paged at 2:00 in the morning and find out that it doesn’t matter.

Wes Winham:
That’s awesome. We’re at … I think we got down this awesome rabbit hole, and we’re talking about seeking feedback, not consensus. One of your other principles is pushing for high standards. How does that manifest in your engineering organization?

Melissa Leffler:
Pushing for high standards. I’m trying to think of a good example. I think for pushing for high standards is, we have a concept when we release a product of good, better, best. That goes back to what I said about, we try and get something out there and get feedback. The customer has to be delighted.

We often go back and make lots of changes based on customer feedback, once we get it out there. For example, we have the ability to … We feature flag stuff, we call it gates, we gate stuff, we do betas, we do all kinds of things, and we have all kinds of feedback channels with the customer. We get out there, and we look and see.

Let’s say we gave you something optional, you could turn on. If you turn it off, if we have a new feature and you turn it on, you turn it off, we reach out and talk to you about it, and try to find out what it is. Then, we make sure that every customer is going to have a great and better experience.

I think we get it out there quickly, and then we continue to iterate until we have it great.

Wes Winham:
One of the common complaints I see from engineers is they get this, the MVP bait and switch. Okay, this is the MVP, we’re going to iterate on it, and they put it out there-

Melissa Leffler:
And that’s it.

Wes Winham:
Next feature comes up, all right, what’s the next? They don’t get time to iterate. How do you make space for those teams to go back and take it from good to better, or from better to best?

Melissa Leffler:
That’s a great question. I think one of the things we do is, once we release something, we measure and measure and measure. If we have a lot of people using something, that just comes in as part of what we’re doing. For example, the CA top three, CA means customer advocate, every week, the customer advocate is in there saying, here’s the top three things we need to do for the customer.

That is part of the work that the whole team looks at when they kick off the week. That stays front and center.

Wes Winham:
You just, by providing a better feedback channel, and what’s going on with customers, ,and with data that allows you to create space to go back and iterate on things, because it’s just obvious? Is that kind of …

Melissa Leffler:
It does. I answered that for more features. We also have, as I think every group has, the concept of tech debt. The product process here, like I’ve said a couple times, the team owns it all. If new features are coming in, the team will do what we call, they’ll define the job to be done, then they’ll do a story time. The three technical folks and the broader squad people that I’ve mentioned, customer advocate, designer and product manager, all get together and talk about something, and the whole team does that together. Then, based on a one pager, the initial thing we write as a one pager that says, what do we want to build?

We came up with the concept of a technical one pager also. For some of the tech debt that we need to do. We made sure that each of those technical one pagers talks about the impact of customer. We don’t want to rewrite the widget because we want to rewrite the widget. We don’t want to move-

Wes Winham:
It’s not pure.

Melissa Leffler:
Yep. We don’t want to move to React 16 because it’s fun, we want to do it to increase reliability, we want to do it to increase performance, we want to do it because we can’t do localized strings without this, et cetera, et cetera. We always tie all of our work back to the customer. That’s how some of the tech work gets introduced as well.

Wes Winham:
You’re putting the customer at the center of your technical debt reduction. That’s pretty amazing. I heard in there that you do a one pager for your products, and you have a … You define a job to be done. Do you use job stories? How do you structure that? I’ve sometimes struggled to figure out how to express what a job is. Do you have a specific technique?

Melissa Leffler:
Yeah, we actually just use it in Confluence, and it’s just called the Job To Be Done. Then we have a couple high level guardrails of what we’re trying to accomplish, and then the team just sits down with that.

Wes Winham:
That’s the one pager, and then that helps you, and you try to make that one pager customer-centric as far as, what does this thing do for the customer? That’s awesome. That’s how you push for high standards and get from good to better to best. How do you stay scrappy and frugal?

Melissa Leffler:
I don’t know to talk about that, what it means for every individual developer, but as an organization, it goes with some of the people we partner with, and some of the technologies we choose.

For example, there’s lots of great monitoring solutions out there. Some of them are very expensive. We started doing all this really cool tracing performance benchmarking, could cost hundreds of thousands of dollars. I think whenever we make any kind of technical decisions or look at what we’re doing, we keep all of that in mind.

Wes Winham:
Make sure that the price for monitoring equipment or tools is commiserate with the value you get as an organization? Makes sense. How do you, because I know, monitoring especially can be really expensive. You can spend as much money on Splunk as you want. They will take your checks.

How do you exemplify the principle to be a curious learning machine?

Melissa Leffler:
There are so many examples there. I don’t even know where to start. I personally have learned more, the six months I’ve been at Drift, that I have in the last 10 years of work. I try to learn all the time. I think that the organization is very open to new ideas in general, whatever it is. The way we look at everything is, we experiment, we look at the data and we learn.

I think that one of the most important things that we learn from all the times the customer. When I look back at organizations I’ve built to be successful in the past, I can’t believe they haven’t been as driven by customer data.

There’s always more analytics you can put in, and more looking and building the reports to see what’s happening. Often in the past, I made the trade-off to focus on new functionality that you absolutely needed in the market, to be first, to, the next quarter is the most important quarter, et cetera, et cetera.

I would say that anybody who’s building a product should spend time really figuring out what data is the most important thing, what makes your customer successful. There’s different things that make a Drift customer successful. We maniacally look at those numbers, maniacally, and we’re always looking at what that equation is too, and we’re always checking it to make sure it’s right.

We release a new functionality, we maniacally look at that data. I think, we try something, and then we learn, and then sometimes it was right and sometimes it was wrong. Almost the most important thing at Drift is the learning.

Wes Winham:
It seems like your curiosity is also very evident in your development process itself. That’s clearly not, you didn’t pick up a book and copy that, that was something you’ve evolved to. I would love to hear more about this customer advocate role and hear … They bring three important things every week to the team. What else is that person doing for the squad?

Melissa Leffler:
Yeah, the way customer support is organized here is, we have three different tiers of tickets. We have front line, we have second line, and then we have third line, which means it gets escalated into engineering. These folks work in the customer group, but they’re embedded on the teams too. They sit with the teams, they sit right next to the teams.

They basically are always bringing forward any new conversations with customers in our support channel, about functionality that that team owns. That’s where, it’s not really a spot for escalations. The escalations are handled, they’re escalated to the team. We use JIRA, and the team goes through that queue also. The customer top three is, they are literally always in customer conversations and gathering that up and saying, here are the most important barriers to our current customers.

Wes Winham:
That sounds really valuable. I’ve been in that position where there’s literally a wall between customer support and development and communication, that is hard. Maybe there’s one channel of communication between the two teams. This sounds like you’ve got a dozen communication channels between individual levels.

I’ve also struggled sometimes, when I am out being the person closest to the prospects, closest to the customer, I feel like I’ll remember to say sometimes, I don’t have that constant stream of communication. Is that something Drift has had since the beginning, or is that something that’s part of the culture?

Melissa Leffler:
Yes. I’ll give another example of something that is one of the favorite things that I do here. Small though. Every single person who comes into Drift does support duty. They do one hour every month of support duty, and you can be sitting there and … We use Drift for support. You can be getting there and getting these chats coming in, and not know how to do it. It doesn’t matter. You’re sitting with the other, the front line CAs, you’re asking them questions, you’re learning about the product. A chat will come in, they’ll assign it to me. I’ll say, hi, I’m Melissa, what can I do to help you today?

It’s great. It’s great to have that customer connection. Every single person from the CEO down.

Wes Winham:
It’s better than even one degree of separation, zero degrees of separation. You are talking right to the customer. It’s amazing. Switch gears, I’m going to talk about, there’re a lot of organizations right now undergoing agile transformations. there’re not as many startups, but I’ve seen some people claim that you really got to do an agile transformation from the top, from the CEO. Is that something you agree with?

Melissa Leffler:
I agree with it from the perspective of, the CEO has to support the way that you can give visibility into roadmap from agile. I believe that agile comes from the teams themselves. It’s my job or leadership’s job to make sure the company gets what it needs from engineering. That transformation doesn’t work if it comes from the top. It has to come from the team.

Wes Winham:
You’ve recently read The Coaching Habit, which is one of my favorite books, and is on my list to reread. Could you maybe give your light summary of that book and why you found that to be a useful book for a engineering leader?

Melissa Leffler:
The Coaching Habit’s a quick read, a lot of common sense, like a lot of books, but it just reinforces the basics. I’ve been coaching people and having one-on-ones for a long, long time. It’s still one of my favorite books, because it reminds me of a couple things that I don’t do well. One of them is listen, and leave space, and leave space for the person.

It starts with, it’s a concept of seven different questions that you ask, and it starts with the foundation question, where you ask what’s happening, and what’s on your mind, and then the next question is, the AWE question, and what else? I think that to me, to keep reminding myself, someone will come and say, oh, I’ve got this issue. Often, when you have the full discussion, that’s not really the issue.

What you can do to most help them is say, and what else? What about that as a problem? Just let them take the space in their mind to think it all through, and then they do a great job figuring out what they’re trying to solve and what they want to do. They don’t need me to jump in.

The whole concept of servant leadership is something that I think a lot of people can struggle with, especially at a smaller company, when your role is to jump in and do a lot of things yourself too.

Wes Winham:
Yeah. You’re also doing.

Melissa Leffler:
Right. When do you jump in, when do you not? When do you let a team flounder a little and have some failures they can learn from, and when do you not? What I really love about The Coaching Habit is, it really helps you understand whatever your decision struggles are. If you can have those kinds of conversations with your people, you’re having the most valuable conversation you can about helping them learn and scale, and also providing value.

Wes Winham:
I love the, and what else, question. I feel like that’s the magic question. I think in medicine, doctors talk about the doorknob question, where someone’s leaving the room and they finally turn around, but we have the ability to ask, and what else, so we can get it without all the doorknob stuff. That’s awesome.

Melissa Leffler:
Yeah. It’s great.

Wes Winham:
What is, something regarding software engineering, maybe a belief that you’ve changed your mind on recently? It sounds like you’ve done a lot of learning over the last six months at Drift.

Melissa Leffler:
Something I changed my mind on is power of small teams. When I’ve been in other organizations, and I think about how much coordination is needed, if you split things up into different teams, it seems like it would be better to have one team, especially if you’re at a smaller company. You go from seven people to 10 people to 12 people. When do you split it up into two teams? The amount of coordination between those teams is going to kill you.

What I found it Drift is that, the amount of coordination doesn’t actually kill you, because it’s one small team communicating with another small team. If those teams are clear on what they own, they don’t need to have big coordination meetings and figure out dependencies across milestones, because it’s two people talking about it. I’ve been in situations where you have so many agile teams, it’s almost like microservices.

That’s the problem. If the exact contract with the microservice is data in, data out, and it’s clean, that’s great, but it’s never that perfect. As soon as it gets a little messy, every microservice affects other microservices. I feel like it’s the same thing. You create scrum of scrums, you create all this process, when if you keep the teams small, they can facilitate that communication really quickly. It follows the three principles of the agile manifesto. Small teams allow you to put people over process, and it focuses on communication, not tools, and it’s unbelievably liberating to the teams and productive.

Wes Winham:
It only took us 25 years to get from there to here. To go all the way back around.

Melissa Leffler:
Yeah. Every dev process is just something reinvented.

Wes Winham:
Yeah. I love that you’ve been able to keep autonomy at those teams. I feel like that’s the thing that creates dependencies is lack of autonomy. If I really need to get someone’s decision on something, then I really do need to coordinate with a scrum of scrums, but if we can avoid it, we can move fast.

Melissa Leffler:
It is.

Wes Winham:
We have a lightning round. I’m going to give you a short sentence and you’re going to give me your quick reaction in about 60 seconds. Are you ready for the lightning round?

Melissa Leffler:
You bet.

Wes Winham:
Let’s do it. What advice would you have for an engineer looking to get hired on one of your teams?

Melissa Leffler:
Self-Awareness, curiosity, passion.

Wes Winham:
What’s a mistake that you see candidates making consistently that they didn’t realize they’re actually making?

Melissa Leffler:
I think when a candidate comes in and represents themselves about the exact role they want, and I want to manage managers, I want to do this, as opposed to, what do you really want to do? What drives you?

Wes Winham:
Walk me through the interview that had the most lasting positive impact on your impression of the candidate.

Melissa Leffler:
I’ve interviewed a lot of great people, but this was actually years ago. I used to do this thing called a tech talk. It’s pretty similar to the things we do at Drift. The concept is, if you have a developer going onto a team, whatever they do, they’re going to be working with other team members. You want them to just talk about something they know, and then you can ask questions like, did you think about scalability, this and that.

I had a woman come in, and she started talking about a bug she fixed. We don’t want it to be pie in the sky, and I just kind of groaned and said, “Ah, it’s a woman. She picked something really small,” so on and so forth. It was amazing. She went from, I went to fix this bug, to this huge scalability, architectural decision, how to replace the engine while the car was driving. It was the most amazing technical talk I ever heard, and we hired her on the spot.

Wes Winham:
That is an amazing bug. Melissa, thank you for being on Scaling Software Teams.

Melissa Leffler:
Thank you Wes.

July 30, 2019

 

‍