By Veronica Ray (Senior, Duke University)
This semester, I took a Computer Science course at Duke called Apps: From Concept to Client. My three-member team worked on a native iPad application for Visualizing Venice, an interdisciplinary collaboration between graduate students and faculty at Duke and universities in Italy.
I was nervous about this class because I hadn’t taken software development, the suggested pre-requisite. Out of 20 students, I was one of three girls. At the beginning of the semester, I worried that telling my teammates I wanted to be the project manager would backfire. What if they told me I had to code, and everything else I was doing was just grunt work? I’m also a girl. How stereotypical.
I knew I could be a good project manager because of my experience freelancing and doing internships at startups. I’ve made enough mistakes with clients to know the issues we would run into if no one took initiative on these tasks. Fortunately, my teammates didn’t want me to do an unfair share of work and agreed to my “no-coding” policy. My teammates expected me to handle communication with the client, project requirements, user testing and documentation. I expected each of them to handle front-end and back-end development respectively. I went into this class with some preconceptions about how an ideal project manager should act. I learned that the reality was more complicated.
Assumption: I needed to make the work as easy as possible for my teammates
The leader of the client team had ambitious long-term plans for the application but no idea about how it would work technically. During meetings my teammates would freak out because they thought we had to do whatever she said. However, I had built up a rapport with the client throughout the semester and knew that she liked to dream out loud and couldn’t contain her excitement about all the potential extensions of the app.
I didn’t want to be the dreaded project manager who gave my teammates an unrealistic workload because I couldn’t say no to the client. However, my teammates also wanted to work hard and cared about impressing the professors. They knew that the professors would be satisfied if we made an application that was below our capabilities, even if the client was happy. At the end of the semester my focus on the client and my teammates’ focus on the professors ensured that we impressed both parties.
Assumption: I needed to be hands off
Late in the semester, one of my teammates asked me to check in periodically on their progress. Since a list of the features and their due dates was available on Google Drive, I didn’t think I needed to check in. I trusted my teammates to finish the features eventually. We also met face to face once a week (at the request of the other teammate) and had class together once a week.
However, my periodic check-ins had many positive effects. I answered questions about the requirements. (Side note: communicating requirements is hard.) My teammates let me know when specific features were done so I could test them. They also told me when they were too busy to get anything done for a couple days.
Assumption: I thought my teammates would have all the answers
Since only one member of our group had written any Objective-C code, we all began on a relatively even playing field. My experience working at startups and freelancing instilled within me a love of self-learning. I relied on Lynda, Stanford’s iPhone development course, Hacker News Search and Stack Overflow to learn the basics of iOS development.
I told my teammates how to use git with Xcode, researched the pros and cons of Storyboards and CoreData and identified the NinehvehGL framework for 3-D models. My teammates handled the implementation of many impressive features like a database, popovers, video, a timeline and an interactive map.
Now that I’m applying for jobs, I wonder if I should have been a coder instead.
Experience writing code for a native iOS application would make my resume more attractive for the Software Engineering roles I currently seek. However, unlike coding experience, project management experience is virtually impossible to get outside of a project management job. I could code up an iOS app in my pajamas from the comfort of my dorm room. I can’t say the same about being a project manager.
This class taught me that technical project management is a role I’d like to play in the future. It taught me how to plan user testing, write software documentation and manage agile software development. Most importantly I left the class with the confidence to learn new technology.
Women 2.0 readers: How did you decide between pursuing project management and development training and/or roles? Let us know in the comments.
About the guest blogger: Veronica Ray is a senior at Duke University, double majoring in Computer Science and Public Policy. She is taking classes on operating systems and computer architecture this upcoming spring semester. Her personal website is here. Follow her on Twitter at @nerdonica.