Danielle Cooper is a tech executive with 20 years of experience building and managing high-performing, cross-functional teams. She’s held leadership roles in the defense, logistics, medical, and real estate industries at a number of companies, including Northrop Grumman, Dematic, and Realtor.com.
We recently sat down with Danielle to get her insights on leveraging engineering to drive profitability. She also shared her thoughts on balancing quality and efficiency, and strategies for communicating the value of engineering projects to nontechnical stakeholders.
Our conversation has been edited lightly for brevity.
I started my career at Northrop Grumman and remained there for quite a while. I was consistently given new opportunities to grow and change and learn new technologies, as well as new leadership skills.
Within the company, I hopped around about every two years, learning new tech stacks and creating new products. I worked in a division that built software for Special Forces, so projects were often quick and dirty-ish things that were needed right away.
It was during my time at Northrop that I realized I was most interested in the “big picture.” I later moved into a tech leadership role with a healthcare startup and then transitioned to Dematic, a very large logistics company with $4 billion in revenue.
I led a team of 50 engineers at Dematic and helped start the company’s engineering office in Mexico. From there, I moved to the director of engineering role at Realtor.com, managing the company’s high-traffic pages.
There are some pretty ubiquitous principles and concepts of good engineering that are always going to follow you no matter what language or what platform you’re working with. Some matter more than others, and there’s always going to be some ramp-up.
But, in general, I consistently encounter situations where I find I’m using past lessons to deal with a current issue. Often I’ll recall a somewhat related situation, and even though it may have occurred in a different industry, it likely has the same underlying causes. So I’ll dig in and start there.
For example, we constantly hear about microservices today, but this really isn’t anything new. The principles of microservices — an application should focus on one specific thing, be independent, have an API, be inherently ephemeral — those are just things that we were using at Northrop day-to-day because they’re good engineering principles. We weren’t calling them microservices — that’s just new terminology.
We recently needed to replace the monolith frontend of Realtor.com with micro-frontend architecture. I found this project interesting because when I listed out the main objectives for the project, I noticed that many of them were not specifically tech goals.
Instead, they related to the overall corporation, how our teams were structured, how we partnered with product, and what we needed to provide for our consumer. Ultimately, the big-picture questions actually made the decisions for this project easier. There were certain aspects of the consumer experience that needed to stay in place, and this influenced how we would architect the project.
This project was really eye-opening, and it was also fun to work on and impactful. I’ve always been fascinated by macroeconomics and how things that feel disparate can actually influence decisions, actions, and even revenue in ways that we may not realize.
I’ve found that nontechnical business partners don’t always have an inherent understanding of technical concepts and jargon. They may not be able to immediately see how a particular piece of tech can benefit the company overall.
The benefits of managing technical debt, keeping tech stacks up to date, or ensuring that automation is in place are self-evident for engineers, but that may not be so to nontechnical leaders.
I try to explain those things in a way that everyone can understand. It usually comes down to time, money, or impact to the consumer — that’s really where the rubber meets the road.
I think it’s helpful for engineers to get out of their bubble and have a little more empathy and understanding for where other business partners are coming from. It’s important to convey the value of the impact you’re trying to create.
For example, engineers will immediately understand that automating routine software development tasks can save tons of hours and reduce mistakes. But this may not be obvious to business partners.
When nontechnical leaders hear “automation,” they immediately think:
To get buy-in from nontechnical business leaders, try talking about the benefits in a relatable way. For example, let’s say your team is manually typing in the number of clusters that are needed for every single deployment. What if someone messes up that number?
Communicate the potential risk in terms of time, money, or user impact. Like, “This is going to save us 25 hours a week,” or, “We lost a million dollars in revenue last year because of simple mistakes that an automated process would never have allowed us to make.”
Sometimes a business is still willing to take the risk — you may have to wait until the risk is realized to actually make a change. I’ve seen this happen.
In the deployment example I just mentioned, the wrong number was keyed in and we were not able to scale. It took us a few hours to figure it out. This resulted in a push for automation that should have already been in place.
User data is incredibly important, but unfortunately, it can be easy to dismiss: “How many people really experienced this problem?” or, “Is this a website issue or a user issue?” The closer you can get to the end user, the better. If you have a product team that’s conducting consumer research, for example, have engineers sit in on some of those discussions.
Here’s an example from when I was at Northrop Grumman — I’ll need to be a little vague on the details. At the time, we were sending a lot of data over a high-latency, low-bandwidth link and using devices with very limited memory and processing power.
Let’s just say I had created some software and then had an opportunity to see it in use. I ended up on a hill in the middle of the desert at night. All of a sudden, the 10-15 seconds that it was taking to get a result seemed a lot longer than when I was sitting at my desk. Sometimes, you need to sit side by side with a user to really understand why something is unacceptable.
First and foremost, the easiest way that engineering can help profitability is to ensure that systems are up and running as expected. When a system goes down, you’re losing revenue in one way, shape, or form.
Engineering leaders can also drive profitability by focusing on becoming more efficient and productive and by reducing time to market. This means eliminating manual efforts, where possible, to reduce costs.
Another way to help profitability is to stay on top of the risk of aging technology by modernizing at the right time. It’s important to balance that cost and risk. If you’re working with technology that’s no longer supported and something goes down, you may not be able to get it back up.
For example, at Realtor.com, we needed to rebuild a certain part of the tech stack, but the technology was so old that we couldn’t install the version of Python that we needed. We had to call AWS to assist. That was expensive — especially when the site was down!
Another tip is to help engineering teams understand the consumer’s pain points and ensure that anything that’s not functioning properly is addressed right away. Consumers don’t like to be surprised and won’t hesitate to move to a less surprising platform.
Lastly, reputation really, really matters. A major “oops” can follow you for a long time, resulting in increased attrition and reduced profitability.
I believe that done is better than perfect. This is something that I’ve had to really coach myself on because I’ve been a perfectionist from an early age. But I try to remind myself that not every task deserves an A+ solution.
Instead, I like to think about time-bounding tasks so they each get an appropriate amount of time and energy. Like, maybe one task gets one hour of really focused time, but another just deserves 20 minutes. And I no longer fall into the trap of thinking I’ll get a chance to redo something — I’ve found that’s almost never the case.
Another tactic I use is to ask myself, “Would you rather send it in this state or never finish it at all?” Because sometimes, if you wait for perfection, the opportunity will pass you by. Maybe you’ll miss a deadline, maybe you’ll lose revenue, or maybe a competitor will get there first.
First, the ability to understand complex concepts and break them down in a way that is easily understood. A picture is truly worth a thousand words.
You should be able to show a system succinctly. If it’s too complicated to explain, that probably means you’re going to have to create it in a way that will be hard to maintain or hard to troubleshoot. Really challenge yourself — how can we build this in the simplest way possible?
Second, the ability to coach your team and ask questions to get everyone’s input.
Third, the ability to balance quality and the need for perfection with the actual business needs. As I mentioned, not every problem needs an A+ solution.
Last, the capacity to empathize with the tech team and cast an inspiring vision of how tech is driving the business. People will be energized when they understand the impact their work has on the bigger picture.
Networking is so important, and it can happen more naturally when you have more in common. Coming from any kind of diverse background doesn’t always help networking happen organically. So work a little harder to create a network.
Find ways to add value for people with whom you’re trying to build a connection. Be intentional about building connections outside your company. This is helpful for keeping your mind open to new opportunities and new ways of working.
Also, don’t be afraid to speak up. This is not just a female thing, but research has shown that women often want to feel very certain that they are correct before speaking up. Don’t worry so much about being wrong. If you have a different perspective, ‌share it. What matters is that you make your voice heard and get your ideas out there.
Would you be interested in joining LogRocket's developer community?
Join LogRocket’s Content Advisory Board. You’ll help inform the type of content we create and get access to exclusive meetups, social accreditation, and swag.
Sign up now
Learn how to implement one-way and two-way data binding in Vue.js, using v-model and advanced techniques like defineModel for better apps.
Compare Prisma and Drizzle ORMs to learn their differences, strengths, and weaknesses for data access and migrations.
It’s easy for devs to default to JavaScript to fix every problem. Let’s use the RoLP to find simpler alternatives with HTML and CSS.
Learn how to manage memory leaks in Rust, avoid unsafe behavior, and use tools like weak references to ensure efficient programs.
Learn more →
