It's annual review time at Microsoft. We differentiate pay between high, average, and low performers in the same roles. Thus, it's time to calibrate those who've made the most of their opportunities in the past year with those in the mainstream of solid engineers and those who haven't quite kept pace with peers.

As a manager, this is also time for the whiners and the clueless to lament to me about their lack of opportunities to grow and demonstrate their true worth. As if managers hoard those opportunities, giving them out only in moments of weakness or pity. As if those opportunities are rare—hidden treasures available only to the select few with guile and charm. No, you fools, opportunities aren't rare and they aren't hidden. Opportunities are big, loud, and aromatic. They stand right in front of you in gorilla suits beating their chests all day long.

Yet many smart engineers don't notice. Huge, noisy, smelly gorillas in their face day after day, and they don't notice. Sometimes their manager hands them the opportunity, invites them to a meeting, or puts them on a project, and still the engineers, capable engineers, ignore it. They hand the opportunity to someone else. They give it only passing attention. They leave it sitting in a corner till it finally devolves from inattention.

Why?!? Why don't engineers notice these opportunities? Why do they toss them aside, only to complain in July about the lack of opportunity? Towering, raucous, pungent opportunities in gorilla suits, every day, ignored. Why?

I'm blind, man

I used to think people ignored these opportunities because they were lazy or apathetic. I still believe apathy is a real problem, but I no longer consider laziness a key cause. Instead, I believe people miss opportunities due to a concept called, "inattentional blindness." Basically, engineers don't notice flagrant opportunities because their minds are focused elsewhere and aren't paying attention.

There's a telling video you might have seen that asks viewers to count the number of times a basketball is passed amongst a group of people. During the video, a person in a gorilla suit walks into the middle of the group, faces the camera, beats its chest with gusto, and then walks out of frame. At the end of the video, viewers are asked if they saw the gorilla. Not only do people miss it (including me the first time), some people insist the gorilla must have been camouflaged. Then they watch the video again and notice the big gorilla in the middle of the frame, making a mockery of their perception.

It is all around us

Engineers don't notice the opportunities in gorilla suits because they are focused on their day-to-day duties of counting basketball passes. They are too distracted to notice. However, perhaps you are one of those who think the opportunities are camouflaged. Allow me to remove your blinders and list the opportunities that pass you by every day:

§  Killer features—sure, you know these exist. You might even know what some of them are. But how do you get the opportunity work on them? I'll bet they've got designs and code that need reviewing, usability, unit, and automated tests that need writing or reviewing, and bugs that need fixing. I'll bet the developer working on them is out from time to time and needs a backup. But, of course, you're too busy.

§  Customer advocacy and business intelligence—you think you know the customer and business, but you don't. That's the opportunity. The more direct engagement you have with customers (product support, usability, feedback data), and the better you understand the business (VP talks, business plan, business model and metrics), the better you'll know what the killer features are and what the critical features are. But that's someone else's job, right?

§  Critical features—you think these dull features like setup, patching, privacy, compatibility, accessibility, and manageability are for losers. Yeah, they can be when a loser implements them. If you are knowledgeable about the customer and the business, you'll know how to go the extra mile to turn the mundane into the marvelous. But why bother when there are cooler things to implement?

§  Task forces, committees, virtual team projects—you could safely argue that these activities boil up straight from Hades. However, they only arise when there is a problem that someone above your pay grade wants solved. Because everyone hates these dysfunctional efforts, you've got an opportunity to actually lead the effort toward a real solution. Or you could let someone else do it.

§  Process and tool improvements—you probably love these, but no one will listen to your ideas. Stop making improvements your idea. Stop making it about you. Start looking at other people's processes and tools. Start thinking about how you can embrace and extend them. Start thinking about being better together as a team and a company (see "Controlling your boss for fun and profit"). Or you could just do your own thing.

§  Problems in general—you can hardly make it through five minutes without spotting one problem or another. Every problem is an opportunity. That's not just a cute phrase, it's true. Yeah, you'll never fix them all, but surely there are some worth pursuing. Or you could live with the status quo.

Poor pitiful me

With all these opportunities being there day after day, I'm stunned when engineers complain about the lack of chances to grow and prove their merit. Yes, you are too busy. Yes, you've got enough for your own job. Yes, there are cool ideas to work on that aren't what customers or the business thinks they need. Yes, someone else can run the meeting, write the white paper, or drive the change. Yes, doing your own thing is straightforward because no one else gets in the way. Yes, accepting the status quo avoids hassle. And yes, ignoring opportunities and being mediocre is always the easier option.

"But I don't have time to take advantage of these opportunities," whine the witless. Are you kidding me??!?!? As I described in my "Time enough" column (chapter 8), you never have enough time to do anything. Each day, each minute, you choose tasks from the unlimited list you have. The key is to prioritize, cutting out the interruptions and time-sucking activities that aren't "must do" in order to focus on the activities that make a difference for our business, our customers, and in turn, your career.

To cowering clueless who say, "But there's nothing to cut; everything I have is ‘must do'!" I say, "So you always accomplish everything you need to do? Really? You must be full of something to say that." Look, if you aren't accomplishing everything you must be making choices. If you are making choices you simply need to adjust those choices. That's what life is. Successful people make adjustments to focus a portion of their time on new opportunities.

This concept of creating time by choosing your obligations goes by a familiar phrase, "under commit and over deliver." Yet most neophytes over commit trying impress management and their peers. At the end of the day, these neophytes under deliver, lose out on opportunities, and get ranked below those who met their obligations and went beyond.

I took the one less traveled by

I'm not saying it's easy. I'm saying it's necessary. No one will serve you success on a platter. Not your parents. Not your boss. Nobody. You've got to decide to take advantage of the myriad of opportunities that come your way every day.

You don't need to tackle all of them, just a few over the course of a year. If you are put on a panel you care about, actively participate. Become one of those people who actually contributes. I don't care if you are busy. Make time. That doesn't mean working longer or harder. It means dropping less important activities that mean more in the moment, but mean less in the long run.

Stop and consider the people you admire. It's not their number of accomplishments; it's the thoughtfulness and impact of their accomplishments. Give consideration to your work choices, be aware of opportunities, create space to take advantage of them, and you can become the person others admire.

I heard a remark the other day that seemed stupid on the surface, but when I really thought about it I realized it was completely idiotic and irresponsible. The remark was that it's better to crash and let Watson report the error than it is to catch the exception and try to correct it.

From a technical perspective, there is some sense to the strategy of allowing the crash to complete and get reported. It's like the logic behind asserts—the moment you realize you are in a bad state, capture that state and abort. That way, when you are debugging later you'll be as close as possible to the cause of the problem. If you don't abort immediately, it's often impossible to reconstruct the state and identify what went wrong. That's why asserts are good, right? So, crashing is sensible, right?

Oh please. Asserts and crashing are so 1990s. If you’re still thinking that way, you need shut off your walkman and join the twenty-first century, unless you write software just for yourself and your old school buddies. These days, software isn't expected to run only until its programmer got tired. It's expected to run and keep running. Period.

Struggle against reality

Hold on, an old school developer, I'll call him "Axl Rose," wants to inject "reality" into the discussion. "Look," says Axl, "you can't just wish bad machine states away, and you can't fix every bug no matter how late you party." You're right, Axl. While we need to design, test, and code our products and services as error-free as possible, there will always be bugs. What we in the new century have realized is that for many issues it's not the bugs that are the problem—it's how we respond to those bugs that matters.

Axl Rose responds to bugs by capturing data about them in hopes of identifying the cause. Enlightened engineers respond to bugs by expecting them, logging them, and making their software resilient to failure. Sure, we still want to fix the bugs we log because failures are costly to performance and impact the customer experience. However, cars, TVs, and networking fail all the time. They are just designed to be resilient to those failures so that crashes are rare.

Perhaps be less assertive

"But asserts are still good, right? Everyone says so," says Axl. No. Asserts as they are implemented today are evil. They are evil. I mean it, evil. They cause programs to be fragile instead of resilient. They perpetuate the mindset that you respond to failure by giving up instead of rolling back and starting over.

We need to change how asserts act. Instead of aborting, asserts should log problems and then trigger a recovery. I repeat—keep the asserts, but change how they act. You still want asserts to detect failures early. What's even more important is how you respond to those failures, including the ones that slip through.

If at first you don't succeed

So, how do you respond appropriately to failure? Well, how do you? I mean, in real life, how do you respond to failure? Do you give up and walk away? I doubt you made it through the Microsoft interview process if that was your attitude.

When you experience failure, you start over and try again. Ideally, you take notes about what went wrong and analyze them to improve, but usually that comes later. In the moment, you simply dust yourself off and give it another go.

For Web services, the approach is called the five Rs—retry, restart, reboot, reimage, and replace. Let’s break them down:

§  Retry. First off, you try the failed action again. Often something just goofed the first time and it will work the second time.

§  Restart. If retrying doesn't work, often restarting does. For services, this often means rolling back and restarting a transaction; or unloading a DLL, reloading it, and performing the action again the way Internet Information Server (IIS) does.

§  Reboot. If restarting doesn't work, do what a user would do, and reboot the machine.

§  Reimage. If rebooting doesn't work, do what support would do, and reimage the application or entire box.

§  Replace. If reimaging doesn't do the trick, it's time to get a new device.

Welcome to the jungle

Much of our software doesn't run as a service in a datacenter, and contrary to what Google might have you believe, customers don't want all software to depend on a service. For client software, the five Rs might seem irrelevant to you. Ah, to be so naïve and dismissive.

The five Rs apply just as well to client and application software on a PC and a phone. The key most engineers miss is defining the action, the scope of what gets retried or restarted.

On the Web it's easier to identify—the action is usually a transaction to a database or a GET or POST to a page. For client and application software, you need to think more about what action the user or subsystem is attempting.

Well-designed software will have custom error handling at the end of each action, just like I talked about in my column "A tragedy of error handling" (which appears in Chapter 6 of my book). Having custom error handling after actions makes applying the five Rs much simpler.

Unfortunately, lots of throwback engineers, like Axl Rose, use a Routine for Error Central Handling (RECH) instead, as I described in the same column. If your code looks like Axl's, you've got some work to do to separate out the actions, but it's worth it if a few actions harbor most crashes and you aren't able to fix the root cause.

Just like starting over

Let's check out some examples of applying the five Rs to client and application software:

§  Retry. PCs and devices are a bit more predictable than Web services, so failed operations will likely fail again. However, retrying works for issues that fail sporadically, like network connectivity or data contention. So, when saving a file, rather than blocking for what seems like an eternity and then failing, try blocking for a short timeout and then try again—a better result for the same time or less. Doing so asynchronously unblocks the user entirely and is even better, but it might be tricky.

Remember this one, "The microprocessor changes everything!" No, it didn't. Yes, it had a big impact, but people still fretted about the same problems and tried to accomplish the same things. They just created problems and accomplished things more efficiently. How about, "The Internet changes everything!" No, it didn't. Yes, it had a big impact, but people just got that much better at creating the same problems and accomplishing the same things. Now we have, "Software plus services changes everything!" Oh, spare me.

You might claim, "I. M., you're wrong about this one. Microsoft did change dramatically with each of those shifts." We changed quite a bit, but not dramatically. If we had changed dramatically, we would have cut or replaced the majority of the workforce (talk to your friends at other companies). Instead, we augmented our tools and our workforce to take advantage of each new opportunity.

Look, I don't want to downplay the importance of any of these shifts. They improved people's lives and made the world smaller and more accessible. They grew new businesses, improved quality, and increased productivity. That's fantastic. But don't go around saying a new technology changes everything, because the things that count don't change: people, their problems, and what they want to accomplish. Just ask those companies who focused on the technology instead of the customer. Oh wait, you can't. They're bankrupt.

I'm fuzzy on the whole good/bad thing

This is why nothing makes me more miffed than engineers who say, "What is software plus services?" Or much worse, "It's a new world; we've got to create services!" Hearing that makes my lunch call for a reappearance. Stop focusing on the technology you fools! It's not about the technology. It never has been. It's about the customer and what they want to do.

Hold on, I hear an Ozzite calling, "But Ray says it's all about services and the cloud." Listen, when Ray Ozzie talks about services and the cloud, he talks about things people want to do and how services and the cloud can help. The starting place is always the same: customers and their goals.

"Oh, so we focus on how customers want to use our software with services, right?" No! Get this straight! Customers don't want to use our software for the sake of using our software, in case your family and friends haven't made that clear. Customers want to accomplish goals, like writing a term paper, sharing pictures of their kids, or fulfilling a purchase order. To the extent that services help customers achieve their goals, we want to integrate and provide those services.

Perhaps some examples would help. Let's talk more about that term paper, the kids' pictures, and that purchase order.

On good terms

Writing a term paper is a common enough goal for students that businesses are built around supplying term papers for a fee. If we want to help students write term papers, the first step is imagining what a wonderful term paper experience would be like. We've all had horrible term paper experiences, so this shouldn't be too hard.

Okay, so the instructor assigns students to write a paper about preparations for the Beijing Olympics in 2008. Stu, our student, opens a word processor and starts jotting down a rough outline. "Let's see," says Stu, "I'll start by talking about the Olympic Games, then the city selection process, then perhaps a history of Beijing, followed by some details of Beijing's bid, followed by their preparation plans, and closing with the current status." Nice outline, Stu.

Stu hits the research button and phrases in the outline get highlighted. Stu clicks on Olympic Games and a search result frame pops up with info about the games. Stu scrolls through previews, selects the ones he wants, and the text is inserted directly into his document. He repeats the process for city selection, Beijing, and the other sections. In each case, the search is narrowed by the context of the previous searches, knowing Stu cares about the Olympic Games.

Next, Stu edits the text to make it sound more like he wrote it and actually understood it. The grammar checker, in addition to highlighting grammar and spelling mistakes, also highlights sections that are too close to the source text to be considered original. When the text is clean of errors and outright plagiarism, Stu sends it to his instructor.

I wish my term papers could have been that easy. So, what pieces of this scenario does Microsoft have already? We've got a word processor; we've got Internet search; we've got a grammar and spelling checker; and we've got e-mail. What we need is a plagiarism checker and a client user interface for Word to talk to Live Search and download parameterized search results. That shouldn't be too hard. Viola, software plus services that is actually valuable.

Sure, it would be even more valuable if Stu could store his term paper in the cloud as he worked on it from multiple devices, including his car and phone, but you can't start there because the cloud and phone are cool. You start with Stu and what Stu wants to do.

Preserve your memories

We all know the sharing-pictures scenario. You plug in your camera, upload your pictures, and click the button that should be there to share pictures. Okay, on Windows XP there's a link to Publish the selected items to the Web and on Windows Vista there's a Share button, but it doesn't share across the Web. I get why this scenario is hard when it comes to open markets and working with partners. That's a good reason, but not a good excuse.

Even in the Windows XP case, assuming the customer can find and understand the Publish the selected items to the Web link, have you tried it? It focuses on giving Windows XP the information it needs to complete the operation, not on the customer trying to share their pictures. This is a case where we've got just about every component we need to deliver a useful software plus services scenario, but we've designed the experience to serve our software instead of serving the customer.

Self-fulfilling prophesy

Most of us shop online for at least some of our needs these days. While it's tempting to talk about the end-customer buying experience, let's talk instead about the order fulfillment experience of the online retailer.

When a customer submits their order, the retailer must:

§  Receive validation of the credit card from the bank.

§  Bring up the confirmation page and e-mail a copy to the customer.

§  Check inventory for the product.

o   If the product is in inventory, send the instructions to the warehouse to ship the product to the customer, and update the inventory.

o   If the product isn't in inventory, order the product from the supplier with instructions around labeling and routing the product to the customer, then track and record the transaction for data mining future buying.

§  E-mail the shipping information to the customer.

All this seems simple enough. Once again, we've got most of the components—Web services for the transactions, ASP.NET for the confirmation page, Exchange for the e-mail, SQL Server for the inventory, and Dynamics for the all the business logic. The key is, "Does this scenario come together as easily as it sounds?" When our small business customers try it, do they have to fight our software the whole way?

Remember, customers believe that all Microsoft software comes from one place, and that Bill Gates writes all the code. They don't understand why one application works differently than another. They can't afford to be experts at setting up each different piece. Making software plus services work isn't about clever new code. It's about focusing on what the customer is trying to accomplish and making that easy as it crosses boundaries.

We can get together

Okay, you're right; there are aspects of software plus services that involve change. The service piece is not a static image on a DVD. It's a living and breathing entity in a datacenter whose life only begins the day you ship. When you patch, upgrade, or revert a service, it all has to happen while the service is still live and functioning. Debugging is insanely difficult, so you need to instrument your service to diagnose problems across machines from anywhere in the world.

All this implies designing your service, and the software that uses it, from the ground up to be resilient, maintainable, and manageable. You don't get to walk away from services after the ship party; the party is just beginning, as is your commitment to keep improving your service every day.

However, none of that matters if we get seduced by the technology and features, and lose sight of the customer. The customer doesn't want software plus services. The customer wants to achieve goals, and well-designed software plus services can help.

The real trick to software plus services is working well across product and group boundaries to make end-to-end customer scenarios work the way the customer expects, instead of the way our company is organized. Learn to do that well, and you will change everything.

It's the political season in the United States, making "change" a happy word around here. Politicians fight over who better represents change. They proclaim themselves to be agents of change. Hysterical admirers jump up and down waving "Change" signs. Change. Change. Change. As if change is desirable. As if change makes people happy. Nothing could be further from the truth. Are these people idiots?

At best it is temporary insanity. The concept of change is seductive, and if you want a new leader, then change is what you seek. But if people really wanted change, it would already be happening. Stasis is the basis for nice happy faces. The fact is that people hate change, as my friend, U. R. Rong, pointed out in "Stunted growth: Change phobia."

Yes, change is inevitable, and embracing change is the right thing to do, but change rattles people to their core. It's stunning the degree to which people will hold onto old ideas and familiar practices that make their lives miserable rather than change to improve their lot. So, good luck trying to fix things at work, at home, or in your community. People won't like it.

A change would do you good

But what if a change is what you need? After all, keeping things stable is nice, but it doesn't move you forward. To have an impact on your life, your team, and the world, you need to shake things up a bit. How do you get past people's cavernous craving for constancy?

Glad you asked. It's not easy, but here's a five-step program:

§  Make the case

§  Prime the pump

§  Test the waters

§  Jump on in

§  Keep it real

While most people do make the case, after that they usually jump on in, skipping steps two and three of the program. That's foolish. Skipping steps greatly increases your risk of failure. And don't give me that macho garbage about taking chances. Change is time consuming and costly. Rolling the dice because you're too impatient or stupid to know better is no sign of courage. If you're putting in the effort, do it right.

Make your opening statement

Before you can even propose a change, you've got to make your case to your peers and management. I talk about doing this in detail in my column, "Controlling your boss for fun and profit." Read it and get sponsorship for your idea so that your boss and peers won't work against you, they'll work with you.

If you fail to get sponsorship the first time, try another sponsorship route or quit while you're ahead. If you move forward without sponsorship, you'll get crushed. Making believe that it will all be fine and that everyone else is delusional is, in fact, delusional. You're not one of those geniuses that no one believed in. Those geniuses kept trying till someone did believe. If you proceed without backing, you're just an ignorant sap whose sob stories will fall on deaf ears.

One thing I forgot to mention in "Controlling your boss for fun and profit" is that you should ensure sponsorship agreement on the measures, metrics, and targets for success. You can't get credit for reaching your goals without agreement first on what to achieve. Without that transparency, you can never claim victory. No one will notice. You can learn more about the right metrics to use in my column, "How do you measure yourself?"

You are ready then?

Now that you have a plan of action, it's time to move forward, right? Wrong! Listen, this is important. Change is a painful process, literally. Change is closely tied to two volatile emotions—anxiety and grief.

Change is tied to anxiety because it is filled with uncertainty. Think about the last time you changed jobs. Were you concerned that the new job would be alright? That you'd be successful on the new team? That you'd have fun and enjoy it? Did you worry about what you'd do if it didn't work out? People tend to be uptight and on-edge during change; even humorless. Jumping right in and assuming that everyone will love it is just asinine.

Change is tied to grief because after the change the old ways are gone. The new ways are unfamiliar and uncomfortable. People initially long for the old ways. They miss them. It's grief, and you should know the five stages of grief:

§  Denial

§  Anger

§  Bargaining

§  Depression

§  Acceptance

Jumping right in before people pass the anger stage is ill-advised. The bargaining and depression stages aren't much better. How do you avoid this debacle? By priming the pump.

I’m in my prime

Priming is exposing people to a situation before it actually occurs. Priming helps people perform better in new situations and feel more comfortable. If you've ever been to a rehearsal or practiced a speech, you've been primed.

Priming change means telling everyone what to expect in advance. Talking about what it will be like, in detail, before it happens. How long before? Long enough to get at least past the bargaining stage. Depending on the scope of the change, this could be a few days to a couple of months.

During the priming you'll want to talk about the change several times, perhaps a couple of times in e-mail and a few times in person. You'll talk about why the change is important in terms that matter to them. You'll talk about the inevitable difficulty of the transition, but lay out the clear path to the desired result.

By introducing the change in advance, you get people moving through their grief and anxiety before they actually are doing anything different. You also get to hear their objections (anger) and suggested alterations (bargaining) before the change goes into effect. That gives you time to make adjustments, and gives people a sense of control and ownership, all of which smooth out the transition. Brilliant!

They could use a good pilot like you

Of course, you'll never figure out all the trouble spots and hiccups with the change by just talking about it. You've got to try it out. How do you try it out and fix issues before everyone gives up on the idea? By testing the waters with pilots.

Pilots are trial runs of the change. You get together a small group or two to work the new way. Their special mission is to scout the future on behalf of the team. Ideally, these small groups are made of early adopters—flexible people who enjoy trying new things. You also want a couple of open-minded skeptics on the pilot teams—they'll find key issues and can become your biggest supporters.

Kick off the pilots shortly after you announce the change, while you’re still priming the rest of the team. As the pilots discover issues and blaze the trail, the rest of the team has time to get through denial, anger, and bargaining. Remember, like all good scouting expeditions, pilots should document their discoveries so others can benefit. The pilots have three other advantages:

§  Experience. When the pilots have completed their initial work, your group will have a ready-made collection of experts on the change. Now you don't need to field all the questions and it won't seem like only your idea.

§  Ownership. In fact, as people on the pilot teams work past problems and have success, they feel more and more ownership of the change. It becomes their idea as much as yours, which is just what you want. Remember to be generous with your support and praise; it will serve you, your ideas, and your team the best.

§  Validation. By the time the larger team hits the depression stage, the pilots will return with stories of success. These quick wins are essential to get your group over their depression and into accepting the change.

Ready to make the leap?

When the bulk of the team has stopped raising objections and suggesting alternatives, and when the pilots have come back with quick wins, you're ready to jump on in. Because of your preparation, this shouldn't be a big deal. Most of the objections and problems will already be resolved. You'll also have the pilot teams there as guides.

However, don't expect everything to go perfectly. There will be more questions and issues that arise due to the increased scale, particularly in the first few weeks. New configurations and situations will crop up as more people take on the change. Let your team know to expect these problems, and that you and others are available to help. Again, broad and regular communication both in person and through e-mail, is critical.

Gone but not forgotten

Once you've rolled out the change and people are starting to see the benefits, you might be tempted to celebrate. That would be premature and shortsighted. When you first got sponsorship, it hinged on achieving certain goals. Your ability to claim victory depends on reaching those goals. In fact, the survival of your change depends upon it.

How can this be? After all, you made the case, primed the pump, tested the waters, and successfully jumped on in. People seem to be getting used to working the new way and may even be enjoying their new-found success. Why would anyone want to switch back? Ah, but you forgot that the sponsors giveth and they taketh away. You must keep it real.

By "keep it real" I mean keep the value of making the change real to your sponsors. The moment they forget the impact of your change is the moment they take it for granted and allow someone new to reverse it. I'll bet you know of examples at Microsoft and elsewhere.

This is why defining and tracking measures, metrics, and targets is so very important. The team and your sponsors can see the improvement over time. It never gets lost. Of course, when you eventually hit or even exceed your targets, you, your team, and your sponsors can celebrate the victory together.

There is nothing permanent except change

Change is a part of life. The people who control and manage it are the people who succeed. It's not easy, but then again, it's not that hard either. Anyone can do it. You can do it. Doing it well will grow you and your team. Prepare well, communicate well, and make your progress transparent. Before you know it, a change really will do you good.

If you are a software geek, like me, being the product support technician for your friends and family comes with the territory. While it's painful to watch your family struggle with software, particularly if you helped write it, at least you can tell them, "Back off, I'm a computer scientist," and repair whatever is wrong. Sure, you'll cringe as you undo their failed "fixes," but in time you'll set things straight. That is, if you live nearby.

If your mom lives a thousand miles away, the call might sound more like this:

Mom: Honey, they changed my password and now my e-mail doesn't work.

Me: Okay, log onto your computer and open Outlook.

Mom: Using what password?

Me: Use whatever password you normally use.

Mom: Not the new e-mail one, just my old one.

Me: Yes. Then open Outlook.

Mom: Where do I type in the password?

Me: On the main screen where you click on your name and then type a password.

Mom: What main screen?

Me: Wait, can you just open Outlook right now?

Mom: Yes, I've got it open, but you told me to log on.

[Another hour like this moving through menus, dialog boxes, and buttons…]

This experience is far better if you can get a tool like Remote Assistance to work, but getting that up and running behind firewalls and routers can be equally entertaining. What should be a five-minute fix becomes an hour of acute aggravation. This order of magnitude multiplier for time and trouble comes into play any time you work across time and distance, which brings us to the topic of distributed development.

Doesn't anybody stay in one place anymore?

It's becoming far more common to run development across global locations for the same project. While the added diversity and talent should be a huge advantage, the results are often frustration, delays, and disconnects in quality and functionality. Why? It's due to the big, bad Bs—bandwidth, boundaries, and being there.

There's insufficient bandwidth for clear communication and fast network access to central services. The boundaries between project work at the different locations are poorly defined causing additional communication, conflicts, calamities, and clean-up. And because the different teams are separated, the one-on-ones, drop-ins, hallway conversations, and other daily human interactions you get from being there don't occur.

With all this trouble you might wonder why we bother with distributed development. No, you fool, it's not the money. Engineering salaries and costs are converging for many roles in China and India, and distributed development adds overhead. The real reasons for distributed development stem from the talent and the markets. The computer science talent pool in Brazil, Russia, India, and China is growing at nearly 20% per year and will have 1.5 times the number of software engineers in all of the United States by 2010. They can't all move to Redmond, and we wouldn't want them to because their home markets are critical to our success.

So if you're running a team, you'd better learn how to deal with the big, bad Bs. Let's break them down.

I get so tired when I have to explain

The first big, bad B is bandwidth—bandwidth between people and between computers.

Clear communication between people and teams is critical to success, as I've said many times before. The amount of information that is communicated between two people in the same room far exceeds that between people over video teleconference (VTC), which in turn exceeds Live Meeting, which exceeds the telephone (as shown in the exchange with my mother), which exceeds IM, which exceeds e-mail. In other words, e-mail is incredibly lame as a communication vehicle, so naturally it's the most popular.

Actually, people use e-mail because it's convenient, asynchronous, and works across time zones. Unfortunately, because e-mail has such little bandwidth, the communication is poor and often several round trips are needed to gain comprehension and answers. Due to time zone differences, a round trip often takes a day; thus e-mail communication proceeds at a glacial pace. Bandwidth between computers can also be quite slow, which means quick source control, file, or database operations in Redmond may take hours overseas.

How do you beat the big, bad bandwidth issue? There are only two ways—increase the bandwidth or cut down on the necessary communication.

§  You can increase the bandwidth by using higher bandwidth communication tools, like VTC and Live Meeting. These work even over low network bandwidth lines. However, the tools are synchronous, so you must reserve overlapping work time for communication with distributed team members. That means if you're in Redmond and other team members are in China, you should reserve 4 – 5 pm Pacific Time everyday for scheduled and impromptu meetings with your peers in China.

§  You can cut down on necessary communication by crafting far more careful e-mails. Mitigate questions and confusion by providing added information and answering common questions in advance. It will take you a bit longer to write e-mail this way, but it won't take you days, which is how long the communication will take otherwise.

§  You can cut out the need for a whole class of e-mails and phone calls by keeping a SharePoint wiki with project information. Fill it with how-to topics, discussion archives, checklists, documents, and project mail, schedule, and status. Any time a new team member arrives at any location, assign them to update the site with improved instructions or missing documentation.

§  You can also cut down on necessary communication by creating clear project boundaries between the work that is happening at different locations. Isolate local communication, including caching of source control and databases. Then you need cross-group communication only when people or information cross boundaries. That brings me to the next big, bad B.

Doesn't help to know that you're just time away

The second big, bad B is boundaries—boundaries between work at different project locations.

If you've never worked on distributed projects or teams before, you might foolishly think that distributed groups are all just one happy team. It's this kind of naïve thinking that causes managers to allow individual team members to work alone from remote locations. Remember, being ignorant, naïve, and foolish is just one step from being stupid.

A project team residing in three separate sites is not one happy team; it's three potentially happy teams working on one potentially successful project. By team I mean a group of individuals with a common understanding working in unison toward a common goal.

Due to the bandwidth issues I described earlier, you cannot hold and maintain a common understanding and work in unison unless you are likely to pass by your teammates on the way to the restroom. That's why shared collaborative spaces are the best. That's also why teams split across floors experience many of the same problems as teams split across continents.

To run a successful distributed project, you must create clear boundaries between the distributed teams that provide enough isolation to allow them to work independently with only minimal coordination; the clearer the boundaries the better the result. I talk about this more in my column, "Blessed isolation."

Typically, boundaries are architectural that isolate components, but they could be boundaries between versions or responsibilities. You could also have distributed teams focus on local market scenarios. Treat each distributed team like a dependency or a vendor and you'll be on the right track. This doesn't add unnecessary overhead; that communication overhead is there regardless. Instead, it reduces unnecessary conflicts, catastrophes, and clean-up.

But if your teams are isolated, how do you keep that sense of unity and sharing as you drive toward common goals? That's where the last big, bad B comes into play.

It would be so fine to see your face at my door

The third big, bad B is being there—being there to create the human bonds necessary to achieve real cooperation and connection.

Making the best use of limited bandwidth and clear boundaries will mitigate much of the difficulties with distributed development. However, you are still one group of people working on the same project with the same goals. There are important relationships you must maintain between teams, peers, and reporting structures that require a human face. Being there is important.

VTC and other live presence tools can help. You should use them regularly for one-on-ones and meetings, perhaps not every time but at least once per month. Remember to reserve the overlap time between locations for these functions.

Of course, nothing can replace actual human contact, so plan to have everyone visit with each other at least twice a year. Plan one visit in October for the company meeting and performance reviews, and plan a second visit in February or March for budgeting and fiscal year planning. Don't visit for a few days; visit for a week or two. Have morale events, one-on-ones, and training, as well as planning and review meetings. Make the most of your time together.

A number of teams do rotations or exchanges. In these cases, team members from one location spend three months, or even six months, with team members in another location. It can be a swap or an assignment. These rotations provide tremendous knowledge transfer while creating understanding, empathy, and connection across the groups.

One last thought… Sometimes giving the illusion of being there can be very effective at maintaining relationships and improving communication. Some companies have tried continuous video feeds of common areas. A cheaper and fun solution that's been effective at Microsoft involves big pictures and even life-sized cutouts of team members placed in high traffic areas. As people leave meetings or walk the halls thinking about the project, they see one of these cutouts and are reminded to include that person or team in the conversation.

Where are you when the sun goes down?

With a little effort, you can make distributed development work for your projects and teams. Soon the sun may literally never set on your team. The advantages for you and Microsoft are enormous.

The diversity of experience, culture, and ideas might initially cause discomfort for you and your group, but over time it will make you better, your group better, and your products and services better. Your work will be more relevant in more markets for more people, and you will learn and grow in the process. Take the time to beat the Bs and you, your group, and your work will become worldly wonders.

We're closing in on midyear career discussions again. It's time to place your hopes and humility in the hands of your hierarchy. I still haven't recovered from the amputation of our midyear ratings, which allowed managers to send messages and employees to salvage careers after a temporary setback. They've been replaced with a time-consuming CareerCompass that contributes complexity and confusion instead of context and clarity.

Don't get me wrong, even though I want the midyear ratings back, I initially found the less confrontational career conversations to be, well … constructive. Unfortunately, though HR and managers may mean well, their advice is often cryptic. Take the biggest offender: strategic insight. The common conundrum: "My boss says I should think more strategically. What on earth does that mean? What should I do?"

Good question. Ask your favorite manager or executive about improving your strategic insight, and he or she will likely suggest getting more involved in planning, focusing on the vision, thinking more about the business, and other such well-meaning nonsense. Yes, strategy happens in those activities, but attending a pro football game doesn't make you a great quarterback.

Strategy is not an activity; it's a way of thinking. It happens anytime, not just during planning. If you want to get better at it, wasting more time in meetings isn't likely to help. You need to mature your way of looking at work and the world. You're not an ignorant waif anymore. It's time to wake up and grow up.

Blind Faith or Cowboy Junkies?

A friend was recently comparing two coworkers to me—a guy who did whatever he liked and a gal who followed the current business strategy. My friend said, "[The gal] is a better strategic thinker." No, she's not. Neither is thinking strategically at all. The guy is a cowboy without a herd. The gal is tactically contributing to a given strategy, which is far better, but is not strategic insight.

There's a growth curve for strategic insight. Take a look and see where you fail, I mean, fall:

§  Ignoring strategy: The self-centered cowboy

§  Following strategy: The tactical contributor

§  Questioning strategy: The strategic tactician

§  Evolving strategy: The strategic thinker

§  Determining strategy: The strategic leader

Let's break these down, examine the pitfalls of each level, and discover how you make progress up the curve.

Yippee-ki-yay, project buster!

The self-centered cowboy ignores strategy, considering it bureaucratic mumbo-jumbo that might otherwise prevent him from creating cool innovative products. His heroes are the storied rebels that broke the rules and created the killer features that vaulted them to the principal and partner levels. Oh, to be that bold and bright!

Yeah, right. Never mind what the actual facts might be in those stories; we're not a startup anymore, and most cowboys aren't working on incubation efforts. They are working on established products and services, and cowboys in the big city will get lost and ignored no matter how well they rope or play guitar.

Why do cowboys get lost and ignored on big projects? Because their individual actions are like random noise. Without coordination, each cowboy's efforts cancel out the others. Their features may be cool in isolation, but they don't fit into a larger whole. Thus, no one sees them, no one uses them, and they add no value.

What's worse, all the random features created by cowboys only confuse customers more. They actually do more harm than good. A cowboy, setting out on his own to change the world, is only setting himself up for disappointment. Not because he doesn't have good ideas or because the big city won't give him a chance. A cowboy fails because he doesn't organize with others to drive the product forward.

Resistance is futile

The tactical contributor follows strategy, trusting the plans of the collective and finding creative ways to bring those plans to life. Many cowboys feel that tactical contributors have cowardly relinquished their freedom for the safety of the collective, with a "baaaa" and a "moo" for good measure. However, the real reason for being a tactical contributor is usually one of the following:

§  "I'm not interested in the responsibility of deciding strategy." As I talked about in "When the journey is the destination," not everyone wants to become a VP or Technical Fellow. Some are happy to make their valuable personal contribution, and then spend time focused on their other interests. Understanding and following the current strategy is the best way to have significant individual impact.

§  "I'm not prepared to take responsibility for deciding strategy." For those who aspire to lead technically or organizationally, to expand their impact beyond themselves, they need a place to start. Even if you disagree with the current strategy, your smartest initial move is to learn it and follow it. Only fools try to fight or evolve something they don't understand, repeating past failures. Intelligent people seek first to understand the strengths and weaknesses of the current strategy before they change it.

Following the current strategy doesn't mean giving up original thinking or creativity. It's actually quite the opposite. Many of the world's greatest buildings and works of art were inspired by the constraints of the land or medium in which they were made. Finding ingenious and beautiful designs that meet a fixed set of requirements is a challenge that great minds delight in solving.

Tactical contributors are highly valuable employees, but they aren't quite ready to make the leap to strategic thinker. Before they can determine new strategy, they must learn to constructively question the current strategy.

Is that right?

The strategic tactician questions strategy, while still following it. This is not to be confused with idiots who complain about everything without providing any constructive alternative. The strategic tactician is still tactically following the strategy and wants to see it succeed. She simply knows enough and thinks enough about the strategy to question assumptions and approaches that seem suspect.

Some people are afraid to take this step. They don't want to seem like troublemakers, and they trust that decision makers know what's best. For the bashful out there, here are a few facts that might get you to the strategic-tactician level:

§  Decision makers are absurdly imperfect, just like the rest of us. They don't always have the right or complete information. They can be blindsided by their own biases. They might even be incompetent, though Microsoft has some real talent in these ranks.

§  Troublemakers aren't thoughtful. There's a big difference between thoughtful questions and annoying questions. If you ask a question you could have easily answered yourself, or you complain for the sake of complaining, you are being annoying and causing trouble. However, if you've thought about a situation carefully, and truly care about getting things right, you aren't causing trouble. You are pointing out areas that need a better explanation or potentially a change in direction. Most decision makers will thank you for your input and think well of you at the next review. If yours doesn't, perhaps it's time to switch projects.

§  The current situation is constantly changing. When the strategy was devised, it was based on what people knew at the time. Today is different. New issues come up. The market, technology, competition, and customers change. Leadership changes. Requirements change, sometimes in subtle ways. All these changes can cause the current strategy to become inadequate or inappropriate. It's your job to notice, check if the strategy still makes sense, and question it if it doesn't.

So how do you notice when to question the strategy? When your gut stops you and asks, "Wait, why are we doing this