Ing. Alejandro Medina recently shared something that caught my attention because it is both funny and uncomfortably true. He wrote:

Antes para programar necesitabas saber varios lenguajes de programación ahora :

Junior = inglés A1
Middle = Inglés B1
Senior = inglés C1- C2

In a few lines, he reframed a big shift in our industry. It used to feel like career growth was mainly about collecting programming languages and frameworks. Now, in many teams, the differentiator is whether you can work effectively in English.

I want to expand on what Ing. Alejandro Medina is pointing at, not as a judgment of talent, but as a reality of modern software work. If you have ever felt like you are doing great technically but struggling to advance because of communication, this is for you.

The joke works because the workplace changed

When Medina maps junior, mid, and senior to A1, B1, and C1-C2 English levels, he is not saying code quality depends on grammar. He is highlighting that the scope of your job expands as you gain seniority:

Junior developers often work on well-defined tasks with close guidance.
Mid-level developers coordinate more, ask better questions, and contribute to planning.
Senior developers influence decisions, align stakeholders, and mentor across teams.

As your scope expands, so does the amount of communication you must do, and in many global companies the default language is English.

The higher you go, the more your job becomes: explain, align, negotiate, document.

Why English matters more than ever in software

Several trends make Medina's point feel sharper in 2026 than it did a decade ago.

Remote and distributed teams are the default

Even if you work locally, your company might have:

a product manager in the US
a designer in Europe
a QA team in LATAM
an infra team in India

One shared language is the simplest coordination mechanism. Like it or not, it is usually English.

Most technical knowledge is written in English first

Docs, RFCs, GitHub issues, release notes, research papers, and conference talks often appear in English before they are translated (if they are translated at all). If you can read and write comfortably, you learn faster and contribute earlier.

Senior impact is measured in decisions, not tasks

At senior levels, the hard part is rarely the syntax. It is choosing the right tradeoff and getting buy-in:

What problem are we solving?
What are the constraints?
What is the rollout plan?
What are the risks and mitigations?

Those conversations are language-heavy. That is why English can feel like a career accelerator or a ceiling.

Interpreting the A1, B1, C1-C2 ladder in practical terms

Medina used CEFR levels, which are common in language learning. Let us translate those levels into what they often look like at work.

Junior: A1 does not mean incapable, it means supported

An A1 level is basic. In a software context, a junior with limited English can still thrive if the environment supports them.

Typical strengths at this stage:

strong coding fundamentals in their primary language
ability to follow tickets and implement scoped changes
learning quickly by imitation

Common friction points:

reading long documentation
understanding fast meetings
asking questions with the right context

What helps juniors most:

Asking for written instructions and summaries
Using templates for questions (Context, What I tried, What I expected, What happened)
Writing short daily updates in simple English

Junior goal: be understandable, not perfect.

Middle: B1 is where collaboration becomes visible

A B1 level is functional. This is often where you can participate reliably but still feel tired after meetings.

At mid-level, your job begins to require:

clarifying requirements
negotiating scope
reviewing PRs with meaningful comments
writing documentation that others can follow

This is also the level where small communication improvements produce big career benefits. The difference between a mid engineer who codes well and one who codes well and communicates clearly is massive.

Practical B1 upgrades that pay off:

Learn the language of tradeoffs: performance, maintainability, reliability, compliance, cost
Practice structured writing: problem, options, recommendation
Repeat back decisions in meetings: So we agreed to X by Friday, and Y is out of scope

Middle goal: reduce ambiguity for everyone else.

Senior: C1-C2 is about leadership through language

When Medina says senior equals C1-C2, the deeper point is this: senior engineers lead with clarity.

At senior level, you are expected to:

influence architecture and roadmap
handle stakeholder tension calmly
mentor and unblock others
communicate risk without drama
write proposals that survive scrutiny

C1-C2 does not mean sounding like a native speaker. It means you can do high-stakes work with nuance. You can be precise, diplomatic, and persuasive.

Senior communication behaviors that signal C1-C2 competence:

Writing RFCs that clearly state assumptions, constraints, and non-goals
Explaining complex systems with simple metaphors
Asking incisive questions that surface hidden risks
Handling disagreement professionally: I see it differently because..., What data would change our minds?

Senior goal: make complex decisions easy to understand and hard to misinterpret.

The upside: English is a learnable technical skill

One reason Medina's post resonates is that it reframes English as part of the modern engineering toolkit. That can feel unfair, but it is also empowering because language improves with deliberate practice.

A simple weekly plan for busy developers:

Reading: 15 minutes a day of official docs or well-written engineering blog posts
Listening: 2-3 short tech talks per week at 0.9x speed if needed
Writing: one short artifact per week (a PR description, a decision summary, a mini doc)
Speaking: one low-stakes practice (pairing, standup, or a short explanation to a teammate)

If you want maximum ROI, focus on work English, not general English. Learn phrases that help you:

clarify (Just to confirm..., What do you mean by...)
propose (I suggest..., An alternative is...)
disagree (I am not sure I follow..., My concern is...)
summarize (To recap..., The next steps are...)

A note about gatekeeping and fairness

It is worth saying explicitly: requiring strong English can exclude great engineers. Companies can do better by offering:

bilingual documentation where possible
more async communication
meeting notes and recordings
language learning support

At the same time, if you are the individual engineer navigating the market, Medina's message is practical. English increases the number of teams you can join and the impact you can have once you are there.

Why this kind of LinkedIn post spreads

Even though Medina's post had low engagement at the time it was captured, the format is classic viral-post material:

It is short and surprising.
It uses a simple ladder people can map themselves onto.
It triggers conversation because it is both true for many and controversial for some.

If you create LinkedIn content, this is a useful lesson in content strategy: a sharp observation plus a memorable structure can travel far, especially when it reflects a real tension professionals feel.

Closing thought

Ing. Alejandro Medina compressed a decade of industry change into three lines: the higher your role, the more language becomes part of the job. Not because engineers should be poets, but because software is built by groups of humans making decisions together.

If you take one thing from his post, let it be this: treat English like any other skill. Break it into subskills, practice consistently, and measure progress in clearer collaboration.

This blog post expands on a viral LinkedIn post by Ing. Alejandro Medina. View the original LinkedIn post →