Ethical leadership in engineering requires persistence despite resistance
Ethical leadership is how enduring companies get built. The reality is that when you make decisions that aim to do the right thing, people will push back. Especially if “the right thing” slows things down or puts extra eyes on how you run your systems. Some will call it idealism. Others will view it as naïve. That’s fine. Do it anyway.
Most engineering teams operate under pressure, deadlines, budgets, stakeholder demands. But pressure doesn’t justify cutting corners. If your system fails and users suffer, no one cares that you shipped quickly. They care that your product didn’t work when it mattered. Leadership means choosing long-term integrity over short-term convenience, even when peers or management resist.
Ethical consistency is hard, and you won’t win every battle. Sometimes, you’ll be outvoted. Sometimes ignored. But if enough leaders consistently hold the line, the culture changes. The bar gets raised. Eventually, doing the right thing becomes default behavior, rather than an exception. That’s where transformation starts, when ethical thinking is standard and not a debate.
This matters not only to developers and engineers, but especially to decision-makers. Building products people use isn’t just about speed or cost, it’s about trust. People trust systems that are built to last. You don’t earn that trust by taking shortcuts.
Developers should not be treated as interchangeable commodities
Developers aren’t machines. They don’t run on reusable scripts and standardized templates. Yet, across many tech organizations, developers are still viewed as plug-and-play components. That mindset slows down innovation and kills morale. If you want strong products, especially in high-risk environments, you need to stop thinking of engineers as interchangeable resources.
Every engineer brings a different set of strengths. One might be great at architecture, another at code optimization, another at debugging distributed systems. Treating them as uniform software-producing units weakens your ability to build anything worth scaling. Some engineers will grow into architects, some into technical leads. Others are better left to deepen their craft without moving into management. That’s a good thing.
Leadership means understanding what your people are uniquely good at, and building roles around that, rather than jamming everyone into titles and hierarchies they didn’t ask for. The forced pipeline from “developer” to “manager” helps no one and often promotes the wrong people. It’s lazy thinking.
If you’re setting up your tech teams for performance, retention, and long-term impact, stop reducing developers to headcount figures. Invest in learning what makes each contributor effective, then back it with resources and mentorship. It pays off. Strong teams aren’t built from cloned skillsets. They’re built from complementary ones that you align around purpose. That approach scales. The commodity mindset doesn’t.
Proof-of-concept (POC) code should not evolve into production systems
A proof-of-concept is a test. Nothing more, nothing less. It’s built fast, often with minimal safeguards, to demonstrate that an idea works. That’s its purpose. What it’s not meant for is long-term deployment. Yet companies routinely ship POC code into production because it already exists and “works.” This decision usually turns out to be expensive.
When a proof-of-concept is treated as a final build, the team inherits code that was never designed to scale, secure, or sustain real-world usage. It lacks the quality, error handling, and system compatibility needed in production-ready software. Cutting time upfront by skipping proper development doesn’t pay off, because that time comes back multiplied when you’re forced to rewrite or stabilize later.
If a POC proves the concept, it’s done its job. Learn from it. Then start from zero and build a real product that can withstand user load, edge cases, and updates. This isn’t about process for the sake of process, it’s about engineering discipline. Treating drafts as finished work leads to fragile systems, unnecessary complexity, and burning development hours post-launch.
For executives, this matters. When your team insists on rebuilding a feature after prototyping, they aren’t wasting time, they’re protecting your roadmap from being slowed down later. Patching early experiments into production might look lean, but it creates one of the most expensive forms of technical debt. Prioritize real builds where reliability is the expectation.
Leaders must be willing to reset projects when they go off track
Sometimes a project doesn’t work. The direction is wrong, the implementation fails, or the person leading the task isn’t getting it done. In those situations, most leaders hesitate to pull the plug or reassign. They worry about appearances, losing credibility, or internal politics. That hesitation isn’t harmless, it has costs.
Engineering leaders who delay intervention because they don’t want to admit a mistake often end up supervising a longer, more painful failure. When the code is wrong, pushing forward doesn’t make it right. The team burns more hours trying to patch mistakes instead of fixing root issues. That delays shipping and corrodes confidence across the organization.
Strong leadership means calling a reset when it’s clear a project has gone off track. Pause the work, shift ownership if needed, and start clean. Not every task belongs to the person who first took it on. Not every plan holds up under execution. Step back when necessary, and communicate the why with clarity. That’s not weakness, that’s momentum strategy.
Executives should encourage product and engineering leads to make high-integrity decisions around resets. Ignoring failure doesn’t make it disappear, it just drags the problem further into the road. When your system is headed in the wrong direction, turning around early is what saves time, capital, and team morale.
Embracing the paradigm shift is necessary for innovation
There’s a point in every company’s lifecycle where legacy processes start to slow things down. Whether it’s outdated systems, comfort zones, or internal habits that no longer align with growth, those things compound. The problem isn’t always technical. It’s often cultural. Teams get used to doing things a certain way, and leadership lets it slide, even when it no longer delivers results.
In the example discussed, system failures had become routine. Rather than fixing the root problem, engineers benefitted financially from the downtime. Leadership allowed it because the team felt “safe” doing things the old way. This isn’t resilience. It’s stagnation. If your system goes down regularly and no one prioritizes solving it, you’re not protecting your team, you’re limiting them.
Innovation requires new input. If your team is showing up every day to manage failure instead of fixing source-level issues, they’re not growing. Culture drives performance. Teams need to be encouraged, even pushed, to evolve how they work. That includes adopting better tools, frameworks, and practices that reduce inefficiency and tighten feedback loops. But change only sticks if leaders create the expectation and environment for growth.
Executives need to step in here. “Letting the team figure it out” isn’t leadership when the team has no incentive to improve. Support your engineers by removing internal blockers. Give clarity on what performance looks like and back those expectations with modern systems and accountability. Teams that are incentivized to get better, do. The rest repeat patterns and stay static.
Engineers must claim full ownership over their code
Strong engineering doesn’t end when code is pushed. If developers don’t own the quality of what they ship, everything downstream gets worse. Tests break. Monitoring fails. Support tickets multiply. Ownership changes that. When engineers are fully responsible for testing, documenting, and instrumenting their own code, the product improves. Fast.
Passing code off to others without context creates weak points in your system. Nobody knows the code better than the person who wrote it. They understand how it works, what assumptions were made, and where it could break. Pushing ownership to developers ensures better reliability at every stage. They’ll write tests that catch real errors. They’ll build observability into the system proactively. And they’ll feel invested in the outcome, because it’s theirs.
Liz Fong-Jones, Engineer at Honeycomb and an established voice on software reliability, put it clearly in the On-Call Me Maybe Podcast: developers should write their own tests, comments, and instrumentation. That level of engagement leads to better-performing, more maintainable systems.
For executives, this isn’t about micromanaging engineering practices. It’s about setting the right expectation across the organization. If developers know they’re responsible for their product’s success and reliability, quality increases, post-release issues decrease, and teams move faster. Ownership creates pride and accountability. Without it, your systems are less predictable, and harder to scale.
Creating a psychologically safe environment fosters growth
People do their best work when they aren’t afraid to make mistakes. Teams that don’t feel safe asking questions, challenging assumptions, or admitting when they’re stuck, slow down. Engineering is complex by nature. It gets harder when people pretend they understand something just to avoid criticism.
Psychological safety isn’t about coddling. It’s about creating a space where talent can speak up without fear of being dismissed, embarrassed, or penalized. The example shared about the high school French teacher who admitted she was also relearning the material highlights a key leadership trait: vulnerability. When leaders show humility, people engage more openly. They participate. They experiment. They learn.
In engineering, where technologies and frameworks evolve constantly, expecting everyone to know everything is unrealistic. Building a learning environment where junior and senior devs alike can grow without judgment leads to stronger, more adaptable teams. You don’t get there through policies or performance reviews alone, it’s driven by leadership behavior.
C-suite leaders should pay attention. If your company culture rewards only certainty and speed, you’ll see innovation drop off fast. Teams won’t speak up early when something’s off. They’ll avoid risk, and that means avoiding progress. Set the tone through your actions. Encourage questions. Normalize learning in public. That helps drive results that sustain.
Kindness during failure builds stronger teams
System failures happen. No matter how good your engineering team is, code will break, components will fail, and things will go wrong. What defines your organization is how people respond in that moment. Pointing fingers doesn’t help. Blame adds stress, damages trust, and slows recovery.
When a team knows that operations are supported, and not punished, during incidents, they’re able to think clearly, debug faster, and recover systems without additional tension. Kindness and professionalism are not soft skills. They’re force multipliers, especially in high-pressure environments where uptime affects revenue, credibility, and customer experience.
Encouragement during failures does two things. First, it builds loyalty. Teams remember how they were treated when things went south. Second, it creates a culture of responsibility without fear. People take initiative more confidently when they’re not focused on self-preservation.
From an executive perspective, this culture has bottom-line implications. If response teams can operate at full cognitive capacity instead of worrying about blame, you get faster resolution times and fewer recurring problems. Set a company-wide tone that expects professionalism under pressure. Reward calm execution, not aggression or escalation. The return is measurable, across resilience, retention, and internal alignment.
Leaders must not let ego hinder improvement efforts
There’s a point where leadership stops being effective, when ego gets in the way of reality. Systems fail. Teams make mistakes. When these issues are raised and leadership shuts down the conversation to preserve their image, nothing improves. That dynamic blocks momentum and damages trust internally.
In the example given, a manager brought forward clear signs of a broken system and proposed solutions. Instead of addressing the problem, leadership took offense. This type of defensiveness discourages critical feedback and makes people less likely to speak up the next time something breaks. The result is simple: problems get buried until they can’t be ignored. And by that point, it’s more expensive to solve them.
Listening doesn’t require agreement. It requires openness. You don’t need to act on every piece of feedback, but you do need to hear it. When people at any level in your organization raise concerns, they’re doing it because they care enough to challenge how things are working. That’s a signal worth paying attention to.
For executives, this is directly tied to system resilience and team performance. If your people are afraid to escalate issues proactively, your organization stays reactive. The best systems and teams get better because they face reality early, and fix it fast. That only happens when leadership is willing to ignore pride and prioritize progress.
Ethical action faces resistance, but consistency can drive systemic change
Doing the right thing isn’t always a smooth path. There’s pushback, sometimes from peers, often from management. That’s normal. But when doing what’s right consistently becomes part of how you operate, resistance softens. Others follow. Over time, the standard changes.
One action may not shift the industry, but patterns do. When leaders and engineers hold their ground on quality, accountability, and transparency, even under pressure, it forces the system around them to adjust. Those behaviors start to define the culture. Once enough people adopt that mindset, ethical decisions become the default, not the outlier.
This isn’t abstract. It’s systemic behavior change. The more consistently ethics guide how teams build, ship, and lead, the more reliable and trustworthy those systems become. Stability improves. Burnout drops. Products last longer. And the company builds a reputation that users, partners, and future employees trust.
From the C-suite, this matters. Culture isn’t dictated by a memo, it’s shaped by what gets rewarded and what gets ignored. If you want an organization that does the right thing even under pressure, you need to model it. You need to support the people who hold that line. That’s how long-term advantage gets built.
Recap
If you’re in a leadership position, especially in tech, your influence shapes more than delivery timelines or product specs. It defines how your teams operate under pressure, how your systems perform when it counts, and how your company is remembered when things go wrong. Ethical leadership isn’t idealism. It’s operational strategy.
A team that owns their code, speaks up early, resets when needed, and builds with integrity will outperform one that’s rushing to ship and hiding issues under the rug. Long-term stability, innovation, and reputation are built when accountability is prioritized over speed, and clarity is valued more than hierarchy.
You’ll face resistance. That’s expected. But the right decisions, especially the hard ones, compound into a culture that doesn’t just move fast, but moves smart. Back the people who tell hard truths. Reward ownership. Cut the noise, fix what matters, and make doing the right thing the standard.
That’s how resilient systems and strong companies are built.
