I frequently have discussions with frustrated engineers or engineering managers on visibility. The frustration usually revolves around two points. The wrong people are rewarded, i.e., some game the system through optics and therefore get more credit than they deserve. Secondly, people just want to do their work and be recognized for it, instead of spending time showing the work.
Both points are valid. Visibility bias in performance reviews is real and should be tackled. And it’s a healthy instinct to prefer doing the work over talking about the work.
But I also think there is one point that gets lost. Visibility is communication, and it’s not extra work. It’s an essential part of the work. Especially for senior roles. Similar to politics.
Simplified, the expectation of a senior member in a software engineering org is the ability to identify impactful opportunities or problems that software can address, create a plan, execute, and deliver results. There is no way to be successful in doing that without effectively managing communication every step of the way.
To refine our own understanding and validate a problem, we need to talk to users, product managers, domain experts, and business stakeholders. To get buy-in for any plan we need to persuade leadership. Managing delivery, resolving blockers, and keeping everyone aligned all require ample communication. Once value is added and impact made, we must ensure people are aware. Not for the sake of our own visibility, but to inspire, build trust, and ensure everyone on the team gets the appropriate recognition and appreciation.
Sure, the above is not needed when you’re working on a smaller scope, but the majority of high-impact initiatives will require it, and impact is how our performance is assessed.
This is why visibility done right isn’t self-promotion; it’s a signal of good work.
Moreover, it’s a virtuous circle. When you increase your visibility, you become a role model and a goto person. This shapes culture and increases your ability to deliver through others, further increasing your impact blast radius.
Additionally, in my experience, there is a strong correlation between effective communicators, strong executional capabilities and quality code. Deep understanding and structure yield clarity, which in turn drives quality in both execution and the code. I think DHH described this beautifully on the Lex Fridman Podcast when he spoke about the difference between a software writer and software engineer.
Software engineering is a socio-technological endeavor, and communication is core to excelling at it. So the next time you feel frustrated about showcasing your work, ask yourself: what would change if you viewed communication not as self-promotion, but as the last mile of delivering impact?