Leading Engineers in Your Second Language

Which habit is behind this for you? The free 3-minute assessment names it and links the playbooks that fix it. Take the assessment →

In a recent essay for LeadDev, engineering manager Dmitrii Sidorenko describes moving from Finland to Los Angeles in 2019 to become lead backend developer on a mobile title at an EA studio. Before that he had co-founded a game studio and run it as CTO, a role where he knew every moving part and every person on the team. He expected the hard part of the move to be engineering at a much larger scale. It was not. For roughly the first six months, he could not reliably follow what the people around him were saying - and he came to see that as a leadership problem, not a social one. What follows is our summary of his account and the lessons in it, with practical additions of our own. The original essay is on LeadDev.

He joined an established group of engineers who had worked together for years and shared their own history and shorthand. He arrived as a specialist, soon picked up direct reports, and coordinated constantly with the company's central technology organisation. The job title said backend; the calendar said one-to-ones, interviews and cross-team negotiation. One peer lead in particular spoke almost entirely in colourful idioms, and in meetings with him Sidorenko estimates he caught about half of what was said. Minutes later, he could walk the same people through how player data would be handled at scale without hesitation.

Most of leadership runs in the weaker language

It is tempting to treat idioms as decoration around the real work. For a specialist, that is roughly true. For someone moving into people leadership, that framing breaks down: the subtext is where most of the work happens.

• One-to-ones depend on tone and on what is not quite being said - telling whether "it's fine" is a real answer or a polite cover for a problem.
• Interviews require decoding a candidate's register, humour and phrasing in real time, not only the content of their answers.
• Cross-team trust is built on relationships and carried by implication more than by literal statements.

The pattern Sidorenko describes is a familiar one: the skills that earn a leadership role are not the skills the role mostly uses. The backend work he was hired for came easily. The work that determined whether he was an effective leader happened in the language where he was least comfortable.

Budget for the gap

The practical consequence is about time. If you are leading people in a culture you are still learning, plan on the people side of the job costing more than it does for colleagues who grew up in it. Some ways to build that into the week:

• Prepare 1:1s in writing. A short shared agenda reduces how much you have to catch live.
• Close every important meeting with a written recap. "Here is what I understood - correct me if I missed something" turns a guess into a confirmation.
• Leave recovery time after meeting-heavy days. Listening hard in a second language is tiring in a way that is easy to underestimate.
• Move decisions to text where you can. Asking for "the decision in the thread" is a normal request, not a sign of weakness.

Do not confuse comprehension with competence

For a leader used to being in control, every meeting where you catch 80% instead of 100% can feel like a failure. Over time, Sidorenko writes, a gap in comprehension started to look like a gap in competence, and he began to wonder whether the engineer and leader he had been at home had been left behind at the border. Under pressure, it is hard to tell "I do not understand this room" apart from "I am not good enough for this room". They are different problems, and only the first one was real.

Treat the language as a work item

What helped was handling the gap the way an engineer handles any other gap: as a backlog. He describes three habits:

• A running phrase log. Every idiom or reference he missed went into a list during the meeting and was looked up the same day.
• Deliberate ear training. The same word sounds different from a colleague raised in one region, another raised elsewhere, and another who also moved from abroad. He practised hearing the difference.
• Asking about jokes. When a joke went past him, he asked what it meant. People were generally glad to explain, and several later told him that asking had raised their opinion of him.

As understanding came back, so did confidence. Each phrase he worked out was a small piece of evidence against the story that he had lost his ability. His ability was intact; what he lacked was familiarity with new ground, and that comes with time.

The code was readable all along

The essay ends with a reframe. The colleague who had been hardest to follow was not being difficult or showing off; he simply preferred vivid, image-heavy speech. And in his own native language, Sidorenko realised, he prefers exactly the same style. In other words, the communication style that had baffled him was his own, just expressed in a language he was still learning.

The team had been understandable the whole time; he simply did not yet have the vocabulary and cultural references to decode it. Those six months were among the most stressful of his career, but curiosity and persistence opened up the language, the culture and the people, and some of those colleagues became close friends. His conclusion is that the job had never really been about control. It was about understanding the people in the room, and the trust that understanding earns.

If you manage someone in this position

The same lessons apply from the other side of the table. If someone on your team is leading or working in their second language:

• Say important things plainly. Save idioms for small talk; state decisions, deadlines and feedback in literal terms.
• Write decisions down. A short summary after a meeting helps everyone, and helps them most.
• Do not read quietness as disengagement. Ask for their view directly, or invite it in writing before the meeting.
• Separate the two accounts when you assess them. Judge technical and leadership judgement on substance, not on how fluently it was phrased.

Source: summarised and paraphrased from "The second language of engineering leadership" by Dmitrii Sidorenko, LeadDev, 2 November 2026. The experiences described are the author's; the checklists, sample sentences and advice for managers are DrillUp's.