The last bit of my BC talk

As frequent readers will remember, I've been posting about my recent talk at Boston College. Previous excerpts are here and here.

This is the last such excerpt.

After talking to the students about a framework to understand global outsourcing and then speaking about the way a leader should look at the job of managing a global team, I tried to impart some lessons-learned. Since much of this content has been covered previously in this blog (look for the "best practices" tag), I'll be brief. I said, with supporting anecdotes in most cases, the following:
  • Managers can delegate authority, but not responsibility. This is often lost on neo-mangers, who will point to the outsourced team and blame them for problems without understanding that they themselves are responsible for the actions of the vendor team.
  • People are not capacity, even though it's seductive to talk and write about "labor pools." Humanize your team. Try to know them by name. Put them on your organizational chart as people, not as "capacity blocks."
  • Communication is made slightly tougher by distance, and tougher still by cultural and linguistic differences. Don't let this overcome you, but adapt: Remove idiom from speech, use good communication tools and technologies, and always seek written confirmation of verbal communication.
  • Use checklists for high expectation tasks. Make tacit knowledge explicit where ever possible.
  • Building a global team, whether insourced or outsourced, takes time. Don't give up before you start to see return on the investment. Avoid "shiny object syndrome."
  • If you want to be "faster, cheaper and better" be ready to answer the question "...than what?" Measure your operations, and use those measurements to inform your outsourcing governance.
  • People fear outsourcing. They fear difference. They fear losing their jobs. They fear competition. Understand that fear, but don't be mastered by it.
Lastly, I presented my belief that outsourcing is its own extant body of knowledge. I used this graphic, directly from my current sales pitch for my consulting business, to illustrate the fact that there is a lot of complicated knowledge hiding behind the simple decision to outsource something...
Judging by the Q&A throughout the presentation, and the people who grabbed me at the end to talk one-on-one, it was a successful presentation. Hopefully, these blog posts captured some of that.


More from my recent talk at BC

This is the second in a series of blog entries summarizing my recent guest lecture at Boston College's Carroll School of Management. The first excerpt is here.

After laying some foundation about the variety and difficulty of global technology teams, I spoke about the importance of selecting the right people to manage a global effort.

Without naming names, I referenced the dozens of great "local" managers I've known through my career who failed utterly in their efforts to manage globally distributed teams.

I spoke particularly about one manager who worked for me - a star in my organization, highly effective, liked and respected by his staff - who in less than a year destroyed a highly functional global team, taking productivity to near zero and creating a massive attrition problem for the person who ultimately replaced him.

The issue wasn't that manager's commitment to the global team. It was that his skills as a manager and a leader no longer applied in the new global context. He didn't adapt or develop new skills to face the challenges of managing a global team.

Particularly, he was no longer able to do "management by walking around," he no longer had the benefit of a team that was capable of sharing tacit knowledge, and he no longer had instant rapport and cultural affinity with all members of his team. In short, he was not a great manager once the rules of the game changed.

I wrapped up the object lesson by stating that it's easy to be a great manager when you've got a great team, all co-located, all knowing exactly what their job is. Adding challenges to this mix is something great managers will overcome. But average or bad managers will not be able to overcome this. In short, globalization may be the straw that breaks the camels back. But it's still a straw.

Being the info-graphic addict that I am, I had a pie chart to make my point.

Most people who begin managing global teams see their world like the graph above. They believe that 80% of the problem is the "offshore team" component. In a globalized world, this view is just wrongheaded, and it will doom this manager to failure.

A better view of the world comes from analyzing successful managers who build or manage great global teams. They aren't more culturally attenuated. They don't have better tools. They don't have magic pixie dust that makes cross-cultural communication easier. They just learn and adapt their management style to new situations. That is, great managers can metabolize the new challenges of a global context because they are great managers. They will inevitable see the world like this:

In this view, the "offshore team" component is maybe 20% of the problem space. I've spoken with knowledgeable experienced technology executives who will argue that it's even less than 20%. Either way, it's not the big piece of the pie chart. The big piece is "I manage." What does "I manage" mean? It means taking responsibility, while delegating authority. It means building a team. It means telling people what you expect of them, and holding them accountable to achieve it.

I'll talk more about this in my next excerpt from this talk.

More later...


Excerpts from my recent talk at Boston College

Several weeks ago I had the opportunity to present a guest lecture to a grad-level symposium on outsourcing theory at the Carroll School of Management at Boston College.

I attended Boston College for several years in the '90s. At the time I thought I wanted to be a philosopher when I grew up. Turns out love of wisdom is not a growth industry.

I actually started my career in high tech at BC, working in their IT shop to fund my graduate studies in the Philosophy of Science. So I always enjoy going back to the campus.

And as an added bonus, the course was taught by a man I like and respect - Mohan Subramaniam, D.B.A.

Professor Subramaniam is the author of a significant amount of new theory and scholarship in the space of global innovation, and really knows his stuff. I was delighted to have the opportunity to talk with him and his students.

The attendees were a mix of professionals and MBA candidates. Their experience level ranged broadly. I tried to keep my comments generic enough to apply to all levels. What follows is a transcription of the salient bits of my presentation:

Managing Global Teams – a Practitioner’s Perspective

I began my talk with a description of the high-level thought processes that drive most organizations to begin outsourcing some portion of their operations. In my experience, this starts with a tacit desire to be faster, cheaper, or better.

All business-drivers that ultimately lead companies to outsource fit into one of these three buckets.

I defy anyone to find a driver that is separate from the desire to be faster, cheaper, or better. The class took me to task on this, and presented some drivers they thought fell outside of my purposefully simplified model:
  • More flexibility in ramping up or eliminating staff - This may be faster, it may be better, or it may be both, but it certainly fits into the model. Faster ramp-up, better ability to align resources to business realities.
  • Access to a large or talented labor pool - This is a form of better. Access to better people than you might otherwise be able to attract and retain.
  • Ability to slough off non-core work and focus on the core -- This too, I argued, is very simply a form of better. Ability to focus on the core is the ability to be better at what is important to your company.

I then presented this flow chart, that sums up the decision gates most companies go through:

If you’re good at this stuff you’ll enjoy good results. You'll be faster, cheaper, better or some combination of the three. Hooray! Good for you.

But if you’re not good at this stuff, you will fail. Like this. Or this. Or this.

In order to understand "this stuff" you first need a framework to talk about the various flavors of outsourcing. I presented my framework.

All sourcing models, I contend, boil down to two questions: Us or Them? Here or There?

I presented the attendees with my UTHT matrix. This matrix, taken from the opening chapters of the book I’m working on, defines a simple 2X2 matrix (I do love a simple 2 X 2 matrix!) and lays out a way to describe all outsourcing team models into 4 quadrants, and 5 team variants.

The team variants I described are as follows:
  1. Pure Local Insourcing
  2. Global Insourcing
  3. Local Hybrid Teams
  4. Global Hybrid Teams
  5. Pure Global Outsourcing
I talked about how each of these 5 team types is subject to a 4-fold problem. Most "traditional" technology teams deal with at most 2 of these facets. In three of these five outsourcing models, you double the complexity of the working dynamic, and face all these problem facets:

Outsourcing is difficult. It adds complexity. In traditional teams you have to deal with the problem space and the team dynamics of your local team. That’s an easy set of problems. You know technology or you wouldn't have gotten the chance to lead a technology team. You know your team; and you probably manage them by walking around. Throw in the complexity of vendor and client relationships and an extra team with potentially conflicting culture and goals - and you've got a real mess.

I use this same slide in my vendor training to describe the fact that outsourced service providers have among the toughest jobs on the planet because they have to be savvy and proficient across all four of these facets. This part of the talk really resonated with the more experienced attendees. I think the truth of this statement may be lost on younger MBA candidates who haven't had the difficulty of managing across multiple facets of a problem space...

This was all to lay the background, and to give the attendees the understanding that the simple, obvious decisions (sic) they’re making and suggesting around their theoretical work and case studies in outsourcing create a whole new level of complexity once implemented.

That’s probably enough for this post.

In my next extract from this talk, I’ll go through the “lessons learned” portion of my talk.


Book Review - Dealing with Darwin

This is another in my very erratic series of book reviews, and is a departure for me.

Normally, I don't like or enjoy business books. I prefer non-fiction with good business-related object lessons, at least for the book reviews I write for this blog. But I just read Geoffrey Moore's new book called "Dealing with Darwin." I found it enjoyable, but also useful and directly related to global outsourcing strategy. Hence the review.

Dealing with Darwin provides a lucid explanation of the Core versus Context debate, and how to use it to inform business decisions.

Here's Moore's explanation in a nutshell:

Core work produces sustainable competitive advantage. Context is everything else.

An important difference in Moore’s explanation, and one that is lost on people trying to intuit their way through the core / context analysis, is that context isn't synonymous with unimportant.

Moore defines a 2 X 2 matrix, as follows:

  • Core versus Context on one axis
  • Mission-Critical vs. Non-Mission-Critical on the other

This gives you the following handy magic-quadrant that you can use to "rank" what your business or organization does. (I wrote last week about using this approach to inform strategy. Read about it here and here.)

The four quadrants, to summarize with some license applied, break down like this:

  • Quadrant 1 -- This is where you innovate and invent. You create new differentiated offerings here.
  • Quadrant 2 -- This is where you deploy your new differentiated offerings.
  • Quadrant 3 -- This is where you operate. I think it's fair to assume that most IT and an awful lot of post-1.0 software development work happens here.
  • Quadrant 4 -- This is work you offload, or cease doing all together.

The last interesting thing Moore says, directly relevant to the question of what and how to outsource, is that you can rotate people from quadrant-1 to quadrant-2, and from quadrant-4 to quadrant-3. This is, to paraphrase, contrary to the harsh Darwinian position that you lay off people as their work becomes non-mission-critical, and hire new people with new skills to innovate. He correctly points out that this erodes morale and destroys the positive aspects of corporate culture.

Moore's a good, accessible writer, and this is an important book for anyone attempting to chart strategy around business investment or sourcing.

Buy it and read it!


More on core versus context

Earlier this week I ran an exercise to walk an executive team through a core versus context ranking. The exercised was designed to generate animated discussion towards a clearly articulated multisourcing strategy.

The exercise was moderately successful, but a few things popped out:

For starters I'll remind the reader (and myself) of the 4 quadrants I used for this exercise. These are as described in Geoffrey Moore's Darwin book.

The exercise I suggested was to create a catalog and inventory of services and then map them into these quadrants. I prepared a few examples and asked for dialog around what quadrant was most appropriate for each example service.

Service Descriptions are difficult to write

Not surprisingly, the first point of debate was around the definition of a service. I had carelessly described an example service as "Active Directory Administration." That caused a lot of confusion, because depending on personal perspective the service was interpreted differently. If you read that service statement as "user provisioning, access and control" it's mission-critical. If you read it as "system administration of the AD servers" it is arguably non-mission-critical. The important lesson here is that service descriptions need to be tightly written, and need to focus on the business value derived from a service, not the tasks required to deliver a service.

An obviously bad service description might be:
  • Active Directory administration
A better service description might be:
  • The organization provides a service (currently but not necessarily run through Microsoft Active Directory) to manage user credentials and single-sign-on logins for the global IT infrastructure. In provision of this service, new users must be added within 1 business day, password resets must occur in real time during normal business hours, and user accounts must be terminated with a one-hour SLA, 24X7. This service includes and subsumes all necessary procurement, topology design, software installation and maintenance, system installation and maintenance, and day to day operation necessary to provide this service to the business.
With that service description, there would be less debate about what was included in the notion of the service, though even with "24X7 " statements in the service description you might bump into the second lesson of this exercise:

"Mission Critical" is not intuitive or self-evident

As I led the discussion about where various IT and development services fell into these quadrants, the core / non-core part if the model seemed to be self-evident to everyone involved. Moore's description - which I paraphrased as "providing sustainable competitive advantage" - is clearly a good, easily internalized yardstick.

However there was much debate around what is and what isn't "mission-critical." Most of what I've read defines mission-critical with synonyms that mean "mission-critical." It's better to define it in terms of impacts to the business, and the pain threshold a business is willing to endure.

An application or service is mission-critical if its failure, cessation, or temporary absence results in unbearable negative impacts, such as:

* Financial penalties or significant loss of revenue
* Lapse of regulatory compliance.
* Injury or loss of life
* Severe degradation of operational efficiency
* Severe adverse public opinion or publicity

The frustrating thing for anyone attempting to use this methodology to inform their sourcing strategy is that it's an "onion peeling exercise." These business impacts listed above are only examples. These items align to the corporate identity and strategy, and as such, what is mission-critical for one company will not be so for another.

So the lesson is to first develop a rough guideline of the pain threshold you're willing to tolerate, and use that guideline to inform your M-C / N-M-C analysis. Your mileage may vary on what is / isn't mission critical, but I'd use the bullets above, and define "temporary absence" as one business week. That will help make it easier to slot items into mission-critical or non-mission-critical.

Missing some important data

The last lesson from this strategy-building exercise is that the quadrant analysis may help you decide what reasonable outsourcing or multisourcing targets you have in your portfolio, but it doesn't necessarily help you prioritize.

It would be tempting to say that you'd go counter-clockwise from quadrant 4, first attacking N-M-C context, then N-M-C core, outsourcing and freeing resources accordingly.

However, it might be more appropriate to look at areas where you can get good bang for the buck, as well as areas where you don't have core competencies or skills to match your aspirations. Hence, I think a couple of modifications are necessary to make this model work well.

First, I'd suggest "surface area" modification to the service inventory. This data may be hard for organizations to track down, but when you inventory your services, also note the estimated dollar amount (fully burdened) that providing the service costs your organization. Then, represent the service as a "dot" where the size of the dot is proportional to the amount spent on the service. Spend $25M on managed network services, you have a big circle. Spend $50,000 a year on managed network services, and it gets a small circle.

Then, you can quickly visualize the "low hanging fruit" in your service portfolio. It may not be prudent to begin an effort to outsource non-mission-critical context if you can only save a very small amount of money or free up a very small amount of time through the effort.

Lastly, this model doesn't represent an organization's core competencies, just their core services. If you aren't very good at providing Enterprise Messaging, then maybe you should consider augmenting your skills through outsourcing as a high priority. A simple modification, encoding the service with your organization's capabilities, will produce another visual representation that will allow you to quickly scan for high priority areas. You can do this by a "gut feel" ranking of core competency, as good (green), moderate (yellow) or bad (red). Obviously, large dollar, low competency areas should be addressed with priority, regardless of what quadrant they fall into.

This model would produce a visual representation like this:

In this model, it's probably more important to have an approach to solving the lack of skills and competency in Service 1 than it is to free up the resources delivering Service 4.

So in this case your outsourcing strategy needs a statement of how you would augment skill in new service development, either through outsourcing to a qualified firm or outsourcing through M&A activity with some attractive start up in the space.

At any rate, the model generated excellent debate. This can be used to build consensus, and also to inform a strategy. With the modifications I suggest above it can help prioritize what areas of your organization you view as viable targets for outsourcing, staff / skill augmentation, etc.


Assessing what to outsource

I've read pretty much every major book on outsourcing. They all devote considerable page-count to the determination of outsourcing strategy. But they mostly miss the mark. There are dozens of models, developed and no doubt used to good effect by dozens of authors. But mostly in my opinion and in my experience, determining what you can safely and productively outsource boils down to advanced common sense.

But that's a tough concept to teach, or to relate to other people.

That's why I was somewhat excited when I picked up and read Geoffrey Moore's new book called "Dealing with Darwin." The book isn't really about picking what you outsource and what you don't. It is about picking what is core to your business, and what is contextual, and then allocating resources accordingly. But the lessons are directly applicable to the question of what to outsource.

This core / context matrix gets referenced a lot in business. But few people I've heard use this model have a crisp definition of what is or isn't core. Moore actually does a decent job of defining core and context. In a nutshell (to save you the 8 or 9 hours it takes to read the book), core work produces lasting differentiation that allows you to retain customers and hence charge more for what ever it is you do... Context is everything else.

Put differently, core is that which your customers believe they can and should buy only from you, context is all the stuff you do to manage to deliver it.

Moore defines a 2 X 2 matrix, as follows:
  • Mission-Critical vs. Non-Mission-Critical on one axis
  • Core versus Context on the other
This gives you the following handy magic-quadrant, that you can use to "rank" what your business or organization does.

The four quadrants, to summarize with some license applied, break down like this:

  • Quadrant 1 -- This is where you innovate and invent. You create new differentiated offerings here.
  • Quadrant 2 -- This is where you deploy your new differentiated offerings.
  • Quadrant 3 -- This is where you operate. I think it's fair to assume that most IT work happens here.
  • Quadrant 4 -- This is work you offload, or cease doing all together.
The 4-quadrant approach lends itself to an exercise you can use as a preamble to creating an outsourcing strategy. The way I'd start this exercise it with a service inventory. This is a little different than what Moore does. He's talking about markets and geographies and big-picture business decisions. But if you're an IT leader, you're not worrying about whether to try to crack into the AsiaPac DSL market. You are, however, worrying about how you're going to provide messaging services to your business.

It's important for the sake of this exercise to separate services (stuff that the engineering or IT organization provides to the business) from a task inventory, for example, this might be a quick task inventory for "Exchange messaging services":
  • Active Directory User provisioning.
  • Exchange server patch management and server upgrades.
  • Storage administration.
  • Incident response and troubleshooting.
  • Spam filter administration.
  • MX record administration.
  • User de-provisioning.
These tasks, while important, don't really matter for the sake of this argument. The service - "messaging" - is what counts. As a service, messaging might best be described as:
  • Providing individual users with the ability to send, receive and store RFC 822 electronic messages from within the company, as well as from individuals at other organizations.
What quadrant does this fall into?

Unless your company builds mail servers and sells them, or offers hosted e-mail to your customers, I'd suggest that your messaging service is contextual. Your customers don't buy messaging from you. That said, it depends on your business whether this is mission-critical or not. Either way, this is a Quadrant 3 or Quadrant 4 service. It's contextual. In my book, that means it is a candidate for some kind of outsourcing. Maybe if it's mission critical, you manage the service, but seek offshore staff augmentation. Maybe if it's non-mission-critical, you outsource it entirely, and just buy it from some company that provides e-mail service to other enterprises.

If you go through everything in your service portfolio, and take the lessons Moore develops for markets and apply them to the much smaller fractal pattern of IT services or product engineering, you can quickly develop a landscape out of what once might have seemed to be a melange of unrelated tasks and services. And you can see, in an act of advanced common sense, what you should do about all these services you have to provide to your business.
  • Those things that are core, and non-mission critical may need more investment.
  • Those things that are context may need offloading, cessation, or augmentation.
To follow Moore's guidance you should try to offload resources (people or money) from contextual work and put it on core work. That's what will differentiate you in the eyes of your customers, and that seems like a pretty good starting point in determining what you can and can't outsource.

I'm leading a facilitated discussion on this topic this week. So more on this later, after I try to walk some people through this line of reasoning.

The difficulty of constant blogging...

I am now more impressed than ever with the amount of output that the blogosphere produces. Through the first half of this year, I was averaging a little over 2 blog entries a week. Then, I got a couple of contracts in my consulting practice, and hit a patch where I was booked at about 120% of capacity, and the wheels fell off my blogging wagon.

And I haven't written anything for Inside Outsource - The Blog in about a month.

The good news is that I have a number of new insights to write about. The bad news is that I'm out of the habit. I hope to fix that starting today. A new leaf. A whole tree of new leaves.