You finish a difficult project and your manager tells you how much the team needed it. Your performance review backs that up. Then you try to explain your standing outside the company and realise that almost everyone who knows your work has the same employer.
That’s a frustrating position for a Global Talent applicant. You can spend years solving serious technical problems while your public profile barely changes. Internal praise is real, but people outside the business haven’t had a chance to judge your expertise.
Speaking and writing give them that chance. Both let you share what you know without needing your employer’s product to become famous first.
Public speaking
Choose a problem you understand well enough to help another engineer solve. A broad talk on the future of AI gives an organiser very little to work with. A session on controlling the cost of a public LLM API has a clear audience and a practical reason to attend.
My LLMSecOps article grew out of a talk I gave at DevOps Leeds. It explains a concrete problem: a short prompt can trigger an expensive response, so limiting requests alone doesn’t control your spend. That’s a teachable topic with a useful technical argument, rather than a tour of someone’s job responsibilities.
Find external technical meetups where that problem belongs. Look at their previous sessions and pitch something appropriate to the audience. An engineer who has never spoken publicly can start with a short meetup slot rather than wait until they feel ready for a major conference. Make the proposal specific about the problem you’ll explain and what attendees can apply afterwards.
Use the questions from that session to improve the next version. Publish the slides or a recording where you have permission, so another organiser can see what you actually teach.
Delivering a talk is activity. An organiser selecting your proposal for a relevant event, or inviting you because they value your expertise, adds external recognition. Attendees applying your approach adds a different signal: the knowledge was useful beyond the room. Those signals can support a recognition argument, but a selected talk doesn’t automatically satisfy a Global Talent criterion.
Writing
Your own blog is a perfectly sensible place to begin. You control the space and can develop an explanation properly, without waiting for an editor to say yes.
Write about a decision another practitioner might face. Explain why you’d choose one approach and where it fails. Let someone test your argument using a public example. A small reproducible demo gives readers something to challenge or use. Another summary of the documentation gives them less reason to remember you.
Once you have a substantial article, look for a relevant technical publication with genuine editorial review. Read what it publishes and pitch an argument that belongs there. An independent editor choosing your work adds validation that pressing publish on your own site cannot provide by itself. Other practitioners citing the article or using its approach can show that your contribution travelled further.
Paying for a flattering feature buys publicity. It doesn’t establish that an independent publication valued your expertise, and it isn’t a shortcut to recognition.
Keep protected employer material out of both routes and check the applicable permissions before sharing work-derived content. Public examples help you teach; removing a company name doesn’t make confidential details publishable.
Meaningful contributions to an existing open-source project, or sustained mentoring through an established programme, are other routes if they fit how you already contribute. You don’t need to pursue every option.
Pick the route you can develop with depth. Give people outside your company something useful enough that they have a reason to seek out your work again.
