People working in tech often, but perhaps not always, want to show off their proficiencies. Advertising these proficiencies is a tool used to demonstrate capability to those with promotion power, usually in hopes that the advertisement will lead to involvement in activities that they can bundle in a brag document of some kind. The more "altruistic" are those who advertise so that they can feel useful to the business and others, sharing their expertise in the hopes that they can inadvertantly help mentor their "lesser experienced" peers, and also incidentally create an environment where they can get thick with the subject matters that they find most interesting, and, therefore, have the most experience in.
Therein lies the crux of what is preferable to advertising proficiencies; interests. Whereas advertising proficiencies is veiled in an aura of "look at me", advertising interests is more about openess and curiosity, seeking a richer, interconnected experience where we know ourselves, and others, better. More importantly, in a work environment, making clear to others about your interests levels the playing field for everyone on a team, no matter their proficiencies, to continue to improve and excel.
Consider this: a junior developer is hired onto a team. She has some minor experiences, but no major proficiencies. If she gets practice, she will develop proficiencies, but she may not want to haphazardly be thrown onto various projects and may have some sense of what she wants to work on. Perhaps she is keen on becoming a better frontend engineer, or she wants to build CLI tooling, or work on distributed systems. And most importantly, these interests are not static, they may shift over time, or change depending on the things that she ends up working on with the initial interests she had. She can practically advertise her interests by saying "hey, I'd love to be tagged on pull requests for this language!" or "can I be a fly on the wall for meetings about technical designs?" Conversely, it is essential to foster an environment where she can advertise these interests and not get shut down or ignored.
Teams that are supported in working in this way are less prone to building up walls between each other. This is an important infraction of Conway's Law, especially if you have cognisantly built an organisational structure around specific communication flows; there is always an underlying fabric of The One Team, and that one team should share and delight in each other's learnings, no matter how seemingly trivial they are.
Leaders can foster this environment by modeling this behavior themselves, role modeling that insights are always welcome on their own pull requests, design docs, and so on. A little it of sunlight, a sprinkle of dissent, a dash of curiosity, all from colleagues who have an equal interest on a subject, will enrich the work being done. Perhaps the largest resistance to this will be the time it may consume or lack of precision it may involve, but at that stage there are other practical methodologies to explore from professional toolkits: timeboxing feedback, clarifying key decision makers versus contextual advisors, and urgency to autonomy grids come to mind. Critically, the aim of this is to foster an acceptance to sharing information, and an acceptance to receiving information, as a sharing of ideas, breaking down entrenched walled gardens built up around experience, tenure, or profeciencies.