6 min read
A Dinner Conversation That Sparked a Deeper Discussion
Last night, I had dinner and great conversation with the CEO and partner of a global software engineering-as-a-service company. During our conversation, we discussed responsible engineering—what it truly means beyond the technical skills required to build software.
He shared an interaction he had with an intern at his company. When asked what responsible engineering meant, the intern answered, “A responsible engineer provides a solution that goes as deep as you can and ensures it operates effectively.” That definition, though simple, encapsulates a key part of what we often overlook in software engineering—the obligation to go beyond the immediate solution and take full ownership of its impact.
I shared my thoughts during our conversation, and he suggested I write an article on the topic. That discussion sparked a realization: I had already created over half the material needed for such an article.
- I created an internal wiki page for my engineering teams to show how a lack of accountability can lead to costly mistakes in a SaaS organization. For instance, in late 2024, unmonitored logging after a production deployment caused expenses to spike by $15K–$20K in just one month. This was due to a coding error that generated excessive log volumes and related log statements that went unnoticed for a few weeks.
- I published an article in 2023 titled “Beyond Features: A Software Engineer’s Code of Conduct for Delivering Impactful Product Outcomes“ In it, I explored how engineers must take responsibility beyond simply writing and deploying code.
These resources are a great starting point for writing this post.
Engineering responsibility does not exist in a vacuum—it extends beyond individual engineers to entire teams and, ultimately, leadership. Another internal wiki post I shared focused on defining team standards for planning, quality, collaboration, and delivery. Because responsibility isn’t just about engineers following their code—it’s about creating a team culture where expectations are clear, accountability is shared, and improvement is measurable.
Responsible engineering has been talked about in many ways over the years, but the real challenge isn’t just defining it—it’s making sure it becomes a genuine part of engineering practices, team culture, and leadership expectations.
What Responsible Engineering Means for Engineers and Engineering Teams
The Problem: Engineering Without Ownership Creates Unintended Consequences
We’ve seen what can happen when engineers fail to monitor their code after deployment. Even when tests like regression or smoke tests pass, they can miss issues like a significant increase in logging volume. There have been cases of AWS Lambda calls running unexpectedly or out of control, causing major expenses before a monitor stepped in to block them. These problems aren’t just about costs—they highlight a deeper issue with engineering responsibility.
When engineers don’t actively monitor their deployments, the business suffers:
- Unplanned costs arise, burning through budgets.
- System performance degrades without anyone noticing.
- Technical debt accumulates because quick fixes introduce long-term inefficiencies.
- Customers don’t receive the expected value or results.
The Engineer’s Role in Responsible Development
1. Own Your Code Beyond Deployment
A “Follow Your Code” culture means engineers don’t just ship code—they track, verify, and own its impact.
- Done doesn’t mean merged—it means verified in production.
- Engineers must proactively check logs, system metrics, and performance impact after deployment.
- If your code introduces inefficiencies or waste, it’s not “working.”
- Can you answer the following? “My changes are working as expected in <environment name here>, and I haven’t noticed any issues after deployment.“
2. Observability & Monitoring as a Core Engineering Discipline
- Use monitoring tools to detect unintended spikes in usage, logs, or errors.
- Compare logs before and after deployment to ensure no wasteful changes were introduced.
- Treat system performance issues as functional bugs—if your code makes the system slower, it’s broken.
3. Write Cost-Conscious and Efficient Code
- Be aware of the financial impact of logging, API calls, and inefficient queries.
- Optimize code to reduce unnecessary compute, storage, and external service costs.
- Avoid quick fixes that introduce long-term inefficiencies or hidden costs.
4. Build with Long-Term Impact in Mind
- Consider scalability, maintainability, and total cost of ownership for every change.
- Engineering isn’t just about shipping features—it’s about ensuring the business remains viable.
- Avoid band-aid solutions that create future complexity.
What Responsible Engineering Means for Leaders and Management
For senior technology leaders, this is not just an engineering conversation—it’s a leadership conversation.
The challenge for leadership is not simply to set expectations but to create an environment where responsible engineering is the norm. The best leaders don’t just demand accountability from their teams—they teach what it means, model the behavior, and make it a shared responsibility.
How Senior Leaders Can Guide This Conversation with Engineering Teams
- Frame responsibility as professional integrity, not fear.
- Ask engineers questions that spark ownership.
- Ensure engineering accountability is built into the team culture.
- Recognize and celebrate responsible engineering.
Leaders can inspire engineers to embrace responsibility by making it a point of pride rather than fear.
RACI Example
This example might not fit your team structure or role responsibilities exactly. It’s meant to be used as a reference.
Diligence Over Complacency, Responsibility Over Negligence
I recognize that most software engineering is complex and difficult. It is a great skill to have, and yet again, I know we will make mistakes.
But responsible engineering is not about eliminating every error—it’s about your approach and accepting responsibility. While it’s OK that there will be an occasional error, there is no room for complacency or negligence.
If you are not willing to take ownership, if you are content with cutting corners, or if you approach software with indifference toward its impact, then this job is not for you.
But this is not about fear—it’s about self-reflection.
Given my current skill set, capabilities, insight, and tools and practices, did I do everything possible to deliver the best code?
That is the mindset of a responsible engineer.
The Software Engineer’s Oath
“I recognize that great engineering is not just about writing code—it is about delivering something that truly makes a difference while honoring the trust placed in me to do so responsibly.”
I commit to:
- Building with diligence, not complacency.
- Respecting the responsibility I hold.
- Minimizing harm and avoiding preventable failures.
- Prioritizing quality, accountability, and long-term impact.
- Acting with integrity and not compromising security or stability.
- Delivering value without judgment of its significance to the user.
Being a software engineer is both a privilege and a responsibility. The joy of building and solving problems brings us into the field, but the trust placed in us by businesses, customers, and users defines us as professionals.
Given the significant changes AI is introducing, I can’t tell you what this profession will look like six months, a year, or two years from now. But that does not prevent us from being responsible engineers as we reshape this industry and how we deliver software.
Until then, have you and your team discussed and defined what it means to be a responsible engineer?
Poking Holes
I invite your perspective on my posts. What are your thoughts?.
Let’s talk: [email protected]