10 Ways to Get 110% Out of Your Dev Engineering Teams

Please welcome our panelists to the stage.

CEO of Drift, David Cancel.

VP of Strategy at Salesloft, Sean Kester. And co-founder and COO of Salesloft, Rob Foreman.

Awesome, super excited to be here today. This is a packed room. Everyone having a good day so far? Yeah.

Cool, cool.

Well, we've got a great panel today and I'm really excited for them to be able to share with you guys The topic is going different tactical ways to get 110% out of your product delivery teams. And so to my left is David Cancel. Anyone familiar with David? Right?

No.

If not, he's CEO of DRev, former CEO at Performable, which was acquired by HubSpot, where he ran product there. He has an awesome podcast. Called Seeking Wisdom. My favorite piece of that podcast is the one which is overcoming self-doubt, which a lot of people deal with. And then all of us at Salesloft are big fanboys of his podcast as well. And then—

5 stars only.

Yeah, 5 stars only. And then we have Rob Foreman, our co-founder at Salesloft and COO, former founder of a company called HireIQ. Fun facts about Rob, he's got 5 kids. And he wrote his first program on a VTech Toy PreComputer 2000, if anyone knows what that is. So just to get a little bit of understanding of the audience, who here runs an engineering team with more than 10 engineers? More than 20? More than 100?

Cool.

This guy. So awesome. So I want to give Rob and David a chance to introduce themselves. And kind of what they're responsible for in their initiatives, and then we'll dive in.

[Speaker] Sure, so I'm David Cancel, CEO of Drift. We help businesses connect with their customers on their website, largely sales teams and success teams. I've been an engineer, though most of my engineers don't believe that at this point. Started out as an engineer and founded, this is my 5th company, and before this I ran product, engineering, design, and all that kind of stuff at HubSpot, grew that team to around 200 until we went public and then started Drift.

Cool. My name is Rob Foreman. And at Salesloft, I have 3 roles as a business partner, as a technology leader, and as an operational manager. And I head up product and engineering support and the operational people operations. And Salesloft is— The easiest way to turn targeted accounts into customer accounts through great sales practices. And my background is in technology. I started programming as a kid and tripped into it. And at some point realized how much I needed sales and marketing and was fortunate enough to meet Kyle and join forces.

Awesome. And so, you know, both these guys got unique backgrounds. They come from very technical responsibilities and some technical leaders. And so they've been on a variety of different teams, so they have a lot of experience with some of the good, the bad, and the ugly. And we're gonna try and pull some of that knowledge out of them today. So the goal is really to share some actionable tactics that you can take home to help empower your teams to ultimately increase ownership, accountability, and empower them through autonomy. And so before we get started, Simon Sinek has this book that says, "Starting with the Why." And so I wanted for them to really set the stage on the why for having a team, why creating a team, motivating a team, and ultimately trying to get them to perform beyond what they thought was possible. So David, we can start with you. What's your why?

What's my why? Mistakes. I think I started out my career trying to follow conventional wisdom on how to build teams, how to motivate teams. That is largely a push. Kind of approach, kind of push people, and kind of hated the cultures we've created, didn't like the results, and so I started to try to optimize and change how we were doing things and move to this kind of pull model where I focus on kind of personal progressions and getting people to kind of pull the company along. And it sounds subtle, but it changes everything that you do in the way that you manage, build, recruit, motivate, and do all that. The results were just amazing. And so we keep doubling down on this kind of servant leadership kind of approach. And it's been kind of the way that we do things for the last 10 years.

Awesome. And I know servant leadership is something that we preach a lot at Salesloft. And it has a lot to do with the founding beliefs that Rob and our CEO Kyle have. And so I think we can start there with your why.

Why? Because we're put on Earth for a reason. And it's too short not to figure it out. I mean, I think that's the level I like to start at, which is that so many times I see people delaying figuring out how to make an impact and how to be a part of something and how to feel alive and are going through the motions. And so two things, two stories, I guess I'd say on that. One, I was on an amazing team that I didn't know why. I didn't know what made it amazing. I was working at Verizon on a core infrastructure team, and I remember being at— we're at happy hour, and everyone else was probably much more fun. I was kind of reflecting on it, and I was, I was asking like, what, what makes this special? We all knew we had something special, and especially, uh, in a large company environment, there are great people, but oftentimes the density is lower, so you don't find each other. But we had found each other, and then I asked them, you know, what makes it great? And None of us came up with anything, and so we just had another beer. So later, at my last company that I founded, I was coming home just feeling completely drained and demotivated. I had hired most of the people I had worked with. I didn't know what I was doing wrong. And my wife would ask me, good day, bad day?

Depends.

And I was like, eh. And then after 3 months, she pulled out a calendar, and she had put a happy face or a sad face, and it was 90 sad faces. And so it was— she said in a— I don't know. It was in a real inspiring way of like, you're better than this, or you're a worse person, you're a worse husband. I don't know how it came out with a good end to this, but I have kids, and so it was like, I can't segment between home and work. It's like I'm one person. And so why does that matter? Because team dynamics matter. If you're on a great team and you have a big problem, then it's energizing. And if you're on a bad team and you have a big problem, it's not. And so the why, rather than waiting to find out how to live an energetic life, it's that I think teams are— that's a lot of the answer. And Kyle and I, we didn't invent any of this stuff. Patrick Lencioni is a big one, a guy that we read. And he talks about the team dynamic being a great way to make a difference in the world now. Because that person that you're interacting with, that you know how to see them, they go home and they interact with other people. And so that's why.

Cool.

It's powerful. And so I wanted to kind of lead this into talking a little bit about process and tactically how you can take that why and insert that into the way that you run your teams. And I know there's a lot of schools of thought around process and methodologies. But one of the things, David, you talked about is autonomy and accountability. Can you share a little bit about what that means? How do you allow someone to be autonomous but also hold them accountable? But tactically, how do you hold them accountable to those things?

Yeah, so I mean, that whole thing started because as an entrepreneur, I wanted to create the environments that I want to work in. And as my wife would say, I don't like being told what to do. So I guess that makes it good for being an entrepreneur. So I wanted to be in this environment as a developer that you actually can build something, have control and say on what you do, and it's just not because someone said so. And so I tried all different ways to create kind of autonomous environment, but I always felt like people would take autonomy and kind of like, I don't know, bastardize it and say like basically they don't want any accountability. And to me, like the autonomy and accountability are two sides of the same coin. And without accountability, then it's just anarchy. So people just want anarchy. And but if we can design a system where we have accountability and accountability that's mapped back to the customer, then we can create this environment where people have to make their own decisions, get to prioritize what they're working on from an engineering standpoint, make a decision tactically of like, are we fixing bugs this week, this month? Are we investing new features? If so, at what cadence? What are we doing? Are we doing infrastructure work? You take all those things that you usually argue around and that you want to create process and constrain because you don't want them spending all their time doing infrastructure like all of us engineers like to do or not paying attention to customers and you let them decide. But as long as the metrics that you look at map back to the customer. That's a subtle thing that took me a long time to figure out. Whatever you incentivize from a metric standpoint is what you're going to get. That sounds very simple, but most of us design metrics for our teams that are totally opposed to the customer, right? Whether making the customer successful, the prospect successful, they have nothing to do with that. And then we wonder and we spend all our time building process to try to enforce good behavior when our metrics are not aligned with good behavior, right? So we created all these ways to really look at each product and engineering team and say that they're doing the right thing for the customer. So examples would be, from a sales standpoint, how many things that are on loss, if you look at win-loss, how many losses, are we getting better at the objections that are coming up from a sales standpoint? And if so, how fast is that happening? How many of those things are happening? From a support standpoint, are we driving down call drivers, which, and most call drivers are, some sort of experience issue. Like if you take out the obvious bugs, it's some sort of experience issue that you're dealing with. So that involves engineering UX and kind of rethinking some of the things in the product. And so those things to us align with a better customer experience. And if we're looking at those things, then we shouldn't have to worry about dates and release versions and numbers and all this kind of stuff because that's a way that we're trying to put control, right? When someone's arguing in a company about like, hey, we need a roadmap. I need a roadmap, I need some dates on this. What they're really saying is like, I don't have transparency into what this organization is doing.

You don't do dates?

No, no, don't believe in dates. We can have that argument.

Let's do it.

The date is our, you know, I've done dates forever, but like dates are, you know, a company instrument, right? They're not, they don't have anything to do with a customer usually. Customer cares about being heard and being serviced and delivering the right solution to them. Right.

And so in what period of time?

What's that?

In what period of time?

In what period of time was undefined.

So like we, what we do is try to, uh, we clearly differ on this.

Yeah. Separate, you know, a company event, like a marketing event or sales event. That I completely agree from a product release. Sure. So we have people running on the product side and they're releasing daily. And I think, I think separating the separation.

Yeah. I think separating product delivery.

Yep.

From marketing is key. I can't go all the way down to the there are no dates. We tried it. Burn down you wrote about?

Oh yeah, burn down.

Printed out, went and put it on the wall. It's like, let's do it.

It's all in the implementation yet.

Yeah, I've totally— I was going to blame you, but I'm sure I screwed it up. I guess the part that I—

Where was the difficulty?

It wasn't going fast. And so one of the ways that this talk was promoted was, is your team kind of failing to release or falling behind or something like that? And I think it feels too idealistic to not have dates. I think that one of the questions, one of the things we drive to is, who creates them? So if we have somebody— if you give me the date and I ask you a bunch of questions, you're like, all right, you're comfortable with the date, and then you miss it, and then we do that game again, and then we do that again, something's broken.

So either you don't know what's going on, perhaps, or you don't understand the problem well enough, right?

But the person I'm asking, that's their date. I asked the team— the team creates the dates.

Yeah, but the team is not the customer, right? And so in the process of shipping, and one of our metrics is, and one of the things our guardrails is, that every team is shipping daily. So there is no—

Yep, completely agree.

There is no, it's not shipping fast enough. But the product manager, the engineer, whoever, the designer, the salesperson, the CEO, the COO, they're all not the customer. So a date predicated on whatever you think is right is usually just them from—

Not a date from on high.

But even from the product manager, because they don't know.

So the way we've landed is that the person who— usually, so if we're creating something, there is a role that tends to—

Pursue, yeah.

Yeah, that has the biggest impact on that. And it's the guy writing it kind of line by line, or woman. And I think there's a skill with estimation. And so if we're bad at estimating, then I I push them to get better at estimating. [Speaker:JASON M. LEMKIN] Cool.

We could keep going on this.

[Speaker:JAKE ARCHIBALD] We could keep going on this.

A couple things. So tactical things that we both just glossed over. We ship multiple times a day. Sounds like you guys do too. That was the biggest single forcing function for test-driven development. So as far as a takeaway is that if you want to get better tests— and this is counterintuitive— I found that we were doing tests. We did tests from day one. We have great test coverage. It's helped a lot of things. But you can get test coverage two ways. You can just get coverage and it's bad, or you can get good ones. As soon as we wired it up, and when tests turn green, it ships, we took it seriously at a different level. And so that's, I guess, one takeaway would be move the team to ship faster.

Absolutely. For us, it was daily cadence— intern, co-op, full-time, anyone, first day, ship, right?

Yep, exactly.

That's awesome. And so on that same line, you want to motivate them to push faster. You want them to do that. Now, pushing versus pulling— and you talked about this— how does that play into it? Because I think the way that you've explained it to me previously is that you can either push someone to go somewhere faster, or you can help the organization pull them in that direction through momentum, right? Can you share a little bit more about that philosophy?

Sure.

And you always let him go go first. I thought—

I know, I thought I was—

you're gonna favor me.

Yeah, I'm gonna, I'm gonna hear this later.

Yeah.

Um, Rob, what do you think?

No, no, no, no, I want to hear this. Push, push, pull, push, pull.

I mean, I've heard you talk about this.

Yeah, it's, you know, one caveat is like it's more work, so like it's exhausting. Uh, but basically what you're trying to do, or what we're trying to do, is figure out what someone is trying to personally achieve. Like, what is your personal goal? Which is a hard thing within engineers, right? Because it's hard— it's hard— it's easy, let's say, with a sales and marketing person who clearly wants something, right? Some progression in a career. It's harder if you're a maker of anything, whether you're an engineer, designer, what have you. Uh, we're trying to figure out like what's motivating you, what's next, what's the next big challenge that you want, and we're trying to gear your work towards that. And the reason that we're trying to do that is when I've— when I've accidentally had that happen, people become superpowered. And so going back and saying, why was that person so great compared to this time versus last time? It was because they were trying to do something that was about their personal why.

The intersection of—

Yeah. It becomes magic. So we spend a lot of time trying to figure out personal progression, one-on-ones for everyone on the team, intern, co-op, everyone. And it's geared around what are they trying to get better? What's the next thing? Because we always felt like when people come to you, when someone comes to you and is like, oh, what's next? What's the next big challenge? That should be a sign that you are failing as a manager. Right, because you should be anticipating what is the next thing for this person, and sometimes that involves pushing them into new challenges. But anyway, once we did that, we noticed that they would pull— they created their own momentum because they were driven by their personal why that would pull the rest of the team and the company with them, right? Because they were trying to get things done for their own reason. Yeah, not just the business reason.

Cool.

Now this one, I've been holding this one for you.

OK, this is a special one.

And it's around culture.

Well, and before we leave that, though, I'd say the flip side of that is that I guess I would lean more a little bit to the other way. When you mentioned that if the manager isn't— like, there isn't that challenge, then they failed, essentially. That feels like push, right? So I feel like it's both. For the leader of the organization, we do weekly one-on-ones with our engineers, with everyone on the team. I think there's a way to do that with excellence, and there's a way to check the box, and I would encourage everyone to do it with excellence. But then creating that push, and the analogy that I go to is look at any fantastic sports team, and there is a push where— the coach is never satisfied. And so leaning, developing that in your leaders takes, to your point, it also does take a lot of time and effort.

And it also goes into the why, right? I mean, starting with the why.

Why are they here? It's hard. No one wants to have those conversations.

And then for Rob, I know internally at Salesloft, culture is huge for us. It's the number one thing. That's our biggest competitive advantage and the reason that we've been able to scale our business so successfully. Can you talk a little bit about culture as it relates to a business and then specifically on the engineering team? [Speaker:JASON M. LEMKIN] Sure. [Speaker:AUDIENCE] And how those dynamics play as we've grown from—

[Speaker:JASON M. LEMKIN] Yeah. I think it's good to define culture. Some people think culture is how you dress or the ping pong tables or the food you have or what meals they get. We talk about culture as values consistently applied. And so really the better question is, what are your values? And at Salesloft, we have a set of values around team over self and glass half full and things like that. Then the engineering team and the product delivery team as a whole also has a set of values around coding beautifully and shipping quickly and really balancing that tension of speed and quality. And then creating mechanisms for that, so we have two I found an aluminum cube and a tungsten cube. One is super light, one's super heavy. So it's kind of just a party trick. And the aluminum cube became known as the cube of shame. If you blow up production, then you get the aluminum cube. And the heavier, weightier tungsten one, which is really— it feels cool in your hand. It's like something you keep on your desk— is around an act of leadership within the team. And so if they do something— really neat, then it gets awarded. An email goes out, and it moves desks. And the kind of fun thing is that when you see it on the desk, you actually can't tell which is which, because they're just both little silver cubes. And it helps us not take ourselves too seriously, right? Rarely do we push something and somebody dies. I doubt many companies here that happens. And so learning from it and then moving on is a big part of that. If you can't own that, then I think the culture would be very hard to scale long-term. Because a key part of that, and you talk about this in your podcast all the time, is learning, the ability to learn. And our own kind of demons are often the biggest challenge to that, owning our own mistakes and knowing where we're weak.

So do you fire based on values?

Yes.

Good. Very few do. So I think that's the key, right, to find your values, but almost no one fires based on their values.

Yeah.

Right? Especially if you have a high performer, engineer, salesperson, what have you.

It's super difficult. I don't take any pleasure in it.

No.

The way— so going back to why, right, is just because someone isn't our values doesn't mean they're not a good person. And if I believe that a human desire for connectedness is core to who we are, then— and that person is not connecting because they don't our values are unlikely to change, and so releasing them to go find a better place, and it sounds a little bit Pollyanna, but I've walked through it a number of times, and have stayed in touch with people after the fact, and kind of walked it out, so it's super difficult, but I think if you believe it in your heart, and you actually love the person on the other side of the table, then you can do it. And then your values begin to mean something.

Totally.

And everybody else knew that you waited too long.

Yes, every time.

Every time.

And David, I know that you've got some pretty specific views on ownership, especially on an engineering team, and maybe controversial views on product management and how that plays into it.

Sure.

How do you empower your engineering teams to have ownership? And do you have product managers? Do you believe that they should be part of that process?

Yeah, definitely. This is a longer thing. I mean, I have lots of controversial views on that. One is that I don't like hiring product managers. I don't like hiring people that have been serial product managers typically, right? Because I find in my world that just product manager as a title is this amorphous thing, right? Your company, it means something different than my company, and his company is totally different. And I might not know the difference between a product manager, program manager, or project manager. Maybe you do, maybe he doesn't. And so like these things are— it's hard to, to have someone like an engineer or salesperson where you actually know exactly what they do and what they bring. So like, so we tended to build our product managers out of different functional areas. And from an ownership standpoint, we've always felt like if you want autonomy, then part of that accountability is that, that, that small engineering team has to own the whole thing, including overnights. Including, you know, the design process, dealing with customers. And it really was like an engineering-led team, and the product manager, designer was there to help that team. But the engineering team was making the decision on new feature, no feature, bugs, infrastructure, what have you. But they were also being held accountable on moving, sales objections, customer support issues, uh, new market expansion, revenue, churn, all that stuff. And so we put that on top of— but not dates, not dates, everything with not dates, money and churn, but not, yeah, That's interesting.

One of the ways we've begun to hold our engineers accountable is through these demo days.

Yep, yep, huge.

And Robbie, would you like to share kind of what the—

Yeah, it's fantastic. Until I saw it, I would have thought that it was too often or so. Yeah. Every Tuesday at 11, we do, everyone in the company, 130, every development team comes up and demos what they built in the last week. And 4 minutes each, click right through them. Don't really do Q&A. We encourage— we do lunch right afterward for the whole company, and we encourage people that if you have questions, because sales 100% of the time does—

Can I sell that yet?

Yeah, exactly. They've backchanneled screenshots somehow. Totally. They'll go to the product owner or anyone on the team, really. And so it encourages tons of cross-team Collaboration. But then knowing that you're going to show something creates a positive forcing function that— it's like a management team having a board meeting every quarter. You have to stop and shift gears and think and produce something and then go back in. So yeah, that's what we do.

Yeah, we did the same thing. I did it at HubSpot. We do it monthly there.

We started with monthly.

Yeah, we do it weekly now.

Do you? Okay.

Yeah, but we did it monthly. The entire company would show up in some way, largely sales, marketing, support, account management. And I didn't know what to expect at the beginning, but it was like the best, in lieu of dates, this was the best thing. This was the best social pressure.

You should try dates and all hands.

Never. And then we tried a couple, we had a couple guardrails. We said like, it was like you only so long, but no demo where nothing that, oh, it works on my laptop, it's in staging, it's in test or whatever. It has to be used by a customer, right?

Yeah, we started with that. I think I got it from you.

Yeah, and that's why we monthly made sense for that.

Weekly. Oh, gotcha. Yeah, weekly will do. It has to be real, can't be— yeah, you know, um, but it can be on the laptop and, um, because sometimes it can take a number of weeks to get the pieces together. Another— I can say another 10 ways, one of the ways to get a lot out of your team is get sort of feature flagging.

You guys do this? Yep.

So that's a huge thing so that you can get it merged into master and out to production. You know, kind of you're building it one little piece at a time. Yeah. And that demo, it goes part of demo.

It was kind of one of the largest things we, we invested in and we do and we continue to do, which is like feature flagging so you can do the daily cadence, right? Hourly, whatever cadence, and so that you can target different groups within the— within your customer base that are using that. And then the thing that you need to remember when you do feature flagging is like you got to build the analog for support and success, right? Because they need to know what versions their customers are running, right? So at any one time they might be running, you know, with HubSpot we would, you know, 15 different versions of things, right? Because we were an all-in-one platform. Yeah. And at Drift it's pretty similar.

Yeah. So we have an internal dashboard with all the flags and states and things like that that support and success can see.

Yep, yep.

And it also measures when sales can start talking about it.

The other thing I'd say with accountability, a bit that's counterintuitive and maybe a little bit controversial is I think most of our companies I talk to, 3 out of 4 have problems with some of their teams, engineering teams. And so I think the idea of Scrum and cross-functional I think there's an inherent flaw in it. And it goes back to what you were saying about accountability. And it's really tricky to solve.

Yeah. I hate Scrum. So—

Yeah. But I mean, it could be anything, right? It could be. You're talking about cross-functional team, right? So a team, they don't have a date, but assume— are all your teams functioning at the same level? Are they, is the question.

What's that?

Are all of your teams functioning at the same level?

No.

Performance. So some are better than others.

Yes.

Right. If you have a low-performing team, whose fault is it?

Depends, right? So like a low-performing team for us might be it's a new problem space, right? So we're going in, so we don't know what good performance looks like in that team. Or it could be an existing space. In that case, it's the fault of the leader and the manager, whoever it is, right?

Like there's a leader.

It depends. Yes, there's a leader.

Yeah, so most— what I've seen a lot— most agile teams, cross-functional, You could do Scrum Master, whatever it is, but there isn't a leader. It's just egalitarian, which is beautiful. I think engineers love the idea. In practice, I think accountability— if more than one person is accountable, then no one's accountable. So if you have a 7-person team, so no one's accountable.

[Speaker:JASON M. LEMKIN] Every team for us is organized around a tech lead. A tech lead's accountable, right? The ultimate accountability. And no, I signed the Agile Manifesto back in the day, and it was great movement from waterfall, but I hate it in this context. Yeah, because it's divorced from the customer. The customer is nowhere in that, in the agile planning process and points process. And it kind of— the teams that I would deal with, like, it taught them to optimize for the wrong metrics.

Gotcha.

You know, even though the customers were mad and you were mad and this guy was mad, everyone was mad, but the engineering team was like, I'm doing great. It's like, why? Yeah, it's like, because I look at my velocity chart. Exactly. What? Your velocity chart? And then it's like, I committed 12 points and I said I was gonna, uh, I only, I committed 12 points, I actually delivered 14 points. And it's like, so what does that mean? Yeah, but we didn't actually do it.

It sounds like you're talking about there's kind of proximity to the customer.

Yes.

I think the other side of it is HBR had a, had a, an article around, uh, 75% of cross-functional teams— so this isn't specific to engineering, just cross-functional, like matrix orgs in general— they considered dysfunctional because they had these 5 criteria around running a project well, and they didn't meet the criteria. Set forward a project plan, they did include dates in it, so hit dates. Hit dates.

Hit the ACRF. Yeah, yeah, yeah.

But if you measure, if you looked at a bunch of teams, you'd say according to a lot of this criteria, they're dysfunctional. And so how do you drive accountability? And so that's what—

That's why we would localize everything. So it'd be like a product— a team that owned a product would be that engineering team, the product manager, designer, but also the product marketing person, right? Would actually be embedded within that team. And they were in charge of communicating to sales and sales enablement and dates that the salespeople may have needed. But like, uh, all of that kind of stuff. And we localized all of that instead of being cross-functional. We made it local.

Yeah. Yeah.

Awesome. Well, we're, uh, we're out of time unfortunately. So, um, if, uh, if anyone wants to get in touch with you, Rob, and ask you more questions, how can they do that?

On Twitter, @robformanatl, as well as rob@salesloft. Cool.

David?

Dcancel on Twitter and dcancel@drift.

Awesome. Well, thank you both for having us. Thanks everyone for showing up. My name's Sean, and I hope you have a great rest of the day.