To be honest, I don't think this is any of the engineer's fault. I think we're an open creature by nature; we like to share and explore ideas with others.
In the corporate field, what I've observed is that deliveries are most important. Not just any deliveries, but the project has to be big and "impactful" (as in, other teams use it too), and you personally have to own it. Like your name has to be attached to it. No one is going to remember your tiny fixes here and there, or tiny feature implementations in the larger system, even if it's tracked in sprint. All that stuff gets looked down upon as just 'doing your job'.
To get any kind of recognition and ultimately, a promotion (or better raise, better rating, better bonus, etc), we absolutely have to clam up and take entire ownership of the work. If that's not done, other people can swoop in and steal the work. Things become need-to-know basis for your other fellow devs, design meetings is just you leading them and asking if this is fine, etc. Everyone has to know you're leading the project, and you have to constantly enforce that knowledge to put down any attempt at a takeover.
I've personally witnessed this happening to an older and more senior dev when a college graduate tried to assert himself on the team until the senior dev fought back with office politics.
In the end, office politics is what matters, along with your work to back up your office political agenda. Another senior dev could come in and take your project, claim your code is terrible and needs a rewrite, etc. You can only win if the boss is on your side, and that requires you to take on more than you can chew (and of course, deliver it all) to get on the boss's good side.
Imagine if we didn't have that kind of pressure of delivery in the workplace just to get recognition. The first example that comes to mind is Open source work. People just contribute, we share and deliver openly, and as a result community projects grew so big our entire corporate infrastructure became dependent on it.
> Imagine if we didn't have that kind of pressure of delivery in the workplace just to get recognition.
While the places I have worked might have a tiny element of this your situation sounds extreme.
What I have seen is yes you do have to do “perception” management to keep a pulse on “how am i rated”.
Having a few long time trusted people vouch “this person is good” helps
and all you need to do is work with them and show that you are good, both in attitude and capability.
However your description sounds like a dystopian “house of cards” scenario that I would be looking for another job asap. If the programmers are more like politicians that is very odd and a bad sign.
I should clarify this behavior is mostly at larger companies... and although it's my anecdotal piece, it is what I've consistently seen at different companies and what my friends tell me they've experienced at other large companies. I've also worked at smaller places and this behavior was not as prevalent since everyone knows everyone on the dev team.
Also, at larger companies your manager tends to reorg. I've gone through 5 managers in a single year before. And with them goes all the goodwill you built up during that time. New manager comes in, and it basically resets your 'perception' factor. The old manager might tell the new manager that some people are good, but you have to get lucky to get the new manager to care, because they haven't seen the results with their own eyes yet. That small time window is when it's ripe for someone to swoop in and claim ownerships of projects, while smooching up to the new manager. That's what happened with the senior dev I saw, but he had aces up his sleeves. What an epic showdown.
Yea, I should leave probably, but it's just one burning ship to another. That's our fundamental reality.
What you are describing is mostly related to practice of building organizational units focused purely on implementation, and nothing else. Your personal success in such a unit depends heavily on a number of successful implementations under your belt.
The more organization separates project implementation from the goal-setting and strategic work, the less reasons are there for people responsible for implementation to focus on something different than just getting another green checkmark on that project milestone (and getting recognized as the one who was most impactful in getting there).
Sustainability, recognition of actual business value, meaningful team work — all of these quickly go out the window as people focus on gaming the only metric they’ve been assigned.
In the corporate field, what I've observed is that deliveries are most important. Not just any deliveries, but the project has to be big and "impactful" (as in, other teams use it too), and you personally have to own it. Like your name has to be attached to it. No one is going to remember your tiny fixes here and there, or tiny feature implementations in the larger system, even if it's tracked in sprint. All that stuff gets looked down upon as just 'doing your job'.
To get any kind of recognition and ultimately, a promotion (or better raise, better rating, better bonus, etc), we absolutely have to clam up and take entire ownership of the work. If that's not done, other people can swoop in and steal the work. Things become need-to-know basis for your other fellow devs, design meetings is just you leading them and asking if this is fine, etc. Everyone has to know you're leading the project, and you have to constantly enforce that knowledge to put down any attempt at a takeover.
I've personally witnessed this happening to an older and more senior dev when a college graduate tried to assert himself on the team until the senior dev fought back with office politics.
In the end, office politics is what matters, along with your work to back up your office political agenda. Another senior dev could come in and take your project, claim your code is terrible and needs a rewrite, etc. You can only win if the boss is on your side, and that requires you to take on more than you can chew (and of course, deliver it all) to get on the boss's good side.
Imagine if we didn't have that kind of pressure of delivery in the workplace just to get recognition. The first example that comes to mind is Open source work. People just contribute, we share and deliver openly, and as a result community projects grew so big our entire corporate infrastructure became dependent on it.