Throughout most of my education, I was taught that collaboration was cheating. With the exception of teacher-sanctioned group projects, I had learned that working with others to solve problems was not acceptable. So when I got to college and the first assignment in my computer science class was to read an article about the benefits of pairwise programming and open source, I was very confused.
Corporations use this model? Who gets credit for the work? Isn't that considered plagiarism? Countless questions flooded my head, and I started to wonder why I had been taught to think collaboration was bad for so long. Working on my code with others and being encouraged to share knowledge with my classmates was eye-opening and enabled me to see how others thought about problem solving. I began to realize that collaboration was not the evil I had been taught for so long; it was the key to success.
After taking two courses that used pairwise programming, I yearned to expand that way of thinking and acting outside of the classroom. By then, I had become accustomed to a classroom setting where collaboration was encouraged. I longed to work in an environment where I would be encouraged to share my ideas and opinions without fear of being out of line. I didn't know it yet, but I longed to work at a place like Red Hat.
Fast forward about nine months. I had applied for a marketing internship at Red Hat and had just been offered the job. By then, I knew a good amount about the company and how vital open source is to the company's success. Though I knew to expect an open culture along with open code at Red Hat, I wasn't sure what that would look like. During the interview process and intern orientation, we were told that this internship wouldn't be about getting coffee for the manager, or anything of the sort; we would all be integral parts of our respective teams. I don't think that statement really hit me until after orientation when I first started to get to work. I was given tasks that directly influenced and contributed to my team, and I was able to see my work come to fruition over time, but only by collaborating with my team and others to get the job done.
At first, adapting to this new mode of thinking and acting (otherwise known as the open source way) was a challenge. Though I knew that this was the type of environment that would encourage my success, I had to free myself of the shackles of individualized work that I had come so accustomed to for most of my education. For the first few days, I'll admit I was a little frightened to ask questions about an assignment. When emails came through from my team asking for feedback on the first draft of a project, I worried I would say the wrong thing. But I've come to realize questions are good; they show you care about the assignment and getting on the right track. And contrary to what I had been taught for so long, working on a team is not only beneficial to all parties, but it also requires complete and honest feedback.
Once I became more comfortable with this open environment, everything started to fall into place. Instead of being the last one on the team to give feedback, I am now sometimes one of the first. I've learned when and what types of questions to ask, and I don't hesitate to see if other team members need help on a project. I continue to step out of my comfort zone by making the conscious effort to interact with other internal teams and seek out their feedback on projects as well. Because even though it can be nerve-wracking to approach a complete stranger and ask his or her opinion of my work, that is the open source way. And for Red Hat, as well as myself personally, adopting that way has been a success.
3 Comments