You broke into the international market. And kept thinking local.

The first time I worked on a project outside Brazil, I thought the biggest challenge would be technical English in meetings. It wasn't.

I figured out the English part quickly. The real problem was realizing, weeks later, that I was operating on a set of assumptions that simply didn't apply there. About how to show value. About what's expected of a senior engineer. About what actually counts as delivery.

I had entered a different market carrying the wrong map.

The wrong map is invisible

When you spend years working in the same context, you develop a mental model of how things work. Who decides. How technical decisions get communicated. What a pull request needs to contain to get merged. What's expected of someone at your level.

That mental model is invisible because it was never explicit. You absorbed it by osmosis.

The problem is that it's specific to the context where it was formed.

In Brazil, at a fast-growing fintech, the senior engineer who ships fast and puts out production fires is valued in a certain way. On a distributed European or American team, that same behavior can come across as impulsive, lacking process, lacking documentation, lacking predictability.

It's not that one is right and the other is wrong. It's that the underlying assumptions are different.

And you won't notice this in the first month. You'll notice it when a technical decision of yours gets rejected for reasons you don't understand. Or when you feel like you're delivering more than anyone else but still remain invisible in architecture discussions.

What actually changes when the context changes

I've worked on projects ranging from software shops serving clients in France to platforms with tens of millions of users in Brazil. What I learned is that user scale and team scale create very different pressures.

On a large, distributed team, written communication is worth more than verbal. Not because people prefer it. Because it's the only channel that survives across time zones, turnover, and short institutional memory.

On a smaller, local team, a quick conversation resolves things faster and everyone still remembers what was decided last week.

When you move from one context to the other without noticing that difference, you start making decisions that make perfect sense in your head but exist nowhere on record. Three months later, when the developer who joined after you questions that decision, you have no way to defend it beyond "I decided that way because it seemed right."

That's not laziness. It's a local mental model applied to a context that calls for a different one.

The mistake I made and watched others make

There's a pattern I call the Local Senior in a Global Context: the engineer who has the right technical skills but projects their success criteria from the previous market onto the new environment.

They write good code. They solve real problems. But they don't document decisions. They don't write RFCs. They don't justify trade-offs in writing. They don't connect the technical delivery to product impact in a way the international team can read without prior context.

On a local team, that works because the conversation happens on Slack and everyone understands the history. On a distributed team with people across four time zones, the engineer who doesn't document is the engineer who doesn't exist for half the team.

The practical result: excellent technical output that never translates into architectural influence. Not because the ability wasn't there. Because the right channel wasn't there.

What actually works

The most concrete change I made was to stop treating documentation as bureaucracy and start treating it as a product of my engineering.

An architectural decision with no record isn't a decision. It's an intention that will disappear the moment you go on vacation.

I learned that the hard way. On a project with multiple parallel teams, I had migrated a module from VIPER to MVVM for solid technical reasons. High coupling, difficulty testing, friction in maintenance. It made complete sense to me.

Two months later, another team reverted part of the migration because "they didn't know a decision had been made." I knew. But only I knew.

The decision was in my head, not in the repository.

What nobody talks about when it comes to technical visibility

There's a common belief that good work sells itself. On a local market, on small teams, that even holds some truth. The manager sees the delivery, context is shared, reputation builds through proximity.

In the international market, on distributed teams, good work that isn't communicated doesn't exist.

That's not politics. It's physics. Information doesn't travel on its own in a distributed system.

The engineer who learns to articulate decisions, to connect technical delivery to business impact, and to write the context others need to trust their judgment... that engineer has influence disproportionate to their formal seniority.

What most people get wrong is thinking that technical influence comes from better code. It comes from legibility. The code needs to be good. But the decision behind it needs to be accessible to whoever wasn't in the room when you made it.

An honest trade-off

Documenting well and communicating clearly has a cost. You write more. You revise more. You spend energy on artifacts that not everyone will read.

On small, fast-moving teams, that cost can outweigh the benefit. You document a decision that's going to change in two weeks anyway.

The question isn't whether to document everything. It's about calibrating the durability of the decision. A decision that will last six months deserves a record. One that will last two days doesn't.

The problem is that most engineers entering the international market apply the small, local team criteria to every decision. They document nothing. And then they become invisible precisely where they should have a voice.

What I would do differently today

I would have realized sooner that my career model was a local one.

Not in the sense that it was bad. It was well-suited for the context where it was built. But entering a different environment without revisiting your assumptions is like trying to run an app designed for an iOS version that's no longer supported on the latest SDK. It technically works. But it breaks at the edges.

The most important adjustment isn't technical. It's behavioral. How you communicate decisions. How you build a reputation in an environment where nobody watches you work. How you calibrate what counts as delivery.

A senior engineer isn't someone who knows the most. It's someone who can make their reasoning survive without them in the room.

On a local team, you can be in the room every time. In an international market, you won't be. And what stays behind in your place is what you wrote, documented, and justified in a way that doesn't need you to explain it.

That's the adjustment most people delay because it seems secondary. It only seems that way.