A friend and I were talking about her daughter, a brilliant, beautiful young woman who is inches away from earning her doctorate but who hasn’t been able to find a professional niche that makes her happy.
\nI theorized that this could be because in her three most recent jobs, as the last person hired, she’s been the end of the trough into which problems no one else wants to touch have been dumped.<\/p>
A friend and I were talking about her daughter, a brilliant, beautiful young woman who is inches away from earning her doctorate but who hasn’t been able to find a professional niche that makes her happy. I theorized that this … Continue reading
\nBeing the new guy is hard for so many reasons, and an excerpt from the book Domain Driven Design<\/a> by Eric Evans brings to mind one in particular: the fact that companies consistently underestimate how difficult it is to convey corporate knowledge\/context to new employees.
\nEvans talks about why the “waterfall”* method of software development hasn’t worked and why long-term conversations between development, marketing and other stake-holders does lead to a better product.
\nWhat was striking to me in reading this is that he talks about a process that goes on for days, weeks or even months at a time.
\nThe consequence of this, of course, is that an organization can’t grow unless it’s found a way to, first, distill those weeks, months or even years of corporate knowledge and second, to effectively teach it.
\nOne place I worked prides itself on its training methodologies. It is a fabulously successful company and their founders are self-made multi-multi-millionaires, so one might assume that their methods work extremely well.
\nI had occasion, though, to hear diatribes from one of their best customers about how the company’s inexperienced consultants were bolloxing up their projects – the dark side of an otherwise good news story.
\nAs far as I could tell, the company compensates for the “all thumbs” new folk by assigning lots of them to projects, making them work long hours, and not paying them market rates. In other words, they throw a lot of cheap resources at a project, and somehow or other, it all comes out in the wash and if you lose a sock or two in the process, no one who signs the checks really notices.
\nI never got close enough to that part of the business to understand it more than superficially, but it seemed like while the company’s training department was able to convey some small amount of corporate know-how, in the field, consultants were essentially re-inventing it.
\nThe system worked because the company charged exhorbitant amounts for its services and leveraged consultants’ pay in such a way that a huge percentage went back to the home office, thus burying the inefficiency of assigning people to work they weren’t adequately trained to do.
\nThere is nothing especially clever or new about this way of doing business. It certainly explains the company’s seeming bias for hiring young workers: they believed that their operating methods were unique so experience didn’t matter, and their “methods” required stamina and a minimum of social baggage, like being the parent of young children, to complicate a consultant’s ability to deploy anywhere and work outrageously long hours.
\nI’ve drifted from my original point, which is that for companies that have a unique product, culture or way of doing things, there seems to be little recognition that assimilating new people poses an enormous training and orientation challenge.
\nThe under-valuation of training frustrated me when I was in HR, and it has frustrated me even more as a software developer. Maybe we still don’t know enough about how the human mind works to have really created good teaching methods for the workplace, or maybe there are aspects of learning we haven’t correlated yet with other cultural phenomena, like language, for example.
\nThe one really stupid thing that businesses consistently do, though, is something that could change overnight if there were the will to do so: blaming the employee for limitations of the system.
\nOf course, that would require a humility and introspection that doesn’t exist among the hoard of Fuld-like CEO clones that have taken over the world of American senior management.
\n*In a waterfall process, an analyst stands between development and users. The analyst interviews users and “translates” their needs to technical staff. I always hated this as an end-user and got my face blown off in a meeting once when I said so. I feel no small satisfaction that some 20 years later, the industry has vindicated my low opinion of this awful practice.<\/p>\n","protected":false},"excerpt":{"rendered":"