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".

Why do you want to be a manager?

Recently, a friend and I discussed an opportunity he has to become a first time manager. As we spoke, I relayed some conversations I've had with employees who have wanted to become managers.

Typically, employees approach me with something along the lines of "What do I need to do to become a manager?" I suspect they expect me to enumerate a series of skills or development needs. Perhaps a course or two, and presto - they are now manager-ready. This is a reasonable expectation, since rating systems almost always focus on the skills required to do a job, get promoted, etc.

Management, however, is not primarily about skills (although skills matter). It's about motivation. I mean, what is the motivation behind someone wanting to become a manager. The question isn't about what, it is about why.

And that is precisely the first question I pose: "Why do you want to be a manager?"

Believe it or not, I can usually tell within a matter of seconds if the person will ultimately make a great manager. Let's start with a few responses that tell me the person isn't ready to manage:

• I want to have greater influence
• It seems like the next step in my growth
• I want to be able to control (insert any number of things here)
• I think I'm ready to manage others
• I'm very good at what I do, and think I can direct others to be as good
  

On the surface, these are reasonable responses. That is, if being a manager is all about the manager. But it's not. Managing is about the people being managed, not the manager.

Read that last sentence again. It's not about the manager. Most of the time, people possess a very "me" centered approach to management. That isn't going to work in my organization.

So, what types of responses indicate that someone is ready to manage? Here are examples:

• I love coaching
• I want to help create an environment where people can achieve more than they can without my guidance
• I want to help people grow and be challenged
• I love helping people succeed

This set of responses is focused on service to others. That is what great managers do. The first set of answers are given by people destined to remain managers. The second set of answers are given by your next generation of leaders.

Is there no hope for the first set of folks? Of course there is hope. I suggest you send them home with a simple assignment: Have them write down the reasons why they want to become a manager. Don't set a time limit - leave it to them. In some cases, they will never return. That tells you everything you need to know about them.

Others will report that they changed their minds. These are people you might be able to coach. Ask them what changed their mind. If they spent time reviewing their reasons, they have demonstrated the ability for self-reflection. You may have to tease it out, but you may be able to guide this person towards a service oriented approach to management. In some cases, people understand this approach, and realize that they would rather stay self-focused. At a minimum, you now know that you have someone who is willing to look inside themselves. They may not be ready today, but keep your eye on them for the future.

The last set of folks will return with their list. This is where your management ability matters. These are the folks who truly want to grow (or they would have not taken time to complete their homework). Usually, you will be able to show them a bias towards self, and reinforce the value of service orientated management.

I'm not saying that these folks are slam dunks.

Some will remain "me" centered. It is up to you to help them understand that management is a service to others. If they can't or won't understand this view, then you have to decide how much damage to the team you are willing to inflict. You also might want to look inside and assess what style you are projecting. They are getting their perception of management somewhere.

When you have an employee that values helping others, you have a potentially great manager. This is a person to nurture. Reinforce the values through your own actions with her or him. With the correct orientation to management, now you can begin a discussion about the skills that must be developed or built on.

These folks are rare. So when you find one, cherish them.

Agile: It's about learning

Driving home this evening, I thought about the reasons I'm attracted to Agile Software Development. Increased transparency and intimate customer involvement are two that come to mind. However, what struck me most is that Agile gives me a chance to do something I love:

Learn.

Quite frankly, spending months developing a set of requirements and more months developing, only to learn that we didn't solve the business problem (but met all the documented requirements) annoys me.

This annoyance has led me through the years to drive for small, reversible decisions. There is a sense of progress. Of accomplishment. Of creating results. Of learning.

Agile allows me to learn frequently. Think about your school days. Which were better learning experiences? The classes where you had one final at the end, or the ones where you had a weekly series of small tests? I never appreciated the instructors who adopted the weekly testing approach. I was "forced" to make steady progress, week after week. I had to master a topic in order to build a foundation for future learning. (Perhaps they should be called course scrum masters instead of instructors?)

Fast forward to executive leadership. What does learning have to do with anything? It's about hitting dates and generating sales, right? Of course. But how do you achieve these goals? By learning what works and what doesn't. Agile allows you and your teams to learn.

You learn what practices are effective and aren't effective.

You learn what your customers like and what they don't like.

It is this constant learning that enables the achievement of your goals. Would you rather learn sooner or learn later that your software isn't going to solve your customer's business needs? Learning sooner (in product demonstrations or sprint planning meetings) gives you time to think your way out of a problem instead of frantically re-work a poor solution.

There is an interesting advantage to be gained by learning. Level of experience is a significant factor in team performance. Using the traditional waterfall approach to development, you perform one planning exercise, and perhaps a few more along the way at the infamous "checkpoint" or "gate" reviews. Your competitor using Agile practices plans every two weeks. After a 6 month project, your competitor experienced twelve planning exercises. That is 3,4, or more times the number your team experienced.

Which team do you think will be more effective planning? Since your customers don't buy plans, consider why this matters.

To be continued...

Make a decision, would ya'?

Senior leaders are paid to make decisions. So, why does it seem like so many prefer not to do so?

Studies are commissioned, "tiger" teams are formed, data are collected. But the decision to do or to not do something is buried in steering committees, integrated program teams, or follow up meetings with a sub-team.

Meanwhile, valuable time and experience are lost.

Watts Humphrey, originator the Software Engineering Institute's Capability Maturity Model and a significant contributor to the concept that software development is an engineering discipline, once remarked to me that one can learn a lot more from doing than by studying.

Of the many lessons Watts' provided to me, this one found itself into my essence as an executive. Don't get me wrong. I'm not walking around all day randomly making critical decisions without thoughtful input and deliberation. But I do not wait forever, hoping that if I just have enough more information or the time is right, then I'll decide.

The key is to make decisions at the latest possible moment (Agile folks should recognize this). Another key is to leave yourself an out if the decision needs to be corrected. Let's be real here - most decisions you make are not so critical that they have to be 100% correct. In reality, you can never know if you are 100% correct anyway. Your goal is to be correct enough, learn from the execution of the decision, then make corrections.

This is not new. Nancy Wang and I wrote about this many years ago in Software Testing and Quality Assurance (Juggling Concurrent Releases). The concept of failing fast, learning from doing, and responding quickly is at the core of Agile Development, as well. With the emerging acceptance of Agile Development principles, perhaps some of this thinking will make its way into the execute suite.

Since Nancy and I wrote that article, I've had many opportunties to make a decision with less than ideal information.

During that time, I've learned another lesson : Build your team to be adaptable. You see, most teams expect their leaders to make infallable decisions.

Try these approaches with your team:

• Let them know that you don't have all the information you would like to make the decision. This is important because someone on your team actually may have more information and prevent you from doing something bad. It also helps perpare them for the fact that down the road, the decision may need to be revisited.
• Be very clear with your team that you have very intention in changing course if the consequences of the decision require it. (HINT: The consequences will). I often set a specific time for when we will revisit the decision. This has the effect of preventing the team from getting too wrapped up with making the decision "stick" and allows the team to focus on the business problem we are trying to address.
• Demonstrate concrete changes you make in response to lessons you learn once the decision is being put into place. I believe this is an action that gains tremendous credibility. It shows that you are willing to take a chance and make adjustments when presented with new information.
• Allow people on your team to fail. Ok, maytbe not fail miserably, but at least them understand that it is OK to take a course of action that doesn't turn out as hoped. The be there for them to help them make the adjustments needed to get back on track.

Perhaps most importantly, these steps begin to build your next generation of leaders. They provide a model of how to navigate uncertain times. Nobody expects a pilot to take off and blindly stay on the planned course, regardless of what reality presents.

We shouldn't act like our decisions are any more accurate and stable than this.

Why do we need another blog?

For several months (OK, years), I've read and observed quite a bit regarding software development, management, etc. Much of what is written is spot-on accurate. I noticed, however, that much of what is written seems to be written by consultants (which is fine - more on this in future posts) or by folks "in the trenches".

As I move from post to post, book to book, and article to article, I have a growing sense that there is something missing. What I find missing is representation from executive leaders.

That is - where are the Vice President and Director level voices out there?

• Are we too busy? (Doubt it)
• Do we not have anything to say? (Doubt that too - just ask my team)
• Do we not care? (I hope we do)

Ultimately, I'm not really sure. Maybe it's just that I am reading/listening/viewing the wrong material.

So this blog is my contribution to the literature - from the view of a software exec.

A few things:

• These writings are my personal opinions
• Any real life stories are going to be greatly changed to minimize or eliminate harm to companies and people I've worked with and for.
• I'll be reluctant to even identify people and places for things I believe a genuinely good, in order to respect folks that may have contributed and have been inadvertently omitted.

If you got this far, thanks for reading.