Entities

First of all, let us keep in mind that tasks are actually what IWs really care about. They are much happier if they can complete assigned task without touching emails. Right? Completion of tasks is what they are trying to achieve. Second, when they have to communicate, they care about distilled information they are expecting while writing/reading emails. You will not get any additional credit through presenting your idea by writing a poem. Senders and recipients come last. Without them, communication can’t happen. These two entities get lower priorities because if distilled information can be gained by other means, say search engine or anonymous DL, who cares them?

Again – email for IWs is all about tasks, not messages. This is the most fundamental philosophy differentiating Pmail’s design from others.

Problems – an abused tool in workplace

By nature, current email systems allow one sends anything to any number of persons at anytime anywhere. Gradually it turns out true that something that can be anything can do nothing actually. Theoretically any email should be of your interest; otherwise sender will not send it to you. Realistically it is so easy to be over-used:

• Email overload. You might probably find everyone around you is complaining about too many emails. Doubt? Open you email clients, see how many unread mails you have. NY Times reports, E-MAIL has become the bane of some people’s professional lives. This occurs likely because of complicated job nature, but I’d say often it is actually because of poor email prioritization. Can you easily tell which email is much more important than others? Or emails tell its priority to you?
• Hard to map emails to one’s day-to-day jobs. How many times you have to search your emails to dig certain messages out because you need something?
• Mail thread discussions often go wild. Do you find you are in trouble figuring out what is going on when suddenly looped in a thread?

At a glance

Pmail’s primary design goal is to help team get jobs done efficiently – under right timing, priorities, order and resources. Everyone would have a clear picture about how his work contributes to team success.

Pmail would also aim to minimize communications as much as possible. Leave users alone please. In task-centered email design, all emails will fall into one of below four categories:

Persona/User scenarios

Key scenarios that Pmail addresses include:

• Know big picture for better prioritization – Steven, who is a developer in a software development team, came to his office in a morning. He opens bird view of pmail to check how his tasks (or WBS in more general term) fits into the entire team progress. He notices one of his tasks, task8, is in critical path according to updated plan(never expect plan is really locked after lock-down). This task is automatically prioritized to p0(highest priority) by Pmail. It is about implementing a feature according to design specification by feature PM.
• Maintain dependencies – Steven goes ahead to open task8 and find this task depends on two resources, 1) one LHS virtual machine, which has been completed by task7. VM address and credential are also attached. Nice! 2) PM spec. It is also claimed completed.
• Main email threads around tasks –Steven opened the spec document in team Sharepoint server, and he finds several points are not clear for him. Then Steven starts a mail conversation with relative PM, Joanne, against this task. The mail thread is linked to task8 and its status is open.
• Drive team work flow – Joanne received a catch-the-ball mail from Steven about p0 task8, so it is a shadow p0 task for her as well. Joanne can check task details in the Pmail. She quickly comes up with answers regarding Steven‘s questions and writes back a here-you-go email to Steven. Steven receives the email and get unblocked. Steven closed the email thread by several sentences. This mail thread is traceable in task8 and can’t be replied any more as it is closed. Several hours later, Steven completes task8 and closes it in Pmail. When Steven re-visits the bird view page of Pmail, he finds task8′s color turns green due to status change. Steven then picks up another one unblocked taks, task9.
• Maintain team discussion – Task9 is about designing a new feature F9. Deliverable is reviewable dev design spec. Steven has two options about solving a technical problem, but not sure which way to go. He then sends a collective-effort discussion mail to the whole team. Since this is not a catch-the-ball mail, team mates will treat it with best efforts, but Steven still gets several great feedbacks. When he feels the problem is solved, he summarizes the thread with several sentences and closes the thread.
• Check history – One year later, Steven transfers to another team and his replacement, Eric, would like to better understand why F9 is designed this way. He opened Task9 in Pmail, check the mail thread and better understand original design decision.

Demo/UI Mock-up

Bird view will look like above diagram. In following task view, you can see all mail threads about one task are at your finger tips.

Mail view will also a bit different. Every mail has a TaskID field to help you get the whole context conveniently.

Key features in Pmail

In addition to biggest differences we covered before, you might also get excited when seeing below features.

• Sometimes feature-rich is not a good thing. It is so easy to reach this point when email system is designed for multiple purposes after several releases, say home usage included. But in any event, Pmail will provide a button to show/hide features(say, increase/decrease indent) which I don’t use in last month. Get me a simple world.
• Mouse hover will show abstract of email(user could assign, or automatically select) before deciding to read it
• Send me SMS notification when a selected critical thread gets new replies. No special carrier service needed, input my cell phone and go
• For discussion mails, send brainstorming results or decision made, and then close the thread by marking it as un-reply-able
• Enforce sequential replies, for example fill in a excel table
• Automatically memorize folder or url of files you are editing, and go to Pmail, it can be attached to the email by a hot key, say “ctrl+shift+v”
• mailURL(say, steven-task9-show-me-money-88; don’t use GUID, please) which can be shared across the clients. Don’t to forward again
• Automatically send out ping for dead catch-the-ball emails after pre-configured interval times out
• Play video/audio right inside the mail client
• Mail web client also provides web API like Facebook. OWA kills programmability.
• Tag everywhere – one mail thread might relate to more than one task. It is not a good idea to put a mail in one folder exclusively.
• Don’t allow send active documents to team for review, put it on shared place(say, Sharepoint) and send a link

I am interested in your thoughs on it. Let me know. Thank you.

Pros and Con

Why bother to build global development team?

• New talents pool – Software development needs so many persons with similar attributes. In Microsoft Company wide, top 3 hiring criteria are smart, passion for technology and fit to company values such as openness, continual self-improvement and mutual respect, etc. From various studies, supply of talented IT staffers isn’t keeping up with demand. And it won’t change anytime soon. Even when Microsoft is cutting 5000 jobs now, we still have another 2000~3000 job openings there. What to do if enough qualified hires can be not found within US? Go outside.
• Lower cost – let us straightly go to data. Annual pay for Level “59″ is about $74,000 in US, while same level is paid about $20,000(~RMB150K equally) in China. Another slight fact – It costs about $1.5 to go most common places in Shanghai…
• Close to market – Most innovative ideas often comes out of interactions with customers. And customers’ requirements vary from country to country. So best way to serve a local market is to be in the market.
• Specific knowledge – Cross-nation acquisition for specific technologies is another reason to build global development. You can’t(or not able to) move all folks to HQ.

Like many other things, challenges always go with benefits hand in hand. You can’t take only part of it. Fair enough.

1. Distance – People who work on the same software can’t work alone, they have to exchange information and make decisions. Less than 3 minutes conversation is often enough for slight but frequently arising communication needs, for example, “Could you show me the bug in your environment?” Distance makes it impossible to stop by one’s office. Network bandwidth is another issue introduced by distance. Why it matters? Suppose one team has to copy large file sets from another remote team daily, it would be a problem. The file sets can be growing amazingly big – for example, daily SQL Server build is about 300GB.
2. Time zone – Would communication a real headache since modern technologies such as email and telephone have been there for quite a long time? But the things are no one is there when you are working due to time zone. You have to wait another day to get an email response. When you rush to office to check it, the most frustrating but concise reply could be – “What do you mean by <insert anything you assume others should understand>? How can I help you?”
3. Culture/Language – Master level of English is unbalanced in global teams. There are dozens of ways to say “A beats B” in English, but only several of them are understandable for general public; dialect is another obstacle. For example, Chinese folks often have hard time pronouncing letter “L”, as a result, words like “girl” might sound weird sometimes.
4. Junior team – In my organization, most hires right come out of college. We are raw smart, but less experienced. It is hard to deny that some key ingredients for great engineers just take time – design skills, debugging techniques, influencing capabilities. This is not a cutting-corner example.
5. Conflicts between hierarchical management and local branding – By organization hierarchy definition, many business units have existence in China. STB, Live, Online Service, etc. They functions nearly independently of each other and reports to US. But from the perspective of customers/partners/talents, it looks a bit confusing because there are so many Microsoft’s.
6. People development – folks in remote sites are not equally exposed to development resources such as face-to-face training, library, mentors, etc.
7. Governing issue – due to well known concerns, something confidential can’t be moved out of US.

How-to

There are several factors playing critical role in deciding appropriate distributed development model. At least you should consider project type, team seniority, team size, team culture, communication cost and history.

• Build trust first. No matter how adaptable a new team is, it always takes time to fit into a specific team culture. So starting with easy jobs to build team moral and credibility is the safest steps before moving forward. Beyond this, the new team can target increased ownership.
• Decide on team coupling level. From highest to lowest, the level could be: pseudo random assignment, same branch same feature/component, same branch different feature/component, different sub branch but same main branch, different main branch & clearly defined data contract. Avoid circular dependency.
• Come up with communication plan. Minimized communication is not always the best, especially for relatively junior teams. The best way to develop people is to work with senior folks on daily basis as much as possible. So you have to make tradeoffs here based on various inputs.
• Shared lab if possible. If you have to copy large files across the ocean frequently, consider doing your job on a lab down in remote team. If you have to do copying, make sure the files meet most critical quality requirements before doing so, for example, a build verification test.
• People development plan. Regular staff exchanging plan such as Marco Polo and Silk Road program, getting a mentor, record trainings, etc.
• Local brand management. Externally shown as one image; internally run by functionality as usual.