From Public Relations to Pull Requests: My First 30 Days on an Engineering Team
The first thing I noticed when I started sitting with our dev team wasn’t how dim the lighting was, how colorful code could be, or how much better their snacks were. It was that everybody kept talking about “PR”. I had just moved from our public relations team to our product team, and I couldn’t believe how much PR talk we had been missing out on upstairs. PR this, PR that; every time an engineer said those two little letters, I’d try to piece together the rest of the conversation like a puzzle. Only I didn’t have the picture on the box so I sat there for about a week thinking, since when do developers care so much about PR?
They don’t. That’s the thing. PR stands for pull requests (what developers submit when they contribute to open development projects to let others know a change has been made). This was the first of many party fouls I’ve made on HubSpot’s engineering team. See, I was on the marketing team for about two and half years before moving over to product. I think in coverage and mentions, not reliability scores and WAUs. But it turns out these two worlds aren’t mutually exclusive. There’s a middle ground and it’s about 5'4", 120 pounds, and still doesn’t have a driver’s license.
I joined our dev team to help build a bigger and better brand in the product development world so that when an engineer in Denver hears “HubSpot”, she’s not only heard of us, but she knows we’re building challenging software on cutting-edge internal tools in the confines of a world-class culture. (Always be recruiting, sorry). This is a new role at HubSpot. There’s no internal playbook or old Google docs I can look at. That’s exactly why I jumped at the opportunity. But it’s also what scared me.
John Collins put it best in his post announcing his new role as Managing Editor at Intercom, “In some ways we’re hatching our own petri dish experiment — putting a journalist into a room of engineers and designers and seeing what happens.” This reminds me of that scene in Jurassic Park when Richard Attenborough hatches a baby dinosaur like it’s nothing. It’s intriguing, but a little ominous. Would the experiment go well? Would the journalist make it out alive? Judging from how many devs, designers, and PMs on our team have told me we should try to emulate Intercom’s blog, I’d say it was a success.
I’ve never spoken to Collins, but I imagine he felt some degree of culture shock at first. I know I did. But not the disorienting, “take me back to the Marriot immediately” kind you feel in a foreign country. It’s just different. For the first time, I’m asking more questions than I answer. I’m finding the balance between how I do things and how things need to be done. I’m putting asterisks on all those tips for young professionals on “navigating the workplace.” And, I’m learning from my party fouls as quickly as I’m making them.
One mistake I made early on was subconsciously deciding that when things got too technical, I’d tap out. The thinking was, I could ask how our tech stack is built, why some engineers prefer one language over another, or why we had to move from Python to Java before kicking off i18n. But, the answers would probably be over my head so why even take up someone’s time getting into it? I’ll just focus on what I do know, like creating content and spotting the stories worth telling. Looking back, I call bullshit.
I might never become a senior tech lead, but that’s not because my brain would break if I tried. Product development is an entirely new world and understanding it is just as important as blogging about it, pitching it, or tweeting about it. In fact, you can’t successfully do any of the latter without the former. That’s why I wish I would’ve been as adamant about absorbing content as I was about shipping it in my first few weeks. Anum, on our Sidekick Growth team, blocks off an hour on her calendar every morning to read and catch up on what’s going on in the world of SaaS. I love how unapologetic that is. Learning is part of the job and it should get the same GSD (get shit done, a HubSpot motto) attitude as any other task.
Working on a product team when you’re not a product person can be hard, really hard. But that attitude doesn’t help; thinking of yourself as a tourist will make you one. I went into this thinking, like Collins, I’m a marketer in a room of engineers, designers, and PMs: let’s see what happens. But this isn’t an experiment and I’m not a potentially-lethal baby dinosaur. As I submitted my first pull request on GitHub last week, I smiled and thought, I am a product person now.
Someone in a Nick Cage movie said, “If you’re going to get wet, might as well go swimming.” When you’re joining a new team, department, or company, I highly recommend jumping in the deep end as early as possible. It might sting a little at first, but that’s just culture shock. It’ll pass.