Every once in a while I kick something over the Drezner's site. Especially when he writes on outsourcing which is one of my pet peeves. As a highly technical architecture level consultant that does hands-on work, I really don't blog about it as much as I probably ought to. I've thought that I could run multiple blogs and keep all those worlds from intermixing, but I think I may begin to blur that firewall too. So on the matter of the quality of engineering and technical talent from the emerging second world, I had this to say:
I think that this distinction between dynamic and transactional engineers is very useful and accurately describes what I see in the software industry as well.Even when chinese and indian programmers are on staff in American companies, there are notable differences. You never quite know what you're getting until you sit folks in a room and start talking about the systems to be built.
Enterprise systems that are to make a difference in the productivity of the target customers are notoriously difficult to assemble, even when using simpler standard technologies that procurement departments are demanding be offshored. That is why companies like Accenture continue to make money in the American and international markets. The skills of management consultants that can do a tight handover to technologists are in high demand, but even so these are applications that tend not to be robust. Anything that takes more than six months to build will suffer from changes in the business environment, turnover in personnel and integration with other systems that themselves are being changed.
Again, the allure of cheap labor in this area is that SQL is SQL. Not necessarily so. It's actually getting more complicated to do these applications properly, primarily because of an attitude the 'best practices' can be built into every application. This means that a lot of abstraction of problems is done, and a number of experts who don't do hands on work are employed. All this is done at the expense of homegrown (meaning inside the client company) experience which is the great hidden expense of outsourced systems.
It comes down, in my view, to a decades old clash between management philosophies. Deming vs Hammer. The Deming method says to evolve the way people are working with technology and business processes. That's highly integrative and evolutionary. It means you have to do a lot of listening and translating. The Hammer schools says, throw out the old and make everyone start from scratch. That's re-engineering. Companies that get re-engineered outsource and offshore better than companies that evolve. Companies that evolve are more productive because the culture of the company teaches everyone what the focus of the business is. They can be more nimble, but there's a steep learning curve.
I'm from the Deming School (an old Xeroid from the McKinsey makeover under David Kearns) and have been in the enterprise sofware business for two decades. The Deming way is harder, and it's often against the best interests of management and technology consulting companies, not to mention software vendors, to evolve a good company to great, but the real loss is that so many American corporations are literally outsourcing their own quality improvement. They don't want to grow their own MBAs, they want somebody else's. This dependency is what both depletes American talent, and keeps consultants like me in new BMWs.
Meanwhile over here at Nissan, things are beginning to get very interesting as deadlines start to loom. While Toyota is poised this year to make 100k more cars than General Motors, I'm finding that the systems that are being built in the wake of Sarb-Ox may have a long-term payoff for American businesses. Because over here in this Japanese company, typical of a large number of companies I've seen, the spaghetti and spontanaity of financial planning and accounting boggles the professional mind. In my close circle, we have a term called 'The Official Ass'. That's where a lot of numbers are pulled from. The number of companies that do real demand planning are few and far between. Demand planning is very difficult to do with most kinds of accounting systems that companies have, and so companies pull numbers out of a collective hole in the ground. That is particularly typical of non-financial companies - that is companies whose business is not primarily the management of money. When your financial staff is considered overhead... well.
It's one thing to understand how to build this database and that database. Sure that stuff can be outsourced. Should it be? It really depends on whether you're building system to be building systems or building them to improve the way a company is run. The latter can only be done by dynamic engineers. I like to think of myself as one of those types, but its not very often that we are called to do all that.
Recent Comments