Student Blogs
MS in Software Engineering, Development Management Track Blog
Wondering if a Carnegie Mellon degree is right for you? Read about our students' experiences through the MS in Software Engineering, Development Track program.
 |
Linda is a first year part-time student in Carnegie Mellon's MS Software Engineering, Development Management track. She is a Software Developer at Electronic Arts in Redwood Shores, CA. She likes to dance and sing and her favorite videogame is The Beatles RockBand. She enjoys Indian, Japanese, Thai, Italian and Mexican food. She comes from Mexico City, and has being living in CA for the past two years. |
 |
Pras Sarkar is a second-year part-time student in the MS Software Engineering Development Management track. He works in Yahoo! Labs. His responsibilities include materializing ideas and concepts into engaging prototypes and demos, some of which ultimately mature into products that Yahoo! visitors use everyday. He is interested in emerging web technologies, social interaction over digital mediums, and creative interfaces that push the boundaries of human computer interaction. |
 |
Vineet is a Lead Developer at Boeing and a second year grad student in the part-time MS Software Engineering, Development Management program. He loves reading, playing with his daughter and pursuing the religious aspect of his life. He is an active volunteer of Vedic Cultural Center, a Seattle-based organization dedicated to promote the Vedic (ancient Indian) arts, culture, music and dance. |
 |
Truc is a second year part-time student in Carnegie Mellon's MS Software Engineering, Development Management track. She is a Software Engineer at Lockheed Martin in Sunnyvale, CA. She loves food and enjoys anything related to food: going to different restaurants, cooking, watching the Food Network, and of course, eating! |
Wednesday, June 27, 2007
Architecture and cross-team communication
What we weren’t been prepared for - and I guess that’s also part of the fun - was that our team would have to work with another team. That’s right, our faculty threw a wrench in our plans - not only would we have to deal with the logistics of scheduling our own team’s meetings, but now we also had to consider the schedule constraints of another 5 people.
And I think that’s where the whole “real world” experience kicks in. In the corporate world, not only do you have to deal with your own team, you also need to worry about other teams, you need to rely on them for some things even though they have different methodologies, different schedules…At the beginning of the mini, I have to admit that our communication with the other team was pretty bad. For the longest time, we weren’t really able to discuss things together. It was more like we were playing a ping-pong game: we get an idea as a team, send an email to the other team telling them our findings. They respond collectively, we respond collectively… We didn’t have hard feelings toward one another, after all, some of our former teammates were now on the other team we had to work with. But you could definitely sense some tension when we were trying to communicate with one another. And cross-team meetings were so big that we hardly got anything done.
That’s when we finally decided to create a sub-team to work on these deliverables. That’s to say 2 people from each team would get together and focus more specifically on the cross-team tasks. The good thing about this is we ended up with a much smaller cross-team. The bad thing is we still had to keep people in the loop.Now, does that sound familiar? To me it does. That sounds very much like those hierarchical meetings: some higher-up goes to a meeting for people at his level, he comes back and relates his findings to people in his group, who relate what happened to people in their own individual groups… and so on and so forth.
Of course, we had to do this while simultaneously working on our other deliverables, meaning we had to keep the overhead of this new form of communication to a minimum if we still wanted to be successful within our team. And I think that’s where I learned something: Processes can always be changed. When things don’t work out the way they should, the source of the problem can usually be identified as either people-oriented or process-oriented.
People problems can be hard to solve, process problems should be easy to solve: if the process is broken, fix it. Create a better one; tweak it so it works better for you. There is always room for improvement but nothing is ever going to be done unless YOU take charge.We had never communicated outside the boundaries of our team, we had quite a bit of work that had to be done while working in parallel with another team on an unrelated deliverable. When we saw the schedule the first time, we were all scared and didn’t know what to do. Then little by little, we found a way that worked for us and that helped us achieve our goals.
I learned something new, and that feels pretty good. Next time I’ll talk about my first impressions about being a team lead (I’m going to be team lead for the first time since the beginning of the program).
posted by Carnegie Mellon Silicon Valley @ 10:47 AM
