Putting together an efficient product team is a challenge that can make a significant difference to your bottom line—"throwing headcount" at your international editions is not an efficient use of resources. If your entire team, including developers, designers, testers, translators, marketers, and managers, is committed to all language editions of your product, and if management holds them responsible for all language editions, you won't have to hire a lot of extra people.
The golden rules for product team managers are as follows:
Managers might argue that holding all team members accountable for all international products will cause them to lose focus, but in reality such a policy will save time and effort in the long run. Developers who are responsible for only the domestic edition of a product have no incentive to design global code, and might not even know how to do it. Later, when problems are uncovered during software translation and testing, those developers will have to spend time fixing errors that would have been easy to avoid; instead of working on the next version of the product, they will be busy redesigning old code. If your team creates a program so domestically centered that bitmaps must be changed or features redesigned, you will sacrifice consistency among language editions. If you choose to minimize the time spent fixing internationalization problems, you will release poor-quality products. Fixing and adjusting an existing product takes time, during which your company pays salaries but loses sales.
Microsoft used to have separate teams working on each product—one for domestic software and one or more for international software—that reported to separate managers and had different objectives. The domestic teams wanted to finish their US products as quickly as possible, with as little interference as possible. The international teams wanted to release localized editions as quickly as possible, and constantly needed domestic teams to make changes that would lower localization costs. This arrangement created an "us vs. them" mentality, as each team invariably had different priorities and felt the other was making its job harder.
Eventually Microsoft merged the two teams, but managers still assigned responsibility for international editions to "international developers." Just as before, these developers had to contend with algorithms that were not designed for multiple languages, and they had to decipher code that other people wrote.
The goal for the Windows 95 project was to ship several European-language editions of the system within days of the US edition, something the Windows 3.1 team had achieved. In addition, the Japanese release of Windows 95 was scheduled within 90 days of the US release, an improvement of more than a year over the release delta for Japanese Windows 3.1. To achieve these goals, Microsoft moved all development for Windows 95 (with a couple of notable exceptions, such as development for the Simplified Chinese edition) to Microsoft's headquarters in Redmond, Washington. The teams working on features related to double-byte, bidirectional, and multilingual versions worked alongside the rest of the Windows 95 team and reported to the same managers. Both the Windows NT and the Windows 95 teams were able to meet strict milestones for localized editions of their operating systems.
Although some teams are still tempted to follow the old approach, it has proved to be a very inefficient way to create international products. Developers find it much easier and more rewarding to be the experts on a subset of features than to be jacks-of-all-trades trying to maintain a working knowledge of an entire product code base. And if you hire one or two people to monitor all international functionality, you are basically paying some developers to clean up after other developers who will continue to make the same mistakes. Why pay someone to fix design problems and bugs that educated developers can prevent in the software's planning stages?
Quick release of localized software requires that translators begin work early. If you plan to hire translators from abroad, remember that it takes time to obtain work visas for noncitizens. Microsoft employed in-house translators and third-party contractors to translate German and Japanese editions of Windows 95. All other European editions of the operating system were translated, tested, and manufactured at Microsoft's subsidiary in Ireland. The subsidiary also hired third-party contractors in Europe. If you do hire a third-party localization company, make sure that translators have direct access to members of your product team, or you will lose some of the efficiency and other benefits gained with early translation.
Much of the expense and lost productivity resulting from the inefficient approaches described in this section drain a project's resources subtly over time and might be apparent only to people who prepare budgets and earnings reports. If you are having a difficult time convincing your company to change its approach to internationalizing software, arm yourself with schedules, bug lists, and sales statistics from past products. Back up that ammunition with market research and testimonials from product team members. Finally, show people this book.