The problem is not how much you know, but the systems you were shaped in. If you have been working as a backend developer in Colombia for several years, it is quite likely that you have had uncomfortable moments where something does not quite add up: you resolve tickets quickly, you know your stack well, you are even the person others turn to when something breaks… yet when you look ahead, it is not entirely clear whether you are growing or simply accumulating more of the same type of experience.

That feeling is often misinterpreted. Many engineers read it as a sign that they need to learn something more—another language, another framework, another tool that will “take them to the next level”—when in reality the problem is usually much more structural and less obvious: it is not what you know, it is the type of systems you have been working on for years.

Because not all backend environments are the same, even if they use exactly the same technologies. And that difference, which is invisible at first, ends up completely shaping how you think as an engineer over time.

Two backend developers, two completely different realities

From the outside, two backend developer roles can look equivalent. Both use Node, Java, or Python; both work with APIs, databases, and distributed services; both write tests and participate in code reviews. On a CV, they might even look almost identical.

But when you look more closely at the type of problems they solve, the difference is profound.

On one side, there is the developer who spends most of their time:

• Fixing bugs in systems that have been in production for years
• Adding endpoints or adjustments to architectures that they did not design
• Integrating external services following already established patterns
• Optimizing queries or pipelines without questioning the underlying model

On the other side, there is the developer working in a product environment where they constantly face open-ended questions, where code is only one part of the problem, and where technical decisions directly impact how the system and the business evolve.

Both are “doing backend.” But only one is developing engineering judgment.

The silent loop of maintenance

One of the biggest problems in backend web development across many LATAM contexts is not technical complexity, but the repetitive nature of the work. Maintenance is not static; on the contrary, it is often demanding, urgent, and constant. There is always something to fix, adjust, or optimize.

And that creates an illusion of growth, because you are busy all the time.

However, if you honestly look at the type of decisions you make day to day, a pattern emerges: most of the time, you are operating within a system whose boundaries were already defined by others. You are not deciding how the system should behave—you are ensuring it continues to function as expected.

That loop has some clear characteristics once you start noticing it:

• The bugs you fix rarely force you to rethink the system’s design
• Performance improvements are incremental, not structural
• Technical discussions revolve around implementation, not architecture
• Important decisions are already made upstream or by another team

None of this is useless. In fact, it is an essential part of any production system. The problem appears when this is the only type of exposure you have for years, because that is where growth becomes flat.

Where the game really changes: working in product

The shift toward product environments is not about adopting more modern technologies or working on “larger” systems in the abstract. It is about something more uncomfortable and, at the same time, far more formative: working on problems with no predefined correct answer.

In this type of context, the role of a backend developer shifts from implementing solutions to actively participating in their definition. This means engaging in discussions where the code does not yet exist, where you need to understand the problem before thinking about the solution, and where each technical decision has consequences beyond the immediate.

For example, a typical conversation stops being “we need to add an endpoint to solve X” and becomes something far more open and demanding: whether that endpoint should exist at all, whether the problem is better solved by modifying an existing flow, how that decision impacts system consistency, what happens as data volume grows, or even whether the problem should be solved in the backend or elsewhere in the architecture.

These are the kinds of discussions that build judgment. And judgment is ultimately what separates someone who executes well from someone who can design systems.

Why is this especially common in Colombia (and LATAM in general)

In many cases, the type of projects available locally—whether in traditional companies, consultancies, or even certain outsourcing models—tends to prioritize operational stability over product evolution. This means a large portion of backend work focuses on maintaining existing systems, fulfilling third-party requirements, or keeping integrations running.

This is not inherently a problem. The issue arises when that becomes your only type of experience during key stages of your career, because it limits your exposure to:

• Architectural decisions from scratch
• Fast product iterations with real user feedback
• Technical discussions involving disagreement and exploration
• Direct responsibility for how the system evolves

Without that exposure, it becomes very difficult to develop a more complete view of the role.

The impact when you try to take the next step

This gap is not always obvious until you try to move into more demanding roles, especially in teams that continuously build product. That is when many interviews begin to reveal a difference that is less about specific technical knowledge and more about how you think.

Questions start to appear, such as:

• Why did you choose that solution over another?
• What trade-offs did you consider?
• How would this scale if the system grew 10x?
• What would you do differently today based on what you learned?

And that is where many engineers—even with several years of experience—feel their answers fall short. Not because they cannot code, but because they have not been exposed enough to contexts where those questions are part of everyday work.

Changing your stack will not solve this

A very common reaction to this situation is to compensate by learning more tools: a new language, another database, a more modern framework. All of that helps—but it rarely addresses the root problem.

Because you can be using the latest technology on the market and still be working on exactly the same type of problems, with the same level of depth and the same growth ceiling.

The real change is not technological. It is contextual.

What you should start looking for if you want to break out of that loop

When you start evaluating new opportunities as a backend developer, there are signals that matter far more than the list of technologies. They indicate whether you will actually be able to grow in terms of judgment and exposure.

Some of the clearest ones:

• Real space to participate in technical decisions, not just implement them
• Teams where backend, frontend, and product collaborate continuously
• Systems in evolution, not just maintenance
• Shared responsibility for what happens in production
• A culture of technical discussion, not just ticket execution

These are not always visible in job descriptions, but they become clear quickly when you ask the right questions.

The inflection point: thinking in systems, not tasks

At some point—if your environment allows it—your approach to work starts to change. You stop seeing each ticket as an isolated unit and start seeing it as part of a larger system, with interconnected implications.

This translates into very concrete behaviors: questioning decisions you previously took for granted, proposing alternatives even if they are not the fastest option, anticipating problems before they reach production, and, above all, understanding that your work does not end when the code compiles, but when the system behaves as expected in the real world.

That shift does not happen overnight, nor is it learned in a course. It is the direct result of the type of problems you are exposed to.

Conclusion

If you are currently working as a backend developer and feel you are progressing more slowly than you should, it is worth looking beyond your individual skills to analyze the environment in which you are growing.

Because the difference between a backend engineer who evolves and one who stagnates is rarely about how much they know, but something far more decisive: whether their day-to-day forces them to make decisions that impact real systems… or simply to keep running decisions already made by others.