How to Get Engineers to Care About Your Localization Ask
Demystifying the Tech Side of Product Globalization
“It’s no use of talking unless people understand what you want to say.”
Zora Neale Hurston
Zora Neale Hurston is one of my favorite American writers of the 20th century (if you don’t know about her work, I highly suggest looking her up). This is one of my favorite quotes of hers and you can apply it to almost anything in life (although I doubt she would have cared much about engineering bugs - she had much more important work on her plate). In the localization world we know what Hurston meant, in fact it’s kind of what localization is all about. Helping people understand and engage with each other through language.
Today I want to talk about bridging the communication gap between loc and engineering. Let me paint you a (probably familiar) picture: Let’s say you noticed a small localization issue. A simple one. A UI element was hardcoded and hadn’t been translated. But it’s an important one, let’s say we’re talking about a core button like a crucial action in a key flow. In English, it said something sensible. In Japanese? French? Spanish? Nothing. Just the fallback key: CTA_SUBMIT_231.
You’ve probably seen this before...so let’s say you flag it, you create a ticket to log it, maybe you even go the extra mile and nudge the right people in Slack.
And then… nothing. The ticket is left lingering in the backlog like Gollum in the Misty Mountains….unseen, muttering in the darkness. Nobody picks it up. Nobody prioritizes it. If you’re a localization professional you know this feeling (ahhh!!). And you also know why prioritizing localization fixes is important, how it impacts users and impacts engagement, conversion, how it makes the app look sloppy and unreliable. So what’s the deal, why does it feel like eng teams don’t see the problem?
Like you, I have been in this situation many times, and I eventually realized I wasn’t being ignored because engineers didn’t care. I was being ignored because I didn’t explain why they should care, in a way that mattered to them. Over the years I have learned that engineers, TPMs, EMs, and senior stakeholders need clarity, context, and a reason to prioritize your thing over the fifty other things they’re juggling.
Today I’m going to teach you 2 ways I position my engineering asks so that they are prioritized and understood. And in my next Deep Dive (at the end of May) I will share with you how I build business cases for LARGER engineering initiatives (bigger than bugs).
First: Talk to the right person
Ok, so the very first step in all of this is to make sure you are talking to the right person when you surface engineering issues. Pinging a developer with “this is broken, it’s important, please fix it” might feel efficient, but it is probably not the best approach. Developers usually don’t decide what gets worked on next; that’s the job of the product manager (PM), engineering manager, or lead engineer. If you want your issue to get traction, make sure you're talking to the person who actually controls the backlog. Note: building bridges with developers is still incredibly valuable, but when it comes to prioritizing work they are not usually the best point of contact.
Once you find the right person, schedule 30 mins with them. Plan the meeting and manage the time properly! Here is my suggested agenda:
Understand their key work and prioritization metrics (10 mins)
Explain your work (5 mins, keep this short and snappy)
Discuss a couple of solutions or ways of working together (remainder of the call)
Understand their key work: when you sit down and talk to them the first thing you want to understand is their key metrics and goals. This could be anything from “increase engagement” to “build a new onboarding flow” or maybe it’s more vague like “optimize technical infrastructure.” Be curious, ask them how they are trying to reach these goals and what their timeline is. Listen for places where your work or expertise may overlap with theirs.
Explain your work and how it intersects: The goal is for them to align with you on the problem. I strongly suggest bringing a short deck to this convo, where you share:
how many localization bugs you are seeing per [period of time, like quarter, sprint or launch]. (if you don’t have immediate access to this data, this could be a cool learning opportunity to grow your technical skills: Watch this short video on how to search for issues in Jira)
Bonus: If you ran a bug bash like we talked about in the post “What is i18n? How Can I Be a Resource for Engineers I Work With?” this would be a great time to bring it up so they can see how localization issues impact your specific users!localization impact metrics (if you can) on why localization matters
How many users are in markets you are localizing for (ex: 30% of our existing users and 70% of our new users are in non english speaking markets)
How good localization can increase user engagement (and other key metrics that they probably care about). If you don’t have company specific metrics I suggest checking out this Medium article by Valeria Nanni which shares really great data on the impact of localization.
Finally, propose a new way of working together and ask for their feedback:
I suggest preparing the following two proposals:
First: And this is the ideal solution, so lead with it and see if you can get it ;) You are going to ask for a portion of dev time to be dedicated to fixing localization issues. Different companies track engineering time different ways, so once you understand how they track their time, ask for a percentage of it to be dedicated to prioritizing localization issues. I suggest making the ask very specific to your org. You don’t want them to think that you are asking for important development time to fix an issue that affects 4 users, you need to be strategic with what you are asking for. Issues that impact key markets or users should carry a higher weight in prioritization. What you want to do is work with them to create a matrix to make these decisions, depending on what metrics are driving their current prioritization. This matrix might look like this:
Now, it’s likely they will say no to this first suggestion. Especially if you don’t have a prior relationship with them and if you are still establishing yourself as a technical partner in the company. In that case, you can go with my second proposal!
The second proposal (and more likely to be accepted) is to work with them on a case by case basis. Don’t include this option in your slides, only propose it if they don’t go for the first proposal. This option is a great way to build trust. Once you work with them for 6 months come back and propose option one again! You will build trust over time by showing them that you aren’t working against them, you are working with them for the good of the end users of your product.
So how to you work with engineering on a case by case basis? Now, even the most empathetic PM can’t prioritize something they don’t understand. Prioritization is a balancing act…they’re trying to do the most important things first. Or, maybe they need to do xyz first so that they can show impact and get more engineers so that they can tackle that growing backlog of tech debt. This means you need to explain not just what’s broken, but why it matters. Like we discussed above, the first thing you should look for is: does this impact a key metric that the PM/Eng Manager/Company is focused on? (if you don’t know what these metrics are - ask!) If you can’t connect the issue to a key metric, you still need to help position the ask. How many users does it impact? Are they paying users, newly acquired users, emerging market users? Is this problem affecting a critical market or feature? Can users still complete a key flow, or are they stuck? And if you can connect it to the company’s business metrics and priorities (usually things like engagement, paid conversions, or new user acquisition) you’re golden. But don’t be discouraged if, during this exercise, you realize the issue might not be the highest priority. That’s part of the process. You should still log it, and understand it won’t be at the top of the pile.
Ok, so now take a deep breath. I know you’re probably thinking “what the hell, I don’t have time to write a research paper every time I need a bug fixed!” Don’t worry, I’m going to make this easier, and you don’t necessarily need all of this data for every ask. My suggestion is to create a decision matrix to help you decide when to throw a lot of effort at getting a bug or issue prioritized. This should be based on your/company’s key metrics. I don’t know what those are, so I’m going to guess here going off of the example we used above. Your decision matrix might look like this:
So if we take a practical example:
Let’s say part of the conversion flow has a localization bug that requires an engineering fix. If we are using the above matrix that would be categorized as a high impact bug because it is a critical flow that impacts users converting to paid. In this case I would recommend spending some time gathering the metrics and business context, and the steps to recreate the bug. I would also escalate this to the PM (or whoever manages the backlog) once the bug has been logged.
Following this process will build trust. If you raise your hand for every tiny issue you become noise, if you show them that you are strategically elevating the most important issues, and providing the right context, you become a partner. Make sure to share your decision matrix with them so they understand the logic behind your prioritization framework. In addition, this builds your technical skills, this is a skill you would need as a TPM, Product Manager, or team lead. It shows you are strategic and understand how your work impacts their work and the broader business.
Another secret weapon? Be in the room. Join the planning calls. But don’t be that person - the one who zones out, only to pop up when their pet ticket isn’t mentioned. Approach their work with curiosity. Listen. Learn how the team prioritizes work. You might realize there’s a strategy behind what gets done and when. Not sure how to join? Try: “Hey, I know I’ve been following up on [XYZ ticket], but I’ve been curious about how sprint planning works here, could I join a call or two just to listen in?” If you’re in a senior role or already have rapport with the team, something like “I’d love to pop into sprint planning or standups occasionally to make sure I’m collaborating as effectively as possible, can you add me to the invite?” works well.
If you're in the room for a daily standup or weekly sync, you can share a quick sentence about your focus. It puts your work on people’s radar without having to chase them down later. When I worked at a smaller company, I rotated through different teams’ standups and made a point to attend at least one planning session per month. I learned a ton, not just about what was being built, but why and how. Aaaannddd the teams got used to seeing me, and this kept my work top of mind. Being in the room says: I’m here, our work intersects and this is how.
Ok, so now let’s say you are doing all of this, and you’ve been asked to log a ticket. If you’re creating the ticket yourself, here’s a quick formula for a great user story:
User Story Formula:
As a [type of user], I want [what the user wants] so that [why they want it].
Examples:
As a Spanish-speaking user, I want to see onboarding instructions in Spanish so that I can complete the signup process without confusion.
As a mobile user in Brazil, I want to see prices in Brazilian Reais so that I understand how much I’ll be charged.
As a product manager, I want localization bugs clearly prioritized so that I can align my team’s work with business goals.
Follow that up with:
– Steps to recreate the issue
– Device + OS/browser details
– Screenshots if possible
– What you expected to happen vs. what actually happened
If this still sounds like gibberish, there are some great video tutorials out there that walk you through each step. Start with How to Create Bug Issues in Jira and/or How to write User Stories & Acceptance Criteria
Tldr:
If you want to get your localization work prioritized, don’t just say “this is broken.”
Be strategic, build bridges and find collaborative solutions. You show what’s broken, why it matters, what the fix could look like, and how it helps the business.
What’s Next? And subscribe for Deep Dives + more focused resources
You guys this week I’m recording my interview with an i18n engineer asking all of your questions!! There’s still time to get your questions in here, and make sure to subscribe to make sure you see the video on your inbox, it will be out next week!
And then at the end of this month, I’ll release a deep dive for paid subscribers on how to position LARGER asks, like building a new tool or feature. I will share a business case template I have created and used in my roles, and walk you through how to apply it in your own space. Subscribing is the cost of grabbing me a coffee, and it helps justify me spending a few Saturday afternoons creating these structured lessons.
What did you think? Let me know in the comments and/or connect with me on LinkedIn!