Customer satisfaction in Outsourcing

Two articles came across my inbox this morning that caught my eye, because we've been thinking a lot lately at Macadamian about how to bring customer service to the next level.

The first was an article about how recent polls show that customer satisfaction in outsourcing has decreased (ouch).

The second was a white paper from Tholons titled "Relationships at the Core of Successful Outsourcing Contracts".

Both cite that roughly 70% of organizations are dissatisfied with their outsourcers. The Tholons white paper highlights something interesting though - around 80% of respondents in their study beleived their outsourcing provider were meeting their contractual committments. Huh? How can you be meeting your obligations yet still have an unsatisfied customer?

Therein lies the kicker - the big secret that's sure to raise the hackles of anyone in legal - in a successful outsourcing deal, the contract doesn't mean squat. It's all about the relationship. Case in point: last year I put a panel together of VPs of R&D in Boston to discuss outsourcing best practices, and the panel agreed - if you get to a point in the project where both parties are pulling out the contract and arguing about what's written and what the obligations are, you my friend are in deep doo doo.

Contracts focus on meeting service levels and specific deliverables - or as the Tholons paper puts it "a fixed unit of utility at a fixed unit price for a fixed time period". If this were taken literally, quality takes a back seat. In reality, the customer expects flexibility when priorities shift mid-project, expects the outsourced team to treat the product as if it were their own, and expects continuous improvement. Often, especially in a fixed-price project, the contract is at odds with these goals.

The survey from the Outsourcing Center, cited in the Tholons paper, sums it up well - in the reasons for outsourcing relationships to fail, the majority is attributed to unclear expectations, poor communication, poor governance, and misaligned interests. Poor performance accounts for a small fraction.

In my own experience, the best projects I've worked had a clear and open line of communication between the outsourcer and the customer. Both show give and take and both feel comfortable picking up the phone at any time to tackle an issue head-on. Conversely, projects that didn't go well boil down to a misunderstanding or a gap in expectations. Sometimes, in a new relationship, people are reluctant to ask the tough questions up front. Either you don't want to ruffle feathers so soon or you're in a rush to get started. Often a frank conversation up front about what everyone expects of one another, how we will judge the project a success, and what makes it a win-win for both parties will save a lot of headache down the road... especially near release-time, when anyone who's worked in product devleopment knows, this is not the time you want to be having a conversation about misunderstandings and mismatched expectations.

On the subtle differences

My second blog post and I'm already off-topic.

Since moving to California from Ottawa, I'm slowly adapting to the subtle differences in the culture in which I'm now immersed - back bacon is Canadian bacon (or sometimes just "ham" - I haven't figured out if there's a difference but it all tastes good with pineapple on a pizza), a bathroom is a washroom (or is it the other way around?), and I now conduct my financial affairs in plain view in the bank (quite the opposite of Canada, where your bank manager leads you down a hushed narrow hallway to her office and locks the door behind you).

But the part I'm enjoying the most, and having to adjust to at the same time, is... it's OK to be frank. Especially in business.

This morning I was in LA at the Growth Capital Conference. Question period rolled around, and naturally, the moderator asked people to be brief.

In Ottawa, this means the audience member who gains control of the microphone has full licence to monopolize the next 10 minutes of the 300 other people in the audience by a) blathering on about their business - "Hi, my name is so-and-so and we're a leading provider of blah-blah to to Fortune 10000 companies" b) compliment the panel and c) pontificate at length about their views of the subject, before d) making a veiled attempt at a question that is really another comment.

And everyone listens politely and doesn't interrupt because that's what good Canadians do. We're so darn nice.

This morning however, you were strictly prohibited from touching the microphone, so that it could be yanked away should your lips start flipping off-topic. A few people were brave enough to start their question with "My name is X from company Y" before the moderator blurted "Could you get to the question PLEASE?"

If you're from Canada you're probably thinking "How rude!". Maybe... but it was certainly more respectful of my time. In the end, the Q&A was one of the most informative, insightful, and productive I've ever attended. And we got out on time.

Ramping up product development for Startups

A couple of days ago I participated in a panel moderated by Sean Murphy at the Startup Epicenter in Mountain View on Scaling up Product Development. Also on the panel was a VC and two serial entrepreneurs, and we talked about how to scale up from the original founders and gurus to a full-fledged engineering team.

Key concerns from the audience were how do I maintain my culture, and how do I compete for the best talent against guys like Google and Yahoo? The answer from the panel was pretty unanimous - before you start hiring, draft up a one-pager that captures your goal, your values, and your vision, and hire people that fit that mold. Sounds simple, but it's hard to do when things heat up. If you've taken a bit of time to write down your values and culture, you'll be able to verbalize that to prospective hires and to your network. You will start to attract people who want to work in that environment. From personal experience, when we figured this out at Macadamian, we were able to scale up faster. Word got around to the development community around Ottawa that when we say we want to build software the right way, we actually meant it. We're using the same approach in Cluj, Romania, to attract talent in a competitive market.

Some of other takeaways:

• Someone has to be wearing the product management hat from day one, whether that's one of the founders who has a talent for talking with customers and understanding their needs, or someone you bring in early on.
• Once you get beyond 5 developers, what should be your next hire? The panel agreed, QA. Get someone on staff who lives and breathes software testing.
• If you don't need the domain knowledge long-term, outsource it.
• Resist the temptation to hire a specialist in some particular technology because that's what you need today. You'll be turning on a dime, so hire people that are flexible, and are great engineers. Hire for raw mental horsepower.

Special thanks to Peter O'Blenis at TrialStat and Terry Cass at Thirdbrigade, who have both successfully scaled up world-class product teams and lived to tell about it, for spending a few minutes with me before the panel so I could learn from their experiences.