Wednesday, February 20, 2008

Offshoring for Rank and File

I've been doing offshore work as long as the next guy, if the next guy has been doing it for almost a decade. There are successes and failures and lots of learning along the way. It's hardly the only thing I've done, but it's a good share of the pot.

Recently, I was asked to speak with some gents about how their offshore effort was going. Which is usually code for "We don't think it's going well". And by all accounts from the team, it wasn't going all that well. It helps when everyone at least starts from the level of dissatisfaction.

Whenever we start to talk about the concept of managing work efforts in more than one location, everyone spits out the same mantras. Communicate, be sensitive to cultural differences, etc. The thing is there aren't all that many that have moved past the theory into practical application. I should say demonstrably successful application. A big part of this shortcoming, from my perspective, has been that while we can have concepts in our heads like cultural differences, and detailed communication plans, we miss what can be the subtle point of these guidelines.

Let's borrow from a recent experience at Big Redmond Software Company. Companies (like Microsoft or Google) don't really run tight ships. Not in the way the unfamiliar would think. At the foundation, they expect individuals to be very self-sufficient and to work with minimal communication. Contributors are expected to bridge gaps in their own style. These companies are impactful because they have leveraged the ability to walk down the hall and say "Build this" while pointing to the contents of a Visio diagram or the corner of a whiteboard. The resources are expected to be accountable for the applicability and context of their solutions, not just the code or outputs they produce. The business value driving the work should naturally be taken into account by the self-reliant resources who are tasked with unlocking that capability.

When you start moving that work to different geographies and timezones, suddenly that level of communication isn't enough. The expectation on all parties is to minimize communication since that is a cost both parties share. But how they each tend to approach that goal is often different. Remember that the sender is expecting to point and grunt and have accountability and context magically shift. They'll be available for questions, they expect to review the progress and deliverables and throw stones along the way. But if it takes more than [insert arbitrary threshold here] energy and time commitment, then it just isn't working out. It would have been easier to do it myself in house.

Meanwhile, the receiver of the work has an expectation that the work will be fully-formed, coherent, and that they will not have significant decision-making requirements. Give me enough information up-front to be self-sufficient and yardstick with which to measure success. I'll come back when the output meets the success criteria. My accountability only extends to the output according to the specifications and acceptance criteria. If those have been ill-defined, that is the senders responsibility.

Obviously, I over simplify a little and as always YMMV. But in practice, understanding the different accountability and communication expectations we place on resources on different sides of a pond (or client-facing fence) will help you be more successful at leveraging offshore resources.

Saturday, February 02, 2008

How "Open" Can It Be?

Something that has bothered me from the beginning of the Open Source movement (and I use the word very loosely) is the seeming hypocrisy of these commercial companies that have huge revenue streams based around the idea of Open Source software.

Not to go off on a rant here, but how open can they really be when they've got hundreds of people paying money for them to support their specific releases? To my mind the idea of Open Source was always that the source could and would be extended by the community at large. However if you are going to start asking people to pay for the specific versions of extensions that you are providing, you've essentially closed the system. At this point, it seems to me you aren't an Open Source contributor any more. You are someone who took an Open Source offering, tweaked it, and are now asking people to pay for your tweaks, thereby closing it. If you did this once, perhaps a point could be argued, but when you've been building on YOUR specific tweaks for release after release, and your support policies are version specific, then you are just like any other software company. Okay, perhaps there is a little more transparency into the code, but still.
” SANTA CLARA, CA January 16, 2008 Sun Microsystems, Inc. (NASDAQ: JAVA) today announced it has entered into a definitive agreement to acquire MySQL AB, an open source icon and developer of one of the world's fastest growing open source databases for approximately $1 billion in total consideration. The acquisition accelerates Sun's position in enterprise IT to now include the $15 billion database market. Today's announcement reaffirms Sun's position as the leading provider of platforms for the Web economy and its role as the largest commercial open source contributor.”

Exactly how open to the inputs of Joe developer are they really going to be when they have to sustain a $15 billion dollar Support industry around these products. Do they really expect us to believe they are going to leave the evolution of these products to the average engineer? The community at large? Hell no. They have product teams and planners and release strategists just like every one else. They just don't have the huge upfront investment in research and development, they essentially jumpstarted their code from the masses. And they won't have a huge testing effort, they'll just rest on the backs of the industry at large. Which makes for good stability.

I hate to see such blatant parasitical behavior cowering behind the beauty that could be Open Source. Greedy bastards.