Hi! Developer and practicing mentor here.
My students are often paralyzed by the following fear:
"If I drop production, break the hardware, or wipe the database, I will go to prison and face huge fines. And what’s worst, I will let the team down. I’d rather work overtime to finish the task and make absolutely sure the solution is safe."
When a student Googles "developer responsibility," they get mixed signals:
Samsung Securities fired the employee who made simple data entry error that created "ghost shares" worth billions, crashing the company's stock.
A junior software developer wiped database, was fired and threatened to get legal involved. A developer started their first day at a new company. The CTO gave them a setup document to get their local development environment running. The document had not been updated and contained a command to "reset" the live production database, not the local test version. The junior developer completely wiped the company’s entire client database. The company had no working backups. The CTO fired the junior developer on the spot and ordered them to leave the building. The CTO also threatened to get "legal involved" due to the severity of the loss (though legal experts noted the company would likely lose, as it was their negligence that gave a Day 1 employee root access to production).
- cscareerthrowaway567 on reddit
Or take an example of Knight Capital. An engineer introduced a bug into a trading bot. In 28 minutes, the company lost $440 million—that is about $5.18 million every second. This disaster cost them all their clients, and the company shut down weeks later. Engineer lost his job (as there was no company left)
On one hand, we are told to welcome mistakes. On the other hand, you hear stories about losing your job over a moment of carelessness. To understand nature of consequences, let’s divide the consequences of a "screw-up" into two parts: Legal Liability and Corporate Culture.
We will discuss:
- How severely can you actually be punished?
- Why are you so afraid of making a mistake? What is the real fear?
- What to do if you make an expensive mistake to increase your chances of forgiveness.
- Famous examples from the IT world and my own career.
I started writing this to gather my thoughts on mistakes. But in the process, I realized a more important truth: we are afraid of mistakes because this fear is taught to us.
Part 1: Can a company legally fine you for a mistake?
In most jurisdictions (USA, UK, Canada), the answer is No. In the Czech Republic (where I live), the Labor Code (§ 257) limits liability to 4.5 times your salary.
For Contractors (B2B/Freelancers): If you work as a business entity providing services to another company, it is stricter. Your contract should clearly state the amount you must pay if you harm the business. I, for example, once had a contract saying I had to fully reimburse damages:
Do you know GitLab? It’s a huge platform like GitHub. One winter evening, a tired sysadmin from the Netherlands was working late. During a database migration, he accidentally deleted a folder on the wrong server. He deleted 300GB of live production data. Only 4.5GB remained when he cancelled the command. The last backup was 6 hours old. He was not fired. He even streamed the database restoration process live. The company turned it into a PR campaign about transparency. They kept the engineer because now he knows the backup system better than anyone else.
If you crash production without evil intent, it is foolish for a company to ask you for money. You will likely just be sent to fix bugs and write a "Post-Mortem" (an analysis of the incident). If you make a mistake due to a lack of knowledge, simply explain where expectations didn't match reality.
Everyone makes mistakes. It is a great way to learn. Did you crash prod because of a pipeline error? That is unique experience and a great chance to improve your DevOps T-shape skills.
You get the most valuable experience by making mistakes. An employee who has been "burned" knows what not to do. If you hire a new person, they might make that same mistake. The "burned" one will check twice.
So, when it comes to fines:
- If you are an employee: Relax.
- If you are a contractor: Read your contract.
Part 2: Corporate Culture
Every company has a culture that dictates how mistakes are treated. Have you heard of "Business Ownership"?
The idea is: If you work as if you own the company, you won't break production. Treat the product like your baby, and there will be no screw-ups. If you don’t want to—we will fire you!
Dropbox skills matrix evalues devs based on how they care about the product:
Ownership
- I proactively identify new opportunities and advocate for and implement improvements to the current state of projects - potentially having broader business impact across teams or products
- I take responsibility for my decisions and mistakes on my project and take action to prevent them in the future. I embrace and share the learnings with others
- When I encounter barriers, I unblock myself and my team by proactively assessing and eliminating the root cause, and focusing on the solutions
- I respond with urgency, and drive urgency in my team to operational issues (e.g., SEVs), owning resolution within my sphere of responsibility
Take an ownership mindset. It will set you apart from all the employees that are just treating the company like a rental car. However, just because you have an owner mindset doesn’t mean you should do everything an owner does. If you are an employee, set boundaries.
- Dan Moore, developer
Transforming developers into “mini product owners” is a strategic way to improve the team’s quality, collaboration, and ownership of their work. By empowering them to take part in backlog creation, you’re equipping them with insights into the product owner’s responsibilities, fostering a culture of accountability, and strengthening the team as a whole.
- EffectiveAgile, consultancy agency
Technical skill is not the key factor of performance of individuals. Ownership justifies such dramatic differences in the impact people have on an organization, beyond their direct knowledge of the technologies and tools they work with.
- Ecomerce agency owner
I wonder, why most of these articles are usually written by CTOs, Directors, and Bootcamps. If there are so many benefits for engineers, why it’s spread by managers who supervise developers?
Let’s be clear, there are two types of ownership:
- Healthy Ownership: I am responsible for the quality of my code and I understand the task so I don't build nonsense. If I mess up, I clean it up.
- Toxic Ownership: I must determine the product's destiny, satisfy the user, and worry about shareholder profits (while getting paid a developer salary).
The internet is full of articles saying: "The product is more important than the code. A good developer cares about business value, not code beauty."
How companies try to avoid mistakes by manipulating you
According to the business ownership methodology, a manager should consider how to build a culture that will help developers develop a sense of responsibility for the product. This is what guarantees developers will work better. That's why you hear that a good developer is someone who cares about the business as if it were their own.
I worked at a Polish company called Allegro. They had "The Allegro Way." To keep your full salary, you had to follow 4 rules, including:
- Growth. I set the highest standards for myself and my team and continually raise them.
- Devotion. I think of the business as if it were my own (They literally wrote it that way!).
- Dedication. I put my ego aside and do everything I can to achieve the company's goals.
- Collaboration. I'm not afraid to voice complaints, but when a decision is made, I keep my mouth shut and implement it.
During my first few months, I struggled to understand the ins and outs of the business. My manager always seemed clueless about the details I was interested in. At best, they'd invite a senior manager, hold a department-wide meeting, and burn through countless hours to give the team a better understanding of where tasks were coming from. I don't recall a single instance where this helped my work.
Needless to say, only 1% of the team followed Allegro Way. The company set unrealistically high expectations, which only served to demotivate employees. Due to bureaucracy and the imposed culture, I could work just two hours and still deliver the same results.
This is also called the IKEA Effect: People value things more if they built them themselves. People are willing to pay more for a cabinet they build themselves, and cake mix sales increase when customers are offered to add their own egg.
I believe the "Ownership Mindset" leads to 3 problems:
- Anxiety about the team.
- Stress from high expectations.
- Inefficient use of time.
"What if I let the team down?"
An ownership mindset leads to concerns about the team. The problem is that the team is a collection of hired people. These people are there for the paycheck. Each developer essentially rents out their brainpower for money. No one works for free.
When you lock in for the team, how does it reward you?
What exactly do you get, besides "good job, Bob"? You might think that you invest in future. In difficult times you might count on your team. I've had both experience being a hero and experience being a slacker on the team. In the latter case, my team's willingness to help me in difficult times was subjectively higher: everyone wanted to help me out, after all, I'm the weak link. But when you're a master of your craft, offering help may seem rude to others.
When you let your team down, what do you lose?
Letting your team down means violating its unspoken rules. These include things not directly related to your productivity. For example: going to the office, having lunch together, or, if you have a tradition of staying late in the evenings, valuing your time. I've worked in companies where letting your team down meant simply stopping staying late in the evenings. This is the result of building a culture of ownership by the employer. The only loser here is the employee who works longer for the same salary. They're cheaper for the company, because they do more for the same price.
If this is your case, don't accept these expectations under any circumstances. Either try to change something: openly raise the issue with your team: "Guys, how come we're working 10-hour days without bonuses?" Or change companies: yours doesn't value you. No one has the right to grill you if, after working 8 hours, you say you're going home.
I'm not an expert on building corporate culture. I'm just a developer. But I've seen developers quit or damage the business more than once because of the improper application of the ownership mindset.
When burned-out devs screw up on purpose
An ownership mindset leads to stress from high expectations. The issue of stress was extensively studied in a study titled Happiness and Productivity of Software Engineers. 1,318 developers participated in the survey. The study found that mistakes are sometimes intentionally made by burned-out developers.
Imagine this: an employee is so unhappy at the company that he begins to harm it. This study justifies cases of developers deleting databases in production. The study concludes:
A company should care not only about developer productivity but also about their happiness. Focus on great tools, autonomy, and investing in tech debt. Productivity should be only one indicator of happiness. A developer's mental health = their productivity. >
To increase employee happiness, a company can offer better working conditions: higher wages, freedom of action, freedom from control and trust, and benefits to boost morale. The company can also do this through manipulation, instilling a sense of accomplishment in the employee who develops the product.
Fear is inefficient
An ownership mindset leads to inefficient time management. Are you familiar with the fear of pull request comments that drive you to review your changes multiple times?
I've changed 4 companies in my career, and in each of them, I encountered a developer who was just as "intimidated." They might go days without submitting code for review, studying and pondering every line. This seems like a good thing - a careful developer will clearly take better care of the product. But developers are judged by the time they need to deliver results.
According to the same study, the main source of stress at work for most developers is interpersonal relationships within the team. With ownership mindset on top of it, It's as if your professional identity is being attacked every time a harsh code review occurs, your work is neglected, or you're outright exploited. This is often the case with tech snobs, ineffective team leaders, and micromanaging managers. As a result, the developer spends mental resources on untangling mixed signals instead of focusing on the tasks at hand.
If I don't show Ownership, how can I become a Senior?
All the competency maps at large companies require senior engineers to "understand the business" and "be responsible for the product." I say, "Forget it, it's manipulation." But how can you avoid being stuck in the middle-level position then?
My students often see poor processes but are afraid to take responsibility for improving them. But companies love proactive engineers. Take advantage of this. For example, say you want to understand CI/CD. Figure out how to improve your product's existing pipelines and propose a solution to the team. Unlike the ownership approach, even if you don't achieve a significant improvement, you won't be upset. After all, you're driven by a thirst for growth, not a need to prove your loyalty to the company. By focusing on personal gain, you'll develop as a specialist while receiving a salary for your growth.
Exert ownership in technical decision-making, not in polishing the product.
What to do if you make a BIG mistake
Let's say you deleted the database. Here is the algorithm:
- Explain lack of intent: Write in the work chat immediately. "I was trying to optimize X and an error occurred." Focus on your good intentions.
- Admit it honestly: Do not hide it. Say exactly what you did wrong (e.g., "I didn't check for a fresh backup").
- Volunteer to fix it: Offer to document the incident and fix the process so it never happens again (e.g., setup permissions, separate environments).
If they fire you for an honest mistake, it is for the best. Soon the only people left in this company will be those who do nothing.
Let's be pragmatic:
Companies want you to work more for less. They use "Ownership" to make you feel like the company is your family. It is not. You do not own 50% of the shares. You are a fungible. You do tasks for money.
If you are fired, in the best case you leave with a paycheck or two.
Examples of Screw-ups
Let's start with a classic – the old Ford story:
A manager made a mistake that cost the company $10 million. The CEO called him in. The manager asked, "Are you firing me?" The CEO responded, "Are you crazy? We just spent $10 million training you. Go back to work."
Here's an example from the IT world:
In 2017, an Amazon engineer was trying to debug a billing system on S3 (a cloud storage service) and had to remove several servers from the subsystem. He made a typo in the command and, instead of just a couple of servers, disabled a huge cluster. As a result, half the internet crashed: Trello, Quora, major media sites, and even smart light bulbs in homes were down. The company's losses were estimated at $150 million. The result: the engineer was retained, and the command line interface was rewritten, adding foolproofing.
A recent example from my career:
A month ago, I deleted all the data on two important environments. I was working on a feature for runtime swapping of logback configs in components. We decided to deliver the new config via Jenkins. In Ansible, I added the
swap_configtag, which triggered the pipeline. We also had theclean_dbflag for restarting the Ansible environment.I successfully tested my feature, but a couple of hours later, it turned out that the environments where the tests were running had lost all their data. Since no one really knew how to restore it, this became a problem. Our Ansible configs were in poor condition, and after two weeks, my colleagues and I still couldn't find the cause of the wipe. The logs weren't saved, and repeated tests didn't affect the data. I didn't even receive any reproaches for the data loss, and the feature is already in production.
A story from my early career:
On my first day at my first job, I deleted the database. I started working in IT Support at IBM. We had our own email client, and emails within the team were stored in a distributed database (similar to GIT). When I first launched the app, it took over 10 minutes to load. I thought it was taking that long to load my local copy. I needed to configure the client first, so I deleted the data, thinking I'd download it all when I had time. So I deprived our team of a year's worth of email history. Then everyone complained about IBM's clunky email client, the situation languished, and no one tried to change anything.
Summary
Don't be afraid to make mistakes. System security is achieved through proper processes, not by your sense of ownership. If you can easily damage the system, it means those processes aren't working properly.
Companies want productivity for minimal money. They can offer employees stock options and higher salaries to give them a genuine sense of belonging. But that's expensive, which is why people start thinking about transferring management ownership to the workers. Personally, I find such attempts unpleasing. Demanding that I have to share the company's mission and values is an intrusion into an individual's personal boundaries.
If you're unlucky enough to find yourself in such a company, the logical step seems to be to pretend to follow the rules but do the bare minimum. Try doing a little less tomorrow and see how your management reacts. If you're not the best worker on the team, that doesn't mean you're a bad person. At worst, they'll ask about your health. At best, you'll save yourself some personal time. Invest this time in self-training, interviews, side projects, and your health. Time is the most valuable thing we have.
Your greatest asset is your skills and nerve, not the success of the company's current project. If production falls, and you learn to fix it, you win. If the company makes money at the cost of your burnout, you lose.
Top comments (0)