Building Trust in Engineering: Strategies from Danielle Cooper

‍

Danielle Cooper, a seasoned technical executive with an impressive track record of nearly two decades in software development across diverse industries. Her invaluable expertise has been honed through engineering leadership roles at renowned organizations such as Northrop Grumman, Dematic, and Realtor.com.

What sets Danielle apart are her extraordinary superpowers. She possesses an innate ability to navigate through ambiguity, allowing her to pinpoint and execute actions that yield the maximum impact. Additionally, her exceptional talent lies in communicating intricate technical concepts in a clear and concise manner, ensuring that all stakeholders can grasp the information and provide crucial business support.

With Danielle's exceptional technical prowess and remarkable communication skills, she is a driving force behind successful projects and strategic initiatives. Her comprehensive understanding of software development combined with her talent for bridging the gap between technical and non-technical stakeholders positions her as a valuable asset in achieving organizational goals.

Partner with Danielle to leverage her wealth of experience and unrivaled superpowers in software development, and witness the transformative impact she can have on your business.

‍

Host:
Hey, Danielle! How are you doing?

Danielle Cooper:
I'm doing well, good morning.

Host:
Good morning to you too! It’s a bright morning for you over there?

Danielle Cooper:
Yeah, I mean, it's actually really gray, but it comes through. It's really great.

Host:
This is some good wind test, then.

Host:
Um, I'm gonna introduce you a bit.
So, this is Danielle Cooper. She is a software engineering executive. To put it lightly, she's been in the industry for over 20 years and she's led lots of different teams as a staff engineer, as an executive, and sort of just pushing software at least to its brink when it comes to scaling and these sorts of issues.
And we're going to talk to her today about a bunch of tech subjects in general and a bunch of leadership subjects in general, and we're grateful to have her here, so welcome.

Danielle Cooper:
Thanks!

Host:
I guess my first question is, what were you doing on that wagon?

Danielle Cooper:
Oh, the wagon? You need to let you in.

Host:
Yeah, that was in San Diego. There's a part of San Diego, I believe it's called Old Town, and they took like the original San Diego and put it out there. But I loved the wagon, and I thought it was a good representation of modernization.
Danielle Cooper:

I got it. I thought you went—I thought you went to the Amish community and were there and talking about moving forward, and then that whole— I thought that's where you were going with it, but I thought that was cool.

Host:
Totally. Yeah.
They were not interested, as it turns out.

Danielle Cooper:
I think that's fair. Teach their own.

Host:
Yeah, for sure.
So, okay, so let me ask you, first of all, how did you get into computing in the first place?

Danielle Cooper:
So that's—I would say a short story. I started as a math major, and I was like, "What am I...?" I mean, no offense to any math majors, but I started talking about careers, and at the time, like, data analytics and stuff wasn't super big or wasn't known to me, and so I was like, "I'll just make other math majors that will be my path," and I'm not interested in that, so I moved over to computer engineering. But it started long before that in...
So my mom wanted me to be a Girl Scout, and I was like, "What? Why would I do that?" Just when I was in elementary school. She was like—she really wanted me to be a Girl Scout. She had this dream of a daughter. And she told me later, like, she wanted to sell Girl Scout cookies—that was her real intention. But I was like, "Those seem like just-in-time skills that I can learn on the fly. I don't really need to, like, learn how to make brownies."
And then they got to go see the robots at Chuck E. Cheese, and I was devastated. And I'm like, "Oh, this has always been my path." I've always been interested in robotics and coding, and I've always thought it was fascinating. So it's been my path from a very early age.

Host:
So Chuck E. Cheese got you into being an engineer. That's the highlight there?

Danielle Cooper:
Pretty much.

Host:
Okay, alright. Well, how did you get into cloud computing specifically? How did you—and that's a reasonably new space—so what made you interested in that relative to all the other things you could have gotten deeper into?

Danielle Cooper:
I think it was two things. I love making people happy with technology, right? And then that lends itself. But even in the early days, before we had clouds, right, we kind of had—we were running lots of virtual machines within VMware to do a number of different things early in my career.
It was just fascinating to me, the power of that, and then it's just a new puzzle to solve—how do I make this so fast and so efficient? And those problems are just very fun for me to think about, so that's kind of how my first foray happened, like, you know, when we first started playing around with virtual machines. Just the power of it and what you could do. So at my first company, we actually—our development environment was always in a virtual machine, and that gave us the power to do a lot of different things and spin up our Dev environments very quickly. So people weren't spending hours and hours building their Dev environment before they could even touch code; we were passing around images or build scripts to just create the VM that you would be in. So all of that just got me really excited about where this could go.

Host:
We actually had someone from VMware on the podcast last time, which is interesting that you're bringing it up again. So they talked a lot about solving problems at scale and for different industries and things of that nature. So I do want to ask you, what industries have you seen cloud computing really assist in, in your experience and your career?

Danielle Cooper:
Anything that has massive amounts of users or massive amounts of data, right? It really helps with that. And part of me wants to say, well, any industry could really benefit, right? But there's a cost-benefit analysis of, you know, is it really worth the extra complexity when we can run everything natively on one machine? Which isn’t really common at this point, depending on your industry. Or where you're at—where, you know, you're a startup, don’t have a lot of consumers yet, and need to get something out quick and dirty, because “dirty” is not always my special skill. I'm like, "Oh, let's build. We can relax when you design that." Or, yeah, you write the design for it, and then you're like, "Okay, now, how are we going to start small and scale?"

Host:
So you've had some experience in lots of different companies. One of them is realtor.com, and the reason I’m asking you this is, I guess, where I am, there was a huge wave with housing and purchasing, and I think that happened in North America in general. So I'm super interested, from the inside, in how you were able to deal with that. And I think that was quite the scaling challenge—there were a lot of scaling challenges in general during that period. But it's always interesting to see, especially in that market, how that scaling challenge was dealt with.

Danielle Cooper:
Yeah, so the infrastructure was set up to kind of already take on peaks and valleys. In those terms, we were a little set up. In other ways, we exposed flaws in the infrastructure. You know, like, talk about it—almost, you know, weeks—much stronger partnership between marketing and engineering. Because what was happening was, "What the heck? Where are all these spikes coming from? Are we being attacked? Like, what's going on?" We had this happen more than it should have, probably. But what was happening was these marketing emails were going out, and they were incredibly successful. And so we couldn’t—we weren’t scaling fast enough to hit all the influx of traffic. Like, over time, yeah, we could have hit the numbers, but the system just wasn’t set up to handle that. So we started a better partnership between marketing and engineering of, "Hey, when are these things coming out?" Because we also wanted to keep costs down, so not having a lot of stuff just sitting there waiting, not being used. So that partnership—we had to get a little better at it, create a shared calendar, send some reminders out, "Hey, this is about to happen," and scale up and down from there. Strategies for building trust came into play as we realized the need for more coordination. So that's one challenge that I saw that we had to overcome. We were set up to handle the slow growth, right? But not the "Oh my gosh, we didn’t realize everyone clicks on it at the same time." So, I mean, we didn’t realize, we didn’t know that many people would be that interested. So kudos to the marketing team, right? They were writing some really impactful content. Trust-building techniques helped us create a smoother workflow between teams, as we started to understand each other's needs more clearly. The team really stepped up and showed the importance of fostering trust, especially in the face of these sudden challenges. We didn’t panic because we had built some level of trust already, so we knew we could adapt together. One thing that worked was having clear accountability in teams, where everyone knew their role in getting things done and making the necessary changes when needed. The better we got at this, the more it became apparent that leadership in engineering also played a key role in supporting these changes and pushing for the necessary infrastructure improvements.

Host:
Right, right. So this sort of leans more into your expertise in general, which is, we have an engineering team, we have other parts of the business, and we want to build a relationship that's beneficial for both, because ultimately, the goal is to bring that business forward. So if you don’t mind, could you talk a little bit about how you were able to—you know, I think with very disparate mentalities.

Danielle Cooper: 

Engineering and marketing build that relationship because these, I think very much, are very opposite kinds of people.

Host: 

Yeah, and um, we had talked about this a little bit before, right? Like building the business case for what you need in engineering. So, if you have, you know, and I've been in companies where the entire chain is pretty technical all the way up to c-suite, and so when you say, "Oh, we need to automate this or that," everyone just automatically understands why that's going to allow us to generate more revenue, be more efficient, get stuff out to market faster.

But if you're a non-technical, very business-oriented person, it’s like, "If it ain't broke, why fix it?" And then okay, well, what's our definition of "broken"? But, you know, building that business case for why we need time to conquer, let's say, tech debt or automation, like saying, "Hey, we could decrease our time to market by 30% if we can get this automation of our deployment in place."

And it's been interesting to me as I move from company to company. To me, it's table stakes to have an automated deployment, but I've talked about so that they are safe, and that they happen very quickly. And they're not reliant on me not being tired that day and not fat-fingering a number, which is something else that's happened. Number of clusters was way too low because somebody, and like, why are we allowing that to be manually input with every build? That's a whole other thing. So, like being able to talk about these use cases to the business. And unfortunately, sometimes for those, "Hey, we're about to run into this scenario," until you run into it, there's just not going to be a lot of listening.

But what you can do is use the mistakes from industry to say, "Hey, look what happened over here. We're actually at risk of that too." That helps get some fire under it. But also saying, "You know, this is how much money we can save, this is how much quicker we can get to market," like put it in terms of, "How am I going to benefit you as a business person with this tech change that I really want to make," is important, right? So that, you know, whether it's marketing or finance or whoever needs to sign off, in a product especially, really, how do I tie those things?

And then another thing is measuring and keeping those promises. So, I've also seen where engineering makes those sorts of promises: "We're going to get this 30% decrease in time to market," or "We're going to save this much money." Either we don't measure it and we don't report it back, or it takes too long, or we never quite get there. And products can really feel it, and then they're not going to trust the next time you say, even if you have data, they're like, "Well, yeah, you said that last time." So really delivering on those promises and measuring and showing that it happened is an important part of that relationship building.

Host: 

Right, so from what I got from that—measuring, obviously communication, business case building, and all those things essentially—they build trust for, I guess, that department or I guess that purpose that you're sort of pushing forward for. I saw something that you put up talking about, I think it was related to tech debt, and there was something needed to be done, and there was an issue, things were down, it wasn't upgraded, and the version of a module was so old, and it was from one language to another. And Google didn't solve, Google didn’t have that version. It was Python 2—I'm trying not to be too technical, but it was Python 2. They didn't support that, so you had to go to them and tell them to help you support that before so that module could actually work and things of that nature. And then you were able to do it maybe eight hours later, but if you guys had at that time had it a bit more modern, even a little bit, then that wouldn't have happened and all that. So, I’m sure for a lot of companies, a lot of different software pieces that are maintained or are not maintained, or at least maybe are focused on or are not focused on, right, because if it’s "If it ain't broke, don't fix it" mentality, it happens everywhere. So how do you sort of keep ahead on all these different projects, make sure all the changes within their own technical ecosystems are there, and for companies specifically? They're not really into tech and like having someone that's always, you know, bringing that technology forward. How do you, or have you, set up your organization to track all that stuff? Building trust in engineering is crucial in maintaining a proactive approach to tech debt and software upgrades, as it allows teams to manage such challenges more effectively. Establishing a framework for tracking changes within technical ecosystems also plays a big part in building trust in engineering, as it ensures that no critical updates fall through the cracks. The key to overcoming these hurdles often lies in trust-building techniques between teams. Ensuring that everyone understands the importance of keeping things up to date and communicating openly helps foster trust and ensures smoother collaboration. One of the strategies we've used is emphasizing accountability in teams, where each team member knows what their responsibilities are and how their actions affect the overall project. Effective leadership in engineering plays a critical role in encouraging this approach, ensuring that the team feels supported and clear about expectations while tackling these challenges.

‍

Danielle Cooper: 

Yeah, so I would say at least once a year, you know, we're doing an assessment.

Host: 

Like that's not too bad, actually.

Danielle Cooper: 

Yeah, I mean because, like, you're not—you will catch that big of an issue at least once a year of, like, what our technology is, what they’re running on, has that been end-of-life? There are so many things that are just kind of simple. So, at Realtor, we did an assessment across our platforms to talk about all of those things and also kind of create a map between what teams own what, where things are located. That just didn’t exist before; it was all kind of tribal knowledge. And so if you have that mapping, then you can highlight the areas of biggest risk.

And that’s something I learned from actually my time working at Northrop Grumman—doing risk assessment and really deep-diving into that. You know, and then there’s several factors that go into it. You can give it a score, and then you focus on the things—pick your top 10, your top five, whatever you have budget for—to say, "No, these are going to get cleaned up in the next six months" or however long you need. And one of those factors is criticality to your whole business. Is this on the critical revenue-generating path?

Host: 

Right.

Danielle Cooper: 

If it is, those things inherently carry more risk. We need to—they are our babies. We need to really be on top of those and spend more of our budget dollars on that. There’s always, like, you know, other ways we’re making revenue, but they’re not, like, the 50 or 60 percent of our revenue spread across, like, ten at five percent, you know. Those things carry less risk inherently. So that’s one way to really create and prioritize that list and make sure that you’re laser-focused on how you’re spending your budget. We only have so much budget to spend on these things per year. Look, let’s use it in a way that’s really going to make a very solid platform.

Host: 

Right.

Danielle Cooper: 

The easiest way to generate revenue is to keep your platform up and running. So that kind of ensures that. And it’s also telling your business partners, “We’ve done this assessment. If we have the budget, this is how we’ll spend it.” I’ve seen too many times where, “Oh, we, you know, just want 20% protected.” Sometimes that works, but—

Host: 

What do you mean by "we want 20%"?

Danielle Cooper: 

We want it to be only 20%—oh, 20% of our, like, sprint budget on either shoring up the system or tech debt.

Host: 

Right.

Danielle Cooper: 

And sometimes some product managers are totally on board with that for a number of different reasons. Some are not. They’re like, “Well, I need to see where that’s going.” And having that crisp list of, "These are the items and this is why they’re at risk for the business" can really help get you that budget.

Host: 

Okay, so I always think, why? What have you seen are the reasons why product managers are kind of, like, feeling a little bit uncomfortable with tech debt, right? Like, sometimes it feels more emotional than it is because it’s—I'm not—there's also, there's definitely, I understand that it’s not business—it doesn’t bring in business directly—but it is understandable that something needs to be maintained to some degree. So where is the mismatch? And especially with people with a lot of experience—if you see a very experienced person that doesn’t really believe in tech debt, what’s going on there?

Danielle Cooper: 

Yeah, probably in a bit of a psychologist’s job now, but—

Host: 

Yeah, right, right.

Danielle Cooper: 

And, you know, it’s the danger of generalizing people. But, you know, one of the things that I’ve definitely seen, whether we’re talking about tech debt or anything else, is we have typically two functions who have different goals, right? So product is to, a lot of times, drive additional streams of revenue, right? And that’s new features, what are we adding, how are we increasing the revenue coming in from what’s already there? Then we have engineering, who’s like, “Keep your systems up,” like uptime, DORA metrics, all of these things you should be pursuing. And so those thing. Like engineering I've seen don't even have those goals; they still have the product goals, but inherently, like we know we're not going to generate revenue if the site’s not up. So, there’s like this mishmash of product getting a lot of pressure to do different things, and we're not always communicating that very clearly. In several different companies, we’re not letting products know, “Oh yeah, did you know the system went down overnight and we spent eight hours getting it back up, and this is the estimated revenue loss from that time?” So, it was just like, because those things are such a fire within engineering, none of the product people were on our channels, they’re not seeing that happening.

I mean, I can remember a couple of very large tech incidents, and product had no idea it had happened. Then, it was interesting because we’d go into our monthly analytics meeting, and there’s this dip. “Well, what happened?” And we’re like, “Yeah, we had that major tech incident.” “Wait, what?”

So, having more communication is just key to everything. And then also, I think successful organizations put some of those quality metrics on the product managers as well, right? Saying we need to maintain and indeed increase our quality metrics, as in addition to uptime or all those things. And it’s interesting because if you think about consumer satisfaction ratings, right? A lot of it comes from reviews and all that, but a lot of that is this feature they never got. That’s part of it, and that’s the part engineering can control because some of it is like, “I don’t like the way this feature works.” Well, okay, we had some input as engineers, but a lot of times, you know, that was done with research from other teams, and we were just executing it.

But that, like, “Hey, does it function the way it’s supposed to?” or “Was it even there when I went to use it, or was the site down?” That’s something that we can all agree on but isn’t as obvious when you’re talking about consumer satisfaction. So, asking product managers, like allowing them to have insight into all of our quality metrics, and also kind of putting the onus on them that their teams need to maintain those in addition to driving new revenue streams, I think, can be really helpful with that. One of the strategies for building trust between engineering and product is making sure everyone is aligned on these goals and communicating openly. Effective trust-building techniques come from ensuring both sides understand the critical role each team plays in the company’s success. By fostering trust through transparency, you can reduce misunderstandings and foster a healthier working environment. Furthermore, it’s crucial to emphasize accountability in teams, ensuring each team is aware of their responsibilities and how their actions impact the organization as a whole. Finally, leadership in engineering can help bridge the gap by promoting a culture of collaboration, where both product and engineering feel equally accountable for the company’s goals.

Host: 

What kind of organization gets to the point where their product team doesn’t understand that something a product did didn’t work at a particular time? Because that kind of lapse in communication, they’d still have a functioning business. You know, there are some sectors that wouldn’t be able to absorb that, right? And then some sectors where it would be fine. So, or maybe some businesses. I’m not sure. But what is that like—what kind of situation can that happen in? The power grid can’t have that, right?

Danielle Cooper: 

Right, right. The power grid, well... Yeah, there's no way it's like, "Oh, there was no power on Tuesday." What do you mean? So, I’m just making sure I’m understanding the question properly. But yeah, yeah, I totally get it.
So, when you are... If you think about a website like realtor.com, right? There are a lot of different verticals within there, and if you have appropriately kind of micro-serviced yourself out, you’re not... For a lot of tech incidents, the hope is that your blast radius is small. So, if one vertical has an issue, the other ones aren’t impacted.
Also, a lot of things can happen underneath the hood that you just don’t become aware of, I think. And as we’re talking, another thing that can happen—as much as I'm like “communication and transparency, over-communication”—sometimes there’s so much coming at you, you just start to shut down. So you’re like, “Yeah, I muted that channel because I just have too many channels.”
So, appropriate communication. One of the things that I’ve set up in the past at multiple organizations is a Wiki page that says, “Hey, these are the channels that you really need to pay attention to. Here are some that are for fun, here’s some if you’re just really interested in...” What's going on in the business or engineering would be useful. So, like, kind of helping people self-serve but giving a little bit better guidance. It's very interesting to me when you're talking to someone and they're like, "How did you know that?" and I'm like, "Well, aren't you on XYZ Channel? It's all there." And they're like, "I didn't even know that existed." Right? So, while I love Slack and other tools, if you don't know the channel exists, it's not going to tell you. Building trust in engineering is crucial here, as it encourages teams to stay informed and proactive. So, how do we do that better?
Building trust in engineering also extends to creating a transparent communication environment where every team member is aware of important updates, minimizing confusion and fostering collaboration.

‍

Host: 

Yeah, I mean, how do we make sure that people are aware of these channels?

Danielle Cooper: 

Having sort of a mapping of that or like a Q&A bot thing that has the answer, like, "If you'd like to know more, join the Slack channel," right? Kind of like an index. There's another feature in Slack with that. I’m not here to endorse one product or the other, but I have my loves. That's true. Yeah, I could go on and on about that, about communication and these kinds of ways to index large amounts of documentation. We have people doing it in GitLab or Confluence or Google Docs; it's all over the place: Airtable. But if you have one index where you can just go in and ask a question and then it points to the right thing, that helps with that as well and allows people to self-service information.

Host: 

Yeah, that makes a lot of sense. So, essentially, you’re giving people a way to navigate the channels and resources more efficiently.

Danielle Cooper: 

Yes, exactly. And that's how you get to the point where you have multiple revenue streams, but some of the things aren't obvious. It's down, and no one knows that but engineering. So those sorts of things, I think, are how that can happen.

Host: 

Yeah, it’s interesting. It’s almost like you gave two examples of microservice architecture—one in the system that prevents issues from leaking throughout the organization, relative to different verticals, and then the other side in communication, where microservice architecture doesn’t work because people don’t have access to these local maximums in a way. It’s interesting, maybe for myself, to draw this sort of parallel between those two different things.

Danielle Cooper: 

Yeah, absolutely. And then sort of, to circle back on the communication piece, how do you communicate all these concerns to your engineering team? Because a lot of the things we talked about are how engineering affects business, but then, how do you explain to engineering how business affects them?

Host: 

Oh, that’s a good question. How do you do that?

Danielle Cooper: 

It can be very challenging, and it's funny, all engineers—myself included, when I started getting this feedback—have the almost identical response. There's never, "Oh yeah, that makes sense." Usually, there's a contraction in us that's like, "Well, that's dumb, they should just know." And I will say, it's very funny when I first started getting this feedback. I was thinking about it, and I'm like, "Yeah, that was my first reaction," because I was so used to having a technical chain all the way above me, so I never had to tie those things together for them.

Host: 

So you had never had to really explain those connections before, right?

Danielle Cooper: 

Exactly. And this feedback came when I was the highest-ranking technical person in the chain. So beyond me, I had to start speaking differently. And when I first started, it was just like, "What? Where did I land? What happened?" And then you get out and you start branching out, and you're like, "Oh, that's not uncommon. The entire technical chain being technical is actually uncommon." So yeah, you just continue, make the first statement, and you watch the contraction happen. You watch the frustration happen, and then, you know, you just start again.

Host: 

Yeah, I can imagine that kind of resistance. But once you get them to that point, it must feel like progress.

Danielle Cooper: 

Exactly. So, let's pretend like you don't know XYZ, and you only know about dollars and cents or time. How would you explain it in that way? And how would you make those connections for people? You know, and so, yeah, I like to talk about knitting sweaters for some reason. I don't knit, but I think it's a great metaphor. Like, okay, engineering team, we're over here knitting a sweater. You told us to knit the sweater. We're knitting the sweater. And they're like, "Okay, but we need to switch priorities quickly and move over and go here." And we're like, "Okay, so you..." You know I can't take this sweater that I was knitting and start and, you know, we're starting with a new sweater over here. They don't match. So like, you know, I can't add this knit to that knit, and now my time is split, and we've lost kind of our momentum in that.

So that's one of the ways that I try to explain to people. If you started me down this path, it's not like I'm starting from here. I have to start from zero and start again. And then if you ask me to pop back over here, I've got to remember what that pattern is, and that's going to take some time. So, like, that's one of the examples that I use to try to explain to business people why we can't just magically switch and things are super fast.
Um, because I see that a lot. Well, I don't understand, like, you were already doing this, just do this. And I'm like, those are two different sweaters. I know it looks like the same sweater, and every now and then it is, oh yeah, there's some building blocks here we can use. But a lot of times it's like, I know it feels that way, but it's just not for one reason or another.

Yeah, so there's different departments—marketing, product, finance, sales—and then, obviously, depending on the size of the company, there are more departments that are kind of more specialized or a combination of two different ideas. Do you see like a difference between how you communicate to each one? Like, there's a marketing, sales are probably kind of similar, product is more related to engineering and more directly associated, but, um, like a department like procurement would be kind of like a different thing. And so is there like, uh, for each department, a way that they like to be communicated to, or is there a certain moments like a gradation, or do you have sort of philosophy on each one and how to engage with them and let them know, um, that you know, we're building different sweaters here, as you would say?

Yeah, so I think, um, I think it's where EQ comes into play. So individuals are really important, and you can make generalizations about individuals within different departments to a degree. But I have seen too many times where it's like, oh, they're in this department, I know what motivates them, or I know what they care about, and you're wrong. For whatever reason, that person doesn't fit the mold.

So not necessarily trying to generalize everyone and understand, okay, what are their pain points, this particular person's pain points or fears? Now, if you're trying to convince a body of people, yeah, what, you know, what goals do they have, what pressures do they have? Because a lot of times what I see is people won't come out and say what their underlying concern is. It'll be a lot of these things that feel disparate, and you can just kind of sense there's something they're not saying because I just addressed all of these.

And if you can ask questions and get to that root of what is the main concern here, then, and a lot of times I've seen it, or even in myself, we didn't address it because it was a no-brainer to us. We already understood how this technology took care of that. Fears of being bring it up, and it was like, oh, that's what—oh, this is why I haven't spoken about that, because XYZ has happened. And like, we know that that's not an issue. And then, you know, you can bring the stress level down and move on with the conversation.

But it’s also essential to implement strategies for building trust across departments. Understanding the specific needs and communication styles of each group can go a long way in fostering trust. Using effective trust-building techniques like active listening and empathy can help you connect with people more authentically, especially when you're navigating sensitive topics. Similarly, fostering accountability in teams is crucial to ensure that everyone is working toward the same goal and taking responsibility for their actions, especially when coordinating across different departments. As someone who works in leadership in engineering, it’s important to recognize the role of trust and accountability in making sure that technical goals align with the broader business objectives.

‍

Danielle Cooper:
So I would say like in—you can come in with a little bit of preconceived notion, but really seeing each person as an individual and everyone has their own stressors and how can you speak to them can be very helpful.

Host:
Right, so, uh, I guess hopefully this is a more fun question for you. What is the most challenging kind of individual you, uh, have encountered when trying to get things done? That way, you don't have to say a name.

Danielle Cooper:
I—that's a great question. I'm trying to, like, boil it down to one archetype or factor stuff. Yeah, um, I would almost say someone who doesn't actually understand how to be successful in their role quite yet. And so they don't know what they need, and so you're trying to help them, but you're not in their role, like you're not in their function. So, as much as you can try to help them, it's like sometimes it can be really hard because you're getting different direction from day to day.

Danielle Cooper:
And you're like, but okay, yesterday you said this, and today you said that, and it's fine, like I'll give you all the information, but I'm not seeing like the overall picture and how this ties in.  Um, and I can't, I can't help you. Um, so that can be challenging for sure.

Host: 

How do you deal with that? I didn't expect that answer. So how do you, uh, how do you make that work for you, and or can you even, right? Because that's you're doing two jobs now, realistically.

Danielle Cooper: 

Yeah, so I think it depends. Sometimes quick wins can help, like, oh, okay, well, I can give you XYZ quick win, which means I built trust. Now you can start trusting me a little bit more, and like, how do I build trust with this individual over time? That can be helpful. Um, and it depends. Sometimes it's out of your control, and it depends on their own growth. Um, I can tell you one situation where it was nice that I could pinpoint, like, oh, okay, so we had come up with, uh, over, like, the course of six months, come up with an SDLC, and who between product, project, and engineering owned each piece, right? And who's going to be responsible for guiding which part? And it was working really, really well. We were pulling stuff to the left, we were executing, we were getting stuff out on time or early, and we had this new person come in, and they were fighting us so much on it. Like, well, I want to own this and this and this.

Host: 

Fighting your own ownership?

Danielle Cooper: 

Yeah, on ownership. Okay, like, this is my responsibility, this and this. And we were like, okay, let's start from zero and explain how we got here and try to guide them along. And eventually, I realized, oh, wait, this person is trying to take ownership, and that was a problem that we had seen in their function, um, of like a lot of people not...function, do not take this much ownership. And I just was like, "Hey, I'm gonna take a minute to say I so appreciate the level of ownership you want to take in this process. That's awesome. You want us to be successful, and you know, you want to own that, any part that you can to make that happen. That's awesome. I so appreciate that." If you try to take that level of ownership at this particular company, you will probably fail, because it's too much for any one person. That's why we have all of these people. This is not the only project that you're managing, like, you have three others. If you try to do this, so you need to rely on us, and we're responsible to you for these outcomes. And it just completely changed the tenor of the conversation. The person came back to me later with other conflicts he was having within the business. "Hey, how would you handle this?" So, like, and it was simply because I appreciated what he was trying to do in his fear, if I don't have the ownership, it's going to fail. And my promise to him, I get it, I want it to be successful too, and I'm responsible to you to make that happen.

Um, that was one situation where I was able to, like, oh, this is the fear, and this is how I can address it. And some people will, you know, let you do that. Other people will still kind of, you know, hold on. But, you know, it's kind of like identifying in the individuals what you can do, and appreciation goes so, so far. That helps a lot because we all want to be appreciated, and we all want to be seen, and that, you know, like, okay, I see you, I feel you. Um, this is how I can help. It can go a really long way. And sometimes, you know, like, I have had people say that to me, and I'm like, "Yeah, that's not helpful."

Host: 

Right.

Danielle Cooper: 

So there's always, you know, we can't help everyone, but we can try, and we can offer our support. "How can I help?" and people will always have an answer for that, but a lot of times they will. Um, or you can offer, like, one or two small things, and then just the relationship-building is so important.

Host: 

So, um, he talked about, I'm gonna sort of pivot into sort of, uh, this idea of ownership that you talked about, where this is happening in a very positive way with this person coming in, uh, but it was interpreted not necessarily the best way, uh, initially, right? So, uh, when we talk about ownership with regards to the internal team, if we flip back, um, there's, uh, we talked about the most difficult kind of person to sort of engage with, um, but what, uh, what kinds of person inside the engineering team, right, is first of all difficult to engage with, best to engage with? You know, what kind of people, uh, do you have in sort of the landscape of engineers, and how do you sort of deal with them?

Danielle Cooper: 

Yeah, this feels a little like controversial, right?

Host:

Go for it.

Danielle Cooper: 

But very transparently, I feel like the hardest type of individual to deal with is the individual that has what feels like an innate but it's not I don't think it's a need to be the smartest person in the room because they can't be wrong, right? Like, and so you can't have a meaningful and productive conversation without different tricks and techniques.

Danielle Cooper: 

Um so one of the ways that I help with that is to um for like design decisions, right? Those things are really emotional and a lot of it comes down to if you reject my... what do you say? software...?

Host: 

Software design.

Danielle Cooper: Right, yeah, software design, okay, yeah, yeah, architecture, all right, this or that because we all want to be smart that's just, you know, a need. um and to reject our idea, oh, oftentimes is to reject me, right? Like, that's really what's happening underneath the hood there a lot of times.

um so the way that I try to pull that out is, okay, here are the 10 factors that we need to consider for each step, each decision we need to make in this architecture and how it supports the business because a lot of times it's, um, the answer to an architecture question is “it depends.” I said, well, from a business standpoint we actually have certain things we need to meet and this decision directly impacts that. So if you can pull out before you even start, these are the factors that each of our decisions and design points like points in the design need to be in like how they're weighted.

You can bring it back when there's like this conflict of, "Oh, we should go this way or that way." Okay, well, how do they score when we come to the 10 factors? You can... so it takes it out of you versus me and on to this, you know, third party that it doesn't have, I don't want to say it's like less subjective.

Yeah, it's a bit amorphous, so yeah, so it makes it less stressful. It makes less, there's a lot less, if you've got human factor, so it makes so all that sort of human emotions get out of it and then an objective decision can be made.

Host: 

Yes, right.

Danielle Cooper: 

So that's one way to help with that “I need to be the smartest person in the room.” Okay, the smartest person in the room—we’re all that and we’re all tying what we want to do to the business outcomes that we want to achieve. Our business can be even like, "Oh, it needs to support our current structure." That's not an option. Like, we need to have these dependencies within engineering in addition to how it drives business outcomes like revenue and whatnot. Building trust in engineering helps align the team with these goals, creating an environment where everyone is working toward a common purpose.

Um, so like there’s a lot of different ways that you can structure those factors depending on the needs of your entire organization, but being able to bring that back to that very concrete and then, "Okay, yeah, I really like the solution but it's not going to move anything at all, so I can let it go and we can move on." So that’s...

Um, like the hardest, and then you had talked about the, you know, what's the best, right? What's your... what's your favorite? I mean, my favorite are people who are open to discussing new ideas and new opportunities and are always learning, always taking responsibility for things like, "Oh, that's not my job," like that’s not my favorite. Building trust in engineering requires fostering a culture where team members feel empowered to take ownership and responsibility, which drives collaboration and innovation.

‍

 um, which can feel like, what do I do all day? Like, I like to do these things, right? um but that's not the job anymore and people aren't growing if you're doing that, but I love those sorts of people who you give them a problem and like I had a manager one time and he was just like, I would give him kind of the direction and what I was thinking and what problem needed to be solved and he would come back with 10 things I didn't even think about that were like, yeah, that's a good point, I'm so... and would have an incredible... I could give him anything and he got through it more than me.

Danielle Cooper: um, you know, I appreciated that because I see sometimes that people are afraid, like, "Oh, well this isn't what she said, so I'm afraid to do it." I see that crop up a little bit sometimes, um, and I get it, right? Like, I've had to be more careful as my, as my role has increased, of trying to not stifle creativity with the people who are like, "Oh no, yeah, like, I can do this even better than what she said," that's great.

Um not even as a competition thing, I'm just trying to do the right thing. Love those people, yeah, and honestly doing it better than you've been asked to do is always, I think, it's a great thing if you have someone who can do... I love that with you right it's those kinds of people are amazing and uh different deserve as much support as they could get you know yeah I'm 100 and no one person has all the answers right um and I love people like we had you know we uh dramatic we kept a lot of um very detailed like records I'll call it but jira tickets and whatever and we noticed there was one engineer and his stuff would just pass QA with flying colors like every time and so we would go out and he was fresh out of school and we're like so what you doing over there because you have this impeccable track record for quality and he was like well I go talk to the QA team into the project manager about how it's going to be used before I start coding and we're like is everyone not doing that like it was just really like he was very thorough he's like yeah I don't want to reinvent the wheel because I didn't understand something I figure out how my feature fits into the larger system and then I could like design and code from there and it was just I was like I love that like he he was just a big picture thinker and it really it showed in his word.

Host: So what's your favorite part about dealing with all these uh challenges right there's there's so many things coming from so many different directions and so many ways each things needs to be presented relative to the person and so much preparation needed if it has if anything interesting is going to happen uh so there's you know some several people or people have different ways of sort of feeling about that some people might feel overwhelmed and they have to do so much before they do something that they would want to do uh some people feel some people really don't like emotional labor they don't like having to consider this other person's whole ecosystem as an individual and then sort of massage towards a goal and you're sort of doing it at scale uh for different kinds of people.

And even when I asked you hey for each department what kind of person he said no I actually go at the individual level so that just multiplies the mental models that you have to keep in order to get things moving forward so what do you like about all this?

Danielle Cooper:: 

I love bringing calm to chaos and I have, I mean completely transparently, I have seen people feel so disconnected. You know, just as our world has become more centered around computers and technology, all these factors can make people feel unseen, unheard, and disconnected. So, while I love building tech that absolutely catapults growth, that's so fun to me, I also love creating systems that are incredibly efficient. When I make one little tweak, all of these people are impacted, and we're generating all of this revenue because of just a few lines of code—that's so fun to me. But I also love being able to talk about the human side underneath it, making sure the people that are creating that tech feel heard and connected. I want to help build trust in engineering within those teams so that they know their work is valuable and that they have a positive impact on the world.

Part of that is my own journey; I have learned so much, and I love passing that on to people. It has made me a better person in general—not a better person, but a more calm person with more space for others. I want to help people feel that the world is a friendly place and that they have an important part in it. This excites me! Teaching people how to make those connections and create them in their own lives by leading by example is a big reason I’m able to do this. Building trust in engineering plays a huge role in this; it’s about fostering a sense of collaboration and making others feel empowered to make decisions and drive change.

‍

Host: 

If people want to connect with you where they can they find you?

Danielle Cooper: 

Um well I'm on LinkedIn it is you know the LinkedIn whatever Danielle Dash in dash Cooper um that's you know I don't have a website or anything um but yeah thank you so much.

Host: 

Well thank you so much for you know reaching out to us and talking to us and learning from uh allowing us to learn from you and um yeah I think it was a great conversation thank you so much.

Danielle Cooper: 

Thanks so much for having me it was so fun I loved your questions.

Host: 

Take care.

‍