It's a difficult situation to try and stand up to an employer who is telling you to do one thing when you know it's the worst possible decision they can make.
The thing I've realized as I've gotten older and more experienced is this: The worst technical decision is not always the worst business decision. Let's over-simplify a bit and go with the notion that "the point of a business is to make money, and a highly optimized business is one that generates the maximum return on invested capital". Given that, the optimization that leads to the best ROIC might not be the most elegant technical solution or the cleanest, most maintainable, well-engineered bit of code.
Of course there is some correlation, and I'd definitely argue that many companies do make short-sighted technical decisions that are also bad business decisions. But we have to understand that the business does not (usually) exist for the primary purpose of creating beautiful, elegant, marvellous technical artifacts that will be revered for centuries.
They hear the people who pay them money over the people they pay money to all day.
Well, yeah... if the customers aren't paying them money, there won't be any money to pay us.
It's a great idea to think we should stand up for our knowledge better, but chances are the arrogance and determination of the employer is going to stomp you right back into place, or even worse, out of a job.
My experience has been that leaders at most organizations are quite willing to listen to your concerns, and aren't going to "stomp you out of a job" for stating a concern and giving your opinion. But when we (techies) start our "holier than thou, we are the techno wizards and you are all brainless sheep" routine, then yeah, what do you expect?
This "respect" thing has to be a two way street. And we (techies) as long as we desire to have paying jobs with for-profit companies as our outlet for our desire to build technology, must, must start doing a better job of understanding business, and the concerns of the "business side of the house". Of course a manager is going to get frustrated when one of us comes to him carrying on about the need to switch to functional programming in Erlang, but without any ability to articulate what the business case is.
That doesn't mean the rest of the company does, but to have one layer between me and the real decision makers that will listen to what I have to say and protect my job in the process is a blessing.
Here's a thought: learn to speak the language of the "real decision makers" and learn more about their problems, concerns, issues, etc. to the point that you can talk with them directly and have meaningful, productive conversations that span the lines between "the business" and "the technology". Ideally they would meet you halfway, but if they don't... well, what can ya do?
Your negative stereotypes about developers ('revered for centuries', 'holier than thou', 'two way street', 'functional programming in Erlang,' etc.) are making it hard for you to address parent's core points. In short, you seem to be all about developers being wrong and managers being right here and it comes across as condescending.
If you hire a pollution expert, that person's job is to provide knowledge about pollution. It is counterproductive to completely silence and fire that expert for doing their job.
If it happens that you take money from people who like pollution, that doesn't mean those people become authorities on pollution.
Unfortunately this stuff DOES happen, and there IS an asymmetry of respect - whether you recognize it or not - and you don't propose any real solution. You just throw it all back on the developer. It's all the fault of stupid, bad developers who do not respect business enough. No, sorry, that is simply not true.
The pollution expert's job isn't to pretend to be a business analyst, or flatter you. If you propose to do something which will hurt the workers or cost more in cleanup than production, it isn't the pollution specialist's job to shut up when it might make money. It is definitely their job to tell you when pollution is likely to affect the real outcomes of your enterprises. And it's definitely your job to listen when it matters. Ignore the experts at the peril of yourself and your clients.
If they are sounding off about things with no relevance like whether we are using Erlang just for the sake of it, they are not functioning as experts. But that isn't an excuse for silencing experts or characterizing people who complain about expert-silencing as holier-than-thou techno wizards who think everyone else is brainless sheep.
There is a division of labor. Maybe you are a brainless sheep about pollution. Maybe not. But the point of informing you is not to hurt your ego and it is not justified to suppress and fire experts in order to protect your ego or advance your personal career.
If you hire a pollution expert, they do their job, and you suppress their opinion - you are doing it wrong.
Your negative stereotypes about developers ('revered for centuries', 'holier than thou', 'two way street', 'functional programming in Erlang,' etc.) are making it hard for you to address parent's core points.
The point is that there are plenty of developers who are SO concerned with technical matters to the exclusion of all else that they make it difficult for business leaders to interact with them, especially when they are the ones perpetuating negative stereotypes about business leaders. Now obviously I'm not referring to all developers, but if you can't acknowledge the existence, even prevalence, of the mindset I am referring to, I would argue that you are very naive or have led a very sheltered life.
Unfortunately this stuff DOES happen, and there IS an asymmetry of respect - whether you recognize it or not - and you don't propose any real solution. You just throw it all back on the developer. It's all the fault of stupid, bad developers who do not respect business enough. No, sorry, that is simply not true.
Your hypothetical "pollution expert" is more likely to be a consultant hired to solve a short-term problem, from what I've seen, so that's not exactly an apples to apples comparison. Nonetheless, the lack of willingness of (some) developers to be proactive and make an effort to understand more about the businesses they work in, and their lack of desire to learn to communicate with the business leaders in their language, IS damaging. And I'm not saying anything like "It's all the fault of stupid, bad developers..." That's either hyperbole on your part, of you totally misunderstood what I said. FFS, I am a developer, and I hate that so many business people are as clueless as they are about technology. Nonetheless, I stand by what I said before:
If WE want business to be out outlet for creative expression (as opposed to working as pure artisans funded by patrons or some other alternative) then there are compromises we have to be willing to make.
But that isn't an excuse for silencing experts or characterizing people who complain about expert-silencing as holier-than-thou techno wizards who think everyone else is brainless sheep.
I'm not sure where you got the idea that I'm in favor of silencing experts, but that's totally wrong. I would never advocate that. But, again, the very best decision from one specific point of view might not be the best possible decision from the point of view of the businesses as a whole.
'two way street'
How is insisting that communications and respect requires a "two way street" anything negative??
In short, you seem to be all about developers being wrong and managers being right here and it comes across as condescending.
I never said that managers are always right, or that developers are always wrong. And if I am being condescending, it's towards one certain class of developers (of which I used to be one) - the ones who are "holier than thou" and who don't understand that the technical artifacts they are building are not an end unto themselves and who walk around insulting the executives for being "brainless suits" and who don't want to hear anything about how a business actually works. To those people, I offer no apology whatsoever, and would add "grow the fuck up".
And when speaking to the decision-makers, discuss the trade-offs and/or offer options. "If we try to deliver pkg DEF on the date you promised, we will have the quality problems that we had with ABC. . .and here the reasons why. . .and the customer will be just as pissed. But we can deliver the most critical, highly-valued 30% of DEF on the date that you promised. . .and the rest 6 weeks later. From a business perspective, the customer only needs that 30% at first, and this phased approach guarantees that both deliverables will be of high quality."
And when speaking to the decision-makers, discuss the trade-offs and/or offer options.
Yes, exactly. I should have said something about that in my little mini-rant above, but I ran out of time or lost my train of thought. That's it in a nutshell though... be able to talk about the relative advantages and disadvantages of various options, and - more specifically - do so in the context of what serves the long-term interests of the business.
The thing I've realized as I've gotten older and more experienced is this: The worst technical decision is not always the worst business decision. Let's over-simplify a bit and go with the notion that "the point of a business is to make money, and a highly optimized business is one that generates the maximum return on invested capital". Given that, the optimization that leads to the best ROIC might not be the most elegant technical solution or the cleanest, most maintainable, well-engineered bit of code.
Of course there is some correlation, and I'd definitely argue that many companies do make short-sighted technical decisions that are also bad business decisions. But we have to understand that the business does not (usually) exist for the primary purpose of creating beautiful, elegant, marvellous technical artifacts that will be revered for centuries.
They hear the people who pay them money over the people they pay money to all day.
Well, yeah... if the customers aren't paying them money, there won't be any money to pay us.
It's a great idea to think we should stand up for our knowledge better, but chances are the arrogance and determination of the employer is going to stomp you right back into place, or even worse, out of a job.
My experience has been that leaders at most organizations are quite willing to listen to your concerns, and aren't going to "stomp you out of a job" for stating a concern and giving your opinion. But when we (techies) start our "holier than thou, we are the techno wizards and you are all brainless sheep" routine, then yeah, what do you expect?
This "respect" thing has to be a two way street. And we (techies) as long as we desire to have paying jobs with for-profit companies as our outlet for our desire to build technology, must, must start doing a better job of understanding business, and the concerns of the "business side of the house". Of course a manager is going to get frustrated when one of us comes to him carrying on about the need to switch to functional programming in Erlang, but without any ability to articulate what the business case is.
That doesn't mean the rest of the company does, but to have one layer between me and the real decision makers that will listen to what I have to say and protect my job in the process is a blessing.
Here's a thought: learn to speak the language of the "real decision makers" and learn more about their problems, concerns, issues, etc. to the point that you can talk with them directly and have meaningful, productive conversations that span the lines between "the business" and "the technology". Ideally they would meet you halfway, but if they don't... well, what can ya do?