MS in Software Engineering, Development Management Track Blog

Introducing Linda Avendano

2011-09-21T11:48:00.000-07:00

When I first came to Silicon Valley to start working for my company, I learned very quickly that even though I had the technical skills for my position, I lacked management and teamwork experience. As a programmer, I was always working alone on my code, and didn’t care about collaborating or working in partnership with my colleagues. But as soon as I got involved with the members of my team, I knew that I needed to learn more about team building and managerial skills. Carnegie Mellon’s program was the right choice for me, as it includes technical and management courses. I needed to upgrade my technical skills and, at the same time, learn how to cooperate with my peers.

When I attended an information session, and learned that most of the tasks during the program were done within a team, I made up my mind and decided to apply for this program. Learning how to collaborate in teams was one of the most appealing aspects of this program. It has always been very hard for me to team up with other people, especially if they did not come from a technical background. However, in my current job, I have to deal with as many non-technical employees as technical ones. Carnegie Mellon provides an environment to experience what it is like to act as a team, to learn about sharing, support, commitment and team success.

It has been four weeks since I started the program, and I have been working with other 3 classmates. So far my team has been doing a great job. We have a lot of support from the faculty to help us build a collaborative and supportive environment to work. This has helped me to immediately apply this knowledge to my team at work. Even though you might think that knowing how to collaborate in teams is not a key objective in the work place, it is. At CMU, you have an opportunity to gain these skills as almost 70% of the activities within the program are focused on learning how to team up with your classmates.

2009-08-25T15:01:00.000-07:00

A few of my classmates have asked me why I chose to pursue the Development Management (DM) track in the Software Engineering course. Though my choice has been based entirely on my personal opinions, I thought that sharing them might help some prospective students who are still trying to decide between the Development Management and Technical tracks.

Firstly, let me explain the structure of the two tracks. Students in both tracks have to take the same courses and are on the same teams during the entire first year. In the second year, the students in the DM track join the first-year students in the Software Management course while the Tech track students continue on with the technical track.

The major benefit of the technical track is that it allows the students to stay technical and further their technical expertise. A big pull of the Tech track is the Practicum class that students take in the second year. This class places you (and your team) in a real-life situation with a real-life company working on (hopefully) a real-life product. In my opinion, this is one of the biggest reasons to choose the Technical track, especially if you're looking to work in a company setting that is different from your current one.

In the DM track, the courses dive deeper into the issues of people and software management. The fundamental difference here is that you're going to learn how to manage people, not code. This is a big shift for most people coming from a technical background. Managing people is quite different from being able to write code and directly contribute to the completion of a project. When being a manager, you are responsible for the people you manage. Your performance is directly related to the performance of the engineers that you're managing. Therefore, this becomes a much bigger choice than just choosing between the DM track and Technical track - it is fundamentally a choice of where you see yourself in the next 5 years.

If you see yourself being a manager, managing a large project, being an entrepreneur, the odds are that the DM track is the one for you. If you see yourself being a lead/senior engineer or an architect, the DM track may still be for you. Why? Let me explain.

If you decide to stay technical for the next 5 years, you can still benefit greatly by learning how to manage people. You can gain a lot of headway in your career path by learning the metrics by which your manager is going to measure you. You may also gain some insight into how your manager's manager is going to be evaluating him/her and how they are going to be evaluating the success of the team/project. This is integral to being able to navigate the organization chart and move upwards. It will also help you become a better team player and make your manager look better (which always makes you look better).

Lastly, if not for anything else, the DM track might help you increase your pay scale. Let me explain since this isn't very intuitive. Initially, turning into a manager may actually result in a pay decrease. However, the more success you have as a manager in leading teams to launch and deliver successful products will only increase your worth. Eventually as you repeat this cycle often with consistent success, you will enjoy a faster pay rate increase. Simply put, being a manager will put you in a position to take risks and reap the benefits from it. It opens the opportunities that you can take advantage of that you may not be able to as an individual contributor.

You must make this personal choice after careful reflection and evaluation of your career goals. But I hope my reasons help you choose between either option, because, at the end of the day, having a plan for either Tech or DM tracks is better than having none at all.

Engineering Requirements

2009-04-01T15:16:00.000-07:00

I am now taking my second course, Engineering Requirements. It's actually halfway through and I currently have a glorious week off. The work load for this course is about the same as the work load for my first class, Foundations. Instead of programming like the first course, this course is about gathering requirements. I've had the opportunity to learn a lot of new things that I am not exposed to at my current job, such as: requirements elicitation, use cases and scenarios, and user interviews. I have been able to also learn from my teammates who have experience with requirements elicitation at their work. Speaking of teammates, I really like my team this semester. We all get along and have a lot of fun together...even during our epic team meetings. Sometimes, I think we goof off more than get our work done, but it always works out. It's been a nice week off from school, but we still have a lot of work left for the second half of the course!

Time Flies!

2008-11-04T11:43:00.000-08:00

It has been 2 weeks since mid-term break and I am 4 weeks away from the end of my first graduate class, Foundations. I have definitely spent more time during the second half of the class. As our project deadline draws closer, everyone on my team has been putting in more hours. We meet almost everyday, whether in person or over phone. It's a good thing we all get along well or we would get sick of each other! With all the extra time I have been putting into school, I don't have much free time with work too. Despite being so busy, time has really flown by and it seems like only yesterday that I was at the welcome orientation.

Why I chose Carnegie Mellon Silicon Valley

2008-10-13T15:01:00.000-07:00

My name is Pras Sarkar and I work at Yahoo! in Sunnyvale, CA as a Research Engineer. My job at Yahoo! involves materializing ideas and concepts into engaging prototypes and demos, some of which ultimately mature into products that Yahoo! visitors use everyday. I'm interested in emerging web technologies, social interaction over digital mediums, and creative interfaces that push the boundaries of human computer interaction.

I'm a passionate engineer and hacker, and I'm deeply interested in the mechanics of software engineering. That is what led me to the part-time Software Engineering program at Carnegie Mellon Silicon Valley. I felt that the program held the right balance between theory and practice - an integral factor in my decision making process.

The program brings together part-time students from a variety of different backgrounds. In my first week alone, I met engineers from varied fields like semi-conductors, defense, manufacturing, etc. Being a web engineer working in a web company, I hardly ever get to interact with engineers from such diverse backgrounds. What I find fascinating are the conversations and collective knowledge gained from such meetings.

The format in most classes is a theoretical session followed by discussion. The theoretical sessions are always informative, but what I find most interesting are the discussions that follow. They usually revolve around past experiences on the topic of discussion - what worked for some, what didn't, pitfalls to watch out for, etc. It also emphasizes how the learnings can be applied in real-world situations where profits are the bottom line and products need to ship to real customers who pay for them. The practical knowledge sharing is what I find to be the most valuable aspect of this program.

My hunch is that these conversations will not only continue throughout the program, but will extend beyond as the students build professional and interpersonal relationships with each other. If you'd like to hear more about my experiences so far, or have any specific questions, feel free to comment or reach out to me through my personal blog at http://headphono.us. Otherwise, stay tuned for my next entry!

Cheers,

Pras

2008-09-22T10:10:00.001-07:00

My name is Vineet and I work for the Boeing Company in Seattle, Washington, as a Lead Developer. Twelve years ago, after graduating from IIT Roorkee in India, I started my career as a Chemical Engineer in the process industry. However, I soon tired of the night shifts and moved my career into the software industry. The Java boom in late 90’s gave me an easy entry into the world of IT. However I always felt my background in Chemical Engineering was hampering my career in IT. Even acquiring a number of IT certifications didn't give me any satisfaction. I wanted to pursue higher education in software. When I arrived in the United States in 2005, one of my colleagues, Andy Chow told me about MS Software Engineering program at Carnegie Mellon Silicon Valley. I was excited by the opportunity to participate remotely from Seattle but still be part of a working team. I applied last year and I got a chance to fulfill one of my dreams to complete my master’s degree from one of the best universities in the US.

Going back to school after working in industry for more than 12 years was a big decision for me. I was anxious how I was going to manage family, work and now school together.

But then I thought this is what I want to learn -Time management which is one of the most important attribute of successful leaders. I got myself ready for orientation scheduled during August 22- 24. Orientation started with Sylvia, the director of admissions, giving us statistics about the students enrolled for Class of 2010 and I thought to myself, “Boy, how did I get into this program with such a talented group of people?” I felt really proud and happy. It was rejuvenating to have this feeling of satisfaction with my achievement. I was amazed with the diversity of students and their past backgrounds and accomplishments. It also struck me as interesting that we had, at the oldest and youngest ranges, a 22 year old and 60 year old student in the same class.

I was introduced to my team with whom I will be working for the Fall semester. Fortunately all of us are Seattle-based so we will not have time zone problem. The next two days we had a couple of team-building exercises .With each exercise I could understand how important team-building is, something we often forget in our work environment. Team-building is considered as one of the least important tasks rather than the most critical task for overall project success.

I was also exited to know that we will be working on a Ruby on Rails project in my first semester. I was working in Java for last 12 years. Now definitely I will learn one more technology in Agile fashion.

The first week of class started as soon as I returned to Seattle. Our team had already decided on the schedule of our weekly meetings. I had been more worried about time management but, thank God I didn't have any production problems and could easily spend 20 hours on study, while most importantly I could spent exactly the same amount of time with my wife Puja and daughter Sanskriti.

An Introduction to Truc

2008-09-15T12:36:00.000-07:00

My Name is Truc Nguyen and I currently work at Lockheed Martin as a software engineer. I have been full time at LM since January 2008. I graduated from Michigan State University with a BS in Computer Engineering. While in college, I interned twice at Lockheed Martin for different business units. I also held several technical part-time jobs throughout my undergrad for the university, as well as local companies. I decided to participate in the Software Engineering masters program at Carnegie Mellon because I feel that there's so many new things out there to learn about that I'm not being exposed to at work or during undergrad. I think the program will expand my knowledge and help me grow professionally.

Admission
I decided to apply to CMU after an info session held at Lockheed Martin. Several of my co-workers have graduated from the same program and they told me it was a good program. I applied about a month before the official deadline. I must admit that the admission process took some effort. The programming diagnostic took the longest because I actually had to learn about MVC in order to complete the diagnostic. Working full time made the admission process a little harder, but it's a good way to prepare you for balancing school and work in the future. The interview portion went well. I did not feel intimidated and left the interview feeling pretty good.

Orientation
I think the orientation was a great idea. I was able to meet all my classmates and socialize with them. There were several fun team building exercises, such as building the lego castle. The best part about the orientation was that I was able to get to know my teammates for my first course, Foundations. I think this made us stronger as a team because we were able to spend time with each other before the class got underway. The food at the orientation was good too!

First Week of Class:
The first week of class went well. I was surprised by the size of the room....or maybe the amount of people that attended class. Everyone was pretty early class too. There were no real glitches for the people remoting in.

Team Experience
We are now on the third week of class and my team has met several times each week. Everything is going great with the team. We all get along pretty well and know when to have fun, but also when to get serious. I think having a little fun and joking around with each other is key to keeping the team sane when the pressure intensifies.

Getting Pushed Out of My Comfort Zone

2008-01-25T10:05:00.000-08:00

Hi all,

Happy New Year 2008! So Foundations has ended and I move onward to a whole new semester, a new team and a whole new set of topics to learn. I’m currently in the Requirements course, semester two of the MS Software Engineering program. One of the most daunting things about starting a new semester for me was getting a whole new team. I had finally gotten used to the old team, made good friends with them, figured out the way they work and their time schedules and it was time to rotate and get a new team. At first I was annoyed and scared to try to get along with three new people but as I got to know these guys and started working with them, I understood what Carnegie Mellon was trying to do. They are trying to force us into uncomfortable situations, placing us slightly out of our comfort zone to make us grow. It’s been great getting to know these guys. Why had they chosen Carnegie Mellon West? Where did they work? What did they do, what technologies do they work on? How are things done at their work place? Every company is similar and yet also very different. Finally, you also realize that every person has such different strengths and by meeting a whole set of people; you are gleaning the best of everyone. It’s also a great networking opportunity.

Another thing about this semester I am starting to learn is that there are a lot of tasks to do, a lot of time to do them, but the time is not structured for you! We have basically 6 weeks that we need to divide and schedule and create milestones for ourselves. While this is a great way of learning time management, I’m also a bit nervous to see if we’ll finish our tasks on time! I’m sure we will, we are keeping to our schedule so far.

And lastly, something very important to note about this class is the introduction of team roles. In the last class, we each had informal roles that we created and kept. There was someone who’d take minutes and send out live meeting invites and the other who’d make sure things are done. But everyone did all jobs and nothing was formally set. In this class, we had to divide up official team roles, such as team leader, QA manager, planning manager, etc, among ourselves. We needed to learn what each of the roles meant and we have to rotate the jobs as the semester progresses. I was immediately excited to actually learn about the various roles but again, I was also a bit apprehensive about doing some of the positions. Most of my team members have already been one or the other at their jobs-each has more experience in industry than me!

For me, I knew the most challenging role for me would be the role of team lead for two reasons - the very fact that we don’t know each other that well yet and I knew some of them were team leads at their work right now! So in keeping with the theme at Carnegie Mellon, I picked the one that challenged me the most. Pushing myself into the team lead role and taking my teammates advice on some things has been very helpful so far. It is making me voice all my opinions, making me learn what’s due etc, learn to run meetings, and many more. I still have a few weeks left in this role and I’ll let you know how it all goes.

So that’s all for now, hope this has helped you a bit, and I’ll talk to you in a few weeks!

The Gathering

2008-01-17T16:02:00.000-08:00

Last week, we had what we call “The Gathering”: this is a meet-up event we have every two semesters where we have activities, special workshops, where some guest speakers come and talk to us about what they do in their various jobs… The event lasts about one and a half days (all day Saturday and Sunday morning), and I would say at this point it’s not so much about team-building anymore, since we know each other pretty well but rather a way to meet outside of school and have fun.

We started on Saturday with breakfast as people were arriving: we focused our discussion mostly on break and vacation and how we were all tired, but as Martin Griss (our Associate Dean for Education) put it: this is the last stretch before graduation, we have to hang in there and make the most out of our last two semesters.

While we were chatting, Martin Radley (one of our faculty members in the DM track) asked around for volunteers. I volunteered along with 3 other students not knowing what we were getting into: he handed us scripts with lines we were supposed to say during a little play and a Starbucks gift card to thank us (yay!). Once we were about to start, we got handed hats to choose from, somehow I wound up being the last one to choose and having to wear the shiny purple hat (I hope nobody took pictures – we all had a really good laugh).

The play was intertwined with discussions about being a change agent and what kind of techniques we can apply at work to initiate change. I recognized myself in a few of the situations we depicted and I wished I had known all of what we talked about a few years ago. The discussion was very interesting and we got to hear experiences from classmates about what they tried to implement, and how they succeeded or failed

Once we were done, Todd Sedano (Director of the Software Engineering program) arrived to tell us his little baby girl was born the night before and he couldn’t join us for the gathering. But he brought us some chocolate cigars and we all got to congratulate him.

After lunch, we had a workshop about professional presentations: we were shown a video of somebody presenting slides during a conference and asked to analyze several aspects of his presentation. The presentation was all about “chicken” (this is the only word he said), but it was nicely presented, and it really helped in showing us that a good presentation is not only about what you say but also how you say it.

We then had a little workshop about patterns: we were put together in teams and had to figure out what kind of patterns we wanted to apply in order to resolve some of our work issues. It was a lot of fun hearing other people’s work horror stories (well maybe not that bad), and trying to figure out how we should resolve the problems: should we take the team out to lunch or organize a brown bag session? Once we were done, each team presented their problem and what kind of patterns they decided to apply. Oddly enough, most of us chose to take the team out for food…

Once the workshop was done we had a breathing and light exercise class. One thing that’s great about Carnegie Mellon West is that it takes a holistic approach when viewing your career and education – and exercise is just as important to your well-being and career as learning code is. It was fun to look at each other struggling to achieve poses that look so simple. Then our guest speaker came in to give a presentation about the culture of change at Yahoo. He had a lot of experience to relate about how they went in trying to push for changes, from Perl to PHP, from PHP3 to PHP4… And it seems like every time they tried something new nothing quite worked like it should have but they keep on learning and trying different ways of changing methodologies, tools… Overall, I think Yahoo is on the right track and it sounded like a really nice place to work at.

It was finally time for dinner (more food, yeah). My group went to a Cascal, a tapas bar on Castro Street: I was at the table with Martin Griss and we got to talk about life, where the industry is headed, and the climate in the various parts of the world we all come from (that was the weekend of the storm in Silicon Valley) while enjoying the delicious food.

The following day, same ritual: we ate breakfast while people were arriving. Then we had a panel discussion about the future of the industry: several professors told us what they thought was going to happen after all these years of being part of the industry: from the rise of embedded systems (phones, toys, MP3 players…) and software as a service to the changes caused by the advent of emerging countries. Dean Morris had an interesting take on the discussion: he asked us what we were working on. His idea was: when you talk about the future, somebody in the room is already working on it.

Our final workshop was a team building exercise: we had to play a game based on the prisoner’s dilemma. And that was a nice metaphor for work: do you want to optimize your output at the expense of everyone else’s on the team or do you try to maximize your team’s output, or even your department’s output. There is no right or wrong answer, but this is something we all have in the back of our heads when we head to work in the morning.

When all of this was done, many of us chose to go to a restaurant in downtown Mountain View where we talked about our experiences at work, how frustrating or gratifying work can be… I think we were all delaying the time to say goodbye as this was such a great weekend. But after lunch we all parted our ways back home to get ready for our last two semesters.

This is the last stretch: it has been an awesome experience so far, and in less than 7 months we will be graduating. Like Dr. Griss said on our first kickoff day: this is a life-changing experience (even though I didn’t really believe it at the time). I had to give up some of my spare time to do it, but I think in the end the results will be more than worth it.

Metrics and the challenges of new teams

2007-12-06T16:07:00.000-08:00

So I’m rounding the corner toward the end of the semester, and I can’t believe we’ve almost completed another course already. This time I’m in the Metrics for Software Manager’s course and it requires us to familiarize ourselves with several concepts that were mostly unknown to us when we first started: a quick survey made by one of the professors on our first plenary session revealed almost none of us had dealt with metrics before. And she pointed out that after a few weeks many of us realized we know a lot more about metrics than we thought.

The format of the course is interesting: we are a team of consultants and we are brought in by a company to help them reach some goals. Usually, the project has some history and we are here to help mitigate risks, avoid the same pitfalls and reach the organization goals.

Of course, none of this is actually spelled out for us. We usually get a description of the problem like what we would get from the customers if we were to talk to them. So, before we even start measuring things we have to figure out what the organization goals are, how can metrics help them and finally make a metrics proposal.

This has been a very hectic course so far, and I have to say I’m looking forward to the end of the class and holiday break. The class structure is comparable to the other classes we’ve had so far, but my team has had a lot of challenges in getting up to speed.

First of all, this is the first time in all my classes that I’ve been on a team where none of us really knew each other: one of my teammates is also a second-year SEDM student like myself, but I’ve never had the opportunity to team with him before. My other two teammates are actually first-year students from the MS in Software Management program, so they are in their first semester at CMU and are still getting accustomed to quick teaming, class structures, etc. This has made the organization of the team take a lot longer than we would all have liked.

Its great to have a new mix of students to interact with – it opens up our network and exposes us to students who have other types of software experience. However, its hard to leave the comfort of the group you’re most familiar with – I’d spent a year already getting to know my fellow Software Engineering students, so now it takes effort on my part to get to know a new group of classmates. On my team, we’ve discovered several very strong personalities, so we’re experiencing a lot of talking and arguing together: this is good in the sense that we are challenged; but probably not the best way for us to be productive.

Finally (and I don’t know if its because of the holiday season or not), we are seem to be very busy this semester – so much so that we never have enough time to work during the week and we end up spending a lot of time working on weekends, and we’ve had to spend a lot of time cleaning up / making changes to the deliverables on top of that.

Thankfully, it seems like we have finally been able to overcome most of these challenges but our workflow is still far from optimal. What I really like about this situation is that this really is the first time I am on a team with issues and that puts a different perspective on the team-building books I had to read during my first year, it went from a concept I could only relate to vaguely to a process I have to live and learn through.

All in all, even though its been a challenging course, I’ve still loved the course content, and really enjoyed the meat of the class. Thankfully, as a team, we have made a lot of progress and we should end up being successful in this class.

Foundations of Software Engineering – Presentation Time!

2007-12-06T15:13:00.000-08:00

Hello, Everyone! Hope you have been getting an understanding on how the CMU West program works by reading all our blogs.

I’m now going to update you on what’s been going on since the last time I’ve talked to you. I’m currently in the fourth and final iteration of our project assignment in the Foundations of Software Engineering class. Our final presentation is this Thursday, December 6^th. So everyone in our team is working away trying to get all the implementation, testing, and presentation slides done and ready. I’m actually very excited for the final presentation. I’m eager to see how the other teams have implemented the project and how our program fares against them.

In the past few weeks we have started getting more into the coding aspect of the class. We have learned to use software like XPlanner to divide up each idea into story cards and tasks. This has helped a lot; and looking back, I wish we had learned to use it better. The way we started coding is by splitting up the code by the UI and the database layer. We would assign two people to each end. And we each jumped around to try to learn every aspect of the code better. I liked this way of doing things since I wasn’t very strong in either end and this gave me a great chance to learn both sides.

Since you caught me toward the end of this class, I’m in a reflective state of mind. What has been done and how could we have done it better and what did I learn? This class forces you to think about those questions at the end of every iteration so the next is smoother. Our team has had some bumps, mainly related to finding a common time for meetings, but overall it has been a relatively smooth process. We inherited code and had to learn that code base and make the call on when to rewrite some things and when to keep what we have. We added a few new features which we will highlight through a demo to our VP of Marketing and VP of Engineering (both roles played by faculty members). Overall I think we have gotten a thorough understanding of the software development cycle from requirements to release. And we’re almost done; this is the final stretch,

Wish me luck!

Happy Holidays,

Sirisha

My Grad School Adventure Begins!

2007-10-31T15:20:00.000-07:00

My name is Sirisha Pillalamarri. Before I start, here’s a little bit of info about me. I’m a 2006 graduate from Carnegie Mellon University (the main campus in Pittsburgh). I received my degree in Electrical and Computer Engineering with a double major in Computer Science. After graduation, I started working at a company called FactSet Research Systems, Inc. They are based in Norwalk, CT, and we make software for Wall Street. It’s a great company and a fun job; however, I had been thinking about graduate school for a while. I wanted to find a program that was more practical than a typical research-based masters for my career progression. I wanted my learning to apply back to my job at FactSet, and I wanted to learn both technical and management ideas. Another requirement for me was that I wanted to keep working in Connecticut while I attending school. I found that all of my requirements converged at Carnegie Mellon’s west coast campus, where I am now enrolled as a remote student in the MS Software Engineering, Development Management program.

So it’s been nearly three months since I’ve started this program and this blog will be a document of what I find on my way!

Let me talk about orientation for a little bit. Orientation is a four day event when you will meet and develop close bonds with all the other students you’ll be working with for the next two years. We have to fly out to California (one of the two required in-person gatherings) and they “orient” us to the program and the course of study. There are a lot of team-building exercises and we get prepped for our first class. The first year of this program is entirely technical, so both the Technical and Development Management tracks are mixed together for the entire year. We are also assigned teams during orientation and we spend a lot of time together. My experience was great! I ended up arriving in Cali a day late and I was very worried of the repercussions; however, the faculty and student services staff at Carnegie Mellon West were amazing! They were so nice and got me caught up and let me settle right in. I also went out during one of the nights to San Francisco with some fellow Software Engineering students (two of whom were my team members) and it was a very fun night and a great way to learn about each other!

After orientation, I jumped right into Foundations of Software Engineering. One of my main concerns was that I would be attending this entire program remotely. How was coding together going to work? Would our meetings be productive? Would I be able to get my ideas in? How would the infrastructure hold together? I was also, obviously, concerned about the time commitment I was taking on, working full-time and attending this grad program. I wasn’t sure how I would transition from working and having my nights free to working during the day and working during my evenings as well!

Well, I can say that the transition has gone fairly smoothly. Since I am in Eastern Time, I come home and take an hour to eat dinner or so and start working on graduate school work at 9:30 PM (6 PM PST) and work till 1 or 2 am. Hey, don’t let the late nights scare you – I may go to bed later now, but I also have shifted my entire schedule - I go to work one or two hours later now but I leave later work later too.

Since we are a remote team, we try to meet everyday for at least five to ten minutes to go over what has happened the day before. Since we spend several hours on the phone, we use Skype as our primary audio software and we use Live Meeting or Himachi to share desktops while we are coding or having a meeting. So far we have not had any major issues with being a virtual team. In fact, it’s more flexible. I don’t have to drive to a certain place to have my meeting or worry about the weather conditions, etc. So to my surprise, working virtually has been quite convenient.

The main challenge (and benefit) of this program and specifically this class, is that you work very tightly with your team. We are assigned to do pair programming, we are encouraged to meet everyday, and the code has so many interdependencies that it is very hard to split up into tasks. In my undergrad experience, I was used to working on my homework or my part and then integrating it with my classmates; it’s a different story at the grad level. So much of what we do is in teams and interactive, that I really have to plan well, so my time is as productive as possible. However, what’s nice is that outside of these meetings, I usually don’t have to do much more individual work for CMU, so that’s a positive. I’ll let you know if this gets any easier as our team learns each others’ strengths better.

The way Carnegie Mellon West is setup is to put you in a real-life simulated environment. It isn’t the traditional classroom setting where you are given strict instructions, deadlines and information that is easy to access. We learn to gather information, ideas, feedback, and suggestions through constant interaction with your peers, advisor and faculty members. So get ready for that.

Anyway, this is the start of Iteration 3 (the week of vacation is over…L). I’ll keep y’all posted on what I figure out, how I do it, and what the end result will be. Keep reading for more updates!

PS: Happy Halloween!

Study groups, Reflections on the first half of the new semester

2007-10-15T15:33:00.000-07:00

Wow, I can’t believe the Elements of Software Management course is (almost) over: only a presentation left and we will all be able to take a well deserved break.

This mini has been very different from the previous classes in that there were no team deliverables: they were all individual and only at the end did we have to make decisions together.

This is very different from what we (the DM students) were used to: our first year was almost exclusively focused on teams, group dynamics and getting to ramp up an effective team. Here, the study group acted more like a support rather than a work group: we relied on each other to talk about our individual work and share knowledge, insight or review each other’s work but we still were working on our own.

The program’s structure was as follows: once a week, we would have a session with a faculty member and other study groups where we would discuss our readings. Some time later in the week our study group would meet and discuss in the presence of a faculty member (our team advisor). Finally, we would hold one more study group meeting where we would discuss and review our deliverables.

This is not a lot of meetings, and quite honestly the change of pace was a little destabilizing: we had to spend a lot more time reading and working on our deliverables than managing a common project. This structure made it somewhat hard to get to know the other people in our study group, and I don’t think we ever passed the Forming stage of team development.

However, I still learned a lot during this course. My objective for the course was to become able to assess a software business’ strategy and financials and I found a new passion: I love reading financial statements and analyzing data. That was not the case of most people in my group (far from it), and it looks many people preferred the strategy assessment part.

Overall, I think I really enjoyed this course and it was a really nice change of pace going from a purely software-development oriented year with classes on requirements, architecture… to something a lot more general that encompasses not only the critical development phase of a project but also the soundness of a business and its practices.

For the last 7 weeks, I have been studying a software company and getting to know it as much as I can. The really fun part of this course is that we have to make a prognosis of where the business we study is going to be in 2 years and I would really love to see how far off from reality I am. Right now, I am pretty confident in my analysis and the soundness of my reasoning but we all know how things can change at the last minute.

I need to go prepare for my presentation tomorrow (wish me luck). Next time I will talk about my first impressions with the next course: Metrics for Software Managers.

Start of Year Two

2007-10-01T14:00:00.001-07:00

Year Number Two has started, and it’s time for me to start the management-specific portion of the program.

We are now separated from the technical track students (if you want to know what they are up to, I suggest reading Minh’s blog), and doing joint work with the software management program students.

During the Elements of Software Management course, we are not working on teams anymore but rather in what we call study groups: our deliverables are individual but we discuss readings and assignments. Also, my group decided to review each other’s assignments in an effort to improve communication and (hopefully) quality.

The basic idea of this course is that we are assigned a particular software company to analyze from different aspects: strategy, finances, etc. It can be pretty interesting at times and pretty boring at others (I’m not a huge fan of financial statements, although some of my other classmates are really into it). However, I think it puts a lot more emphasis on the business aspect of software: this is why I switched from the Technical to Development Management track.

The change of pace is kind of hard to get accustomed to after having fallen into a routine for the past 3 semesters, but overall I think it will make me appreciate better the challenges faced by higher-level managers and executives. So far, I have learned a lot of things with which I was not at all familiar – from finding a company’s strategy to reading a balance sheet.

But more than that, the idea is that we are simultaneously learning all this and doing it at the same time. This is something one of the people in my focus group mentioned: if I only had to do the readings, I would forget that stuff pretty quickly. However, since I am analyzing a company at the same time it actually gives me the opportunity to see how this applies to the real world.

I also think learning this has made me a more well-rounded individual and while I currently don’t need all I’m learning in my job it certainly opens up more opportunities and it has allowed me to have interesting conversations with project managers and directors at work, and I think that’s what this is all about: even though I am far from being an executive I am now able to understand their jobs and the kind of decisions they have to make every day.

That’s it for today. Next time I’ll try to talk a little more on the dynamics of study groups and how this affects the way we work.

Year 1 Retrospection: What I Learned, What I Need to Improve

2007-08-22T10:46:00.000-07:00

In this blog entry, I wanted to go back and reflect on my first year at CMU West: what happened, how things changed… and what I need to improve on.

About a year ago, I went on to attend orientation: there were quite a few of us, and we all had very different motives for joining. Some of us were fresh out of school, and some of us had up to 25 years of working experience. I didn’t really know what I wanted to do, except for one thing: I didn’t like my job and the way things were starting to turn out for me.

Orientation was a lot of fun: we did all kinds of activities, I got to talk with very interesting people, and get an idea of what the program was going to be like (at the time, I was signed up as a Technical Track student). We got to talk with former and current students, and I met my first team. The first semester (Foundations of Software Engineering) had quite a bit of coding and meetings, understanding how classes worked and faculty’s expectations. For me, it was also about working in a team: learning how to depend on other people’s work and building trust. I went through that part with great pain (as I’m sure my teammates will attest).

For the second semester (Requirements), I was with brand new teammates: most of whom I had not really had the chance to talk to before the class. We had three people in California, one in Seattle, and one in Atlanta. That’s when I started to understand the importance of team dynamics and how growing together as a team influences the efficiency of your work. We had been introduced to the Tuckman Model of team building during orientation (the four phases of team building being forming, storming, norming and performing), but now we really got to see the model in action. And our faculty continued to reinforce our team building by helping us stay introspective and reflect on our learnings. We did a pretty good job and I was happy with how we eventually came together.

Finally, the third semester (Architecture) was interesting: in the beginning, I felt like out team was the most lethargic team I had been on. I had one former teammate on that team, and we both thought there was something wrong with the team and how we operated. During the second half of the semester, I became team manager and tried to fight this as much as I could: trying to involve people, make them talk and have fun together.

Here are a few of the comments I got in my peer evaluation (not all comments are here, and not all questions either).

My most positive contribution to the team:

Assertive in making decisions for the team.
Good understanding of issues involved.
His ability to be personable to the rest of the team. A good team leader in making sure that everyone gets his/her chance to talk during the meeting and getting inputs from everyone on group decisions.

What could I do to make higher contributions to team learning:

Maybe Rom could show a little more interest in deliverables he is not directly involved in.
Try to motivate the team to do more than what's just required.
As a team leader, maybe try to develop a team learning plan so he can host a learning session where everyone gets a chance to learn from everyone else.

So, it looks like I achieved what I wanted: the whole team felt involved and enjoyed me as a team lead. However, it looks like I overlooked some of the learning aspect while doing that: I was so preoccupied with making the team “good” that I totally missed other important aspects, such as team learning. That almost looks like the opposite of where I was a year ago: I wasn’t really interested in teams but only in my own self-improvement. Now that I understand what a high-performing team is, I should put more investment into the individuals on that team.

I’ve made some progress, but there are definitely things that I need to work on. Namely, I need to learn not just to view the team as one entity, but also as individual people with unique strengths and weaknesses, and create bonds with them. I have to assimilate the methodology and make it mine, and become human again in my relations with others.

However, in one week, the program is about to take a 180-degree turn: this is when I won’t be involved with Technical Track students anymore but will start the management-specific part of the Development Management program. And you can already see that from the list of books we have to buy (no technical books per se, all management books).

It looks like the course format is going to be different too: we’ll see how that plays out.

For now, I’ll enjoy the vacation with my family.

Aaak! I’m the Team Leader!

2007-07-11T15:38:00.000-07:00

In my last entry, I was celebrating the end of the first Architecture “mini.” Well, now I’m going to share about the beginning of the second half (or “mini”) of the Architecture course. We spent the first “mini” studying various architectures and evaluating them. Since each course builds upon the last, we now need to take that knowledge and choose an architecture for our project.

Each course is set up as if we were employees in a fictitious company, ND Software Systems (random trivia - the “ND” is a reference to “Andy”, in homage to CMU’s illustrious founder, Andrew Carnegie). In this particular class, my teammates and I are acting as a small team of architects and technical experts; and our goal is to select an architecture to present to our VP of Engineering, our VP of Marketing and other executives (all role-played by several members of the faculty).

I didn’t think this would be too difficult a task, except for one thing: I am team lead now. I was chosen because I had never been a team lead here at Carnegie Mellon West before. And that shouldn’t be a problem, except that I have a few faults:
· I’m strongly opinionated
· I tend to talk a lot
· I have always had a hard time at social relationships

I guess you can see how those could be problems when you are supposed to lead a team to success. Since I have been at Carnegie Mellon West I have made a lot of progress in resolving some of these flaws: I have had to read a few books on team communication, and leadership (as well as some books that were not required reading, but recommended by faculty). And while those books could have helped me even if I wasn’t enrolled in this program, the real learning and transformation comes through being forced to put my newly acquired knowledge to the test. What’s nice is that this is a safe “sandbox” for me to play in – I get to flex my leadership muscles, with room for mistakes and growth. If I perform poorly as a leader, my teammates will let me know. And I will probably ask a few team members for their feedback next week.

So far, I have tried to role model a few things: start meetings on time, try to stick to the allocated times on the agenda, and get everybody to talk and express their opinions. Still, sometimes I feel like I’m somewhat authoritarian and close-minded. The good part about being able to experiment with this in school is that I have a opportunity to improve with very little pressure.

This is good, because I can try to improve and “grow my antennae” as one of my former team advisors used to tell us. The odd thing about managing people and talking to them is that somewhere in the gap, you know there is a problem even if nobody really wants to talk about it. I think the difference between good managers and bad managers is that good managers know how to recognize when there are issues and take action, whereas bad managers will stay focused on their objectives while forgetting that they need the whole team to achieve them.

Am I a good team leader? I don’t know yet, but I’m trying to improve. This is both a learning experience and a personal challenge. I want to know if and how I can deal with people other than through predefined social conventions: can I improvise? Can I help the team get the most out of each and every member? Am I bound to fail? Can I overcome my timidity?

I will keep you guys posted.

Architecture and cross-team communication

2007-06-27T10:47:00.000-07:00

I’ve had a lot of things going on lately… I have reconnected with a long-time friend; my first work project is officially going to be complete this week, and I get to enjoy the one-week break between both architecture “minis” (our Architecture course is broken up into two “mini-semesters,” or “minis” for short). Which are all very good things, by the way.

Anyway, I wanted to talk about my experience with the first Architecture mini. You have to understand how the curriculum works: as students we are arranged in teams that get shuffled around each semester. Since this is our third semester, and therefore, the third time we’ve had to go through all the pain and the fun of working with new classmates; we thought we were totally ready to jump into the same routine of figuring out meeting schedules and work styles.

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).

Being a remote student at Carnegie Mellon West

2007-06-04T11:35:00.000-07:00

For this blog entry, I will write about something a lot of people I talk to ask me about: How can you be a student at Carnegie Mellon and live so far from there.

My response is usually twofold. First of all, I attend classes at Carnegie Mellon West, which is Mountain View, CA and not in Pittsburgh, PA.

Second, I am a remote student, which means I don’t go to campus every day or even every week. So far, I have gone to campus a handful of times (I used to live in Sacramento and could justify the 2-hour drive), only 2 of which were mandatory.

Now, if I don’t go to campus and I don’t even have real lectures, is that even a real degree? The answer is YES, it is. It’s challenging, interesting and so far I have learned a lot of no-nonsense software engineering principles and ideas.

The truth of the matter is, I don’t think I could be a remote student and sit in a “virtual conference” with a teacher lecturing and me listening. I mean, when you are in person at least you have peer pressure to keep you coming and staying in class quietly. In CMU West’s case we have better than that: interesting courses and assignments.

Being remote, I have never been on a truly local team, but I have been on mixed teams, and have had to work with local teams. And it seems like the experience local and remote teams are having are very different. Local teams will try to meet in person at least once or twice a week, and when they do they will usually spend a LOT of time together. I have heard some teams work for 5 or 6 hours straight over the weekends, but of course, when you’re meeting together in person, you tend to do more goofing around and hanging out mixed in with the actual schoolwork.

Remote teams on the other hand tend to meet more often (usually 4-5 times a week) but for shorter amounts of time (we usually limit our meetings to 30 minutes to an hour). This means we also want to make the most of our time when we meet: we always want to come prepared to our meetings, have done our readings and we are coming to make decisions or split up work. Don’t get me wrong, we debate and argue but only those points that make sense and we always try to stay on topic.

Most of the time, the whole team is not working on the all the deliverables but tasks are assigned to smaller groups (usually 2 to 3 people), and when that happens we try to find a schedule that works for all of us. I also really enjoy having to work more closely with people as I get to know them a little more personally: we can usually spend a few minutes talking about our personal lives and what’s going on at work.

I also enjoy being able to work (mostly) whenever I want and not having to follow somebody else’s work routine (I usually do school work in the morning before going to work, unlike many people who prefer to stay up at night).

If being remote is so great am I missing anything not being local? Well, for one I feel like I am missing mostly on the social aspect of school: we all try to put our pictures up on IM and on our student wiki pages, and after a while we can all recognize each other’s voices. And usually by the end of the semester I feel like I know my teammates fairly well. However, I don’t know many other people outside my team: I miss on most (if not all) of the meeting events that are organized outside of the coursework.

For example, we have a monthly presentation where some students talk about a Software Engineering subject of their choice. Attendance is mandatory for everybody, but by attending virtually, I miss out on the opportunity to share pizza with and talk with other students.

Overall, I think being remote is an opportunity: I can work out my schedule the way I want, still have a social and a family life (I have a 5 and a 1 year old) and get a higher-grade education at the same time. What else could I ask for? Maybe some rest, but I knew those 2 years of school were going to be a pretty big commitment – however I think in the end it will be worth it.

Next time: I will talk about what has been going on in the architecture class so far and cross-team communication.

First blog entry and team relationships

2007-05-16T11:53:00.001-07:00

Hi everyone, my name is Rom Lemarchand. I have been working for almost 6 years and had jobs in very different industries (telecom, credit card, semiconductors). I just took a job as a software engineer at Qualcomm down in San Diego and have been a remote student ever since I started the program (I will talk about that in my next blog entry). When I’m not working or at school I’m a husband and father of two.

This is my first blog entry for Carnegie Mellon West and I have to say I am a little nervous. I have been in this program for 2 semesters now (only 4 left to go) and so far this has been an incredible experience. I have learned a lot of things about myself, my family and made some friends I know I can count on.

Right now, I have just started the Architecture course and so far I’ve settled into a good rhythm, because each course has a similar structure: in fact, somebody on my team was just saying it feels like now we are used to the swing of things – balancing the work–meeting–homework routine. However, the one thing that stands out to me in making each semester different is not so much the course subject, rather it is the different teams I get put on each time.

I have been on 3 different teams so far, and all of them have been great. Each of them have had their fair share of issues but we’ve always come out better afterwards. In fact, I’ve developed close relationships with so many of my teammates, because of the amount of time we spend working together and interacting with each other, that I realized even with my newest team, we actually care for each other, even worry about each other, despite being a remote team and newly formed.

For example, a teammate of mine had to go on a trip for a few days - that in itself was no big deal, we picked up the slack and forgot about it. However, after a few days we started to get worried - he was supposed to be back but didn’t respond to email and since he was out of the country we couldn’t call him on his cell phone. Thankfully, he came back safe.

However, this experience has made me realize that we are not only here for an education. We are also here to learn how to interact together, how to lead, how to be supportive, how to voice our opinions and concerns… It seems to me that above all else, our team interactions determine our success more than any other factor I can think of.

The main reason why I chose this program is because of its learning-by-doing approach: you can apply what you have learned directly on the job, and I think this is probably one of the most valuable lessons I have learned so far. Technicality is important, but your interactions with other people (management, reports, peers, stakeholders…) will determine how successful you are.

Now what does that mean? Well, I think this is one of those things you have to experience to understand. As software professionals there are a lot of factors that determine our ability to complete our work. Enjoying our work and the people that we interact with is definitely a big part of the equation.

Next: Remote teams: the good, the bad and the better