There is a lot to be said for the advice "Don't work where egos are more important than the mission." But what Russ didn't learn was "How to get the mission done in the presence of egos." The thing is that there are lots of people with big egos, people who rightfully or wrongfully work against others who threaten their ego, even when doing so is counter productive to the company. What is worse is that as a manager you know these egocentric people are there but sometimes you really can't do a whole lot about that.
However, when you find someone who can get stuff done without rustling the feathers of the prima-donnas, that person should be pretty valuable. A good manager can really appreciate that skill, a poor manager cannot. Allow me to illustrate.
Lets use Russ' example because its out there and we won't get into trouble. Jump up to the corner office and look at what is seen:
1) Product is slow
2) Repeated meetings and updates where the slowness has been raised have been deflected with various plans, arguments about direction, finger pointing, and general lack of progress.
3) Junior programmer rewrites a chunk of the system and shows off an order of magnitude improvement.
4) Meetings where senior people are exploiting that demo to make others look foolish, advance agendas, and generally do damage to others.
Now consider a different scenario
1) Product is slow
2) Repeated meetings and updates where the slowness has been raised have been deflected with various plans, arguments about direction, finger pointing, and general lack of progress.
3) Engineer figures out the problems and, knowing the solution, starts talking to various other engineers about how they decide to build what they build. Asks questions that talk to the bottleneck (Like they might ask, "I'm thinking about using that kind of socket in my code, but I'm not sure about it, how much performance could I expect?" and "I wrote this bit of test code, it just copies stuff around, and it seems to be waiting on the socket a lot, could you take a look and tell me if I'm doing it right?")
Now by planting the questions/seeds around these engineers start to do things a bit differently, the come up with some alternate strategies. The socket gets eliminated and this speeds up the product tremendously. Everyone is excited about how much progress they are making and generally morale improves.
4) Meetings now how have big performance gains, and the product is going to be much better. Congratulations all around.
Now in the latter case the environment gets better, the same result is achieved, but most of the company doesn't know they were the one who 'fixed' the problem. That employee's manager should know, and they should be ready to reward that effort. People who can effect the change you want in an organization without disturbing the politics are really good to have around. Things just 'magically' get better. When they leave it is really obvious that things don't work as well.
The problem is, I have worked several places where the problem wasn't that nobody understood the problem, but that nobody would solve it. Either because they were busy with other things or because egos were on the line or some other intraoffice drama. Which puts someone in the situation described here in a predicament. He can tell people, who already know what is wrong, how to fix it (in nice ways), and watch as nothing happens. Or he can just do it. I fall into the latter. Just Do It. If your managers are childish enough to use it to attack each other, that is there problem. But I'm at work to make a good product and that is what I will do. I won't gloat about it. I won't call people stupid for implementing it that way or not solving it earlier. It will simply be a ticket I work on that goes out in the next release.
Unfortunately, no one else will see it that way. The person responsible for the bad design will probably raise hell, the project manager might raise hell about changing the architecture without review, and the Management will do everything they can to push you out of the company.
It happened to me because of my Just Do It attitude, and now I need to go check the job listings again. Unemployment insurance is running out.
I'm not sure how (3) could go anything like you suggest in your revised scenario. If the young hacker in question had asked about pub-sub architectures being slow after the engineer responsible had already taken a political position on pub-sub then the answer is going to be "of course not!". At this point admitting that pub-sub can be bad would be a big embarrassment.
The way to fix this is to get people to think of stuff like that before they've taken public positions on the issue.
My experience has been that generally, even the most egotistical programmer, will listen to someone. Finding out who that is, and then working your way backward to someone who will listen can be a useful strategy.
The point I was trying to make is that you can make change happen in highly political environments if you're willing to not get all the glory (and sometimes any glory).
"The way to fix this is to get people to think of stuff like that before they've taken public positions on the issue."
Absolutely great advice. The challenge some times is know what they are thinking before changing position would cause them to lose face (respect). In Russ' post he had inherited a system that was broken, it read like those choices had been made long before he got there. I once proposed a RAID device at NetApp which had similar functionality to but a different implementation than the way it had been done. Watching the anti-body reaction on that was particularly enlightening. I wasn't so invested in the idea that I was going off and beat them about the head and shoulders with a fait accompli, and it wasn't something I could build in a couple of months worth of weekends. I decided to move on instead. Life is too short to spend it fighting the system for something which is right but ultimately not your passion.
I once was in a meeting where they had implemented a solution to a problem, but the solution was totally inadequate. I had an easy fix, but they didn't understand the problem correctly. I was treated pretty poorly in the meeting.
Unfortunately, I took it badly and got annoyed. I eventually managed to force in my solution, which saved quite a lot of contracts from falling through. Sadly, this caused me issues later down the line with the remarkably arrogant developers (one in particular!).
In the end, I would have been better not stressing about it and focus on other things. The company was later acquired by a large storage company who managed to throw away the secret sauce and keep the dysfunction, and eventually they sold it to a certain well known virtualisation company who has now dropped the product. So in the end, it probably wasn't worth it!
One way is to improve the code and run it privately yourself. When other people see your system flying just shrug until they are begging to know the answer.
Best political advice I ever got was "Never volunteer. Make them ask you to do it."
Every time I've ever fixed something or made something awesome, I've been punished.
The times I've played it detached and cool, grudgingly do some seemingly impossible task (which is actually easy), I get rewarded.
I've said this here before: If you ever do something awesome, tell no one. If it's awesome enough and the stars line up, convert it into your next startup and eat your former benefactor's lunch.
I've said this here before: If you ever do something awesome, tell no one. If it's awesome enough and the stars line up, convert it into your next startup and eat your former benefactor's lunch.
A little machiavellian, but not wrong.
Unless you're an owner or part-owner, the fruits of all your 'awesome' ideas are going to accrue to the owners. Is that what you want most? In many cases, genius coders, professors, and creative people are paid in prestige and exposure, while investors and founders are paid in $.
This is one of the best pieces of advice in the thread and should be much higher. Make the fix but never check in the code, and just run it like that on your own machine. Assuming it is a visibly big enough change someone is going to eventually notice.
An extra bonus potential is, who sees the change running first....if it is engineering personnel from the "wrong" camp, one could derive some delicious pleasure watching them squirm once they've seen what you've done and the implications dawn upon them, I can just imagine seeing the gears turning in their head, trying to figure out how to get themselves out of the predicament!
There is a lot to be said for the advice "Don't work where egos are more important than the mission." But what Russ didn't learn was "How to get the mission done in the presence of egos." The thing is that there are lots of people with big egos, people who rightfully or wrongfully work against others who threaten their ego, even when doing so is counter productive to the company. What is worse is that as a manager you know these egocentric people are there but sometimes you really can't do a whole lot about that.
However, when you find someone who can get stuff done without rustling the feathers of the prima-donnas, that person should be pretty valuable. A good manager can really appreciate that skill, a poor manager cannot. Allow me to illustrate.
Lets use Russ' example because its out there and we won't get into trouble. Jump up to the corner office and look at what is seen:
1) Product is slow
2) Repeated meetings and updates where the slowness has been raised have been deflected with various plans, arguments about direction, finger pointing, and general lack of progress.
3) Junior programmer rewrites a chunk of the system and shows off an order of magnitude improvement.
4) Meetings where senior people are exploiting that demo to make others look foolish, advance agendas, and generally do damage to others.
Now consider a different scenario
1) Product is slow
2) Repeated meetings and updates where the slowness has been raised have been deflected with various plans, arguments about direction, finger pointing, and general lack of progress.
3) Engineer figures out the problems and, knowing the solution, starts talking to various other engineers about how they decide to build what they build. Asks questions that talk to the bottleneck (Like they might ask, "I'm thinking about using that kind of socket in my code, but I'm not sure about it, how much performance could I expect?" and "I wrote this bit of test code, it just copies stuff around, and it seems to be waiting on the socket a lot, could you take a look and tell me if I'm doing it right?")
Now by planting the questions/seeds around these engineers start to do things a bit differently, the come up with some alternate strategies. The socket gets eliminated and this speeds up the product tremendously. Everyone is excited about how much progress they are making and generally morale improves.
4) Meetings now how have big performance gains, and the product is going to be much better. Congratulations all around.
Now in the latter case the environment gets better, the same result is achieved, but most of the company doesn't know they were the one who 'fixed' the problem. That employee's manager should know, and they should be ready to reward that effort. People who can effect the change you want in an organization without disturbing the politics are really good to have around. Things just 'magically' get better. When they leave it is really obvious that things don't work as well.