How to Offshore

Today we fired one of our offshore teams.  This post isn’t to criticize that initiative or the manager, they definitely weren’t working out, but it does bring to mind several lessons learned, at least from my perspective.  This wasn’t my offshore team, but I do have an offshoring effort that’s been very effective thus far.  Some advice for when you may be considering your next offshoring initiative:

Preparation

When we created the offshore IT Operations Center, I spent a very significant amount of money with the offshoring company’s consultants to document every application, database, and server they would be supporting.  I had them develop all of our procedures for how to escalate problems, and they put together all of our SLA documentation.  In short, they wrote the manual on how to do business for our IT Operations Center.  Then, and only then, did we consider hiring them to do actual operations work.

Augment, Not Replace

When we brought on the offshore team for the ITOC, it was an augment of existing personnel, which gave us two advantages.  One, we didn’t have a fixed limit on transition period which occurs in a lot of offshoring initiatives.  Second, we were not letting the onshore team go, so we did not end up with personnel training their replacements or the onshore teams attempting to poison the project.  In fact, the offshore team has been a huge success with the onshore team they were augmenting because rather than having a 5 person team covering 24 hours a day, 7 days a week via pagers, cell phones, and a brutal on call schedule, the onshore team now has the ability to leave their house over the weekend rather than be tied to a laptop and Internet connection with confidence we have coverage for the business.

Process, Process, and did I mention Process?

If you cannot onboard a new resource in 30 days, no matter how complicated the position, you’re not ready to offshore.  You cannot take a position that requires intense collaboration with onshore resources, high-end skill set, and a strong requirement on independent thinking and problem solving skills and send it offshore without also outsourcing the entire function.  Creating a new team in a far-flung location requires them to be able to execute their job without ambiguity, without constant reliance on onshore resources, and with a clear direction as to their responsibilities and deliverables.  This means that the processes they are facilitating need to be documented, defined, and well understood.

Offshoring is not Outsourcing

These two terms are used interchangeably, but they are anything but interchangeable.  Offshoring means augmenting your resources with lower cost alternatives in another location (usually another country but I hear people are doing the same thing with lower cost US locations).  Outsourcing means you are moving a function or a department to be handled by another company.  Offshoring is often outsourcing but not always.  If you are expecting a high-end skill set, you will only be successful with outsourcing the entire function.  The team will need the flexibility to define the process, determine service levels, and generally be in control of the deliverables if you want them to do something other than providing a very specific well defined function.

Summary

Offshoring can be awesome for everyone involved, or it can end up in failure.  How it’s approached has everything to do with how it’s received by the co-workers on-shore.  Deciding whether to augment or outsource is critical, and if it’s an augment ensuring there are well defined processes that govern the output of the augmented resources is critical.  Unclear expectations, lack of preparation, and malicious compliance by existing personnel will doom any offshoring effort to failure.


Customer Centricity is Evil, in IT

I was listening to a video from Startup Lessons Learned, where a brief comment was made regarding customer centricity at IMVU, which reminded me of a nagging thought in my head in recent months.  Customer Centricity is evil, in IT.  That’s a bold statement, so let me explain.  There are a lot of mechanisms of providing the customer what they need, and perhaps even want, without placing them at the center of your activities.

Being customer centric, as implemented most places I’ve seen, means an unwavering attitude internal to the organization that it will bend over backwards to provide the customer what they want.  This leads to some unintended consequences, such as a continual focus on the functional, rather than the non-functional.  For those who spend little time doing software project, program or requirements management, functional requirements are things like “I want the software to be able to calculate taxes and print it on a receipt” and non-functional requirements are things like “I want the software to always work.”  Bending towards customer centricity and an attitude that the customer is always right, especially in the world of custom software, means the resources of the organization are constantly allocated to the functional while often largely ignoring the non-functional until it’s too late.

This attitude can and will, at a point in the future, leave you in a situation where the scale and complexity of the software the IT organization is producing will begin to collapse under it’s own weight.  The nimbleness once felt, perhaps as recently as a few years back, will begin to become cumbersome, as the continuous iterations of “get it done, the customer needs it right away” lead to band-aids, patchwork engineering, and layer upon layer of complexity.  Time for things like application rationalization activities, engineering and architecture improvements, and infrastructure improvements are pushed aside in order to make room in the capacity model for more functional requirements for the customers.

The solution? Simple IT.  A culture of simplicity is required around every change to drive compromise between what the customer wants and needs and what IT can deliver and maintain.  Constant reinforcement of a simplicity culture is required to drive every individual contributor to ask “is this additional complexity required?”  It will drive from monolithic to modular, from n to n-1 layers of abstraction, from customization to off the shelf.  No organization is perfect, so additional iterations of software should continually simplify and rationalize the changes that in hindsight complicated rather than simplified.  The customer demands the non-functional without asking for it, and the customer gets what they’re asking for through simplicity.

What does the mean for the customer?  The customer asks for 30 reports, they get 5, because it’s actually in their benefit.  The customer wants business rules that force the agents to jump through hoops to try to upsell customers, which leads to ridiculous clicking and wasted agent time, IT pushes towards training, because the complexity hurts the users’ perception of the software and impacts their behavior negatively.  The customer asks for a different pricing model for every market, IT refuses to support it.  Will this lead to significant conflict and accusations that IT is not responsive to the business?  Absolutely!  Perhaps the company will go through three IT leadership teams before they realize their behavior is the problem, or perhaps they will never realize.  Either way, IT has a duty to the business to draw a line between what is possible and what is right, and IT is in the unique position to provide the business with facts and data about how decisions driving complexity hurt not only IT, but hurt the business.  Simplicity is, in reality, complicated to deliver; it’s the enemy of mediocrity; it’s the champion of forethought and design; and a culture centered around simplicity is the only way to deliver years of iterative software without being forced to spend significant amounts of money, time, and resources, redoing what customer centricity, and by extension, complexity, create.


Time to start writing thoughts again

A couple of things have happened recently which has made it to where I believe it’s time to start writing thoughts, publicly, again.  First, I’m relatively certain people do not read this, at least regularly.  Secondly, even though I have advanced significantly in my career and I am now a very competent middle manager, I believe my entire happiness in my work life is suffering simply because we seem to defer to political correctness.  Making sure no one’s feelings are hurt rather than running an organization as a meritocracy where the best ideas win seems to be lay of the land, at least in American business these days.  I used to not be afraid of putting my thoughts out there, now I seem to be in constant fear that being liked is the most important aspect to career advancement.  I have decided that while I have come very very far in the last few years attempting to ensure that I am effective at change in a large organization due to being well liked and respected, I will no longer place being liked ahead of stating what I think will be in the best interest of our organization.  That does not mean I intended to go back to being a daft prick like I have been in former years, but I will be firm on my thoughts on the direction our organization should be taking.  I want these ideas to stand on their own, so this will be immediately followed by another post on being too customer centric.