Production on Fire - Where Does Seniority Really Begin?

Anyone who has worked in software development probably knows this scenario. Deployment day. The deployment is successful, the pipeline is green, and the long-awaited feature is finally in production. The team is celebrating, the business is happy that the new functionality is going to make their work easier… until suddenly, errors start popping up. A Flow isn't working as expected, data is being updated in unexpected ways, or an error prevents users from creating new records altogether. The stakes get even higher when the issue means real financial losses or puts the company's reputation at risk. The first instinct? “We need to fix this as quickly as possible!” But be careful - this is exactly when you can make a mistake far more serious than the one that caused the problem in the first place.

A production incident itself isn't necessarily the worst-case scenario. Mistakes happen, and they can never be eliminated entirely. A chaotic response to them can turn out to be far more dangerous.

Seniors aren't infallible either

Many people - especially mids and juniors - seem to believe that once someone becomes a senior, they somehow become immune to mistakes. That's a myth. Sure, a senior may know the platform well, write solid tests, perform better code reviews, understand deployment procedures, and be more aware of the risks introduced by a change. None of that makes them infallible.

As experience grows, so does the scope of responsibility. More complex processes, more dependencies, supporting less experienced colleagues, meetings, and "quick calls" all add more things to keep track of. The more complex the system and the greater the cognitive load, the more opportunities there are to overlook something despite following good practices. On top of that, working with Salesforce means constantly learning. You can spend 5, 10, or 20 years in the ecosystem and still not know everything.

Experience doesn't mean you stop making mistakes. What distinguishes a senior from a mid or junior is the ability to manage their risks and consequences more effectively. And a crisis is often where that difference becomes particularly visible.

Before you reach for duct tape and zip ties… figure out what's actually broken

A less experienced person's first instinct may be to open VS Code or Setup and start looking for a fix. A senior knows that before fixing anything, they need to stop and assess the situation.

What exactly isn't working, and since when? Did our deployment actually break it, or had the problem already been sitting unnoticed in production? What's the scale of the issue, and who is affected? Service Agents who can no longer do their jobs? Or customers who can't complete a purchase?

A senior also checks which processes are affected and whether the issue is spreading into others. Is any data at risk? What happens if we do nothing for the next 30 minutes? Is there a workaround?

They also don't automatically assume that every reported issue is a bug. The root of the problem may be messy data or incorrect use of the system. Even "user error" doesn't always close the case - it's worth checking whether users were given proper documentation and training in the first place.

A junior is therefore looking for the answer to: “How do I fix this?” A senior first wants to know: “What actually happened, and what are the consequences?” At the same time, they remember that communication is part of the solution. They clearly separate what they know from what they don't know yet. They avoid presenting speculation as fact, drowning the business in technical jargon, or promising a resolution time without a solid basis. Most importantly, they don't leave the business in the dark while they're still looking for answers.

The road to more bugs is paved with good intentions… How not to make things worse while "fixing" them

We’ve established what's broken and which process is suffering because of it. We can also see that, technically, the fix is simple - a single click in Setup. The junior is already relieved: one click and we're done! The senior asks one more question: what else will happen when we click it?

Because a “technically simple” fix can have consequences that aren't simple at all, affecting other processes or even data security. A senior doesn't look only at the configuration standing in their way. They check why it exists in production, what depends on it, and what else may rely on its current setting. Disabling it might put out one fire while starting another.

A less experienced person will often focus on the first solution that works. A senior looks for alternatives, even when they require more effort. They check whether a rollback is possible, consider a hotfix or workaround, and compare the impact each option would have on processes, data, and users. The simplest solution isn't always the safest one.

The difference also becomes visible when those options need to be presented to the business.

A junior might say: “We have three options. Which one do you want?” A senior knows that a list of possibilities isn't enough. The business needs to understand how each option will affect its processes, while the specialist should assess the technical consequences and risks and then make a recommendation: “We have three options. I recommend option B because…”

That doesn't mean overwhelming the business with technical details. Quite the opposite. A senior should be able to translate technical consequences into the language of risk and business impact. The final decision may belong to the business - the specialist’s job is to make sure it’s an informed one.

Ownership without a witch hunt

Another important difference between a junior and a senior is the ability to admit a mistake or say “I don't know” without seeing it as a reflection of their overall competence. A less experienced person may fear that admitting they started the fire will undermine how others perceive their knowledge or skills. That creates the temptation to stay quiet, downplay the issue, or try to fix it before anyone notices.

That's why the senior's attitude matters so much. If they made the mistake themselves, they acknowledge it openly and focus on resolving the situation. If someone else made it - especially a less experienced colleague - the goal shouldn't be to find a scapegoat, but to understand what happened and why. This helps build a team where someone can say, “My change caused the issue”, without being afraid of getting blamed for it.

And this isn't just about maintaining a friendly atmosphere. It's difficult to put out a fire quickly when part of the team is afraid to tell you where the flames came from. Fear of admitting mistakes obstructs the flow of information, delays the response, and makes it harder to prevent the same issue from happening again. Ownership means taking responsibility for a mistake - not starting a witch hunt.

Once bitten, twice deployed - one lesson closer to seniority

Here’s the good news: every production fire gives the entire team +100 experience points.

Juniors and mids get a chance to learn crisis management from their more experienced colleagues. Seniors get a chance to improve the way changes are managed.

But working on an issue doesn't end with the fix. Once the situation is under control, the team should review the incident and ask a few questions. Why didn’t our tests catch the issue? Was the business scenario properly defined? Was there a difference between environments that we hadn’t anticipated? Could someone have spotted the problem earlier? These questions should be the beginning of the analysis, not the end.

The analysis should lead to a change in how the team works. Otherwise, the lesson has been wasted. The outcome might be an additional test, a sanity check, a change to the review process, better monitoring, or a more reliable rollback plan. The point isn't to add procedures for the sake of having more procedures. It's to make the same fire harder to start a second time.

Because seniority isn't built solely on the number of years spent in the ecosystem or the number of Salesforce features you've learned. It's also built through experiences like these - as long as, once the fire is out, they leave behind something more than a closed ticket.

About the author:

Sandra Kuc-Malinowska is a Salesforce Developer working on the development and maintenance of solutions built on the Salesforce platform. Her work combines software development, process automation, integrations, and business requirements analysis. She is particularly interested in designing solutions where technology addresses real business needs and processes.