Imagine having a career at a company where you can bring your ideas to management or engage in discussions with the key developers and founders of the software with which you work. In many organizations with traditional hierarchies, being a newbie may mean you’ll be ignored in these circumstances or, at best, will receive a short reply weeks later.

This wasn’t the case for me during my experience as an intern at Red Hat. As CEO Jim Whitehurst points out in his book The Open Organization, at Red Hat the best ideas always win, no matter their source. In such a meritocracy, even an intern like me has a voice—as long as I can back my ideas up.

From my first day as a new member of Red Hat’s Kernel QE (Quality Engineering) team, I knew I was in for a ride. I was tasked with bringing CI (Continuous Integration) to Red Hat’s InfiniBand tests. For those unfamiliar with what that means: CI is a test-driven development practice in which developers execute automated unit tests often, such as when a developer pushes a patch via Git. The earlier we run tests that can inform developers a patch has an issue, the sooner they can fix it. This process helps alleviate the pressure associated with failed nightly builds or builds overloaded with bugs when handed to QE. In short, the description of my task was short and to the point.

But that was it. My team gave me a few pointers on the tools I’d probably need, as well as some documentation, and set me free. What makes the task even more ambitious is that some of the frameworks and tools I required to accomplish this were still in development. The task quickly turned from “add something” to “lead the way,” a position in which you wouldn’t expect many interns to find themselves. My team knew I loved challenges, so it was a great task for me.

As I learned how to provision machines, automate workflows, integrate frameworks, debug processes, and trigger builds, I found myself constantly communicating cross-team and globally. I met often with my mentor and frequently had conversations with members of the platform team, kernel developers, and some of the QE folks from China and the Czech Republic. At first, I was reluctant to constantly ping them. However, they were always welcoming and open to feedback, and they kept me up to date with their progress. Soon I experienced Red Hat’s climate of transparency, respect, trust, and collaboration firsthand.

While constant communication across all of these teams was essential in building up this CI suite, everything still felt too scattered. So many components must come together for CI to happen efficiently. I therefore took it upon myself to begin writing a “how-to” guide on integrating CI into more kernel tests. I pulled together every relevant document and team contact, added in code snippets and screenshots, and drafted some best practices. My goal was not only to put everything in one place but also to make CI seamless for others.

My manager loved this idea when I showed it to her. Once my mentor saw it, we started scheduling weekly meetings so he could follow my step-by-step guide, verify the processes, and help me fill in any pieces I missed. How many people can come out of an internship saying they got to define their own work, engage in it passionately, and add this much marketability to their overall experience?

Everyone else that discovered this guide seemed enthusiastic, too. For example, one of the kernel hardware supervisors contacted me to ask if he could share it with his team. I was thrilled to agree. Suddenly I was making an impact not only with the work I produced for my own team but for other teams as well. With every code change I made through Git and every revision I saved to my document, I felt that much more influential. To top this all off, I wrote the guide as a community wiki. As Red Hat continues to grow and inevitably evolve, anyone is free to revise the guide, add to it, and keep it up to date. This is something you can only get in an open organization that balances freedom, courage, commitment, and accountability as core values.

Sure, I may have only contributed a couple hundred lines of code. In the long run, however, I know that my CI efforts will soon pull together better software that’s tested thoroughly, beginning with the community of developers themselves. I see that as indirectly contributing millions of lines of better code. I had an idea on how to do something better and took action on it, a freedom you won’t find in other types of organizations.

Intern
Stories

This article is part of the series of Red Hat Intern Stories. These interns share their experiences about what it’s been like to work for an open organization, and more.