This document discusses BEA Systems' decision to move the engineering functions for their WebLogic Integration (WLI) product to their India R&D center in Bangalore. This represented a major risk for BEA as the Bangalore team would now be responsible for overall design, codebase ownership, release management, and program management. To mitigate the risks, BEA focused on building a balanced engineering team with the right mix of skills, experience, and motivation. Individuals were also challenged with new roles outside their specialties. Regular team meetings and the ability to break down requirements were keys to the team's success. Interactions with customers and conducting local training further helped the team grow.

1. Great Leaders take Risk
Building a
World-Class Software Product Development
Team in India
Sanjeev Kumar
VP, Engineering & Head, India Technology Center
BEA Systems India
August 2007
BEA Confidential. | 1

2. BEA Systems Inc. – Introduction
The Middleware Company
 “BMW” of Infrastructure Software Industry
 “Software that customers use to build their software”
 FedEx, DHL, WFB, PG&E, eTrade, Verizon, NYT, ideaCellular, Railways
Brands & Products
 WebLogic: WL Platform, WLS, WLW, WLP, WLI, WLCP, WLEvS
 AquaLogic: ALSB, ALBPM, ALUI, ALER, ALDSP, ALES, ALSR
 Tuxedo: Core (/T, /Q, /WS, /Domain, /M, /HA), SALT, Jolt

3. BEA – A History of Risk Taking
1995: Tuxedo Purchase from Novell
 Helped crystallize the middleware market-segment
1998: WebLogic Inc.
 Bet-the-company acquisition, created J2EE app server market
 Best value-creation via acquisition (till VMWare acquisition)
2001: CrossGain & Westside
 Web Services, Controls & IDE; Did not meet expectations
2006: WebLogic Integration (WLI) in India
 All engineering functions to be done in Bangalore

4. WLI Move to BEA, Bangalore
India R&D Center
 About four years in operation
 Initial teams focused on sustaining engineering
 Currently 2:1 split in favor of mainline projects
WLI Functions at BLR Lab in 2006
 40% of development projects
 Most of QA, sustaining engineering and backline support
Risks
 Ownership of overall design and code-base
 No prior record in release and program management
 High degree of interactions and dependencies (“chatty-ness”)

5. Engineering Team Parameters
Balance in Product & Technical Expertise (“DNA”)
 Mix of new hires from similar product or competing companies
 Few senior engineers with a three-year history with the product
 Skills coverage on all the building-block technologies used
Balance in Team
 Small “pyramid” teams, anchored by experienced engineers
 Technical Depth, Energy Levels, “Can-do” Attitude & Motivation
 An environment for technical discourse and a “positive echo”
Coverage in all Functions
 Development and QA are well understood
 Release Management: inter-team interactions & dependencies
 Program Management: bridge customer-view and product internals

6. Placing Bets on People & Team
Individual Level Roles
 Developers taking on new or unfamiliar sub-systems
 An QA engineer learns to be a release manager (“herding cats!”)
 An architect from an ERP product company steps up as program mgr
Performance as a Collective (Engineering Team)
 Weekly local product team meeting covering all functions
 Ability to break-down high-level requirements into manageable chunks
 Estimation of schedule at task, intermediate milestone and release levels
“External” Interactions as Growth Opportunities
 Critical customer situations: leads visiting serious deployments sites
 Local beta customers: feedback loop on functional & operational aspects
 Local training courses: leads conducting Q&A sessions with customers