7 ms·
This is what happens when engineers subordinate themselves to non-technical management in a business-driven (as opposed to engineering-driven) organization. Th
by bkeroack 12y ago
This is what happens when engineers subordinate themselves to non-technical management in a business-driven (as opposed to engineering-driven) organization.
The ironic/tragic thing is that the consultants who are brought in at much expense (and who therefore have some credibility with "the business") are often no better than--usually worse than--the in-house engineers they are supposed to help. If you ever find yourself an engineer in a dynamic like this, you should interpret it as a sign of mistrust--even outright disrespect--of you and your peers by your bosses. Imagine if you were a physician and hospital management thought it necessary to bring in outside physicians to help you with your patients. Not many doctors I know would put up with that, but engineers are culturally so submissive that they go along with it and deal with the Dilbert scenario of the $500/hour consultant giving the same recommendations the in-house engineers have been saying all along (which the consultants get credit for, of course).
If you're ever in a position of authority and feel that it's necessary to bring in consultants to "fix" your codebase, it would be worthwhile to reflect for a few moments on how this situation came to be. Either you failed your organization on the hiring front and have terrible engineers (unlikely), or your otherwise talented engineers cannot do their jobs effectively due to the environment you've created. Perhaps you've forced them to incur so much technical debt by nonstop "sprints", unrealistic deadlines and multiple pivots that any forward progress is all but impossible. Consultants probably won't fix this.
- tieTYT 12y ago> Either you failed your organization on the hiring front and have terrible engineers (unlikely) What makes you say that is unlikely?
- bkeroack 12y agoIf you accept that engineering skill fits the normal distribution, it's less likely that they are "terrible" than merely average. Amazing 10X engineers could still pull off shipping a working product even with all the organizational handicaps I mentioned in my earlier post. This doesn't excuse the deficiencies of the organization, nor does it mean that "average" engineers are undesirable or can't do good work. I agree with the theme of the cited article--rather than scapegoat the engineers and pay external consultants to "fix their mistakes", fix the organization and enable the engineers to do quality work.
- s73v3r 12y ago"Amazing 10X engineers could still pull off shipping a working product even with all the organizational handicaps I mentioned in my earlier post." They could. They're also good enough that they could easily say, "Fuck that shit" and go work somewhere that doesn't have that toxicity. And unless you have a significant ownership stake in the company, I don't see why you wouldn't do just that. Life is too short to work shitty jobs if you have the option not to.
- mreiland 12y agoI get the idea in general, but you know sometimes you bring that outsider in for knowledge you don't have in-house. I'm a full stack developer, but I'll be the first to tell you I don't have a deep knowledge of any RDBMS. If that sort of knowledge is necessary, they're either going to pay me to figure it out, pay someone else to teach me, pay someone else to do it, or some variation of the above.