It's easier to train developers than to change corporate culture Several years ago, I was hired as director of consulting services for a small software development firm. I had 40 workers under my charge — about 30 contractors in three cities and 10 local employees. But my real job involved “mentoring” developers who were underperforming on key projects. To make matters worse, while the problem developers were reporting to me, I was in charge of none of their projects. Think: the matrix from hell.It didn’t take long to discover the problem: Management showed no respect at all for the company’s employees. Nor did they display even the slightest sign of planning skill or development savvy. New developers received only minimal training, and their managers seldom allocated time for hands-on experience to augment training. For instance, after a one-week .Net programming course, a young developer would be expected to design objects on the fly for a system with no concrete design and an awful data model. (Specifications were either nonexistent, stupid, or ignored.) Favored workers were never criticized, while new hires caught the blame for their mistakes. One time, in a desperate attempt to get a project out the door on time, company executives actually sat with developers in their cubicles as the poor guys hacked code. The executives were there to “keep them focused.” Oh yeah.Project planning was totally top-down. Developer input was solicited, but nobody took it seriously unless it met with management’s expectations. And, unless a developer made a major scene about a task being underbudgeted, the suits took acquiescence as commitment. One huge problem was that none of the upper-level managers (my boss included; in fact, my boss in particular) had the slightest notion that their workers were afraid of them. I knew it was going to be tricky bringing this fact to my boss’s attention, but ultimately, I didn’t see any other way to move forward. When I told him, he promised to reconsider his communication techniques — but nothing changed at all except his attitude toward me. I realized that now he saw my concern as nothing less than willful interference.I had been hired to get specific “problem developers” up to speed, not to look for systemic solutions or propose fundamental changes to the corporate culture. Still, the solution seemed so simple to me that I couldn’t resist writing a short report for upper management. It discussed how to treat workers as collaborators in the business process, rather than objects to be bullied into submission. I suggested bringing developers into the bidding process to help and learn. And, I recommended that management take active responsibility for detecting and correcting problems, rather than simply assessing blame.I submitted the report and waited for my boss to let me know how impressed he was. Are you familiar with the term “lead balloon”? After 10 months on the job, I was divested of my supervisory role. Three months after that, I was on the street. I probably should have walked away long before that. If you’re surrounded by incompetent jerks whose standard technique for getting systems to work involves bullying and secrecy, my advice is: Run, don’t walk, to the nearest exit. Software DevelopmentTechnology Industry