My manager called, he is encouraging me to write up a blog post about my new role at Red Hat. So I open a browser and surf to my intranet profile to write it and, of course, realize I really need to start an internal blog and not just a one-off post. And I need to start at the beginning, just as I do here.

I started work life as a computer scientist, which I really enjoyed before I tried making money at it. I found coding at the university was a lot more fun than in the real world — there was more exploration, and the projects changed regularly. In the real world, I felt like there wasn’t much variety, or time to be curious — you were given a project and worked on it for long periods of time. Being given a new facet of an old project wasn’t interesting to me; it made me sleepy. Because I lacked passion about it, my career stalled (how could I compete with peers who liked finding and fixing bugs?) It didn’t take long before I realized it wasn’t for me. One thing that always drew my interest was other people, what they did, why they did it, and how.
 
I started leading teams, and managing projects, and earned a Project Management Professional certification. I really enjoyed seeing how I could help people work better together, be more efficient, collaborate better. But something gnawed at me, I was surrounded by really smart people and I had a burning question “why do some people’s ideas get used more than other people’s ideas?” I decided to start answering  my own question in my PhD research, my dissertation titled “Networked Creativity: Understanding the Process and Effect of Interpersonal and Networked Interactions on Workplace Creativity”.

After earning my PhD in Communication, Rhetoric, and Digital Media from North Carolina State University in 2014, I used what I learned to inform my decisions and processes as a program manager.  I studied how interconnected system elements influence individual and group creativity — so I’m sensitive to the ways that these elements can support or hinder workplace creativity. These elements include things like processes, roles and responsibilities, tools, work objects, and different communities (e.g. teams) that we are part of in the workplace.
 
When I approach my role at Red Hat, I try to do so with a “light touch”. Culture is both a sensitive thing, and a powerful thing, and it’s hard to tell when it is one or the other.
 
Generally speaking, the software industry socializes leaders to be aggressive, power through decision making, and make a measurable and fast impact on organizations — but that’s the surest way to do more harm than good, especially at a unique organization like Red Hat.
 
So I approach interlock from something like the 80/20 rule — what 20% of change will give us 80% of the benefit? What is the easiest thing for teams to do to make themselves more informed and efficient? What is already part of a team’s workload or process? What can we reuse? What can we reorganize? This simple (and one hopes, elegant) approach helps to add immediate value to my role as well as preserve the unique Red Hat culture.