Winning with offshore

I recently had an opportunity to speak about being successful with offshore partners. Having worked with several partners in my career, I was fortunate to be able to have some experiences to draw on. There were three themes I eventually landed on:

• People versus resources
• Relationships versus transactions
• Collaboration versus isolation
  

People versus Resources
The language we use is a reflection of our thoughts and shapes future thoughts. So here's a simple question: Do you report the number of people or the number of resources you have offshore? You see, resources are interchangeable and anonymous. People are flesh and blood.

Several years ago, my former manager began penalizing our team every time we referenced our partner either by their country ("I don't know how that happened, Antarctica tested that feature") or by their company name ("I can't believe Igloo Offshore would have coded it that way!"). She forced us each to examine the way we viewed them. Were they simply a group of disposable parts? Or were they committed and loyal people, just like us.

And guess what? Things changed. Professional respect across the two teams emerged. As people visited (every try to buy a round trip air ticket for a 'resource'?) back and forth, we began to learn names of our counterparts. Phone calls, instant messaging, and web cams became the preferred method of communicating.

More importantly, we built trust. My manager was on to something those years ago. She knew that when a person has a name, they are real.

Relationships versus Transactions
Once we began to see our partner as a collection of people, this next distinction sort of fell into place. You can't have a relationship with a resource. You go to an ATM and withdraw money from a machine, not from Bob. Once we began to know each other as people, we evolved to a new relationship. We became interested in career development on both sides. We deepened our relationships with their families during visits.

OK, you might be asking what this has to do with costs and productivity. And that, I assure you, is my point. Sure, you can get what you negotiate for in terms of transactions (do project X by March for Y dollars.) But our product isn't piece meal. It is a living, breathing product that evolves over time. I can't afford to have people coming on and off my project, all the while keeping the "resource count" level.

That's the punch line.

Our relationships are the bond that allows for continuity. We have wonderfully low turnover and deep experience with our offshore team. I fundamentally believe that is a result of the relationships among people from both sides. It's more than just a cool project on the resume. It about being on a world-class team with people you care about.

Collaboration versus Isolation
This too is a natural extension of the previous point. We don't distinguish between whether a person is here or there, with the exception of a few key customer facing positions. In other words, if a test lead is better situated there, then so be it.

We often have feature (scrum) teams comprised of people from both us and our partner. And because of the strong relationship, they work well together. Not only in a "feel good" sense, but in a hard core results delivered sense. People work hard for each other because they know each other. They have shared a meal together. They know about each other's families and celebrations. They have worked side by side together.

So when we need that push, we get much more than compliance because we are the customer. We get the energy, the passion, and the loyalty that is the difference in being able to deliver great software.

Ironically, these themes are exactly the way you should be treating your onshore team members already. Ultimately, it's about being able to look across your two organizations and see one team.

Why not?

Igor's post really got me thinking.

What are we really trying to achieve as leaders? Igor's notion of a "star team" is compelling. It is also rare in my experience. That isn't necessarily due to team talent, environment, or other factors. It ultimately comes down to me and my willingness to make space for the team to grow.

So here is an interesting "quiz" for you:

• Are you comfortable taking vacation and not staying connected to your team?
• If you couldn't present a topic to the E-staff, would you be comfortable with a team member presenting on your behalf?
• Do you let your managers have their own meetings without inviting you? And can you resist the urge to drop into their meetings to check in on things?
• Can you let your team execute a plan you don't agree with, knowing that they have the right goal in mind?

If not, why not? Take your time - think about this. Again, why not?

Now here is the kicker...

Now that you have an answer to "Why not?', ask yourself what you are doing to remove that barrier. The "Why not" is a barrier to your team member being successful. For example, imagine you said to yourself "Sally couldn't possibly brief the E-Staff. She gets too nervous in front of people." Sounds like Sally is doomed, right?

Wrong.

Her inability to brief the E-staff is as much your responsibility as it is hers. This is what I mean when I ask, "What are you doing to remove the barrier?" That is where people development comes in.

It's not about finding people's limitations. It's about removing them.

What is a manager for?

Eventually, managers are needed for one thing - to effectively use resources to achieve goals though implementing changes. Sounds rather trivial, however every word in this statement is essential.

Resources meant here are varied - administrative, financial, human, etc., - you name them. The point is that in our world all resources are limited and thus, effectiveness plays a key role in success. A person using resources effectively achieves better results than one who does not.

Goals always exist - even if they are not explicitly expressed and not presented in specific numbers. We all want something, and our investors/sponsors are not an exception. When hiring a manager they expect him to achieve something they want - even if the manager has to guess their wish.

When we have resources and defined goals, are we thus managers? I guess not if we do not have to change something to achieve results. I strongly believe that when there no changes then no need in manager. Coordinator who is controlling the established status quo is enough. However, I’ve seen only a few people in my life who did not want to change anything...

It took me some time of working in managerial positions to realize the points above and to "feel" what a manager is expected to do. I intentionally use a reference to feelings here since logically everything is simple and clear. There are plenty of books and business schools available where everybody can learn similar things. However, knowledge and logical understanding is not enough to apply professional skills. You must try and adjust the knowledge to yourself.

So, eventually I came to this point and realized that being a manager is very simple! All you need to do is to build a team that is able to work effectively to achieve goals by implementing changes that team defines itself. Cool, huh?

Since I'm a rather lazy person, I started to work on the team doing my job immediately! That was the beginning of a long journey during which I distinguished three types of teams:

"Team of Star"
This is a team almost fully controlled by a manager. As long as the manager is there, knows and controls all details, the team is effective. However, such a team is only as effective as the manager is.

"Stars Team"
This is a team of advanced people where each person works independently. However, team work assumes interdependency. Therefore, advanced people capable and preferring independence often struggle with each other. This decreases overall team efficiency. To be the most effective, the team requires a very strong leader capable of breaking barriers between individuals and directs their potential to the team success. The team is efficient as long as the manager constantly and consistently prevents personal interests from dominating team objectives.

"Star Team"
This is a team utilizing its potential and other resources in the most efficient way, with minimal involvement of the manager. This is any manager’s dream - a team capable of implementing any vision and overcoming any challenges by itself. Direct manager's involvement is only necessary in critical situations and to adjust direction the team is moving on.

Therefore, a good manager should:
- Build appropriate vision through intellect and imagination;
- Build a team capable of implementing a vision in the most efficient way;
- Monitor team progress and adjust direction as situations change.

This is not a complete list of manager's capabilities. In future posts, I will discuss other abilities, such as working with people, clients, investors, and financial information. Ultimately, a manager is only a manager when he directs other people. Almost everything may be delegated to a team besides the team building itself.

In the end, people development is the most important skill for anyone who wants to be recognized as a good manager.

Why Planning Matters

A few weeks ago, I wrote that I love Agile Development because it provides an opportunity to learn. Ultimately, my example led me to the point where the repetitive planning inherent in Agile Development allows my team to get better at it. I left off by stating "Since your customers don't buy plans, consider why this matters."

So why does it matter?

What do customers buy? Certainly, they buy products and services. But let's go a bit deeper. In the enterprise world, which I've been part of for twenty years, there is something intangible that goes into selling. There is something a C-level buyer wants.

Commitment.

At some point, you have to look your customer in the eye and commit to delivering what she needs. This was true many years ago when I was involved in non-stop mission critical systems, and it remains true today.

You can make a commitment and hope for the best. Alternatively, you can create a plan that demonstrates how you are actually going to achieve the commitment. This is the connection back to my earlier post. By having more "at-bats," you plan better and faster. You are able to have a realistic shot at collaborating with your customers on a real commitment - one that is negotiated based on mutual trust and respect.

Maturity

Over the past several months, I've noticed an alarming trend in the way I answer questions. When asked about a product feature or a particular nuance regarding a release schedule, I find myself responding with a shrug of the shoulders and a simple "I don't know. I'll have to ask my team."

This trend forced me to examine my role. As a manager and to a large degree, as a director, I had command of each issue, task, and aspect of a software release.

When our customer support team would urgently inquire "What is the status of issue ABC?", my immediate response would be "It's being coded today, tested tomorrow, and a patch is shipping to three customers Friday".

Those days are gone. What changed?

Have I lost mental ability? Have I risen to the infamous level of incompetency? Am I slipping?

I think I finally figured out the answer. I matured.

Laugh if you will, but I am 100% serious. You see, 15 months into this Vice President role, I am beginning to act like, well, a Vice President. I'm not talking about the Dilbert pointy haired boss stereotype. You know, the one who is essentially an idiot, unable to inspire or generally function as an adult. No - I'm talking about beginning to think holistically about the business. In other words, contributing to my company's financial health (not just budgets and headcount, but sales, revenue, and margin), culture (not just organization charts, but how we think about each ourselves, the broader company, our markets, and our customers), and operations (not just product development, but marketing, support, services, customers, and so on).

It's not about losing my mental capacity or becoming incompetent. It's about me letting go of details.

I simply can't know everything going on anymore. As my responsibilities grow, I can't be everywhere. We all try to stay in our comfort zones. When I was promoted to Vice President, I fell into the same trap I did when I became a first time manager years ago. I kept doing what I did before, and assumed that the "new" part of my job would settle down once I learned it.

I continued to attend meetings that I should have let my managers run without me. I continued hanging around developers and designers making tweaks to the product (when I should have worked with my team on my vision for the application).

By clinging to what I had done well in the past, I eventually started to hate being a Vice President. I subconsciously yearned for the comfort of knowing everything going on. Fortunately, somewhere along the way, I realized that I have a team to build software. My job is to build team identity, product vision, and grow my managers to eventually take my current job. Their job is to deliver "results".

This realization has given me a new found understanding of what being a Vice President means.

In a future post, I'm going to be joined by friend and colleague Igor Vershynin. Igor and I will further explore our thoughts on what it means to be a senior leader. For now, please take a moment to share your experiences regarding when you first realized you had to let go of details. I am eager to find out if I'm indeed "normal" or "crazy".