Managing Self-Managing Teams

Managing self-managing teams sounds like an oxymoron. I assert that it isn’t. Hear me out.

Central to my position is an understanding of management (managing), self-managing, and the manager role.

Management refers to the collection of activities required for the healthy functioning of an enterprise. These activities include planning, organizing, measuring, budgeting, coordination, etc. We can lump these activities under the umbrella of “managing.”

Researchers (as far back as the 1970s) have described self-managing teams as groups of individuals who can self-regulate on whole tasks. Dr. Richard Hackman developed a typology that includes self-managing teams. Other team types include manager-lead teams, self-designing teams, and self-governing teams. Hackman’s typology below describes teams based on their management responsibilities.

Last but not least, a manager is anyone assigned managerial responsibilities (and not just people with “manager” in their job title). This means that a Vice-President in a software development firm is a manager because they have management responsibilities. I will not wade into the nonsense I consider the manager-leader distinction. That will have to wait for another day.

Bringing this home to product development, a self-managing team has responsibility for executing the team task and monitoring and managing work process and progress. “Executing the team task” requires little explanation and is pretty straightforward to understand—the team has full responsibility for completing the task required to achieve desired outcomes.

Self-managing teams also have responsibility for managing how they get their work done and monitoring their progress on their work. Of course, the team must have the competencies to do this well. It’s not enough to declare a team self-managing and expects that they can now magically “monitor and manage work process and progress” effectively. Self-managing is not without its challenges, and anyone who suggests its a panacea is not being truthful.

(While I have you, let me share that I prefer self-managing over self-managed because it speaks to the ongoing nature of the management activities the team is responsible for.)

Hackman’s model makes it clear that “other-managing” will focus on other aspects of management, i.e., “setting overall direction“ and “designing the team and its organizational context.” A self-managing team is not focused on these aspects of management. These aspects can be the responsibility of a manager. It will be the responsibility of some individual(s) outside the self-managing team.

The effective manager of a “self-managing” team will continually ensure the self-managing teams have the resources needed to succeed. The manager will address external friction impeding team progress. The manager’s role is to provide external managerial support so the team can self-manage. And this is managing—managing a self-managing team.

Now it’s easy to try and establish a clear separation between the focus on the manager and the focus of the self-managing team based on typology. Doing this would be a mistake. While the responsibilities are distinct and can be analyzed separately (to a degree), the responsibilities interact and influence each other.

For example, when direction or organizational context changes (and it will), the self-managing team needs to know to adapt their processes appropriately. Conversely, the self-managing team needs to make its progress transparent so the manager can use this information in direction-setting and organizational context conversations. 

These interactions don’t change the locus of responsibility. Rather the interactions remind us that everything is connected and the importance of healthy feedback loops.

I firmly believe that many product development contexts would benefit from (at least) self-managing teams. We know that the more autonomy people have over their work, i.e., what they do, and how they do it, the more meaning and fulfillment they derive from work. The more committed we are, the more we positively contribute to our organizations.

Self-managing teams are rare in product development organizations despite many senior leaders claiming them. I believe a key reason for this is that many senior leaders in organizations do not understand how to foster self-managing teams. They often give mixed messages. On one hand, they tell teams they want them to be self-managing, and on another, they tell managers they are accountable for “monitoring and managing work process and progress.” Well, what do you think happens? 

Many managers feel a strong desire to control. It’s a natural expression for many of us. Additionally, our organizational socialization leads us to believe the only way to control is to take over the responsibilities of self-managing teams. Without proper training in other management areas, while enabling self-managing teams, managers focus on what comes naturally. So manager-led teams continue to dominate the landscape.

Organizations need managing. While self-managing teams manage critical aspects of their work, they will also need management support if they are going to achieve organizational goals. Managing self-managing teams is not an oxymoron.

Thoughts on “Managing” Software Development

I’ve written in the past on management and managers and you can find some of those thoughts here however I want to share some additional thoughts.  These thoughts are basically my answer to the question of: what does a Software Delivery/Development/Engineering manager do?

(Even if you’re one of those who believe managers are not needed in knowledge work, I’ll crave your indulgence to read on).

(I do believe that Software Development/Engineering Manager are better role names than Software Delivery Manager but I digress).

It is dangerous to define the job duties of a role without taking into consideration the guiding philosophies of an organization.  For example, let’s just look at the concept of the manager. The definition of management (and hence managers) in an organization that adopts the principles of Frederick Taylor will be markedly different from that of an organization that adopts the principles of Edward Deming.  In other words, roles are not defined in the abstract.  The organizational philosophy ultimately defines the role.

I belong to the school of Deming when it comes to management, and as a result, my definition and description of a software delivery manager is going to be based on Deming’s view on management and managers.  I posit that real Agile and/or Lean organizations take a similar stance.

A software delivery manager is a “manager of software delivery” and if we decompose the role into its component parts we have manager and software delivery.

Douglas McGregor basically describes the Taylorist manager as person who works with the assumption that:

…workers have an inherent dislike of work and hence needs to be directed, controlled and threatened with punishment in order get them to work hard to achieve company objectives  

The Taylorist manager is all about control and external direction ergo this manager focuses on defining how the work should be done by the individuals on the team and then measuring individuals to ensure they are meeting pre-determined targets the manager defined.  This manager leaves little room for individuals and teams to self-direct as these managers need to do all the planning and provide all direction.

So how does Deming describe as the role of the manager?  According to Deming (excuse the gender-specific tone), a manager:

1. Understands how the work of the group fits with the aims of the company. He teaches his people to understand how the work of the group supports these aims.
2. Works with preceding stages and following stages
3. Tries to create joy in work for everybody
4. Is a coach and counsel, not a judge
5. Uses figures to help understand his people
6. Works to improve the system that he and his people work in
7. Creates trusts
8. Does not expect perfection
9. Listens and learns
10. Enables workers to do their jobs

Deming is not alone in his thinking.  Other management thought leaders such as McGregor, Drucker, Ackoff, and Senge all share the same thoughts.

If I were to summarize, I would say that the role of the Agile (and some would say modern) manager is to:

Create an environment where people and teams can do their best work for themselves and the organization in a manner that is both rewarding and fulfilling

The modern manager realizes that s/he is dependent on their team to be successful.  The team is also dependent on the manager.  In a nutshell, the team and the manager are interdependent.  The manager and the team share in the responsibility of developing and delivering software.

(If you work for an organization that says they are Agile and but exhibit Tayloristic management tactics, I hope for your sake that the organization is in the early stages of Agile cultural adaption.  If they aren’t, you’ve been warned).

So we’ve defined manager but how about software delivery? Software delivery is simply the aim of the system that the manager and their team(s) belong to. This system has the goal of delivering software that addresses the needs of stakeholders.

What then are the duties of the software delivery manager?  Here are a few that immediately come to mind:

• Provide clarity to team members and teams on organizational objectives and what achieving them entails
• Define operating constraints and boundaries for teams in which they operate
• Provide teams with the appropriate authority, resources, information and accountability
• Provide career guidance and coaching to individual team members and teams
• Staff teams appropriately within budgetary constraints.  Manage their budget responsibility
• Partner and network with other managers in the organization in addressing organizational impediments
• Provide feedback to the teams on the software that is being developed.  Engage in product “inspect and adapt” sessions.

What else would you add to this list?

While we’re talking about software delivery teams, I need to remind us that in Lean and Agile organizations, the work is done by cross-functional teams.  The implication of this is that software delivery teams will often be composed of individuals from more than one functional group in the organization.  A software engineering delivery manager will often need to team up with managers from other functional groups in the organization e.g. infrastructure manager and together they will provide the team the support it needs.

It’s also important to remember that Agile teams (regardless of the framework of choice), as a part of being cross-functional, have a role on the team responsible for championing the product (or something similar to a product).  This role, often referred to as the Product Owner, and not the software delivery manager, decides what the team should focus on.

So there you have it.  These are my thoughts on the Software Delivery/Development/Engineer Manager.  I anticipate that some readers will disagree with me.  Please share your thoughts in the comments.  But as you disagree with me, take a moment to explore why it is that you disagree with me.  In fact, I would implore that you examine the underlying philosophy and mental models that inform your definition. Where do they come from?  Do you know?  Are they based upon Taylor’s Principles of Scientific Management, Deming’s principles or something else?  

Our actions reveal our beliefs.

Velocity is NOT about Productivity

I happen to participate in a couple of Lean and Agile subject matter groups on LinkedIn. This is my way of learning and sharing.  In my opinion, any serious Agile practitioner should join and participate in such types of groups (no it’s doesn’t have to be on LinkedIn). I personally learn more from these groups than from workshops and certifications classes.

I’ve observed over the past year that not a week or two goes by without someone having a question around Agile velocity on one of these discussion groups.  Interestingly enough, their questions are never about how to use velocity for forecasting and/or planning. No, the questions are always about how to increase or improve their team velocity.  As an example, check out this very recent velocity conversation.

Why are so many of the velocity questions focused primarily on productivity?

Unfortunately, many of these well-intentioned posters find themselves in organizations where velocity is considered to be a primary measure of productivity.  Not only do organizational leaders use velocity as a measure of productivity, we find some Agile practitioners (sometimes unintentionally) doing so as well.  I’ve seen postings on LinkedIn where teams are congratulated for increasing their velocity.  I’m saddened and disappointed that in 2016 we’re still talking about velocity in this way.  I’m not sure what got us here but instead of simply complaining, I am compelled to share my thoughts in the hopes that it may help someone or some organization now or in the future.  Paraphrasing Peter Block, start with the room you’re currently in.

First of all, let’s agree on what velocity in the context of Agile software development is. Operational definitions are extremely important and I think defining velocity will do us some good.  Velocity can simply be defined as the:

Sum of effort estimates completed in an iteration (see the Agile Alliance reference for more information of velocity).

Any other usage of the term in an Agile software development context is a redefinition of the term.  Agile velocity doesn’t refer to how fast a team works.  It’s not even the count of items completed in an iteration (that could be throughput). It how much of our effort estimates did we complete in an iteration.  No more, no less.  That simple.

As the Agile Alliance article makes clear, velocity is primarily a planning instrument. Carefully read the article as it provides a pretty good explanation of the purpose of velocity and what it should be used for.  Pay attention to the common pitfalls as well.

(However I must point out that many Agile teams effectively forecast and plan without using velocity.  Stated differently, velocity is not a requirement for forecasting and planning.)

But maybe you still think that we should be able to use velocity to gauge how productive our team is.  Maybe the information presented so far is not convincing enough for you. In that case, let’s take a moment to dissect what it means for a team to increase its velocity.

If velocity is the sum of our effort estimates, increasing our velocity would mean that we have to increase the sum of our effort estimates completed.  On the surface, it may seem that this would be easy to do.  All a team has to do is increase the number of items it completes and their velocity will increase.  However, completing more items doesn’t assure us of a velocity increase because we can’t assume that our estimates are the same or larger than our estimates for previous iterations.  In fact they could be smaller and our velocity could actually decrease and yet it would be a good thing!

For example, let’s assume a team had a velocity of 20 points in Iteration 1, which meant they completed 4 stories each estimated at 5 points.  Then in Iteration 2, they had a velocity of 18 points after completing 6 stories, which were estimated at 3 points each. Were they less productive in Iteration 2 because their velocity went down?  What if they completed 7 stories in Iteration 3 and each of those stories has an estimate of 1 point? Are they still less productive?  How do we know?

Don’t forget that velocity is calculated using “effort estimates”.  Estimates are subject to many factors that I won’t get into in this article and yet its important to remind ourselves that each iteration the team is solving problems they have never solved before. The team effort estimates could go up due uncertainty and complexity and it would have nothing to do with how productive they are.

Determining how productive a team is based on how much of their “effort estimates” they complete totally misses the point.  I think Deming would refer to this as management malpractice.  It’s that bad.

And yet teams can easily increase their velocity.  In fact, it’s not hard at all.  All they need to do is make their effort estimates larger.  I’ve seen many teams do this in my career. I’m not sure your organization really wants that.  Riffing off of Goldratt:

Tell me how you’ll measure me and I’ll show you how I’ll behave.

So encouraging teams to increase their velocity is simply something organizations that are intentionally adopting Agile should not be doing especially if they don’t want their teams to game the system.  I will go further to suggest that using velocity to determine predictability (in the small) is in serious danger of missing the point of velocity as well. There are there better ways to do this and I will be addressing that point as I finish my series on predictability.  If you missed the first two posts, check out Part I and Part II.

After all this talk on velocity, I am moved to remind us that the primary measure of progress for an Agile team (and organization) is the amount of software that has been delivered to users and that the users find valuable. All other measures are secondary and tertiary.  Velocity can be used to help forecast and plan (and there are possibly better alternatives to it) but let’s not use velocity as a measure of productivity.  If you must use velocity, use it responsibly.

Is Your Oven The Right Temperature?

A large number of organizations attempt to to have their software developments go “Agile” for a variety of reasons.  The sheer number of discussions in Agile discussion groups is a reflection of this craze. Many of these attempts fail and fail miserably.

A careful read of the Agile Manifesto makes it clear (to me) that the signatories anticipated a certain type of environment  for Agile software development to thrive in.  Consider the following principles:

• Principle 4: Business people and developers must work together daily throughout the project.
• Principle 5: Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
• Principle 8: Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
• Principle 11: The best architectures, requirements, and designs emerge from self-organizing teams.

Each principle implies a lot about the type of ecosystem in which Agile software development has a chance of being successful. Many organizations that are trying to do or be Agile are only aware of a set of codified practices and are oblivous to the principles that I just mentioned.  Unfortunately, the Agile manifesto itself doesn’t explicitly address the ecosystem needed for Agile to have a chance of being successful.  Organizations that are interested in Agile software development need to actually look to other sources for information on how to cultivate such an environment. Sources such as Argyris, Deming, Drucker, Weinberg, Ackoff, Senge, Hackman, Pink, Mintzberg (to list a few) are a great place to start for anyone who is interested. If you are a manager and most of these names are not familar to you, I would strongly suggest that you look them up.  In fact, if you get nothing else out of this post, I hope you just start a reading list.

The fact, however, is that many (if not most) large organizations have systemic structures (politics, hierarchy, funding models, appraisal systems, control systems etc etc) in place that are at odds with the structures needed for Agile software development to actually succeed.  Several thought leaders in the Agile space have largely given up on “the large organization” and have suggested that it’s waste of human potential trying to create the conditions for Agile to succeed in such environments.  Others have fused other methods such as Lean Thinking and Theory of Constraints to create a more holistic approach.  I’ve especially found the work of Bob Marshall (@flowchainsensei) and Rightshifting to be particular motivating for me in this regard.  Let’s take a look at few examples of organizational structures typically found in the large organization and the challenges they present to Agile.

Political Structures

The larger an organization, the more of an influencer “politics” is.  People protect their territory (which often includes other people) at the expense of the overall good of the organization.  Transparency is lost as a result of folks continually manuvering. Alliances form beind the scenes and nothing gets done.   In a highly political charged environment, Agile will struggle.

Funding Structures

If your organizations sees technology as an auxillary function (a cost center) that provides utility services then technology will be funded in a such a way.  Very often that funding leads to the execution of projects.  I’ve written in the past about projects and products so I won’t rehash that here.  But, in a nutshell, if your organization delivers projects, it may be challenging (or impossible) for your organization to be Agile.  (I realize that the manifesto uses the word, project. Don’t let that mislead you.)  On the other hand, if your organization sees technology as a strategic lever with the understanding that product development is primarily an exercise in discovery, then Agile may work for you as you’ll find that you work be doing projects.

Accounting Structures

This is related to the previous structure but it still warrants being called out explicitly.  Cost accounting or throughput accounting?  Your accounting structure can impact your ability to truly work in a Agile way. What accounting structures do you have in place?

Hierarchical Structures

Traditional organizational structures are largely Taylorist in nature. Managers (and this includes all titles involved in the management) are brought in to ensure that people (very well educated and compensated people mind you) are doing the right things.  I’ve also written about this recently and so I won’t repeat what I said.  I’m saddened by how many managers are unaware of the role of the manager in an organization.  Your organization will struggle with Agile if the organizations view on hierarchy and management remains Tayloristic.  If you don’t plan on making a true commitment to enable self-directed teams (see Hackman and Kimball) and network-based structures, then Agile is probably not for you.

Decision Making Structures

Heavily centralized or heavily decentralized ? What is prevalent in your organization? Do people have to run everything up the chain of command for approval before they can actually do their jobs?  Is information centralized in a “special few” (think Director of Agile Coaching) roles in the organization and nothing happens if they are not involved?  Is leadership at all levels promoted or does your organization just pay lip service to such an idea.  Are ideas valuable based on the title of the individual who came up with the idea or are all ideas considered equally?  If your organization doesn’t make a concerted effort to push information out to as many people as is possible to enable quick decision making, Agile may not be for you.

It has been said that “culture eats strategy for breakfast”.   A study of the Toyota Production System reveals how important the culture of an organization is.  I believe the same to be true for any organization interested in the Agile thing. Having teams try to do it on their own is (a) a local optimization and (b) not Agile.  An organization interested in Agile (and continuous improvement in general) needs to make a commitment to changing it’s existing structures if it realizes that its structures impede its ability to “do Agile”.

Your can have the perfect cake batter, but if you don’t bake your cake at the right temperature, you won’t have a cake.  Is your oven (organization) at the right temperature?  If no, what are you doing about it?  Can you do anything about it? Better yet, should you do anything about it?

I’m a Manager, I Manage People

Ok, stop.  I mean it.  Stop this moment.

Is a manager supposed to manage people?  NO.

You, dear manager, are supposed to focus on creating an environment that enables people to excel at their job.  I’m not making this up.  Take some time to read the work of Deming and Senge, you’ll see that I’m not off my rocker.  Then again, as a manager, how come you haven’t read their work?  Oh, that’s right, you were probably just promoted into a management position and asked to figure it out on your own.  Don’t worry, that’s what happened to me as well.  There is hope for us.

I’m sorry you’ve been misled and that the prevailing management theory in use is still from the Stone Ages.  I’m sorry, very sorry.  I have a confession.  I was also brought up (or is it brainwashed) to think and act that way as well.  Yes, I do find myself at war with myself at times as the flesh wants to revert back to “old way”.  So no, I am not judging you.  I’m challenging myself as I challenge you.

Trust me, there is a better way.  A way that makes work more enjoyable for everyone.  I’ve experienced it.  I need for others to experience it.  While we’re at it, let’s stop talking about “empowering people” as well.  I think we can do better.  It doesn’t reflect well on us.  It suggests we have power to give others power.  What’s that?  Hubris?  I used to use that word all the time.  I’ve stopped. I think we all need to stop. And since we’re stopping the use of words, why don’t we quickly add “resource” to that list.  But this could all be wishful thinking on my part.  Old habits die hard, don’t they?

But I got sidetracked there, the point of this post is to remind us (managers) of what our focus should be on if we really want to make a difference in our organizations.  Focus on the system.

I’m a Manager, I Fix Problems

Well depending on what type of organization you are trying to help create, that could be a problem.

For business agility via Agile or Lean methods (remember methods are NOT the goal) to be highly successful in an organization, the organization must promote the concept of the self-organizing team.  This runs counter to the traditional hierarchical philosophy that is found in many (maybe most) organizations and often prevents organizations from having their teams perform at their highest levels possible.  In the traditional approach, the organization is largely dependent on managers directing their reports and solving the teams problems. Annual goals (and you know my thoughts on performance appraisals) are built around such an approach.   I find it interesting when a manager suggests to me how “Agile” they are and then begin to rattle off how many people they have reporting to them or how often they looked at the teams’ burn down chart or inspected their card wall to see how long things were taking or solved all the problems that the team had.  They are yet to realize that their behavior is not what is desired in the age of the knowledge worker. The manager who “fixes all the problem” is not a plus in an Agile environment.  They don’t realize that they are possibly the biggest reason why their teams will not become high-performing. To quote Drucker on the knowledge worker:

For, once beyond the apprentice stage, knowledge workers must know more about their job than their boss does–or else they are no good at all.

But the fact is that many organizations that are engaged in an Agile or Lean journey have a good number of good people in managerial positions. So what are they supposed to do if not manage team members and fix team problems?  I have a suggestion: focus on the system.  What is the system you may ask? Read this and this for starters.  Can you now identify the system you are a part of?

Management (hence managers) need to focus on creating an environment (system) in which their teams can excel.  This is also known as leadership.  If you are in management and consider your responsibility to be the “management of people” then, from a knowledge worker perspective, you’ve (unfortunately) totally missed it.  If you want to get into to management for the aforementioned reason i.e. fix the teams, please do us a favor and reconsider.  Don’t rob the team of it’s ability to learn and self-organize.  Your focus and attention needs to lie elsewhere.   As a manager, you need to help design a system that allows the teams in your organization to perform an excellent job.  A job that people want to do.  This unfortunately, is quite different from our classical view, understanding and training on management and requires a complete paradigm shift of our mental models.  This transition is not easy in organizations that reward managers for behaving in a completely different way.  So once it again, leadership is required to change the system.  Quoting Deming:

Remove barriers that rob the hourly worker of his right to pride of workmanship. The responsibility of supervisors must be changed from sheer numbers to quality.

Even though many workers are now salaried, the guidance is still relevant.  No Agile (or Lean) based transformation is complete without a transformation in the way managers conduct their behavior. Beware of consultants who peddle solutions that don’t require such a paradigm shift. Be sure of what you want.  Beware of Agile managers who are fixated on jumping into the team and solving their problems.  They are probably getting in the way.

Dear manager, focus on the system.  Fix problems outside the control of the team.  Design an environment that allows the teams in your organization to be successful.

Performance Appraisals – Are They Useful?

It’s that time of the year again when companies are going through their annual evaluation cycles.  Are performance appraisals valuable?  As much as I don’t like the term “performance appraisal”, I believe that the spirit of these things can provide some benefit.  I believe that most people want some sort of feedback on their work however my experience with this process has left me with these observations (not exhaustive):

• These “appraisals” happen too infrequently (twice a year at best and most times just once a year)
• Generic templates and scoring is used ignoring the fact that each individual is unique
• Little focus on growth and development of the individual
• Human beings are not real estate/property/equipment/inanimate object, why are we acting like we are

Do you really want to wait an entire calendar year to find out if you are doing a good (or bad) job? I didn’t think so.  There should be a continuous two-way conversation between manager and associate that happens all year long.  At the end of the day, what are we really trying to evaluate?  The individual or the work they produced? I believe that the work produced should be evaluated and because its being produced everyday, we should be able to provide feedback on the work quite frequently.

It looks like, the mass production of  appraisal programs, generic templates and their associated methods has created a deadly management malaise that discourages managers from getting to know their people and appreciate their differences.  For example, individuals demonstrate leadership in different ways and score everyone based on some set criteria seems to completely miss the point.

Some companies and managers have this notion of the “one-on-one”.  My personal experience with this is that it’s rarely about the individual and mostly about the work the individual is doing.  Discussions regarding the individual are always left to the last five minutes.  Yet, I’m convinced that if the individual becomes the focus, the work ultimately gets taken care of.

As a manager, how often do you check in with your associates to see how they are doing as human beings.  Are they still finding joy in their daily work?  Is the “system” set up in a way that will allow them to succeed?  Do they feel like they are being treated fairly and are part of something exciting?  What areas do they think they need grow and develop?  Do you need the best way to provide each individual with feedback?   If as a manager you want to provide effective feedback, then you have to  take the time to get to know your people individually.

I believe that most people inherently just want to do a good job.  If you don’t do anything else, at least use this “performance appraisal” season to find out how you (as a manager) can help them with that.

Why You Should Offshore

We are all, to some degree, slaves to our individual opinions and I’m no exception.  However, I find it a somewhat therapeutic and mind-clearing exercise to move to the other side of the table and lend my backing and support to  something that I generally wouldn’t campaign for.

Today, I’m doing this exercise with the topic of off-shoring and providing reasons for doing so.

A little bit on my experience with off-shoring.  In the early 2000’s, I had the unique responsibility of starting and growing an off-shore presence for the software development team that I was a part of.  This included interviewing countless number of applicants, hiring the the very first two folks who joined the team and mentoring them until they were fully integrated with the rest of the team.

I must say that I am very glad that I had that opportunity as it exposed me in a first-hand way to what it takes to successfully have an off-shore development team.  The long hours of telephone calls, the nights with a couple of hours of sleep, multiple (long) trips to the continent of India, are just examples of the toll that needed to be paid to get things off the ground.  I must be very careful here to note that I wasn’t the only one making that investment.  The two people who had just joined this team and were trying to succeed where also making a significant investment.  The scary thing about it quite honestly, is that I had nowhere the insight into successful collaborations as I do now.  Reaffirming once again, in my mind, that most organizations survive not necessarily because they are good, but because no one knows any better (but I digress).  This initial investment was made (somewhere between 1 to 2 years) and after that they were able to bring on others to the group by themselves and continued to grow the group somewhat on their own.  At the time I left the organization, the off-shore folks outnumbered the on-shore folks on the team and the off-shore team and were generally very productive.

So if I had a good experience (which doesn’t seem to be the case for most people), why is it then that I seem particularly anti-offshoring?  Well, because of four major reasons that I can think of right now:

1. Most organizations offshore to reduce cost without giving consideration to the fact that there are other variables (such as quality or delivery times) that they are impacting
2. Most organizations will not make the investment required to successfully have offshore teams
3. Most organizations fail to understand that product development is hugely dependent on human collaboration/interactions and have the misconception that its just about smart people writing code around the clock. (Oh that’s why we’re called resources isn’t it?)
4. Those who decide that an organization should offshore are generally least informed about what is really required for it to succeed

So dear technology executive, this brings me to the point where I give you reasons and encourage you to offshore.  As a technology executive, if the following things apply to you, then you have every reason to leverage an offshore team in your product development space.

• The end users and the off-shore team are geographically located in the same place
• Lowering personnel cost is more important than costs incurred by from lower throughput (at least in the short-term)
• The products (or enhancements) being developed are not strategic and are more utilitarian or support-oriented.
• You will make a significant technological investment in communication tools to ensure that collaboration is at its best
• The offshore team understands the domain (and technology) fully or an investment will be made to have domain experts present to support the team locally
• You intend to staff all the key roles required for successful software delivery in the offshore team
• You will pay for good offshore talent
• You will make every effort to develop the members your offshore team and provide them with new opportunities so as to reduce turnover (and having to start again)
• You have committed onshore folks who will work to make the offshore initiative successful

This is by no means an exhaustive list, if however, you don’t intend to do these things or the circumstances don’t apply to you, venture in at your own risk.  But before you do decide, seek the advice of those who really know what product development is about (and no, just because someone has a computer-related degree, it doesn’t make them knowledgeable).

A word is enough for the wise.