In Outliers, Malcolm Gladwell argues that talent and ambition are much less important than practice.  De acuerdo.

I grew up without an apparent talent for anything:   I was too skinny for sports, too tone deaf for music, had too much ADD for serious study, and was way too awkward for social/political pursuits.

So, I was delighted to see a cohesive argument for the efficacy of practice & dedication.  It’s the only way I’ve become decent at anything in my life – by working my ass off, despite the fact that (in almost every case), I lacked any discernible talent or proficiency for the stuff I loved.  Now, at 32 years old, there are even a few things that I might be ready to call myself an expert at…after a few more years and several hundred hours of practice!

In a simplified version of Gladwell’s model, you are an expert after you put 10,000 hours into something. Then, if your culture and general situation is fortuitous, you have a shot at being one of the best in the world at your pursuit. 

After enjoying the way his arguments applied to my life, I began thinking of how this applies to teams – specifically to global teams.  At Monsoon Company, many of us have been working together for close to a decade, just around the number of hours (and years) that Gladwell believes create true expertise.

In one of his examples, Gladwell takes a look at classical musicians.  Early in their careers, there are clear standouts – people with the immediate & obvious talent I have always lacked.  However, when you track their careers, the successful musicians were almost always the ones who simply practiced more.  Period.  Talented or not, if these musicians  spent 10,000 hours or more dedicated to their craft, they were most likely successful concert musicians, while their counterparts became teachers and went on to other fields.

There are programmers and designers who dedicate themselves to both their craft and their team’s system.  A significant portion of their 10,000 hours are spent this way: meeting, arguing, collaborating, iterating, etc. As a unit.

Those that dedicate to practicing and internalizing team processes routinely leapfrog team members who were far more talented.

Over time, these hours of dedication turn a bunch of solid individuals into an expert team.  Things simply begin to flow.

All too often, business literature puts far more emphasis on ‘fresh perspectives’ and ‘thinking outside of the box’.  And when your team is creatively stagnant or bogged down in process, there is a definite need to prioritize these thing things. 

(more…)

I recently wrote a piece for Forbes, a perspective on why the world is still round. Hopefully, the first paragraph convinces you it’s a worthy read (that’s all I’m allowed to post to my blog):

My apologies to Thomas Friedman. I was cursing out the window of a rental car in New Jersey when I realized that the world is still round.

Read article >>

Why did we change our name? 

On January 1st, we officially became Monsoon Company (after 7 years as BCM Digital). 

There was no obvious business reason for the name change.  We didn’t get acquired, change strategy, or get sued.   Instead, we changed our name for a much simpler (and perhaps more important) reason.

For too long, ‘outsourcing’ has being stigmatized as new and disruptive.  Due to political rhetoric and cultural biases, many of our competitors mask their Indian roots under an ambiguous identity (what’s an infosys?). But, the rhetoric doesn’t make sense.  

Global trade is as old as the monsoon winds that used to carry spice traders to India.   With our new name, we choose to celebrate our Indian team. 

And why not?  Their work has lead to long term relationships with Fortune 100 clients, dozens of innovative software products, and industry-leading expertise in development platforms like Vista, Ruby on Rails, and Facebook. 

In an article published in the San Francisco Chronicle, Jim Breyer, managing general partner of the Palo Alto venture firm Accel Partners puts it bluntly:

“There isn’t a board meeting that goes by that we don’t ask, ‘Why aren’t you being more aggressive (with software development) in India and China?’ ”

It’s been a few years since the article was first published, but, given today’s economic climate, a team in India may just be what you need to impress the investors.

With the LA Times article running today, we’re getting a lot of new visitors.  If it’s your first time here, don’t waste your time reading everything.  Here are a few of the best posts:

• Outsourcing is Dead
• Look for no
• The world is not flat
• Save now, pay later. 

Our comic, Doubtsourcing, was recently featured in TechCrunch:

Something that you don’t often see a lot written about in new media is the strong trend by startups to outsource a lot of their work. Digg for example was originally designed by Kevin Rose outsourcing the job on elance, and sites such as Slideshare, illumobile.com have gone down a similar path.    

 This post lead to a 100+ comment debate about Indian IT.  Overall, the TechCrunch community had a lot of interesting things to say.   It’s clear that a significant percentage of Web 2.0 entrepreneurs have tried working with an Indian team.   While the results are mixed, most of the community agrees that, when managed well, the cost efficiencies and scale that a global team can bring are worth it. A few of my favorite comments from the post are below. 

Mr. Recycle tells people to get over the fear of getting their idea stolen: 

I’d say outsourcing (or offshoring) is more of a fortunate reality than an unfortunate one. And should you really care about the protection you get in third world countries? Do you think your idea is that original anyway? Guess what, it isn’t. It is your execution and vision as a business that matters, not your code base. You could hand Facebook’s codebase to 100 entrepreneurs today and you would probably get 100 failed start-ups.   

Fabio Rosati (CEO of eLance) talks about low bidders:

 A more appropriate generalization supported by our data, is that buyers who consistently hire the lowest bidders for a particular class of jobs tend to have lower success rates.   

Raza Imam stresses Fabio’s point about highvalue vs. low cost. 

Outsourcing is tricky, but it’s like anything else in life. It takes practice to get it right. Outsourcing is about high-value, not low cost. If you pay someone ten bucks an hour and expect great code, you’re kidding yourself.    

Newsflash: outsourced labor is cheap.

It’s so cheap that your CFO (generally a serious guy) has been seen around the office giggling randomly and uncontrollably (this is especially embarrassing at board meetings).

It’s so cheap that you are saving thousands, tens of thousands, or hundreds of thousands a month. And your team is now twice as big as it was before. Which means that you, the CIO, can finally do all that stuff on your list.

You can integrate that cool (and unnecessary) Google Maps interface with the employee directory. You can get three teams to work on the exact same project and vote the losers off Survivor-style. You can implement a full-fledged CMS to support your 23 page corporate website. You can get a team of six to research the FaceBook API (despite the fact that you make ERP software).

You can. But you shouldn’t.

Yes, the additional labor required to create that new stock-ticker Vista Gadget is inexpensive. But don’t ignore the true costs of side projects. I’m not just talking about the managers, infrastructure, and preparation time you will need locally to manage all of the additional work. You can probably handle that, given all the money you’re saving. I’m talking about trust.

Every new team situation begins with a period of mutual evaluation. You watch carefully, because you want to know if your new employees (or partners) are qualified. And, of course, your new team members want to find out how they are going to be managed.

Unfocused, open-ended side projects dilute trust. If the new mobile version of your website is not a business priority, your team is going to notice, no matter how many miles away their office is from corporate HQ. If you scrap that cool new Silverlight version of your UI after a team stayed up all week to get it done in time for a fake deadline, they will notice.

And, the next time you push them, they won’t work as hard. Which is too bad, because eventually, you are going to want to get something important done.

When communicating project scope, it is always better to draw a picture.

Think your scope document was clear? Ready to rely on section 19.2a on page 38 and head to bed?

Assuming your whole team stayed awake to even read that far, confusion is common and inevitable.

The use of language varies across cultures and job descriptions. More importantly, just because someone speaks English doesn’t mean they understand it.

So start drawing. Can’t use photoshop? Start with a pencil and a scanner. Get the boxes, circles, and lines out of your head and onto a piece of paper. Begin simply and improve from there. (nod)

In a culture of yes, look for no.

In an honest effort to please (and get business), an offshore team may commit with enthusiasm to what they simply cannot deliver.

So, look for no. Find a company who tells you what they do, not what they can potentially do. If you need a hammer, find a hammer. Not a screwdriver that is willing to grow a hammer out of its side. Trust me, someone is working on the hammer you need. And, when you’ve found the right team, first make them prove they can do what you need. If they really want the job, they will.

Nari Kanan from SourcingMag talks about the lack of iteration in offshore IT work:

However, (offshore) software development has institutionalized non-iterative ways of doing things. You CAN come up with a definitive requirements document that CAN be turned into a definitive design document that CAN be turned into perfect code, which in turn makes users ecstatic! Couldn’t be further from the truth.

Definitely. But how do you organize a successful, iterative process with an offshore team? Time & geography are the obvious challenges. But, the problem goes much deeper than that. It is about mindset. And, although your business development guy won’t admit it, his offshore team doesn’t have it.

Most offshore developers have never really been included in a brainstorming session or a scoping process – their job is about one thing: take requirements and churn out code. Now, we need them to learn to iterate. They haven’t even spent time scoping!

Successful iteration isn’t about reworking your code 14 times a month. When most offshore firms talk about iteration, what they really mean is that their project managers are going to rewrite requirements over and over again, guiding their developers through a series of protracted, stressful waterfall processes until everyone loses their mind.

14 waterfalls don’t make a river. They just make a lot of noise.

When we first started embracing iterative development 4 years ago, it just meant that we didn’t sleep. We would work with the client during the day, stay up with our team to communicate scope at night, and then get up early to synch everyone up and ‘iterate’ in the morning. Think that’s scalable? Ask my wife.

No, true iteration requires a reworking of the entire offshoring process. More on this soon.