Bringing Developers Closer to the Customer

How do I allow developers to engage with customers in the most productive manner? What can Customer Success do to facilitate this? What outcomes may I expect? All this and more as I interviewed Cloud Cost Advisors founder and software leader Kevin Benz in this episode of Customer Success by Design - LIVE!!!

As an action oriented individual I ask and encourage each guest to share which charitable and social change organizations they'd like to promote and share to help combat COVID-19 & social injustice. You may find the list of organizations I am active with and support here.

Kevin asks you support Hopelink of Kirkland which is a nonprofit organization working to end poverty in our community. In addition, Kevin requests you assist Northwest Harvest a Washington-based nonprofit leading the fight for hungry people statewide to have access to nutritious food while respecting their dignity and promoting good health.

Thank you for watching Kevin's and my discussion on bringing developers closer to the customer. I look forward to seeing you at one of my future live stream events here.

Cheers

Adam

TRANSCRIPT

(*for clarity I have omitted filler words and corrected other grammatical matters)

Adam Peddicord: [00:00:00] Good day and hello everyone. Welcome to Customer Success by Design-LIVE!!! We are here today to talk about the value in bringing your developers slash engineers, closer to the customer. Here to offer up some tips and tricks on how to do it best with our subject matter expert, Kevin Benz.

Kevin Benz: [00:00:21] Hey, Adam. Great to be here. Thank you for the offer to do this. I find these a great amount of fun and always learn something and hopefully try to teach something at the same time.

Adam Peddicord: [00:00:33] That's awesome. Thanks, Kevin. I'm super stoked to have you here. What I'm gonna do real quick is set the tone for everyone in the audience today.

Quick housekeeping. Remember this stream is live and it's interactive. We want to hear from you, so type in your questions into the feedback area of your chatbox. The little screen right now. Everybody should be seeing on YouTube. If you type in your questions, both Kevin and I will see those.

We'll get to as many questions as we can during the, allotted time, if we don't have the time to get to your question, I'll capture them. And send them back out with a response via email.

This stream is going to be recorded and will be posted on my website csbydesign.com as well as my YouTube channel.

If you have any additional questions or feedback please send them to info@csbydesign.com.

Without further ado, My name is Adam Peddicord. I am your host. I am the founder of Customer Success by Design, a boutique consulting agency, focused on customer success, strategy, and execution for all types of businesses. I have 15 years in customer success leadership roles. I'm a member of the community emergency response team, helping out with COVID-19 response locally. And I'm also a U.S. Army combat veteran. My special guest star today is Mr. Kevin Benz. Kevin is a software executive at AT&T and Direct TV.

He's a technology advisor to startups, investors, and venture capital firms he is the founder of not one, not two, but three businesses eatcandy.com, Interknack, and his current venture Cloud Cost Advisors. He is a lifelong Washingtonian, an avid golfer. Kevin, did I miss anything on the bio?

Kevin Benz: [00:02:25] Well, the AT& T and Direct TV was passed. Currently, Cloud Cost Advisers is my current emphasis.

Adam Peddicord: [00:02:35] Right. Thanks, Kevin. The boomstick data drop for today is that customer-centric companies are 60% more profitable than those that are those of you who have subscribed on YouTube channel before who have read my collateral for know, that I anchor on this data point, which is not mine it's Deloitte's because of the power of the statement, which is how do you get to be there because of the results that you'll see.

So Kevin is going to be our guide today, as we have a great conversation about how we can best involve engineers and developers in this effort. So, Kevin I pulled this image from the interweb, because my perception, and I think a lot of people's perception out there is that this, kind of the life of the engineers.

So maybe just to level set for the audience, can you just describe to everyone? What a day in the life of a software engineer is like?

Kevin Benz: [00:03:32] You have to remember that software engineers are fundamentally, the job is solving problems and that can include operational issues, whereas a product going to go, did we build the right thing and.

It's really not different from the product groups and the customer success groups, where everyone is incented in the success of the customer, but how they achieve it is very, very different. And that's an important distinction, you know engineers engaged by writing code or fixing code or deploying code or monitoring code in production, whatever, whatever these engineers and developers are doing, they all contribute in some way, wait to the success of the client.

How they do it is very different a day in the life. In a more traditional, agile development environment, they are working with the product team. I'll be at the product owner, working on user stories. It's, it's not any different in Kanban or Lean based approach is quite a bit different from, from my waterfall perspective. But in the end, they're sprinting or essentially making small, incremental contributions to a codebase in order to satisfy some needs.

Adam Peddicord: [00:04:53] Got it. So, can I share a little bit of a story about my first introduction to software engineers?

Kevin Benz: [00:05:00] Sure sure you haven't let us have it. I mean, or not, this is your chance, Adam.

Adam Peddicord: [00:05:06] So it was at a startup, a bootstrap founder-led organization is a tag-team approach. One co-founder was the software architect and chief engineer who built the platform. The other brought the marketing and sales component to it. And, I walked in for my first day in the office and all the lights were out.

Like all the lights are out and I'm like, why are the lights out? It's like nine o'clock in the morning. So I turned the lights on and then all of the engineers in unison stood up and turned around and looked at me with death ray eyes because I had, what they described to me, was it, easier on the eyes if you're staring that long at the computer and it broke their concentration.

So what I had walked into unbeknownst to me, it was an organization that was driven really from the engineering side. I had never been there before, but I'm like that. So for me, it was a bit of a shock. And then I also learned that it was not okay for me to go over and walk and tap them on the shoulder.

Kevin Benz: [00:06:09] Yeah.

Adam Peddicord: [00:06:10] Which, which I'm sure you, as the leader would have loved.

Kevin Benz: [00:06:13] Well that, you know, or I would do it. Right? Yeah. But what, when do you need to understand about engineers is what they are, what they're essentially doing is they're limiting their external inputs. Cause when an engineer's deep in thought there they're trying to construct in their head, a mental model or mental, operational model.

Okay. If I do this, what happens to the client over here? What happens to the inventory over there? So really they're emulating the subroutine in their brain in order to understand how it might, how it could work, what's wrong with it, whatever the case is.

So limiting those external factors those external inputs are very important to them being productive in the end they're problem solvers. And they are incented by one, the feeling of accomplishment when they actually produce it. And which is fed by their ability to stay committed to it, as well as feedback of the work that they did directly.

Adam Peddicord: [00:07:16] It's been interesting for me in my professional growth and development as someone who's customer-facing and through, value add products that are all software-driven to when I would go over there and try and strike up the relationship or the conversation to the software, engineers and developers, how to find that balance of when is the opportune time to, interrupt them from work, how do I triage that?

And then how do I facilitate the right relationship? Not only with them, but then with the leadership, because, I've always viewed my charter as the customer person was to make sure that the customer's voice was heard and in smaller, more agile, and then nimble organizations that were software-driven.

A lot of that was just me getting up from my chair. And going down and tapping people on the shoulder. So can you write down why that might not be the best approach? Because I had to learn that the hard way. Can you maybe put on your software engineer hat and describe for the audience why that probably isn't the most helpful way to do it?

Kevin Benz: [00:08:14] Well, and your background and what you are, what you advocate is really part of your problem. That, and because. In some respects when you have a support organization you're in the firefighting mode, right. And you're you just say, Hey, I've got this and, they have a client that's having a, struggle trying to get past something.

And the code is blocking or the code or the environment or conditions, whatever is blocking that. And you as a customer support person, want to act on that right away, immediate. Validation to be able to get the gratification, make the customer happy, success, right? You, achieved success immediately.

And the faster you act, the less likely it is that a client would churn in this, so, developers, on the other hand, they're trying to construct that mental model and that's why they do something. When, they come together as some of the more effective teams, put a working agreement in together, which is, "hey, this is the way we work".

And we're going to, and, and in that working agreement could be how they're, where the way they're going to develop what environments they. They deliver it to what, how testing is going to happen, and how demos going to happen. So they're very structured people, both mentally and in, practice or the way they do their work.

So Adam comes in and boom, you know, we've got Adam in that.

Adam Peddicord: [00:09:37] You're making it look like a beating people Kevin.

Kevin Benz: [00:09:42] It's just different approaches, neither are wrong. That's when things go into a queue and you start to say, Hey, I've got this question. Let me know when someone can take it. And some of those things are best done in Slack. Someone raises their hand and says, Hey, I can take it. Right. And that's, when some of the non or as acute messaging type environments can be so effective. Is you basically just raising your hand and saying, hey, will someone, I got a client with an issue.

When you go down and tap someone on the shoulder, you are interrupting their current path. When you, when you raise the hand, someone who's already at a point of departure, or, they're at a point at which they're taking a break and they notice your hand up.

I find the most effective way to do it. That makes sense?

Adam Peddicord: [00:10:31] It makes total sense. And I love that feedback and that was a hard lesson learned for me because one of the things that, was great for me to learn was just the level of intensity and focus that it requires to stay committed, to writing good code, and then working through what really did warrant coming down the hall and tapping on someone's shoulder and who was the right person to tap.

Kevin Benz: [00:10:54] Right.

Adam Peddicord: [00:10:55] I think the interesting thing might be to talk a little bit about That triage element. You mentioned just a moment ago, how you, as the leader of the software engineers, like to put together a "how we work" form and bring together to the business, some thoughts around how you can reach us when the shit hits the fan.

Do you, do you mind describing your thought process for putting that together and small executional tips for anybody listening?

Kevin Benz: [00:11:25] From a peer, this is the working agreement. And the one I'm talking about is more of an agile and basically what the developers are doing is saying we're going to come together as a team.

It's traditionally very internal to the hands-on, six software development, for example, I but they, come together and say, we're going to act as a team. And this is the way we're going to act. This is the way we're going to hold ourselves accountable work is not going to be done until it passes ABC. To be able to say, things like the definition of done and, artifacts such as that are key to being able to, build a repeatable process. And that's really from an engineering perspective, one of the most effective ways to reduce, software defects is to, limit interruption because every one of those interruptions it is a mental shift in their brain. If they're trying to map an algorithm runs this way, or this piece of code runs that way. You interrupt that. And you're changing their training thought. And then when they come back to that, can they come back to the same state of knowledge about what they're doing, trying to accomplish and what the system is trying to do or what the user needs to do those things.

So it's very important from that perspective too. Really think of it as raising a flag and not lobbing a bomb.

Adam Peddicord: [00:12:49] I think I mentioned this data point earlier and I'd like, it sure is if you could validate it, that it takes about 15 minutes for an engineer once interrupted to get back into that mental flow, if at all is that fairly accurate in your experience?

Kevin Benz: [00:13:03] It's hard to use an absolute like that because I've seen developers who never really come out of it and try to talk to you. And I'm sure you've seen some of those who, that they're staying in that and they're allowing the external, input to, they're ignoring it or giving it to them marginal response.

And some that can take hours to come back and I can't really equate it to backend versus, front end developers and stuff, because, as the complexity of what they're working on increases, so does that time to be able to get back to reengage and to get back to being effective.

Adam Peddicord: [00:13:45] So from a leadership perspective, it sounds like the core things that you're always looking for your engineers is really the quality of the output of what they're producing and the time and the productivity do I have it summarized right?

Kevin Benz: [00:14:00] Well, in terms of its productivity is a difficult thing to manage to measure because what they're working on really determines the level of invention.

So if you're going in and changing button color from green to blue or red to black or whatever. That's very simple that you can probably measure productivity because from a time-motion perspective how long it takes for him to get to the code, make a few changes, check it back in and test it, and all that stuff.

But as the level of invention comes up you're building something that hasn't been built before, or you're trying to integrate piece a to piece B. And it hasn't been done before now is more thought and more understanding and more due diligence needs to occur. Those cycles are so important because they're in most cases, building a pattern that will live on for a long time. And so they're being very diligent to being very patient and careful is highly rewarded.

Adam Peddicord: [00:14:59] That's great, Kevin. The thing that I had to think through and learn as a customer success leader, especially when it came to and trying to deepen the ties and bring the engineers closer to the customer was how did I strike that balance?

How do I learn what the day in the life of the software engineer was? What really are they held accountable to? So then I could work with them and their leadership team to start partnering through how I can best start engaging them and bring them closer to the customer. And one of the things that I thought was interesting was how close did the engineers even get to a customer generally speaking? Cause it sounds like with just those types of metrics of success, that type of work environment, that type of role, you may never really get the opportunity to actually see the end-user, take what you've written as your code, your baby, and put it out there and really hear or experience that feedback outside of anything other than just input data around usage.

Kevin Benz: [00:15:59] Right. And that's so true and such a problem and a benefit is a developer depends on the bigger category of how product is managed in some respects, you want to limit the input right?

You want to have one view of authority when it comes to what you're building and that relationship and in an agile mindset, that's really the bashing of the product owner and their product owner is there to represent the product and the business to the engineering and be the path back from engineering, back up into product and the business.

And so they really take what they're building on faith that it's wanted it's needed in your case, where you had a founder and a business founder, developer and co-founder marketing guy. It's small enough where they both probably sat in both the user product and engineer role, very simple, but, the more organization's scale.

Suddenly you're worrying about operations. You're worried about keeping the lights on in the server room or you're, trying to make sure the cloud is working the way you need it to there's those layers of separation, both. Allow your developers to be as productive as they can be at the same time a substantial wall from which data doesn't pass and, some, are customers.

I was at, AT&T nearly all AT&T employees have AT&T phones. So from a phone perspective, they know exactly the way their systems work, but it's, they get into more arcane situations. Like, imagine the API that satisfies the Apple store to be able to provision an Apple phone on the AT&T market.

They don't live in that code. And so it's more isolated more and more a black box that they can't see into. And so, it is critical a time that, developers hear the voice of the client. Sometimes it doesn't make it through product the way it could, because product is really talking, with the next 90 days.

And in some cases, that long-term experience with a client is missing in a lot of cases and is so important.

Adam Peddicord: [00:18:16] One of the ways that I found to try and bridge that gap was through something that I like to call an empathy exercise, because once I'd grown in my own professional development to the stage of realizing that, I understand what the day in the life of a more technical person or software engineer person is.

I understand what they're truly held accountable to from a KPI perspective. How do I then help facilitate bringing them together? What I realized was that if I could just find a way to give them an opportunity to come up for air, to breathe and put them in the customer's shoes.

That would be pretty powerful so I came up with is the customer empathy exercise, which was literally taking and working in partnership with your rock star customer success person who knows the ins and the outs, of, the tool so well knows deeply the value that a customer, is trying to get, do a complete retrospective and map to value that customer has gone through in their entire journey and present that in a very targeted format to just the group. For example, the engineer groups and just walk them through and allow them to have that Q&A session because I just found it to be so powerful and just so driving as a whole bunch of "a-ha's", because I know that. As, as a member of a lot of fast start SaaS startups, there's lots of hackathons, a lot of great ideas that come out of that, but I always sat back and wondered about, wow, they're working on some great things, but they're just not the things that the customers are really talking about or what we're trying to like feed into for the engine.

So I found that to be most productive. What are your thoughts on that type of an approach and from the engineering leadership perspective, what makes it most valuable to you to have that broadcast to your team?

Kevin Benz: [00:20:08] So from customer success, it's pretty clear to understand who your client is when you're an engineer and your client may be product.

And that's where some of the chasms between engineering and the client occur is because they're really working for product or the product owner. And to them, the empathy exercise that is also missing is the effort with customer success before. And then you can inquire them, the final client or whatever is the last client empathy exercise.

In my mind. It's important. Not only to do that empathy, exercise but empathy, you know, empathy with sales, empathy, with product and operations, making sure, engineering or product or software development and operations is another case where the empathy exercise, is so.

So important. I mean, in the end, we need to build bridges with all the internal groups, but getting that client. The one willing to pay for the goods and services that's. Critical that, that make it through all the paths, to, product and engineering and the rest of the organization.

So I'm completely with you there on that.

Adam Peddicord: [00:21:19] Kevin, we have a question from one of our audience members This question is going to come from Eric.

Hi, Eric as a technical person do you have any tips on how to communicate the technical side to people like me, or is that not necessary? Kevin?

Kevin Benz: [00:21:33] It's absolutely necessary. It's so important to walk in each other's shoes, right?

The tips you need. In different roles that I've had, I've, relied on the enterprise architect or the software architect to really be that, arbitrary between the technical and the business and, having a good, skilled communicator able to, talk, both sides, of that chasm is critically important to some of the tips are to one, a lot of organizations I've been in use acronyms for ease, but in the end, what the errors are a big, big hurdle to cross, because like when I was at, AT&T, which is by nature, an acronym.

We had dictionaries of acronyms and it's and sometimes it's so easy to complicate the language. We use that in the end. What you have to do is sit down and really negotiate. Common dialect between engineering and business because an engineer they could be talking about the database that could be talking about some of the software, internals, the objects, and it just isn't helpful too.

Throw all these technical terms at each other. So, that's really part of the empathy exercise when Adam and I worked together, we met frequently to talk about what was going on, what was coming. We used release planning from a quarterly perspective to talk in advance about what was coming down the line.

And that gave both parties the opportunity to explain it. And for those that want, it more information to be able to dig in and say, well, if you think of it this way, and so lessons to simplify grammar, get to a common dialect and documentation, believe it or not, although not necessarily, price and in the agile sense is still important when it comes to creating a common, consistent language to in visuals to be able to reinforce what both sides of the chasm.

Adam Peddicord: [00:23:44] Thanks, Kevin. And thank you, Eric, for your question.

So, Kevin, that's actually a nice inflection point because I think what you're talking about there and what Eric was even alluding to, it was really relationships, building and establishing relationships. We talked earlier about making sure that we in customer success understand what it's like to be an engineer, the empathy that we have to present there, then our job I believe is to make sure that you understand on the engineering side, what it's like to actually be in the customer's shoes to help you facilitate the great solutions and work in partnership with product management. The final layer that I would say which you just hit upon in your response to Eric is how do we make maintaining the mojo and the momentum there?

Kevin Benz: [00:24:26] And it's critical. The other thing remember is, although it's easy to look at engineers in dark rooms, hugging their screens, beating on their keyboards. Is be aware is really, the best engineers take incredible pride in what they do. So in some respects, a defect or a bug, whatever is, an affront. And being careful when it comes to, "hey, you guys are this piece crap". You hear a lot of trying to get the negativity out of that relationship because they take it personally, the great ones take it personally.

But when you think about, you could trace some of those details or, non-performing code back to, less than perfect working environment or less than perfect thinking or imperfect requirements or, just stupidity. Sometimes what you don't know is much greater than what you do know.

Adam Peddicord: [00:25:17] You're great at these segues. Thank you.

Kevin Benz: [00:25:21] I have gray hair to show I've lived them all.

Adam Peddicord: [00:25:26] We've talked about building and establishing that channel of communication, being empathetic through each other's shoes, and especially driving home from the customer's shoes and then building on that mojo. The final thing I would have people, think about, see if there's an opportunity to allow customer success or certain parts of those teams to be in on the quality control process prior to release.

Because what it does is giving the business, in my opinion, the best opportunity to provide the people who are closest to the actual application users, the chance to use it before it goes out. Do you have any thoughts on that?

Kevin Benz: [00:26:05] That's critical. You're dead on and having a limited group of clients seeing pre-release code, I think is critical as well you know, in a time when finding developers is so hard and can be so expensive. Making sure you're building the right thing important. So prototyping showing clients' advance. One thing I do want to talk about before we end is that engagement with the customer.

Practices I've found very important is to prepare, number one, you just don't grab a new developer and throw them on the phone because developers are problem solvers and you really want to hone them into what the problem they're there to address rather than. Look at some I can fix this year and I can, I think we should do this there.

And all these things really it's the luxury of focus to be able to say we're here to talk about this part of the problem. There's great benefits to being able to develop her, see the user interact with code while they can trace it or see, see the path underneath it. And that's just great. So preparing will not only pay you back there but also be able to.

To create that environment where you can best engage with developments in a planned way and let them help them get their work done. We all want to get our work done, believe it or not.

But customer success, please orchestrate those interactions. You're in control. You're the leader. You, set up, I think a 10-minute session.

You want to stay focused on the problem at hand and I respect everyone's time and certainly, we want to respect the user and the client's time. Then, in the end, make sure it holds your engineers accountable to write up what was actually, observed what some of the technical details they observed.

Cause that's critical that needs to go back to the product owners as well as inform the technical damage that what needs to be done in the system itself, they'll find things that they don't realize is there. And it's so critical to be able to capture that in a way that lives on beyond the engagement of that particular client.

Adam Peddicord: [00:28:10] I couldn't agree with you more and I think that. The power of having, CS lead and facilitate that represents CS, what they are, which is the conduit between the business to the customer. And it also allows you as the leader of engineering to maintain a little bit more structure on what problems the engineers should be solving and focusing on.

Kevin Benz: [00:28:30] Right and planning will help you find, in the end of may my code, but it could be an operational problem. It could be a server follow. That could be something in your identity system. So that planning is critical to find me the right and most effective person and showing success for your client.

All groups are interested in the success of the client, how we accommodate it. And that goes back to my first statement, how we get there is very different, but in the end, we still want our clients and our customers to be successful.

Adam Peddicord: [00:29:01] Couldn't agree more. For the audience the takeaways from today's conversation. From a CS perspective, I can't drive home enough, the power of the customer empathy exercise, and Kevin, thank you for, evangelizing that as well I think that's super important.

One thing we didn't talk about that also piggybacks on the customer empathy exercise is you can help beat the drum by doing monthly, meet the customer meetings internally, share relevant metrics. We didn't spend too much time on that. So Kevin I'll have to pick your brain on that then another time.

We talked a lot about this is on the CS side, nurture the relationships with the dev team. Just the power of doing that. And then Kevin, please course correct if you see anything. That I missed, but we talked a little bit about listen and focus to the problems assigned from the engineering perspective, you know, trying to give them the structure framework.

So they're being hyper-efficient and hyper-focused on what is the core problem that the customer needs solved.

Kevin Benz: [00:29:56] Amen.

Adam Peddicord: [00:29:58] We talked about the value in allowing CS to participate in any pre-release testing before any code shifts. And then again, the value of the relationships and nurturing those of the CS team.

Kevin, did I miss anything from a takeaway that you would really want to advise any of the listeners to the audiences with today?

Kevin Benz: [00:30:17] I do want to reinforce that planning aspect because you know, that. engineers can be great people, but they're typically not graded. They're not the best communicators.

And so laying the foundation out in advance what to expect you know, you're going to be talking to Susie and she runs this and she's responsible for that. And, and so just a return to planning frequently.

Adam Peddicord: [00:30:44] That's great feedback, Kevin. Thank you.

Finally, before we break a few things, one, I want to make sure that everybody knows that like everyone else out there my family has been touched by COVID-19. So these are some resources that are available for anyone out there. Who is looking to go above and beyond just moral support as well as financial support these organizations out there where you can get involved and contribute your time and your resources and your energies to actually helping fight COVID-19 the sooner we can kick this thing and the nads the better off we'll all be.

Kevin Benz: [00:31:18] Thanks for putting that up there Adam, that's awesome.

Adam Peddicord: [00:31:20] You bet, buddy any organizations that you would like to champion as well to Kevin's since we're talking about this?

Kevin Benz: [00:31:27] Mary and I are supporting, Hopelink of Kirkland currently and we've always done Northwest Harvest in a warehouse in the South end of Washington don't forget food you have Feeding America up there.

But also think about some of those local food banks and food kitchens that are out there cause people are seeing some real issues.

Adam Peddicord: [00:31:49] That's great. Kevin, thank you for that.

For anybody who has any additional questions that you'd like to ask Kevin, or I please go ahead and email them to info@csbydesign.com I'll go ahead and aggregate them. Make sure Kevin gets an opportunity to reply as well, too. If you'd like to get a hold of any additional resources, you can find us here at csbdesign.com or info@csbydesign.com. Kevin, thank you so very much for being on this live stream today. It was a lot of fun but had a great

Kevin Benz: [00:32:20] Thank you.

Adam Peddicord: [00:32:20] You bet, man. Thanks to everybody who came and participated today.

Take care

Cheers