Lesson Learned: One Team, Different Pages

Blogger's Note: What follows is a paper I wrote for a digital media class I recently completed at Utah State, part of my masters program in technical communication (six more credits to go).

As a group of college friends works with a foreign team of programmers to build a new social networking website, they forget that a good plan – including communication and accounting for setbacks – is key to success and company morale.

The inflammatory rhetoric flowed like pyroclastic lava.

“As I see it, we are already being held hostage by the programmers,” one said. “We are at their mercy and we can’t afford that.”

“I hear you, man,” another replied. “It took three months or more for this incompetent programming team to get where we are right now, it will take equal amount of time or longer for [us] to take it to where we want to be, is my opinion.”

It is early September, 2008. Designers for Uncharted.net, a new social website that focuses on citizen journalists sharing their travel adventures with their friends and the world, are fed up with the site's programmers.

Seeking an inexpensive alternative to building the website, which includes searchable databases of stories, photos, and videos; social functions such as member profiles, e-mail, and chat, Uncharted chose Nyros, a software development company in Kakinada, India,for the work. Operating from an arbitrarily-set August 31 deadline, the Uncharted team anticipated the programmers would finish the work in two months, at a cost of about $11,000 – a bargain in programming circles (similar work done in the United States, we discovered, would have cost us between $50,000 to $75,000).

As the programming “dragged on,” however, tempers started to flare. Only an intervention by the company's executive director and an increased focus on clear communication with the programmers pulled the company away from ruining what has now blossomed into an excellent working relationship between Uncharted and Nyros.

In retrospect, we see four things we could have done differently to make this project go more smoothly from the beginning:

● Get a good communicator involved immediately.
● Consider programming styles – and make sure everyone has the same style in mind.
● Use multiple means of communication.
● Assign one or two interested team members to become apprentice programmers.
● Plan for setbacks.

Get a good communicator involved immediately. In our case, Scott Stephenson, Uncharted's business manager, was the best fit to act as communicator between our team in America and our programmers in India. First of all, he is an immensely patient man, willing to recognize that differences in communication and culture would have to be surmounted. He also has a class and work schedule that allowed him to stay up late – often times to two to three in the morning – communicating by chat and e-mail with the programmers in India, who started their day at 9 pm Stephenson’s time.

He found right away that there were some concepts he was familiar with but that his counterpart in India was not. “Perhaps the biggest ‘wake up Scott’ experience was with the modular idea I mentioned” to the programmers, Stephenson said. The Indian programmers were in the habit of building websites from the ground up, with parts that were tightly integrated with each other. For Uncharted, Stephenson wanted them to take a modular approach, developing site functionalities in pieces so they could be more easily updated and repaired. “I remember well the sensation I experienced when it hit me that he didn’t understand what I was talking about. I set everything aside and took about fifteen minutes just to talk about the philosophy. I am absolutely certain that things have gone incredibly more smoothly since then because I took the time to explain it.”

He has an apt metaphor: “All you have to do to see it is walk in someone else’s kitchen and try to put the dishes away,” he says. You discover quickly, he adds, “that in some ways [people] are very alike, but in many things we are as different as night and day.”

As technical communicators, we can take this dish duty metaphor into a discussion on finding innovation. As David Hailey, an associate professor at Utah State University writes in an unpublished manuscript he made available to his digital media class, creativity is not enough to foster innovation. “We think students should be taught how to make innovative decisions – it is not enough to permit students to make the decisions and solve the problems on guesses and unsupported opinions,” Hailey writes.

When working on a new procedure to be used to assess radioactive waste being repackaged at a U.S. Department of Energy site in Idaho, for example, I learned a good lesson on how innovation is the smarter, older brother to the creativity expected of technical communicators.

I worked closely with an expert in nuclear criticality safety and two equipment operators to write the procedure, sitting next to these experts as they worked on the actual equipment in the field. We worked together to find the best possible wording and asked questions of each other. They learned more, as we worked, about the writing process and the standards writers go by, while I learned to understand their processes and science in order to write accurately.

The innovations arrived at through discussion and trial and error were simple ones that relied on trimming the language to take into account the operators' training – which I would not have know about without working with them closely – and by clever application of the company's writing standards in using looped steps and nested routing tables. Because we, as a cross-disciplinary team, had spent so much time working together and writing the document together, an audit of the procedure and process went with only minor bumps – a first in this criticality safety expert’s experience.

Stephenson has taken a similar approach with Nyros, working closely with Uma, a lead programmer at the company, to explain what Uncharted wants and to help troubleshoot when problems arise.

Use multiple means of communication. Even though Uma speaks English, Stephenson learned right off the bat never to assume that his English translated word for word into the English spoken by his Indian counterpart. “Language is one of the things we modify more than any other thing,” Stephenson says. “The phrases we use, even the words we choose to express our thoughts and feeling are a result of our society, even our friends and families. I’d be willing to bed you’d be hard-pressed to find a joke that someone in another country would understand without some sort of explanation to go with it . . . even if they grew up speaking English.”

Stephenson relied, at first, heavily on instant messaging to communicate with the Indian programmers, checking in frequently that he was being clear. “At least until they get fed up with you asking them if you are communicating clearly, assume that they don’t understand what you’re saying,” he said. The same approach, of course, works with native English-speakers in the United States as well, he adds.

Later on, after he built a relationship of trust with Uma, Stephenson switched from relying heavily on instant messaging to relying on written lists, followed up with IM. “The lists allow me to take a bit more time to think through how to say something,” he says.

Giving lists, he found, allowed Uma to delegate tasks to co-workers who don’t speak English. “If I give him a list and give him the opportunity to ask me any questions he has, then go to explain it [to the others], he has the dual experience of learning from me and teaching his co-workers, and understands [what we want] more” than with lists or IM alone.

He also includes as many visuals in his lists as he can, from screen shots to sketches. “If you can find someone that fits your needs that also knows how to sketch, hang on to them, because the sketching talent is worth more than people realize,” he says. “Some things cannot be communicated with words without some kind of visual aids.”

Consider programming styles – and make sure everyone has the same style in mind. Design of the new website proceeded in a classic waterfall pattern, with the design team working in its corner, emerging from time to time like a February groundhog to show us the latest screenshots. We had one team member who excelled at extrapolating what appeared on the static screenshots into functionality, but the rest of us struggled with the concept. That team member left the organization, leaving us with a design-to-functionality gap.

That gap appears to have been shared by the programmers, at least in the early stages of development. The programmers worked very hard to ensure that the site looked exactly like the screenshots they’d been given – but when it came to having the website function as intended, results did not arrive as quickly as the team had anticipated.

It’s clear now that the Uncharted team anticipated Nyros would program in a waterfall pattern, mimicking how the site had been designed – while Nyros followed a spiral pattern, placing emphasis on the first iteration on appearance over functionality, since they interpreted our primary emphasis on the first iteration as design (due to the innumerable number of screenshots we sent them) over functionality.

We could have avoided the confusion – and frustration – felt on the Uncharted side had we been clear that we anticipated a waterfall approach. Nyros, too, could have helped us avoid the confusion by stating that the first iteration was just that – an iteration focusing on design, to be followed by an iteration on functionality. Too many assumptions were made on both sides on what was expected and anticipated.

Part of the difficulty, we realize now, lay in that we were building an entire site from scratch. The next time, we know, it’ll be easier, because we’ll work on the site a piece at a time – and we’ll be sure to communicate with Nyros on what is expected with the first and subsequent iterations.

Assign one or two interested team members in becoming apprentice programmers. If these interested parties choose to learn how to program, the better for them. But, more importantly, these individuals should know enough about programming to be familiar with enough programming “landmarks” to understand how things work. And to have a grasp on how much work is involved in what functionalities the team would like the website to have.

Part of this effort will result in what is known as code switching – using words from different languages in the same communication. This code switching, as Hailey writes, is “intentional and effective, adding an air of friendliness or professionalism” to our conversations.

He points out as well, however, that code switching can be accidental, “demonstrating, for example, that the speaker is struggling with a new language.” I know this feeling well from my efforts to learn French. Even with several years’ worth of language study and after living in France for nearly two years, I still engage in code-switching when I find I don't know the French words or sentence structures for the thoughts I want to speak.

In either case, code switching shows the native speaker that we take our communication engagement seriously. If non-programmers are able to show that programmers that we at least have a rudimentary understanding of their language, we open up chances at better communication.

“A thing some people don't realize is that programming is hard,” says Dave Densley, Uncharted's website project manager. “Some don't know what it takes to make what's been designed function, what it takes to make that button do what it's supposed to, what it takes to make things work.”

Those team members who complained about the pace of programming admit their unfamiliarity with Ruby on Rails, the programming language Nyros is using to build the site. They could use other languages to make a more static, less socially-engaging site, but could not achieve the functionality that Nyros' work is providing, Murry and Stephenson say.

Spurred by our Uncharted experience and a desire to increase my marketability as a technical communicator, I've begun refreshing my memory on the basics of HTML and, once that is solidified in my brain, I will work on understanding the basics of Ruby on Rails. I learned basic HTML just after the Internet's infancy, thanks to policies at the University of Idaho that urged students to use e-mail and build their own web sites, using server space the university provided. Through experimentation, using web browsers' “view source” feature, I learned enough to build several websites. When I left school, however, those skills went to the wayside until recently. Now I'm back to examining how web sites are put together by using tools such as Mozilla Firefox's Firebug, an add-on to the popular web browser that shows HTML, CSS and other web-building code behind the sites I visit.

Plan for Setbacks. Stephenson’s day job is in the aerospace research industry. “This is cutting-edge stuff. Ultra-modern research. And I’m constantly amazed at how, even among people trying new and difficult things, how they rarely plan for setbacks.”

We recognize better preparation could have come through taking a spiral approach to the programming – getting one aspect or module of the overall site working, then moving on to additional aspects or modules – rather than anticipating that once the programming switch was flipped on, things would go smoothly. “As we were going through the [programming] process, we found things that were missing,” Stephenson says. “We had a rather sophisticated design, and we should have anticipated that in this design things would be missed or looked over.” Taking a spiral approach to the programming would have allowed both the Uncharted team and the programmers to identify problems more quickly and get them repaired more quickly.

“One of the problems we have is unrestrained optimism, which is a good problem to have in most respects,” says Alan Murray, Uncharted’s executive director. He’s seen that optimism serve the company well as, for example, the marketing team worked on promotional strategies, the design team worked on website screen shots and the editorial team worked to coordinate content. But when it came to the programming phase, Murray and others saw those optimistic inclinations work to the project’s detriment.

“It seems like we never planned for things to go wrong” with the programming, he says. As one deadline after another fell, Murray saw the optimism quickly exchanged for pessimism, attacks on the programmers and an overall diminution in corporate enthusiasm for what is the company’s flagship – and practically sole – product: the website.

“I think some of us lost the focus, the energy, because of the setbacks,” Murray said. “We'll have to work hard to get that back.” Planning for them, in retrospect, might have helped soften the blows and ease that drain of energy.

Conclusion. “Next time we do programming, it’s going to go a lot more smoothly,” Stephenson says. He believes this for two reasons: First, we have a site to start with, and further programming will be adding to it, rather than starting from scratch. Second, we know that we have to take the extra mile to communicate clearly. Lastly, we know what pitfalls lie in our own creative and innovative processes – pitfalls that glow as brightly as a fresh lava flow.