I wasn't going to write about offshoring so soon. But two things happened.
During the Etech conference, I noted an announcement tacked onto the jobs bulletin board outside the sessions hall. Basically it announced cheerfully there were plenty of jobs to be found. You only needed to search on Google using a few simple search terms: [your_job] jobs India. There were many feelings wrapped up in that announcement and certainly one that came across was bitterness.
The second thing that finally got me to blog on this was that last night I noted this news story where Kerry pledges to stop the flow of jobs overseas. A leader shouldn't pander to our deepest insecurities and fears but instead draw out our innate potential and tap into our collective strengths. He was speaking to the "poor little me" voice within that buys into our own stories about being feeble and powerless.
Perhaps it's time to rise up to the challenge, to innovate and adapt instead wasting energy lobbying and railing against the system. Turbulence and chaos are a natural part of the process of any system that is reorganizing to a higher level of order.
In this month's Wired magazine, there is an article that outlines another industry that railed against the competition from foreigners and begged for protection:
"The 2,000-vessel fleet that ruled the seas after World War II had dwindled to fewer than 900. New technologies - containers, automated loading - were taking hold on foreign ships while America clung to old methods. As a result, other countries were transporting nearly 80 percent of worldwide traffic."So the government threw a lifeline: the Merchant Marine Act of 1970, which provided new protections and massive subsidies for the industry.
It didn't work. Today, US carriers handle barely 2 percent of international cargo.
The US fleet was a classic victim of the efforts to save it. Rather than adapt to new economics, the American industry suffocated under overregulation and protectionism."
In the same Wired issue - actually a cover story on India entitled "The New Face of the Silicon Age" there is an alternative stance offered -- seeing the silver lining:
"Less than 30 percent of R&D spending at mature software firms goes to true innovation, according to the consulting firm Tech Strategy Partners. Send the maintenance to India and, even after costs, 20 percent of the budget is freed up to come up with the next breakthrough app. The result: more workers focused on real innovation. What comes after services? Creativity."
Anyone that has spent any time on software development knows it is not exactly the most efficient or effective process. To many non-CS degreed managers it's a magical, intensively labor intensive process. Albeit highly skilled labor. So the solution appears to throw cheaper labor at it. But it's still a brute force approach -- what about a novel approach? What about having regular Joe (or Josie) use a lever to lift the big objects instead of corraling together several burly defensive linemen?
Would this result in even less I.T. jobs? I don't think so. There is a huge need for software development and information technology projects that are just not getting done today because of the costs and risks involved. Most software project ideas (and we're not limited by imagination here) get put on the backburner because they don't appear realistically achievable. That XYZ project just appears like wishful thinking to the manager so they kill the idea before it even has a chance to be a project at all.
Most project and product manager can quote statistics (and I've had my share of painful experiences to vouch for them) about the success rate of software projects. They're dismal -- anywhere from 50-90% of all software projects fail according to whose statistics you subscribe to. So, if you have that many failures, can you blaim companies for wanting to fail more cheaply? (Yeah, that's a Dilbertesque joke.)
If the software project success rate was consistently high and it really delivered the promised impact, you bet a lot more software engineers would have jobs everywhere, not just India.
During the boom years, I was a CTO at a start-up trying to hire senior enterprise Java engineers. It wasn't pretty. Even offering them twice my salary wasn't enough pay -- they almost always got more cash, a bigger signing bonus, or a cooler fozball table somewhere else. I started fantasying about Indian development companies to help with all the coding that needed to get done.
But a few things prevented me from outsourcing in the end. The management team felt that software development should be one of our core strengths. Without our own development, our strengths would instead be in product management or operations management or product marketing or somewhere else. All fine things, but we also wanted to be a software company. This is not true for every company, and if I.T. is a context function - I say seriously consider outsourcing it. (The core versus context distinction is clearly articulated in Geoffrey Moore's book, Living on the Faultline.)
I knew that communication among the product team was vital to a successful product and we would have to turn on a dime to respond to customer feedback. Although good communication is not solely a function of distance, I know in real life it is a factor. There's already so much room for error between your own internal marketing team and the internal engineering team within the same four walls. Having that engineering team moved to the opposite corners of the earth in another time zone typically doesn't help matters.
One company in Boston had an innovative answer to the inevitable outsourcing question that I'll let you read about at your leisure. The executive in the story is "convinced that having people working onsite gives him control over quality and timing that he wouldn't have enjoyed if he had subcontracted overseas." I agree.
Also, the amount of formal, rigid specification we needed to provide to the outsourced development partner to ensure there was no room for misinterpretation (their requirement) was in the final analysis cost prohibitive. If we could spec it with extensive UML diagrams that precisely describe each software component in minute detail (and that's by far the hardest part), the coding itself would be a cakewalk.
But just because I decided not to outsource doesn't mean that others won't. I encourage everyone in the industry to stop throwing labor - cheap or expensive - and really get to the root of the software development problem. It's time to be creative. Let's look at the whole thing in a new light. Pretend you don't know a thing about software development and ask: Why do you do it this way? Is there another way?
Look into the agile software development mindset (see book by Alistair Cockburn and agilealliance.com for starters). While we're at it, a revamp of traditional customer requirements gathering and interface design are needed too. That's just the start. Go brainstorm.
But you need a job, you say? What about the individual software engineer? It's time to innovate how you develop software and even your own career. Be creative. Proactively think about where you fit in the evolving software and I.T. value chain. How can you add real value to your customer (that just might be your employer)?
Easy for me to say? I've been there. I was in software engineering roles for over 10 years. I've gone through two layoffs and two company closures. I have only once voluntarily left a company of my own accord (and that time I was in a marketing role). In retrospect, being out of a job became huge turning points in my career and directly led to positive outcomes that I could never have planned myself. The edge of chaos is uncertain, but your perception labels it positive or negative. It's also that same edge where a new higher level pattern emerges. As a friend says, "Chaos is just a new kind of order you don't recognize yet."
Comments