Companies That Don't Understand Engineers Don't Respect Engineers
An anonymous reader writes Following up on a recent experiment into the status of software engineers versus managers, Jon Evans writes that the easiest way to find out which companies don't respect their engineers is to learn which companies simply don't understand them. "Engineers are treated as less-than-equal because we are often viewed as idiot savants. We may speak the magic language of machines, the thinking goes, but we aren't business people, so we aren't qualified to make the most important decisions. ... Whereas in fact any engineer worth her salt will tell you that she makes business decisions daily–albeit on the micro not macro level–because she has to in order to get the job done. Exactly how long should this database field be? And of what datatype? How and where should it be validated? How do we handle all of the edge cases? These are in fact business decisions, and we make them, because we're at the proverbial coal face, and it would take forever to run every single one of them by the product people and sometimes they wouldn't even understand the technical factors involved. ... It might have made some sense to treat them as separate-but-slightly-inferior when technology was not at the heart of almost every business, but not any more."
I think this has a lot more to do with the machismo of business people than anything else. The suits don't have a lick of understanding of what the engineers actually do--sure, they understand the iPhone once it rolls off the lines, but up to that point, what engineers do is basically a bunch of technovoodoo magic to them. Since lots of businessmen are macho, domineering types (especially in large, competitive companies), the concept of having subordinates who are doing things far beyond their understanding is not one they like. In turn, the business people feel the need to assert how hard whatever it is they do--"oh, you wouldn't understand because business is sooo much more complicated than rocket science"--and elevate the complexity and importance of their own job beyond that of the lowly engineers.
I don't think it's lack of "understanding the engineers." I think it's lack of understanding the engineering and feeling uncomfortable about it.
/. may be a software-centric site, but those of us in mechanical, electrical, optical, materials, and other branches of engineering are in the same basic position. But sadly, even in businesses which promote engineers into senior roles end up respecting people primarily on the basis of how many direct reports (that's the term for peons whose salaries they determine) they control. Until you're able to rate people by the quality/quantity of output regardless of altitude in the org chart, this problem will continue.
https://app.box.com/WitthoftResume Code: https://github.com/cellocgw
Should I halt work on the next version for a month to do custom work for this important customer?
Should I save time by making the system very inflexible in this regard to get it out the door for a narrow market at the expense of a wider market later?
Should I follow the spec that management and business analysts wrote even though it seems wrong, or go up the chain or to the customer and likely fix or rewrite the spec?
These are the kind of business decisions I used to find myself making. In most cases it turned out that I made the correct decision in hindsight, but I got a lot of fighting from management in the process about that not being my job, even though there was nobody else competent to do it.
The biggest problem I run into is that the management assumes that the engineers are completely unable to talk to customers and look at outside non-technical specifications. I have found that engineers tend to be better at it than managers and all but the best business analysts.
Go green: turn off your refrigerator.
But business managers don't respect anyone who isn't also a business manager.
The shepherds did so well protecting the flock that the sheep no longer believed that wolves existed.
Of course they do. Real Engineers design up front, before implementing. We understand the implications of our decisions. We optimize. We know that there are many orthogonal factors to consider in doing this. Shoud we optimize with an emphasis size or speed? If we optimize for size, how will that decision effect scalability and the ability to add functionality we may not have originally considered, or that the original design specification didn't call for?
... because they system won't work if we don't, and it would cost too much and be too risky too change it!.
Anybody who thinks that Engineers don't have a major impact on the entire business model have never worked in the real world, or have no idea the impact we have. "Why do we do thing X even though it no longer makes sense?
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
Complex engineers do everything real and imaginary engineers do.