10 Ways to Get 110% Out of Your Dev Engineering Teams (Video + Transcript)
In this session, Sean Wester, VP Product Marketing at Salesloft, moderates an in-depth discussion with Rob Forman, Co-founder at Salesloft, and David Cancel, CEO at Drift, about how you can get the absolute most out of your engineering team. As the leader of your team, it all starts with your “why,” which will motivate you and guide all your actions.
The panel delves into the push vs. pull approach, what culture really means (hint: it’s not free food and ping pong tables), how autonomy and accountability should go hand in hand, and surprisingly, whether or not setting dates on projects is actually beneficial or not.
And if you haven’t heard: SaaStr Annual will be back in 2018, bigger and better than ever! Join 10,000 fellow founders, investors and execs for 3 days of unparalleled networking and epic learnings from SaaS legends like Jon Miller, David Steinberg, Jennifer Tejada, and Eoghan McCabe. If you don’t have tickets, lock in Early Bird pricing today and bring your team from just $ 999! (All ticket prices go up December 31st.) Get tickets here.
Announcer: 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 Forman.
Sean Kester: Awesome. Super excited to be here today. This is a packed room. Everyone having a good day so far?
Sean: Cool. We’ve got a great panel today. I’m really excited for them to be able to share with you guys. The topic is, “Different Tactical Ways to Get 110 Percent Out of Your Product Delivery Teams.” To my left is David Cancel. Anyone familiar with David?
David Cancel: No.
Sean: [laughs] If not, he’s CEO of Drift, 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. All of us at SalesLoft are a big fanboys of his podcast as well.
David: Five stars only.
Sean: Yeah, five stars only. We have Rob Forman, our co founder at SalesLoft and COO, former founder of a company called HireIQ. Fun facts about Rob, he’s got five kids. [laughs] He wrote his first program on a V Tech toy, PreComputer 2000, if anyone knows what that is.
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.
Sean: Awesome. I want to give Rob and David a chance to introduce themselves and what they’re responsible for and their initiatives, and then we’ll dive in.
David: Sure. 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, although most of my engineers don’t believe that at this point. I started out as an engineer and I’ve founded…this is my fifth company.
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.
Rob Forman: My name is Rob Forman. At SalesLoft, I have three roles, as a business partner, as a technology leader, and as an operational manager. I head up product and engineering support and the operational, people operations.
SalesLoft is the easiest way to turn targeted accounts into customer accounts through great sales practices. 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, I was fortunate enough to meet Kyle and join forces.
Sean: Awesome. Both these guys got unique backgrounds. They come from very technical responsibilities, as in technical leaders. They’ve been on a variety of different teams. They have a lot of experience with some of the good, the bad, and the ugly. We’re going to try and pull some of that knowledge out of them today.
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.
Before we get started, Simon Sinek has this book, it says, “Starting With The Why.” I wanted for them to really set the stage on the why for having a team, like creating a team, motivating a team, and ultimately trying to get them to perform beyond what they thought was possible.
David, we can start with you. What’s your why?
David: My why? Mistakes.
I started out my career trying to follow conventional wisdom on how to build teams, how to motivate teams that is largely a push approach, push people.
I 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 pull model where I focus on personal progressions and getting people to pull the company along.
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. We keep doubling down in this servant leadership approach. It’s been the way that we do things the last 10 years.
Sean: Awesome. I know of servant leadership. It’s 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 so, I guess you can start there with your why.
Rob: Why, because we were put on earth for a reason, and it’s too short not to figure it out.
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.
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 the core infrastructure team. I remember we’re at happy hour and everyone else was probably much more fun.
I was reflecting on it. I was asking, “What makes us special?” We all knew we had something special, especially in a large company environment. There are great people but oftentimes the density is lower, so you don’t find each other the way we found each other.
I asked them, “What makes it great?” None of us came up with anything, so we just had another beer.
Rob: 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’d worked with. I didn’t know what I was doing wrong. My wife would ask me, “Good day, bad day?”
Sean: It depends.
Rob: I was like, “Uh…” After three months, she pulled out a calendar, and she had put a happy face or sad face, and it was 90 sad faces. Really inspiring way of like, “You’re better than this,” or, “You’re a worse person. You’re a worse husband.”
Rob: I don’t know. It came out with a good end to this. I have kids, I can’t segment between home and work. It’s like I’m one person. 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. If you’re on a bad team and you have big problem, it’s not. The why, rather than waiting to find out how to live an energetic life. I think teams, that’s a lot of the answer. Kyle and I, we didn’t invent this.
Patrick Lencioni is a big one, a guy that we read. 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. They interact with other people. That’s why.
Sean: That’s powerful. I wanted to lead this into talking a little bit about process and tactically, how you can take that line and insert that into the way that you run your teams. 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? Tactically, how do you hold them accountable to those things?
David: That whole thing started because as an entrepreneur, I wanted to create the environments that I want to work in. As my wife would say, I don’t like being told what to do. I guess that makes it good for being an entrepreneur.
I wanted to be in this environment as a developer, that you actually can build something you have control and say on what you do. It’s just not because someone said so. I try all different ways to create an autonomous environment, but I always felt like people would take autonomy and bastardize it.
Basically, they don’t want any accountability. To me, the autonomy and accountability are two sides of the same coin. Without accountability, then it’s just anarchy. People just want anarchy.
If we can design a system where we have accountability, an accountability that’s mapped back to the customer, then we can create this environment where people 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, 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. You let them decide, but as long as the metrics that you look at map back at the customer.
That’s a subtle thing that took me a long time to figure out. Whatever you incentivize from a metrics standpoint is what you’re going to get. That sounds very simple, but like most of us design metrics for our teams that are totally opposed to the customer, whether making the customer successful, the prospect successful.
They have nothing to do with that. We wonder and we spend all of our time building process to try to enforce good behavior when our metrics are not aligned with good behavior.
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.
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. Most call drivers are some sort of experience issue. If you take out the obvious bugs, it’s some sort of experience issue that you’re dealing with. That involves engineering, UX, rethinking some of the things in the product.
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 we’re trying to put control.
When someone’s arguing in a company like, “Hey, we need a roadmap, I need a roadmap, I need some dates on this,” what they’re really saying is I don’t have transparency into what this organization is doing.
Rob: You don’t do dates?
David: No. I don’t believe in dates. We can have that argument.
Rob: Let’s do it.
David: The date is our… I’ve done dates forever, but dates are a company instrument. They don’t have anything to do with the customer usually.
Rob: Customer cares about dates.
David: Customer cares about being heard and being serviced and delivering the right solution to them.
Rob: In what period of time?
David: What’s that?
Rob: In what period of time?
David: In what period of time? It was undefined.
Rob: We clearly differ on this.
David: We try to separate a company event like a marketing event or a sales event…
Rob: That I completely agree.
David: …from a product release. We have people running on the product side and the releasing diary, and to have a separation.
Rob: I think separating product delivery from marketing is key. I can’t go all the way down to, there are no dates. We tried it. Burn down your road map.
David: Oh yeah, burn it down.
Rob: Print it out and put it on the wall. Let’s do it.
David: It’s all in the implementation, yeah. [laughs]
Rob: I was going to blame you, but I’m sure I screwed it up. I guess the part that I…
David: Where was the difficulty?
Rob: It wasn’t going fast. One of the ways that this talk was promoted is your team failing to release or falling behind or something like that. It feels too idealistic to not have dates.
One of the questions, one of the things we drive to is who creates them. If you give me the date and I’ll ask you a bunch of questions, you’re like, “All right, I’m comfortable with the date,” and then you miss it, and then we do that game again, something’s broken.
Either you don’t know what’s going on…
David: Perhaps, or you don’t understand the problem well enough.
Rob: The person, I’m asking, it’s their date. The team creates the dates.
David: The team is not the customer. 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.
Rob: Yes. Completely agree.
David: There is no…It’s not shipping fast enough. The product manager, the engineer, whoever, the designer, the salesperson, the CEO, the COO, they’re all not the customer. A date predicated on whatever you think is right…
Rob: Not a date from on high.
David: But even from the product manager because they don’t know.
Rob: The way we’ve landed is that the person who, if we’re creating something, there is a role that tends to, that has the biggest impact on that.
It’s the guy writing it line by line, or woman. I think there’s a skill with estimation. If we’re bad at estimating, I push them to get better at estimating.
Sean: We could keep going on this.
Rob: We could keep going on this. A couple things there, so tactical things that we both just glossed over.
We ship multiple times a day. It sounds like you guys do too. That was the biggest single forcing function for test driven development. As far as a take away, if you want to get better tests and this is counter intuitive, 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. You can get test coverage two ways. You can 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. That’s one takeaway would be…and move the team to ship faster.
David: Absolutely. For us, it’s daily cadence, intern co-op, full time, anyone first day, ship.
Sean: That’s awesome. On that same line, you want to motivate them to push faster. You want them to do that. Now, pushing versus pulling, you talked about this. How does that play into it?
The way you’ve explained it to me previously is that you can either push someone to go somewhere faster or you help the organization pull them in that direction, the momentum. Can you share a little bit more about that philosophy and how that…?
Rob: You always let him go first. I thought I was…you’re going to favor me.
Sean: I’m going to hear this later. Rob, what do you think?
Rob: No, no, I want to hear this. Push pull. I’ve heard you talk about this.
David: One caveat is, it’s more work, so it’s exhausting. 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 with engineers, because it’s hard.
It’s easy with a sales and marketing person who clearly wants something. Some progression in their career. It’s harder if you’re a maker of anything, whether you’re an engineer, designer, or what have you.
We’re trying to figure out what’s motivating you, what’s next, what’s the next big challenge that you want. We’re trying to gear your work towards that.
The reason that we’re trying to do that is when I accidentally had that happen, people become super powered. Going back and saying, why was that person so great compared to this time versus last time. I was like, “Because they were trying to do something that was about their personal why.”
Rob: The intersection of…
David: It becomes magic. We spend a lot of time trying to figure out personal progression, one on ones for everyone on the team, intern, co op, everyone. It’s geared around what are they trying to get better? What’s the next thing?
We always felt like when someone comes to you and it’s like, “Oh, what’s next? What’s the next big challenge?” That should be a sign that you’re failing as a manager. You should be anticipating what’s the next thing for this person.
Sometimes that involves pushing them to new challenges. 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. They were trying to get things done for their own reason, not just the business reason.
Sean: I’ve been holding this one for you.
David: This is a special one.
Sean: It’s around culture.
Rob: Before we leave that though, I took the flip side of that. I guess I would lean more a little bit to the other way. You mentioned that if the manager, there isn’t that challenge, then they’ve failed essentially.
That feels like push. I feel like it’s both. For the leader of the organization, we do weekly one on ones with our engineers, and with everyone on the team.
I think there way to do that with excellence and there is a way to check the box. I would encourage everyone to do it with excellence, but then creating that push. The analogy I go to is, look at any fantastic sports team. There is a push where the coach is never satisfied. Developing that in your leaders, it also does take a lot of time and effort, because they don’t know why.
Sean: It also goes into the why. I mean starting with the why. Why are they here?
Rob: It’s hard. No one wants to have those conversations.
Sean: For Rob, 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 and how those dynamics play as we’ve grown from…?
Rob: 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. A better question is, what are your values? At SalesLoft, we have a set of values around team over self, and glass half full, and things like that.
The engineering team and the product delivery team as a whole also has a set of values around coding beautifully and shipping quickly. Really balancing that tension of speed and quality, and then creating mechanisms for that. I found an aluminum cube and a tungsten cube. One is super light, one super heavy. It’s a party trick. The aluminum cube became known as the cube of shame.
If you blow up production, then you get the aluminum cube. The heavier, weightier tungsten one, which feels cool in your hand, it’s like something you keep on your desk, is around an act of leadership within the team. If they do something really neat, then it gets awarded. An email goes out, it moves desks.
The 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. It helps us not take ourselves too seriously. Rarely do we push something and somebody dies, I doubt many companies here that happens. 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. A key part of that, this is in your podcast all the time, is learning, the ability to learn. Our own demons are often the biggest challenge to that. Owning our own mistakes and knowing where we’re weak.
Sean: Do you fire based on values?
Sean: Good. Very few do. 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 in your sales person.
Rob: It’s super difficult. I don’t take any pleasure in it. Going back to why is, just because someone isn’t our values doesn’t mean they’re not a good person. If I believe that a human desire for connectedness is core to who we are, 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 walked it out.
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. Your values begin to mean something, and everybody else knew that you waited too long.
David: Yes, every time.
Sean: 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? Do you have product managers who believe that they should be part of that process?
David: Yeah, definitely. This is a longer thing. I mean, I have [laughs] 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, because I find in my world, product manager as a title is this amorphous thing.
Like your company, it means something different than my company, and his company is totally different. I might not know the difference between a product manager, a program manager, or project manager.
Maybe you do and maybe he doesn’t, and so these things it’s hard to have someone like an engineer or salesperson where you actually know exactly what they’re doing, what they bring.
We tended to build our product managers out of different functional areas. 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.
It really was an engineering led team, and the product manager designer was there to help that team. The engineering team was making the decision on new feature, no feature, bugs, infrastructure, what have you.
They were also being held accountable on moving sales objections, customer support issues, new market expansion, revenue, churn, all that stuff. We put the…
Rob: But not dates?
David: Not dates, everything, but not dates. Money, insurance, but not dates.
Sean: One of the ways we’ve begun to hold engineers accountable is through these demo days. Rob, would you like to share what the…?
Rob: It’s fantastic. Until I saw it, I would have thought that it was too often. Every Tuesday at 11:00, everyone in the company, 130, every development team comes up and demos what they built in the last week. Four minutes each, click right through them, don’t really do Q&A.
We do lunch right afterward for the whole company, and we encourage people that if you have questions, because sales 100 percent of the time does…
David: Can I sell that yet?
Rob: [laughs] Yeah, exactly. They’ve back channeled screenshots somehow. They’ll go to the product owner, or anyone on the team really. It encourages tons of cross team collaboration. Knowing that you’re going to show something creates a positive forcing function. 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. That’s what we do.
David: We did the same thing. I did it at HubSpot. We do it monthly there, and…
Rob: We started with monthly and it…
David: Yeah, we do a weekly now. We did it monthly. Entire company would show up in some way, largely sales, marketing, support, account management. I didn’t know what to expect at the beginning, but it was the best…In lieu of dates, this was the best thing.
David: This was the best social pressure.
Rob: You should try dates and all hands.
David: Never. We had a couple of guardrails. We said, like you, only so long, but no demoware, nothing that, “Oh, it works on my laptop, it’s in the staging, it’s in test, or whatever.” It has to be being used by a customer.
Rob: We do that. We started with that. I think I got it from you.
David: That’s why monthly made sense for that. Weekly, it doesn’t make sense.
Rob: Got it. Weekly, it has to be real campy, but it can be on a laptop, because sometimes it can take a number of weeks to get the pieces together. I guess another 10 ways, one of the ways to get a lot out of your team is get…feature flagging you guys through this.
You can get it merged into master and out to production, you’re building it one little piece at a time, and it goes part of a demo.
David: It was one of the largest things we invested in, and we do, and we continue to do, which is like feature flagging so you can do the daily cadence. Hourly, whatever cadence, and so that you can target different groups within your customer base that are using that.
The thing that you need to remember when do feature flagging is you’ve got to build the analog for support and success, because they need to know what versions their customers are running. At any one time, they might be running with HubSpot 15 different versions of things, because we weren’t all in one platform, and at Drift, it’s pretty similar.
Rob: Yeah, we have an internal dashboard with all the flags and states, and things like that, that support and success can see.
Sean: Also, measures when sales can start talking about it.
Rob: The other thing I’d say with accountability, the bit that’s counter intuitive and maybe a little bit controversial is, I think most of our…Companies I talk to, three out of four have problems with some of their engineering teams. I think the idea of scrum and cross functional, I think there is an inherent flaw in it. It goes back to what you were saying about accountability, and it’s really tricky to solve.
David: I hate scrum.
Rob: I mean it could be anything. We’re talking about a cross functional team, right? They don’t have a date, but are all your teams functioning at the same level? Are they? That’s a question.
David: What’s that?
Rob: Are all of your teams functioning at the same level?
Rob: Some are better than others?
Rob: If you have a low performing team, whose fault is it?
David: It depends. 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. It could be an existing space. In that case, it’s the fault of the leader and the manager, whoever it is.
Rob: There is a leader on the team?
David: Yes, there is a leader.
Rob: What I’ve seen, most agile teams, cross functional, you could use 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 if more than one person is accountable, then no one is accountable. A seven person team, so no one’s accountable.
David: Every team for us is organized around a tech lead. A tech lead’s accountable, they’re ultimate accountability. 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.
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?” It’s like, “Look at my velocity chart.”
Rob: Exactly. What?
David: Your velocity chart. It’s like, “I committed 12 points, I actually delivered 14 points.” It’s like, “So? What does that mean?” We didn’t actually deliver…
Rob: It sounds like you’re talking about there is proximity to the customer.
Rob: I think the other side of it is HBR had an article around 75 percent of cross functional teams, so this isn’t specific to engineering, just cross functional, like matrix origin 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.
David: …HBR afterwards.
Rob: 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? That’s what…
David: That’s why we would localize everything, so it’d be like a team that owned a product would be that engineering team, the product manager designer, but also the product marketing person would actually be embedded within that team. They were in charge of communicating to sales and sales enablement, and dates that the sales people may have needed.
All of that kind of stuff. We localized all of that. Instead of making it cross functional, we made it local to the team.
Sean: Awesome. Well, we’re out of time unfortunately. If anyone wants to get in touch with you, Rob, and ask some more questions, how can they do that?
Rob: I’m on Twitter, @robformanATL, as well as rob@salesloft.
Sean: Cool. David?
David: @dcancel on Twitter and dcancel@drift.
Sean: Awesome. Thank you both for having us. Thanks everyone for showing up. My name is Sean. I hope you have a great rest of the day.
The post 10 Ways to Get 110% Out of Your Dev Engineering Teams (Video + Transcript) appeared first on SaaStr.