10 Ways to Get 110% Out of Your Dev Engineering Teams
David Cancel and Rob Forman discuss how to get more from engineering teams: move from push to pull leadership, ship daily instead of hitting rigid dates, use feature flags and weekly demos for transparency, and fire people who repeatedly violate your values.
Chapters
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?
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, Salesloft are big fanboys of his podcast as well. And then on the other five stars only. Yeah, five stars only. And then we have Rob Forman, our co founder at Salesloft and COO, former founder of a company called Higher IQ. Fun facts about Rob. He's got five kids and he wrote his first program on a VTech toy, pre computer 2000, if anyone knows what that is. So just to get a kind of 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.
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 fifth 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 Forman and at Sales Loft, I have three roles. As a business partner, as a technology leader and as an operational manager. And I head up product and engineering support and 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 both these guys got unique backgrounds. They come from very technical responsibilities and 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 going to 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. It says starting with the why. And so I wanted for them to really set the stage on the why for having a team while creating a team and 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. You know, I think, like, I started out my career trying to follow kind of 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. And 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 has a lot to do with the founding beliefs that Rob and our CEO Kyle have. And so I guess 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. 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 were at happy hour, and everyone else was probably much more fun. I was kind of reflecting on it, and I was asking, like, what makes this special? We all knew we had something special. And especially 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 I asked them, 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, And I was like. And then after three 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, a real inspiring way of, like, you're better than this, or you're. You're a worse person, your worst husband, or. I don't know how it came out with a good end of 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. 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.
Boom.
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, you know, as an entrepreneur, I wanted to create the environments that I want to work in. And as my wife would say, like, I don't like being told what to do. Like, so I guess that makes it good for being an entrepreneur. But, like, so I wanted to be in this environment as a developer that, you know, 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, you know, autonomy and accountability are two sides of the same coin. And without accountability, then it's just anarchy. So people just want anarchy. But if we can design a system where we have accountability and accountability that's mapped back, back to the customer, then we can create this environment where people have make their own decisions, get to prioritize what they're working on from an engineering standpoint, make a decision tactically of, like, are we, you know, fixing bugs this week, this month? Are we investing new features? If so, what cadence are we. What are we doing? They get. Are we doing infrastructure work? Like, you take all those things that you usually argue around and that you want to create process and. And kind of like constrained 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, right? So, like, you know, that took me. That's like a subtle thing that took me a long time to figure out, like, whatever you incentivize from a metric standpoint is what you're going to get, right? That sounds very simple. But like, 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. 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, you know, from a sales standpoint, like, how many times, how many things that are on loss, you know, if you look at win loss, how many losses, you know, are we getting better at the objections that are coming up from a sales standpoint? And if so, you know, how fast is that happening? How many of those things are happening from a support standpoint? Like, 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 like 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 hook 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's 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 customers. 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?
What period of time was undefined? So like we, what we do is try to.
We clearly differ on.
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 separate separation.
Yeah. I think separating product delivery.
Yeah.
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, burned down.
Printed out when you put 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. Yeah. I guess the part that I, that I.
Where was the difficulty.
It wasn't going fast. 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. 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. There is no. It's not shipping fast enough. But the product manager, the engineer, whoever, the designer, the salesperson, the CEO, the CEO, they're all not the customer. So a date predicated on whatever you think is right.
No, 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. That has the biggest impact on that. And the guy writing it kind of line by line. Or woman. And they. 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.
Cool.
We could keep going on this.
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?
Yeah, 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 and how that you.
Always let him 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.
Robin, what do you think?
No, I want to hear that. Push, push, pull, push, pull.
I mean, I've heard you talk about that.
Yeah, it's, you know, one caveat is, like, it's more work. So, like, it's exhausting. 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. 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 their career, it's harder. If you're a maker of anything, whether you're an engineer, designer, what have you, 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 accidentally had that happen, people become super powered. And so going back and saying, like, why was that person so great? Like, compared to this time versus last time, it was like, because they were trying to do something that was about. On their personal.
Why the intersection of it becomes magic.
And so we spent a lot of time trying to figure out, like, personal aggression. One on ones, every, for everyone on the team, intern, co op, everyone. And it's geared around like, what are they trying to get better? What's the next thing? And 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're failing as a manager. Right? Because you should be anticipating what is the next thing for this person. And sometimes that involves pushing them to 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, not just the business reason.
Cool.
Now this one, I've been holding this one for you.
Okay. 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. And you mentioned that if the manager isn't that challenge, then they failed. Essentially. That feels like push, right? So I feel like it's both and for. 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 whole. 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 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 is also does take a lot of time and effort.
And it also goes to the why, right? I mean starting with the why, why aren't they.
It's hard. No one wants to have those conversations.
And then, you know, for Rob, I know internally at sales off culture is huge for us. It's the number one thing. It's. 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 and how those dynamics play as we've grown from.
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 super heavy. So it's kind of just a kind of 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 hear 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 the key part of that, and you talk about this in your podcast all the time, is learning, the ability to learn. And our own demons are often the biggest challenge. That owning our own mistakes and knowing where we're weak.
Should you fire based on values?
Yes.
Good. Very few do. So I think that's the key to find your values. But almost no one fires based on their values. Especially if you have a high performer, engineer, salesperson, what have you.
It's super difficult. I don't take any pleasure in it. The way. So going back to why is. Just because someone is in 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.
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. How do you empower your engineering teams to have ownership? And do you have product managers? Do you believe that. That they should be part of that process or.
Yeah, definitely. This is like a longer thing. I mean, I have lots of controversial views on that. One is like that I don't like hiring product managers. I don't like hiring people that have been serial product managers typically. Right. Cause I find in my world, that just product manager as a title is this amorphous thing. 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 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 small engineering team has to own the whole thing, including overnights, including 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, new market expansion, revenue, churn, all that stuff. And so we put all that on top of.
But not dates, not dates.
Everything would not date, money and churn, but not dates.
One of the ways we've held or we've begun to hold our engineers accountable is through these demo days.
Yep.
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. 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 four minutes each. Click right through them. Don't really do Q and 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 back channeled screenshots somehow. 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. Right. 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.
And we started with monthly and it.
Yeah, we do it weekly now.
Okay.
Yeah, but we did it monthly. Entire company would show up in some way, largely sales, marketing support, account management. And I didn't know what to expect from the. At the beginning. But it was like the best, you know, in lieu of dates, this was the best thing. This was the best social pressure.
You should try dates and all hands.
And then never. And then we tried. Then we tried a couple, you know, we had a couple guardrails. We said like it was, you know, like you only so long, but no demo wear, nothing that. Oh, it works on my laptop. It's in staging, it's in test or whatever. It has to. We do that 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, but it can be on the laptop and. Because sometimes it can take a number of weeks, iterations to get the pieces together. Another, I guess another 10 ways. One of the ways to get a lot out of your team is get sort of feature flagging, you guys.
Yep.
So that. 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. 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 and a drift. It's pretty similar.
Yes. We have an internal dashboard with all the flags and states and things like that that support and success can see.
Yep.
And 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. 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. I hate Scrum, but I mean, it could be anything.
Right.
You talk about a 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? That's a question.
What's that?
Are all of your teams functioning at the same level? Performance. So some are better than others?
Yes.
Right. So if you have a low performing team, whose fault is it?
Depends. Right. So a low performing team for us might be it's a new problem space. 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, the manager, whoever it is.
But there's a leader.
It really depends. Yes, there's a leader.
Yeah. So what I've seen most agile teams cross functional, you 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. Yeah, seven person team, so no one's accountable.
Every team for us is organized around a tech lead. Tech leads, 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 because it's divorced from the customer. The customer is nowhere in the agile planning process and points process. And the teams that I would deal with, it taught them to optimize for the wrong metrics. 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, look at my velocity chart. Exactly what your velocity chart. And then it's like I committed 12 points. And I said I was going to. I committed 12 points, I actually deliver 14 points. And it's like, so what does that mean? But we didn't actually deliver.
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 an article around 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 five 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. 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 why we would localize everything. So it'd be like a team that owned a product. It 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 sales people may have needed. But like all of that kind of stuff and we localized all of that. Instead of being cross functional, we made it local.
Yeah.
Awesome. Well we're out of time unfortunately so if anyone wants to get in touch with you Rob and ask you more questions, how can they do that on Twitter?
Rob Forman, ATL as well as Robert Salesloft.
Cool.
David Decancel on Twitter and Decancel at Drift. Awesome.
Well thank you both for having us. Thanks everyone for showing up. My name is Sean and hope you have a great rest of the day.
