ABOUT MAULIE DASS

Maulie Dass (@mauliedass) is the Global Lead for Cisco's Innovation Labs, which works closely with local industries to create new technology solutions that solve common pain points and positively impact business, society, and the planet. She has been in the industry for over 20 years in a variety of tech, strategic, and customer-facing leadership roles. Maulie is passionate about her customers, innovation, technology, inclusivity, and cheese pizza.

"Even if a customer is very clear on a solution that they want... 'I need an AI ML solution that does X, Y, Z.' The question that I use often is 'Tell me more about that? Like, what is instigating this need?' Think of the next question that'll kind of get you closer and closer to the source, or the root of the issue."

<cite>- Maulie Dass    </cite>

Check out our friends and sponsor, Jellyfish. Jellyfish helps you align engineering work with business priorities and enables you to make better strategic decisions.

Learn more at Jellyfish.co/elc

SHOW NOTES:

• Maulie shares the “expensive lessons” she learned while designing her first microchip (2:00)
• How learning and curiosity guided Maulie’s career across engineering, sales, and innovation (6:19)
• What engineering leaders can learn from sales (11:07)
• “Seek to understand first” & questions Maulie uses to empathize (17:30)
• When should leaders stop asking questions? (21:57)
• How to use the design thinking tool “A Day in the Life” to cultivate customer empathy and communicate between engineering and product (23:05)
• How to navigate your product vision versus feature requests from sales (28:45)
• How to manage and sustain your personal energy long-term (32:40)
• The impact of changing your communication style & having cultural awareness (36:03)
• Rapid-Fire Questions (39:17)
• Takeaways (42:19)

LINKS AND RESOURCES

• Get-Woke on Github - A tool to detect non-inclusive language in your source-code
• Mismatch: How Inclusion Shapes Design (Amazon) - Maulie’s book of choice for avoiding accidental exclusion in the world around us

TRANSCRIPT

Maulie shares the “expensive lessons” she learned while designing first microchip

Patrick Gallagher: We have uh, a warmup for how we kind of kick-off these conversations, Maulie, just to learn more about you, beyond your career story and to get to know more about Maulie as the person and the human being.

And so, one of the things that we do, and this is something we do with our different peer groups is ask people to share a random object from around their environment with everyone. So like, for example, I don't have, I don't have many objects with me because I've been driving across the country, but I have one important thing I want to share with you.

My pothos plant, Eloise.

Maulie Dass: Nice. Hi Eloise.

Patrick Gallagher: Eloise has made a cross-country journey. This is her second cross-country journey. So she is, she's very experienced in navigating the road. Um, However, she's had a little bit of a hard time on this trip because it's been so hot,. It's been 99 degrees. And so, my fiance and I are doing some plant rehabilitation.

So we bring her inside every time we come inside. And so she's got a couple of leaves that got wilted when it was super hot through Kansas. So it's Eloise. She's a, was it like a spotted pothos plant? Very special to us. We got her when she was about this big, so.

Maulie Dass: Oh, she looks like she's on the mend. That's awesome.

Patrick Gallagher: Yeah. Yes. We've watered her and tried to restore her back to life. So she brings a lot of joy to the family and makes all of the adventures. So, some people are crazy dog parents. Some people are crazy cat parents. I'm a crazy plant parent. So.

Maulie Dass: That's awesome. Okay. Well, I'm going to step away from my desk real quick to show you my thing, cause I'm guessing that's where you're going with this, right? All right. I'll be right back. Okay. One second.

All right, I'm back.

This - I don't know if you can read the text, it's called Vishakha. This is basically a layout of the first chip I ever worked on. Actually the second chip, back when I started my engineering days that I ever worked on.

It was based on a project which was a chassis-based networking system or switching system back in the early 2000s. And this was a port ASIC, and a port ASIC just means that it's like the ASIC that is, sits behind the RJ45 ethernet port. And this is basically just kinda like the actual printed layout of the ASIC itself. And then these are the actual prototypes.

And the reason I have this is because I was in design verification, which is all about making sure your chip works as much as possible at like, it is as bugless as possible. So that way, once it goes to the fab, you get the right chip the first time.

Now what this thing doesn't show is that the first chip we ever made, we forgot about a feature that we needed to test and verify. And so, when the chip - yeah... when the chip went to the fab and it came back and then it went, you know, we were like checking all of our things. And then it went to like through QA or like or testing functionality and like kind of a broader system, the QA engineering was like, "So the specific part about ethernet that you've forgotten to go into your chip doesn't work..."

And so we had to re - like fix the code of our ASIC, retape out and wait again for it to be fabricated, which is anyone who's in the chip industry when it looks like super costly.

So this is, we got the right ASIC on the first time, which meant that the verification process was successful. So that's something that I am proud of.

Jerry Li: Wow. What a long, expensive QA cycle.

Maulie Dass: Yeah. I mean, that's the thing. It's like, chip verification is probably the best thing to invest money into or tech into. Because then you actually don't have to spend that money at the fab, which ends up being like 10X the cost at a minimum.

Patrick Gallagher: That's so special too that you have that plan. I love that. I've actually never seen a plan, a layout like that from a chip in the early stages of the cycle. So this is a first for me and it's really special.

One of the big emergent technologies with chip manufacturing now is like using AI to help with the layout, like, to like what's the optimal physical layout as things get smaller and smaller.

I can't imagine like manually designing the optimal layout for a chip. That is something that is beyond my comprehension.

Maulie Dass: Yeah. I mean, that was like a really specific skill set. You have "place and route" engineers who were looking at computer design tools all day long. And like, they had to sit in a dark room basically to actually be able to see the contrast of the different layers on their screen, on their computer screen to know when to like connect things and stuff like that. So they were like, it was like the darkroom is what we called it, but it was like nine engineers that sat in a room that was totally pitch dark.

How learning and curiosity guided Maulie's career across engineering, sales & innovation

Patrick Gallagher: Maulie, it is so exciting to have you here on the show. Thank you so much for joining us at the Engineering Leadership Podcast. It's great to have you here.

Maulie Dass: Thank you for having me. I'm glad to be here.

Patrick Gallagher: Jerry's background is in software engineering and engineering leadership. I have some sales experience, but you've done both. And now you're also leading Cisco's Innovation Lab. So your career story is absolutely fascinating and it really emulates an uncommon path between what most people would consider two separate worlds, being sales and engineering. But we've heard from several engineering leaders on our show that the skills or the experience that they've learned from sales has been an absolutely essential skill to help with their success as an engineering leader, and to help the company adopt new ideas, to sell new programs, features, or just new paths and strategies forward.

Maulie, can you tell us a little bit about your story of how you arrived at Cisco's Innovation Lab? How and why did you go from engineer to business development and sales, and now back to innovation and engineering? Give us a little bit of the arc here.

Maulie Dass: Yeah, I think my career overall in the past 20, 21 years has been... the common through-line and like what guides my career is learning and curiosity.

And so, to your point, I graduated with an electrical and computer engineering degree. I went into design verification and design automation with a semiconductor company that was outside of Cisco, at National Semiconductor. And then I moved to Cisco, basically doing something really similar. And so I was in hardware design, board design, and ASIC verification and automation for, I would say like the first four or five years of my career.

And then as we started to see success in our product, I'd always get this news. Like, oh, this is like this board that your ASIC sits on top of is one of the best-selling products at Cisco. And I'd sit there and I think, gosh, I don't even understand why. I don't even understand that use case.

Why is this actually so interesting? Why is this flying off the shelves? And so, that was kind of the initial reason why I started to explore other roles. And there's a variety of field-facing roles, you know. There's post-sales or like support and professional services. So we have an amazing bench at Cisco of like network consulting engineers, for instance. And they're like, they're so smart. I can't even fathom it. It's amazing.

And then you have like folks that are looking at, okay, what's the product roadmap, what should be, that's like your technical marketing bench, and then you have actual sales and sales engineering. And they're the ones that partner with an account manager in a traditional enterprise tech sales environment. And they'll go out and, you know, build credibility. What you're selling really is your trust, but you are right in front and center of customers and their pain.

So I went from engineering to sales, spent about 15 years overall in sales and a variety of roles. Ultimately fell in love with "what is next," because a customer could say, "Hey, I need a switch that does X, Y, and Z. "After a while, you know, you're kind of normalizing your story. The value is normalized. This is just how you solve this problem.

But what about those problems that aren't solved and they're actually tough to solve? And what about like the stuff that doesn't exist or is really nascent or really emerging? Like what can we do with there? Because that's where the new market opportunity is.

And so even in sales, my journey gravitated from sales engineering to actually business development and kind of building net new, and always thinking about the art of the possible.

But the challenge there is you can only do so much in sales, right? At the end of the day, when stuff hits the fan, you have to help the team make the number.

And now this is about, I guess, 20 years into my career. So this was just last year, exactly. I thought, okay, I'm in my mid-forties. I'm gonna, you know, I'm thinking about the back half of my career. I want to stay employed. How do I do that? Cause you know, you have age-ism and whatnot in tech and so I was like, okay, I want to modernize my skillset. There's a lot to do here. So many things have changed. The last time I coded was when code wasn't connected to the internet. So I have, oh, this is going to be a lot.

But what I know is I have empathy towards customers and their pain. And so maybe, and what I have is a fondness for net-new and the unexplored. And what I know I'm good at is, you know, having a big, hairy, ambiguous problem in front of me with no clarity and then just going after it, figuring it out. So maybe innovation is this right spot.

And I got quite lucky to find a role at that particular time. And now I lead Cisco Innovation Lab. So here I am. So now I have gotten back into coding. So many things have changed. So many things haven't changed. That's like an experience and a trip on of itself. The best part about my job is I get to talk with customers all the time.

Not in a selling capacity, I don't need to do that. We have amazing talent Cisco that sells very well and aligns our solutions to customer problems. But I get to always have the conversation like, what's next? What's unsolved for? Should we go figure it out together? And so that's the journey of my career.

What engineering leaders can learn from sales

Jerry Li: Since you were working in both the capacitive and engineering sales, how do you feel the difference between very two different peoples? Because, at one point in my career, I started at a company and the sales team stayed on one side of the office... Then our team stayed on the other end of the office, and they almost never overlapped.

And we don't talk to each other. We just know that the sales are really loud. Right? And you want to be quiet, right? Don't want to be interrupted.

So, you have seen and worked very closely with engineering and sales. How do you see the difference? And what you can learn or what have you learned on the sales side that you believe can be helpful for engineering leaders?

Maulie Dass: Wow. Yeah, it's a great question. And Jerry, I think you, kind of, talked to it. There is a pretty significant cultural difference that I noticed going from engineering to sales, and now coming back from sales to engineering. There are visible differences to your point, like separate sides of the building or you know, of the campus.

Different cars, that was something I immediately noticed. I'll tell you, like one time I went, I got one of my jobs. I was a business development manager at one time at NetApp, and I spent two years at NetApp in between, you know, to a stint in Cisco.

And the first thing I noticed is that the minute you walk into the sales parking - are you driving in the sales parking lot at NetApp? It's like Beamer, Benz, Lexus, Audi, you know, like fancy. And I drove in with my beat-up Honda Accord. And then literally the next week I bought a Lexus SUV cause I was like, I just don't want to have this complex, you know? But you know, in engineering it's like, your car is not the way you build trust. And it's like a silly example, but would be such a stark difference actually.

So I challenge everyone to take a look at the sales parking lot and the engineering parking lot, just to like notice, is there a difference? Is it not? Because maybe there's more alignment. Maybe there's less.

The other is from a visible perspective, even just wardrobe, because if you're customer-facing, what you don't want to do is have any aspect of your appearance influence your outcome. Which typically for a salesperson is a sale, or it's like more than anything, it is gaining trust with your customer.

When I went from engineering to sales, I mean, I had ripped jeans and I just had the flip flops at work every day. And, you know, stuff like that. Probably shouldn't be doing that anyway, to be honest, but like, you know, that's just kinda how it was. And then when I went to sales, I was like, all right, I have to, have to clean this situation up here. So I like got some collared shirts, some non-torn jeans, some close-toed shoes. And then I was able to start building technical, or rather trust with the customer.

In contrast, now that I'm back in engineering, it's like my very buttoned-up wardrobe that I had for sales is completely useless here in engineering. This is a way to actually... like I realized this is kind of a visual way, as a leader especially, where that could impact my credibility.

And so one of the first things that I did in the first month of my job last year, it was like, “all right, let me go on Amazon. Let me just buy a whole bunch of t-shirts and move on with my life!”

You know? and we just solve this problem really quick. And it works. It worked out well.

Then there is the cultural nuance. I mean, Jerry, you mentioned kind of like the volume factor. Sales is an emotional role. It is because you are constantly in the job of listening, of connecting, of trusting, gaining trust, empathizing, building that relationship, and differentiating your products from your competitors. And by way of a relationship, in addition to technical capabilities and awesomeness, you know.

And as a result, there's more energy that goes into showing up as who you are. And so, I remember my first sales meeting. I walked in, you know, and it was really just like a commit call where everyone's going around the room and talking about what they're going to deliver for the week, what sale they're going to deliver.

And there's so much applauding. It was crazy, it was so loud. And I kept thinking, is this the state of the union? Like why is everyone clapping all the time? Why is everyone, so overly interested? And then, cause right before then, like a week before I joined that job, the only way to communicate with my colleague who literally sat in the cube next to me, was to email him. Because it wasn't comfortable or it was too loud or it was too in your face to actually go to his cube and be like, “Hey, can we talk for a second?”

So yeah, that was super different.

Then I would just say there are more similarities than less actually. And as a leader ultimately it comes down to making sure whether you're an engineering leader or a sales leader and, you know, you've gone one way or the other - making sure you empathize with what someone is trying to solve for and aligning.

And, my point of view on leadership is servant leadership. It's how can I actually help you get to where you need to go? Ultimately that'll help me in where I need to go too. But, let me just listen. Let me just seek to understand. And that seeking to understand is just common all over the place. That's just leadership.

So, that's where I sit now is I'm able to leverage my sales skillset and just ask interesting questions. The goal of sales is to never ask a binary question. Like, “do you like this product?”

Yes or no.

That's not the right question.

“How do you feel this product could potentially solve your issues? I have some ideas, but I'd love to hear from you, madame customer.”

And ask them those open-ended questions to seek to understand. To expand the opportunity of working together... that fits right into engineering just fine.

Jerry Li: What I hear so far is the emphasis on both sides of the seeming difference in style, in many ways that shows up in engineering and sales, is driven by what each team is optimized for. There's a reason. And the overlapping goal of that is to make a business or a company successful, but they're just in very different circumstances.

So one side needs more energy, one side needs more focus. That comparison provides a lot of empathy.

Maulie Dass: I think that's a really elegant way to say it. In sales, you're trying to drive trust; in engineering, you're trying to build competence, focus,

strong command, and clarity all the time. And yeah, that'll absolutely drive a work culture and communication style.

"Seek to understand first" and questions Maulie uses to empathize

Patrick Gallagher: You mentioned some, just gold nuggets of wisdom in terms of interacting with people. So you mentioned “seeking to understand” as fundamental leadership. That's something that I learned in some early sales training. It was “seek to understand first, before being understood.”

And that's a mantra that goes on before any meeting or conversation. And then the other thing you mentioned, where there were certain questions that you found to be really helpful as a sales leader. I was wondering if we could deconstruct those two things for how you apply those principles to leadership.

So seeking to understand first, when it comes to working with different people or trying to navigate and figure out a problem or figure out what's the next step? Or questions that you use with your teams that you've learned from sales that have been helpful in terms of navigating the organization forward.

Maulie Dass: Seeking to understand, I think is really, “know what you're seeking for.”

You're seeking to understand the pain. And so when in a customer context, and even like... now that I'm back in engineering, we're still meeting with customers. I'm really trying to get to the heart of the matter.

So, even if a customer is very clear on maybe a solution that they want. "I need an AI ML solution that does X, Y, Z." Okay. The question that I use often is "Tell me more about that". Like, what is instigating this need. You know, for those that are familiar with observability, it's kind of like doing the trace of like, what was the genesis? What was the path that led you to like this clear idea that you need this X, Y, Z solution?

And so think of the next question, that'll get you closer and closer to the source, or the root of the issue.

Tell me more about that?

What are the challenges that are driving your thought process?

Or what are the things that are really driving your strategy?

What's the burning platform? That's actually one of my favorite questions because it's like, “where's the building on fire? Like what's the hot mess?”

And sometimes I actually ask a question by giving an example, like “For us, the burning platform is data normalization...” I mean, I'm just making stuff up by the way, for, you know. “Here where we are, the problem is this and this and this, you know, this is what we're struggling with. Are you seeing the same things?”

And that's a provocative question. Cause I think they could say, “yeah, oh my God, we are totally there. We are, you know, we're challenged with this!”

Or they could say, “yeah, no, not really.”

And then, if they're just like sitting there and say, “Nah, no, not really.”

Then it's like, okay well, then talk more about this. Help me understand it. Sometimes even just saying, I'm going to, I've seen account managers or sales reps say, "Well, help me understand this." I think those are all like fine questions.

It's like, this is what I call party conversation. And sometimes it's just like, get folks in the mood. It's like, the art of like the initial social conversation kind of like what we did to start, this conversation was like, “Hey, show us something on your desk.” All right. That's like actually a cool party trick, very well done.

One of my favorite questions is have you seen any good movies lately? Have you gone into the office recently? What did that feel like? You can have like these, any kind of real-time questions that might actually just get the conversation going that always helps and that's a good party conversation.

But then if you're hanging out with a friend and they're just like, "God, I'm so frustrated. I need to figure this out..."

Like a good friend would seek to understand what's hard about this without having to solve the problem!

And here's the rub: is that sometimes when you get a lot of engineers in the room, and you know... they're so smart, they immediately go to, "I know what your problem is, and I know exactly how to solve it."

Not necessarily. And this is the rub... This is where a stint or a stretch assignment or a rotation, or even just shadowing a salesperson is always going to be really helpful because you get to see the stark contrast of engineers that are going in, making some assumptions, and solving a problem with the toolkit or the portfolio of products or tech that they have in their head.

Whereas a salesperson might actually say, "Hey, if I can actually get to the very, very specific problem that you have, then I can bring in my engineer. We can align to... or then I can have an engineering conversation with you. And we can align to like, “here's why this product that I have can actually solve your very specific problem."

There's an art to that, but it's - actually, there's no art to it. You just do it.

It's never assume that you know a customer problem. Always seek to listen. Empathize. If you're having a hard time empathizing with a customer that's where you can also start to ask more questions about seeking to understand. Cause it's better if you can relate to a problem.

When should a leader stop asking questions?

Jerry Li: Where do you stop asking? Where you know that you got to the root?

Maulie Dass: For me personally, Jerry, I stopped asking when I can relate or empathize with problem.

Now, I think Brené Brown defines empathy as, you're connecting to someone else. You're using something within yourself to connect to someone else's story or experience, something like that. I think that's very true, you know, in a customer conversation. It's even if, you don't know exactly like the internal workings of their product or process, but like the minute you can start to relate and be like, oh, that's really hard. Uh. Oh, I see. That's kind of what I stop asking questions.

Now this could actually be really inefficient. If I'm just like, I cannot relate to you, I do not get the problem... so that's why you want to bring more folks in the room. And this is where design thinking comes in really handy because now you have a methodology for user interviews and building empathy. So that way you can have user, like you can clarify what an end-user experience looks like and what the case study is, what the story is, et cetera.

Design thinking is like a way to kind of help, in an efficient, methodical manner. Get to empathy and stop asking those questions or, you know, know when to stop.

How to use the design thinking tool "A day in the life" to cultivate customer empathy and communicate between eng and product

Patrick Gallagher: So I wanted to go back to one of these, you mentioned very early on, Maulie, and you shared the moment where you were like, I don't know why people love these chips. Like somebody sent me an email and like told me why this is so amazing and impactful, but I don't know why I don't understand the customer, and I can hear this key focal point and this sort of through-line through your career, around customer empathy and helping people solve problems. And there's a lot of lessons from that and,

and I was imagining, I'm also imagining, like in sales. I'm thinking of the friction point between sales and engineering oftentimes feels like there's a disconnect between what engineering wants or what sales wants, and because sales is in contact, in conversation with the customer every day. And when the customer says, no, I don't want to purchase your product or platform or whatever. That can be really emotional, like, "Ah, crap." Like we lost that and they're not buying it because we don't have X, Y, or Z, and engineering on the other side may have a certain point of view for like what's right for the product or platform to move forward.

And there could be tension there. But I think the thing that connects all that is, the customer empathy and that how you align both of them is if you can have an empathy and a clear understanding across both about what's right, or what's not for the organization, that's important.

We've had a lot of people ask us in some of our small peer groups share... "My team is scaling really fast. We used to do customer interviews and our engineering team felt really connected. How do you help cultivate customer empathy with the different engineering teams or the different people touching innovation at Cisco?"

And as that scales and becomes bigger, because I think that's one of challenges as the organization becomes bigger and more abstracted, that connection to that customer pain, and creating that empathy becomes harder to do.

It was kind of a long windup for a big question to get to that point. But that seems to be a common friction point between the two groups.

Maulie Dass: It is, it's all about telling the story. How do I convey empathy? And so one of the tools that we use is called a day in the life.

Now, back in the day - maybe we still do this - but I remember when I was, you know, a sales engineer. I would go to these internal conferences at Cisco to learn more than about the depths of our products. And one of the sessions, it would always be a part of these conferences was a day in the life or a packet walk. And it would be okay, a packet comes, you know, it's ingress. It goes through the RJ45 port. It hits Maulie's port ASIC. Right.

And then it, you know, gets arbitrated to this other path and it goes to that port ASIC and then this happens and it goes to that, you know. Cause like even just from a system and like kind of doing a day in the life of a packet with something that is like, it's always, actually really meaningful to understand what's going on.

The same can be said for a customer. Let's do a day in the life of a customer. So the way we actually tell a story is to do a day in the life. So for instance we just started working on a project run: how do we actually, post-COVID, really augment the fan experience as they returned to the stadiums for a football game or a soccer match, or, you know? And one of the reasons that this was instigated is because I have a really smart team in Japan that has really collaborated in the past year over like, okay, how do we help with the Olympics? How do we ensure their safety with the Olympics? What can we do? Things like that, and that kind of instigated this other process around like, okay now at some point someday, we'll all be getting out of our houses. We will all go be going to these events. What happens? And so you start to do the day in the life. I'm going to drive, you know, I live in San Francisco. I'm probably gonna be stuck in traffic. I'm going to drive two hours to Levi's. I'm going to go through, I'm going to park. Then I'm going to walk in.

There's a security gate. I have to now use a clear bag. I can't have like a, you know, actually, my other bag in the car, you know. It's all these things. And there's probably going to be a temperature check or something. I don't know, like a COVID health check of some sort. Right.

And then maybe there are some aspects of social distancing that I have to be mindful of. As an event planner, you know? I walk in, then what do I do? I go get a drink. I go sit down at my, you know, or maybe I find my seats first, and then I go get a drink, so on and so forth.

Right. So it's kind of day in the life, but then being able to play as an overlay, the pain. What's the pain doing that? How, what are the inefficiencies in this day in the life? What is the sequence of events that kind of yields this pain?

That's what we do here all the time. And so literally it is a slide or sometimes it's actually in Figma. And if we can show like, kind of like the example of a day in the life in terms of a mock-up but that's what we use often to convey a story.

And sometimes it's like with fun cartoon characters and stuff like that. So that way you're kind of abstracting, like your perception of real people and you're kind of able to get to the heart of the matter, which is the pain.

Jerry Li: Very timely insights for ourselves as well. And this is the first time I heard of this approach.

Maulie Dass: Yeah. Well, it's, such a useful tool because you can, I mean now it's like, I feel like we use a day in the life to articulate when I go travel now to see my mom, my partner, and be like, okay. Day in the life.

So we're going to get there. I'm going to drop you off. I don't want you to take a left, you know, just be on the safe side. You're gonna get there, you're going to put on your N95 mask. You're going to put on your face shield and you know, just make sure you have your ID. Like, again, it's kind of like the sequencing. It's like kinda like a checklist manifesto, but you're like going through this all the time.

It's a great way to tell a story.

Jerry Li: As engineering leader, one of the common challenges we heard over the years is that the feature requests from customers bring back by salespeople. They think that adding a feature can help sell the product and keep piling up. And you and your leaders, sometimes they feel less empowered because the sales conversation or their argument is something that can bring revenue to the company while your own team itself, it's expensive to run.

So, when a decision has been made, do we add a feature, or do we optimize for architecture or productivity, whatever.

How to navigate your product vision versus feature requests from sales

Jerry Li: What are the insights you have that can help a new leader to navigate some of those type of situations, whether you have a vision for a product, that something that we're probably going to come up with more tech like that in the future, but short-term is going to help us win sales?

Maulie Dass: Yeah, that's a great question. I think qualifying the business case is super important as a leader. And it is really, is there return...? If I pivot, maybe here's my roadmap right now. I was thinking about these features, but now sales wants me to think about other features. If I do that, what's the gain?

This is a very interesting question, Jerry, because a startup might be more keen on thinking about their biggest customer and whatever their biggest customer, right? Because you just gotta like, get fed. And not just sales, but the entire company. So you just gotta like serve that big customer, right?

So it's the squeaky mouse that gets the cheese. That's kind of what my guide and engineering roadmap for a leader is. That's a business case in and of itself. Is "We're going to get more out of this customer than all of our other customers combined. It's worth it."

Then you have like really large organizations, like at Cisco where... and we have like 16,000 plus salespeople at Cisco. So, if they all were to come at every single engineering manager, be like, we want this and we want that. The question is, how do you aggregate that? Right?

So to build a business case, first what we do is we have a tool that sales teams can interface with and it's a feature request tool. And the backend, and ideally it's kind of aggregating and we're doing some analysis on these tools. We're understanding which segments these features would serve the most.

If there ends up being a critical mass of a feature that's just like, “oh, you know what? Across every single segment, across multiple customer geographies, this seems to be a pain. We need to solve for this.”

And usually, those are pretty apparent. If you're surprised by what those are then that's another leadership opportunity.

But if there's asks from the sales team that arise like that? All right. That is probably a no-brainer and your business case can likely show the value of prioritizing those features.

Then it is, I think based in partnership with a product manager, “what is really important for the life cycle of this product?”

If you're in a certain part of the lifecycle where it's gonna retire, or go off into the sunset in like a year or something, maybe it's not worth it. If it is something where it's like, “oh, you know what? This is alive. And we have two-plus years to, focus on this?”

Like, yeah. Or this is actually going to serve another segment of the business with these other products? Okay.

And so I think it always ends up being, and you could drop it down to like, if then else and like, what is like the best outcome.

I think it's tough because you have to let go of your attachments. And you have to put, as a leader, your company hat on and your shareholder hat on and be willing to call your baby ugly, be willing to pivot and go to where the market needs because reality is even if you had full agency to go forward with your feature set in your plan, regardless of, you know, contradicting sales input, your stuff is not going to fly off the shelves. So what's the point of view of designing this product anyway? What's the point? Like always have ongoing alignment and how that feedback, and if your customers are giving you feedback on like, “Hey, please put these features in.”

That's meaningful to listen to, and at least be aware of. It's always the business case and always qualifying and doing the if, then else to find the best outcome

Jerry Li: Yeah, it's helpful to know the two ends of the spectrum, as a startup and also large enterprise. I guess the missing middle is the part that gets people confused. Like as you grow, as you scale, initially it's clear. But at one point something changes and you have to learn to adapt, and all that can be something interesting to dig into.

Maulie Dass: Yeah, that's hard. I mean, and as long as we can be agile, to pivot, and we have executive sponsorship if we don't pivot. That's also super helpful.

How to manage and sustain your personal energy long term

Patrick Gallagher: So one thing you shared Maulie that I thought was really interesting was one of the biggest differences that you noticed was in energy, and considering how you show up from an energetic perspective and how there are differences between sales and engineering there. I think there are some interesting correlations to communication with that.

So I was curious to know, like, are there certain sort of practices or ways that you approach, generating the appropriate amount of energy for your audience that you carry over from your experience with sales to the work that you're doing now?

Maulie Dass: Yeah. I'm definitely in the camp of I had to learn how to talk to people. I thought I was an awesome communicator and when I went into sales, I really, you know, that's kind of why I go to, like, that's how I actually created those like, party conversation. Like, you know, what's your favorite movie? Or now, these days, it's like, what are you watching on Netflix?

You know, you know, my go-to is, you know, to just kind of get the conversation going and it's a good way to gauge like the other person's way of communicating because there is this aspect of miming that I think we naturally do.

Like I have this tendency now, like I'm looking on this video feed and you see Jerry like, leaned back at his cup of coffee and - pardon me, one sec. So I'll do the same thing: lean back, get my glass of water, right? Like we mirror all the time. And this is a kind of uh, nonverbal way of just kind of aligning with someone.

And so for me, to be able to kind of modulate everything from volume, to energy, to body language, you know, how expressive I am. I think there is a cultural aspect to this and it's just, you know, cause I have a global team, one of the tools that we have at Cisco is called GlobeSmart where it basically, you can actually put in all the different locations of your team and you can also basically use this tool to characterize yourself and it will match how similar or different you are across different cultures represented in your team, which is incredibly helpful because it's a way for me to not only modulate my communication based from a cultural aspect but also when I'm listening, maybe if there's a culture that's super direct, I shouldn't take things personally. If there's a culture that's super indirect, maybe I should try for clarity in a different way and things like that. So there's one piece.

And I think that the cultural piece, especially as, you know, the world just gets smaller and super important. The other is, just like getting the conversation going and just kind of understanding how someone is like showing up. I will say that I'm not an introvert, but like, I mean, I know after this conversation, I'm going to need to like, just take a break.

For me, there was a point in time where like, I'm very much in the middle of the scale. I do need to recollect my energy. And so for that, it is planning what I did before this, as I block off 30 minutes and right after this, I've blocked off an hour. I should know myself. I just know I'm going to need that time. And that's okay.

And that took some practice with sales because there were times when I was like back to back to back. But the thing is, is, I have shown up poorly when I do that, because I just didn't have the sustaining energy to constantly have to socialize, what our products do and what our value is; it just gets tough.

And even if it's the same conversation, cause there are times in sales where you have the same customer problem over and over and over again. So it's like, Groundhog's Day, we have the same conversation over and over and over again. And even that is draining. Just because you have the pitch in the back of your head doesn't mean it takes any less energy. So those are the things I don't know if that's helpful, but definitely being aware of your audience, knowing like any type of cultural nuances.

The impact of changing your communication style & having cultural awareness

Maulie Dass: I'll just add one last piece. This gets really interesting from a recruiting perspective. So, you know, our goal is to always be very inclusive when we recruit. But what's really interesting is that, if you think about gender, like how women apply for roles or when women feel like they should apply for roles versus when men feel like they should apply for roles are really different.

There's data that just shows that men will take a look at a job announcement or job requisition, say you know what? I kind of like, meet, like 40% of those requirements, I'm going to go ahead and apply.

And so many women, and I think there's also a cultural thing, I don't think it's just a gender thing, but so many people will take a look at an entire job requirement. Like, you know what? I only meet about 80% of this. I don't think I would get the job. I wouldn't even think I'd get an interview.

And what I try and coach my team is when you know your audience, you know who you're trying to recruit, just know that your approach is going to have to be different and you're going to modulate accordingly.

So when it comes to us trying to get more women engineers on the team, we have to actually recruit and encourage, because many of them are looking at a job record and saying, "You know what? I don't think I would apply.

And then you see some engineering managers saying, "you know what? She's really good, but she basically thought that she shouldn't apply." And it's like, maybe that's on you, right? And how you're communicating and how you're reaching out because of your audience and of your recruiting target basically. So that's kind of an interesting example

Patrick Gallagher: I think that is a really interesting example because it's flipping the agency. We've done a couple of different events where we've dove into some of the statistics around women more often self-selecting, especially around like if your job applications have more gendered language, like more masculine gendered language, it turns away candidates. And for the same reason of like, if you have extra job requirements or responsibilities there that are sort of extraneous to the role more often to self-select out of that process.

So we've done a lot of work around like adjusting language and adjusting, you know, the reqs and scope of your job. But not about like the concept of like the, I guess the, you know, user empathy of like walking through what's that X person they thinking about when they're going through that job application process.

And if you've actively provided that encouragement, that's going to change that person's success in relationship in the role. I think that's really interesting.

Maulie Dass: Yeah. And then the encouragement isn't because that job is guaranteed to that person. It's an encouragement to say, "Hey, you should take a look at it too. And I encourage you as a hiring manager to take a look at it too."

Now you still have to go through the process and we're still going to pick the best candidate. But my gosh, just because you feel like you don't, you know, meet all of these requirements, that is not the reason you shouldn't apply. Yeah, it's a different approach and you have to have kind of an integrated marketing approach to this. We use Textio at Cisco to kind of make our job recs more inclusive. I think that there are other tools that have just come out of the inclusive language space or inclusive namespace, like get-woke for instance, that can also be used for these, which is good too.

Especially if you're doing whether it's from sales and you're trying to like, do the growth marketing thing, or you're trying to associate like anything in your funnel to actually a deal close, or if you're actually trying to target and recruit. I mean, you have to do more than the rec, the written word.

Rapid Fire Questions

Patrick Gallagher: Maulie, I know we've reached the end of our time. Do you have a few moments to wrap up with some rapid-fire questions? Are you ready to dive in with that?

Maulie Dass: Let's do it. Yes.

Patrick Gallagher: Okay, perfect. What are you reading or listening to right now?

Maulie Dass: I'm reading a book called Mismatch. I'm blanking on the author cause this is a rapid-fire, but it's all about how you know, taking, you have to take user empathy one step forward and actually be more inclusive with our empathy. So, and this is all so that way we can have inclusive product design, but it's a good book. It's called Mismatch. Check it out.

Patrick Gallagher: Second side note, I know these are rapid-fire questions, but I also, I just read your blog posts about "My fear of racist, sexist, homophobic robots around inclusive design practices". So I just wanted to shout that article out because I thought it was wonderful. Thank you for putting that out there.

Maulie Dass: Thank you.

Patrick Gallagher: Number two: what tool or methodology has had a big impact on you?

Maulie Dass: A The Day In the Life that I was talking about before. Being able to just sequence out a customer journey to understand pain and problems that they may be running to do, that I can solve for? That's been brilliant.

Patrick Gallagher: You can answer yes or no for this, we don't have to go super deep. But would you recommend like all the way down through the org, all the way to the frontline person, doing a sequence customer journey? Is that a practice you would have trickle all the way down?

Maulie Dass: Yes, absolutely. Hands down.

Patrick Gallagher: Awesome. What is a trend that you're seeing or following that's really interesting to you or it hasn't hit the mainstream?

Maulie Dass: That's a tough one. I think it's actually modernizing manufacturing. It's not like a super sexy example, I guess, but I think that it's a really important example.

Like we're all consumers of products. These products get made some way, somehow. There's a dependency on tech. If that tech is not modernized, if that tech is not, you know, composable, cloud-native, AI and ML-based, then like, oh my gosh, I think we're in for a world of hurt.

So I think that this is definitely a place that everyone's exploring. But the impedance is that like, there's such a fixed configuration of so many manufacturing environments. And so how do you actually get it to a place of like true flexibility and agility, which is what supply chain and manufacturing organizations need.

Patrick Gallagher: You shared some really good questions with us so far, Maulie. What's your favorite or most powerful question to ask or be asked?

Maulie Dass: What are you trying to solve? That's like the money question. When you've like hit a dead end and you just don't know, what are you trying to solve for?

Patrick Gallagher: Last one. Is there a quote or a mantra that you live by, or a quote that's been really resonating with you right now?

Maulie Dass: Well, one that I live by - I'm a huge fan of Oprah and she, uh, from a career journey perspective um, I feel like, time and time again, this quote has like shown valuable.

And it is "Luck is when preparation meets opportunity".

Patrick Gallagher: A perfect way to conclude Maulie. To have somebody who's sort of stood in the world of engineering, sales and innovation, and has bridged the gap of communication and creating empathy across all of those different areas, it just is so great to, to see how those different things translate to, to help our community bridge the gap there.

So thank you for sharing your stories and your insights and the things that have made an impact.

Maulie Dass: Thank you so much for being interested in my story. It means a lot.