“Living in India is like living on another planet.” Based on his expat experience, an American co-worker provided me with this perspective as I arrived in India in preparation for a one-year assignment in that great country. While I soon understood my co-worker’s conclusion, I found my year in India to be one of the most rewarding in my life. I loved both the people and the culture there; and I gained a better perspective of globabl software development. International teams present both opportunities and challenges. I’ve been fortunate enough to work on global technology teams at three organizations. Pulling heavily from my Intel experience, here are some of my observations.
People are People
Hire talented, committed people
Whether you have a local team or a geographically dispersed team, your collective success will depend largely on the quality of the people on your team. I’ve worked with talented, committed technology professionals from around the world—India, Malaysia, Latin America, Africa, Europe, Australia—all over really. One of the great things about today’s global economy is that wherever you go, you can find amazing technologists.
Starting a new team outside your home city, state, and country can be intimidating. I’ve heard many horror stories and I’ve experienced some of the challenges. It’s essential to get off to a great start. To do this, find someone in your expansion city who is competent, gets your vision, and can assist with effectively engaging the talent in the targeted area. This resource could be an existing member of your broader organization, a local recruiter, or an outside tech organization that’s already established in that city.
At Intel, I engaged with a senior manager to start our India team. I had worked with this manager before on US based projects. He had taken a new role to build up Intel’s presence in Bangalore. He (and other seasoned Intel leaders) spent time in India upfront finding right people to get Intel going there. After he helped us hire our initial team, those initial team members played the pivotal role in expanding the team. We looked for people who were not only technically talented but who also match up well with the culture of the company and our team.
Key point summary: Technical hubs with talented people can be found around world. Invest time to bring the right people on upfront. Look for not only tech skills but for fit with team culture as well.
I was close to a large IT project that failed to take off. The project involved 300 people and cost millions (many millions) of dollars over multiple years. At the end of the day, it did not happen. As I talked with people involved on the team about the reasons for the failure, they could not put their finger on an exact cause. So many people were involved in driving the large and complex project, it was almost impossible to say why it failed or who was responsible.
We purposely avoided attempts to boil the ocean—or to deliver huge collections of complexity with large waterfall-based releases. Instead we took a more agile approach. We targeted prioritized functionality through a series of smaller releases that were each supported by a set of sprints or iterations. We broke our large team down into multiple sets of smaller teams (5-7 people). And we gave each subteam responsibility for specific functional sets associated with our tools. By breaking down our ocean of requirements into a series of limited releases with clear ownership, we were able to orchestrate a series of on-time, in-budget, customer-pleasing releases.
Key point summary: Don’t try to do everything at once. Divide up requirements into manageable chunks and divide your team up into manageable sub-teams. Expect the sub-teams to deliver fantastic for their respective functional focus areas.
So Far Away from Me
Make communication a focus
Have you ever been in a long-distance relationship? It’s tough—even when it just two people. Minus the romance of course, global teams can be a lot like that—except exponentially more challenging. Consider you have multiple people (some who may not even like each other) who must maintain (ideally build) a positive, healthy, functional relationship while working on an endless stream of complex requirements with unrelenting deadlines. Throw in time differences, cultural differences, and the lack of face-to-face (cube-to-cube) interactions—it’s tough.
Communication disconnects come easily and often. These often lead to frustration. Frustration is the path to the dark side. Frustration leads to toxic talk. Toxic talk leads to anger. Anger leads to hate. Hate leads to team morale and productivity falling to pieces. (Yoda-ism-ish) I’ve seen it happen. It’s much easier to point fingers at people you don’t know as well—who don’t sit next to you, who don’t eat lunch with you, who aren’t your friends. So you have to put processes and practices in place to make sure this doesn’t happen. Here are a few of the things we did at Intel:
- Global subteams. We tried to avoid geo-specific assignments (aka Indian team owns this, US team owns that). Our sub-teams generally included contributors from multiple locations.
- Daily communication. Daily communication was a given. Most days there were handoffs every morning and night (as our two main teams were about 12 hours apart). Scrums, individual calls, chat sessions, WebEx session—there were cross-ocean discussions going on constantly throughout the development lifecycle.
- Constructive confrontation. Intel embraced a concept constructive confrontation. This encouraged frank, open conversations even on tough subjects—even if it allowed a junior developer to question the principle architect. We embraced this as a team. Loved it. It built trust between cross-ocean counterparts.
- Cross-team exchanges. Building trust was a priority for us. We budgeted time and money to make this happen. Indian team members came to work in the US for 2-3 week stints. We had 1 to 2 people traveling in each direction every quarter. And these just weren’t managers or senior developers, we tried to give team members across the board these opportunities.
Key point summary: Long distance relationships are tough even for the best of people. You have to plan for this. Put processes and practices in place to keep communication channels open and healthy.
What’s On Your Mind
Define and communicate requirements clearly
Have you ever played the telephone game? One person whispers in a sentence another’s ear. That person whispers to the next person who whispers to the next person. And so on. It continues down the line until the last person repeats the message out loud to the whole group—only to find it is nowhere close to the original message.
Apply this to product development. Customers or stakeholders tell product managers what functionality they need. The product manager captures what he heard the best he can. Then developers (who have a different perspective to begin with) in another time zone, who grew up in a different culture, and whose English is more of UK variety than the American kind—then these developers take what your product manager wrote and build a technical solution. You expect them to get it right? Everytime?
We had some trouble early on with our offshore development team delivering interfaces and functionality that didn’t quite match the expectations of the product team or customers. So we reexamined how we captured and communicated requirements to our international peers. After a few iterations, our requirement handoffs looked like this:
- Well-written, reviewed requirements. We wrote up each requirement (feature, fix). Basic enough. We made sure that we included all the pertinent details in each requirement. Requirements were peer reviewed and (often) reviewed with key stakeholders as well before they were handed off to Dev.
- Use cases. Beyond the written requirements, we wrote up multiple use cases for each requirement. This process started with the product team and with the QA team eventually taking ownership.
- Mockups. A picture is worth a thousand words. Designing clean, simple, intuitive software was important to us. We ended up hiring a couple designers on our team. They created visual mockups of all UI related requirements. These served a duel purpose. They allowed us to gather invaluable feedback from stakeholders/customers early on. And they provided the development team a clear picture of what we wanted built.
- Requirement handoff sessions. We generally targeted 3-4 major releases a year. As our focus transitioned from one release to the next we held multi-hour requirement handoff sessions to review written requirements, use cases, and mockups. These meetings allowed for coordination, questions, and design approach discussions.
- Sprints or Iterations. Each production release consisted of a collection of sprints or iterations. Breaking up these releases into this smaller sets of deliverables allowed us to evaluate the progress of the requirements or functionality as we went—allowing us to change course as needed.
Although the attention to requirement definition may not appeal to agile purest, our approach was agile in spirit. It made development more efficient and it allowed us to better manage customer expectations.
Key point summary: Take the time to define your requirements well and to make communication of those requirements clear.
All the Small Things
Exercise pragmatic judgement
Somewhere between 5 and 6 in the morning, the our lead architect started practicing karate moves on me. Both kicks and punches with accompanying sound effects. Stranger thing is that I didn’t stop him. Must have been sleep depravation delirium. We hadn’t slept at all that night. Or the night before. Maybe a couple hours the night before that. A subset of our team had spent the night in a conference room getting our production environment working with our latest software release. This was supposed to be taken care 3 days before, but, hey, there we were—engaged in an impromptu early morning karate session.
Early misses motivated us to make process improvement a constant priority. We pulled from agile, scrum, extreme programming, and more traditional development methodologies. Our philosophy was to pull in the best ideas we could find and incorporated them where the made sense.
For example, the agile concept of pair programming worked wonderfully for us. It allowed us to match up and mentor junior developers with their senior counterparts. And even better it allowed us to pair developers from both sides of the ocean. It not only produced great code—it built bridges of trust across the team. We didn’t have everyone do pair programming all the time. We used it with judgment where and when it made sense. And this is the main point I want to make here—when it comes to process don’t let the ideologues win. Be a pragmatist.
At the same time, the larger IT organization in India was determined to become Level 5 CMM certified. To facilitate this objective, they implemented a bunch of superfluous and burdensome processes to demonstrate how efficient and effective their processes were. People who had drunk too much of the process-is-everything Kool-Aid were given the unbridled reigns to drive the whole organization into compliance. Process trumped productivity at the expense of the end product and team morale.
With great process comes great responsibility. Great leaders recognize when process is helping and is not. Their motivation is the overall success of the team, product/solution and not on driving process for process sake. They know how to exercise prudent (pragmatic) judgement. (Just saying. Will jump off soapbox now.)
Key point summary: Take from the best process approaches, methodologies, concepts available and adapt them to your situation, needs, challenges, opportunities. Start with industry standards and then tweak as needed.
She Blinded Me With Science
Leverage available technologies
There are so many applications available today to facility easy, effective global development. The expansion of cloud technologies and applications has made it easy to develop with a dispersed team structure. I’m not going to list them all or offer recommendations here. But you should always be on the look out for new technologies that can make your development easier, your code more reliable, and your end product easier to user. There are many different types of tools available—code repositories, real-time collaboration, QA, publishing/updating production environments, requirements gathering and prioritization, and bug tracking and prioritization.
We sought balance in transitioning to new versions, tools, languages, & libraries. We never made the move for technology sake alone. Architecture decisions needed business drivers; we always calculated the cost of change in advance. The agile driven segmentation of our code-base into functional areas allowed us to make some transitions incrementally.
Key point summary: Take advantage of the best modern (mostly cloud-based) tools available for collaboration, communication, coding. Make collaborative, business driven decisions on technology changes keeping in mind their impact on the entire team.
One
Build unified team culture
Awesome team culture doesn’t happen by accident. Healthy, happy, productive team cultures start with leadership and are measured by the collective perspective of the entire team. Attitude reflects leadership. How does the most junior developer feel about the team? What type of culture is reflected in the unscripted action of team members?
At Intel, our team culture began before we had a presence in India. We set challenging expectations and worked hard to achieve them. But we also liked to have fun—team lunches, late-night release parties, post release celebrations, and individual contributor recognition.
Our work hard, play hard mentality was perhaps most notably recognized by spontaneous fish throwing wars (thank you, Charthouse Learning). For years, stuffed fish flew over cubical walls looking for elusive headshots and occasional beverage upending. You were most likely to catch a large-scale flying-fish war late in the afternoon with battle velocity and intensity increasing as code release drew near.
We loved the culture of our US team and believed it was a key ingredient to our success. As we spun up our India team, we wanted our international counterparts to not only share the same deliverables but to also embrace and enjoy the same culture. We took them through the same training. And more importantly, we brought early India team members to US to immerse themselves in the positive team culture that we valued.
We wanted all team members to feel just as comfortable working on one side of the ocean as they did on the other. We wanted them to feel just as comfortable throwing a stuffed fish over a cube wall in Oregon as they would in Bangalore. We were (generally) successful in this—team members felt a shared sense of belonging to one team reguardless of where they sat.
On a side note, having been on the receiving end many times, fish flew in India just as fast as in the U.S.. (Cricket=Baseball??)
Key point summary: Create a healthy, happy team culture that people want to be a part of and you’ll get much more productivity. It’s important that your team shares not only goals, technologies, and processes, but that they also share a common team culture.
All for You
Engage stakeholders/customers
Our team served many masters. Multiple organizations with overlapping yet different requirements and objectives used our suite of web-based tools to engage with a wide-range of global audiences. Like most every software project in the universe, we always had more to do than resources to do them. Given this, effectively managing expectations was essential to our success.
Our engagement approach started with being honest and transparent with our stakeholders and customers. If we could not deliver what a group wanted when they wanted it, we would tell them why not. And we would explore alternative options for meeting their business needs. Many productive ideas came out of these discussions.
We connected our developers directly with our key stakeholders. When brought developers and QA into key stakeholder meetings as it made sense to do so. At certain points, we invited customers to talk directly with development sub-teams about specific concerns or needs. Support also regularly engaged with development and QA to provide them with customer perspective. We worked to provide development and QA with a customer-centric view of the business challenges that we were addressing with our software.
Our efforts to engage the development team with stakeholders and customers was not limited to the US team. For example, when we released a brand new set of event management tools. We sent contributing Indian team members to the US-based conference where the tools debuted. They sat side-by-side with the event management team and worked as a first level support as classes, activities, and attendee records were managed.
We wanted our entire team to feel some ownership in the success of our stakeholders and customers. We made decisions that reflected that. Providing our entire team with opportunities to engage directly with our target audience not only gave them a better perspective of what we were trying to build, it also increased their commitment to put forth their very best effort.
Key point summary: Take steps to engage development team members directly with customers and stakeholders (as it makes sense). This will give developers a better perspective on what they’re building and increase their commitment to do their best. It will also build connections that will increase customer/stakeholder satisfaction.
Things Can Only Get Better
Keep improving
After every release we conducted detailed retrospectives (we called them postmortems). They were an essential part of our team’s growth and success. We reviewed what we’d accomplished, what did and didn’t go well, and we discussed changes we wanted to make moving forward. These were frank and open discussions. “QA really missed the ball on testing the . . .” “Why did it take so long to . . .” “Requirement #347 was not clearly written . . .” Though they occasionally delved into challenging topics, these repeating retrospectives were generally celebratory in tone. They were reoccurring upbeats in the rhythm of our product life cycle. Because we had established openness, respect, and trust across our team, these sessions often morphed into productive brainstorm sessions with significant contributions from both sides of the ocean.
Continuous improvement was not limited to quarterly meetings. Refining our approach, developing our people, increasing our productivity, improving our end product were constant focuses for us. There were always ways for us to collectively and individually to be better.
Building the best possible solution for our global audience was guiding star. Not surprisingly, our solution was rated highly by our target audience each year as well as by industry luminaries.
Key point summary: Continuous improvement should be a constant. There’s always a way to make your customer’s exerience easier, better, more rewarding. There’s always a way to improve your development approach and to increase your team’s contribution to the overall organization.
Born in the U.S.A.
Embrace and expand an American ideal
Stories of Indian parents putting up large portions of their incomes to ensure that their children got the best education possible were not uncommon. I knew an Indian developer who was the first in her family to attend college. When her father died, she thought she would have to drop out. But her older brothers who had limited earning capacity themselves stepped up financially supported her education. Through their commitment and sacrifice she became the first in her family to graduate from a university. And she got a great job at a Fortune 500 company. Her story and thousands of others like it are part of the larger Indian story that captures this time of growth and development there. But their stories are rooted in what has long been considered an American ideal—the American Dream if you will. Anyone—regardless of socioeconomic background—can work hard, develop their talents, seize an opportunity, make great things happen, and get rewarded for it.
I don’t want to debate the merits of US corporations moving tech jobs outside the United States or to explore why America must seek qualified candidates from outside its shores to fill open tech positions in the US. Instead I just want to point out this: However it has come to be, American (and Western) technology companies have turned into global technology companies. In doing so, American tech companies have exported the ideals that have fueled American growth and prosperity for centuries. When properly enabled and pursued, the American Dream has been and continues to be a very good thing. Furthermore, the American Dream never has been based on a scarcity model. Success of one does not necessitate the failure of others. So why not let whomever (inside or outside the US) chose to embrace this American ideal, give them every opportunity to pursue it, and see what comes out of it. I’m guessing that all the world (including the US) will be better off for it.