Role Models: Rebecca Poulson, Technical Program Manager, Emerging Platforms at Northwestern University

rebeccapoulson

Today’s Role Model is Rebecca Poulson. Rebecca studied art history and creative writing in college and then spent her early career writing and directing plays. She found herself being drawn towards technology enabled experiences and interactives and then started coding more seriously, working as an engineer at Kickstarter for a couple years. In her current role leading AR/VR projects in the journalism school at Northwestern, she gets to combine her background in technology and storytelling. Rebecca also speaks at conferences (she gave WebVR workshops on three continents last year) and enjoys cooking, knitting and playing with her dog.

What’s your official title and how long have you been in this role?

Technical Program Manager, Emerging Platforms at Northwestern University Knight Lab. I’ve been at the Knight Lab for 2.5 years and I started my current role in March 2017.

What attracted you to this role?

When I started at Knight Lab I was a web developer who did VR stuff as a hobby. I was lucky to join at a time when the lab’s interest and investment in VR was growing. About six months into my time at the lab, one of the faculty members I worked with really championed me. We were able to design a role that took advantage of my interdisciplinary background and combined coding, design and student engagement.

Walk me through a typical day in your role. What activities do you engage in? What types of meetings do you join? When’s lunch?

I bring breakfast from home and eat it at my desk while answering emails first thing in the morning. (This period is the only time I look at my work email.) I like to do quiet focussed work in the morning and I like to start my day by learning something new.  After email, I’ll read a paper or watch a talk about AR or VR. Following that time, I might be investigating a new library or prototyping tool or debugging student work. At the beginning of the school year, I was doing a lot of interviewing and hiring. Before lunch I try to do a little planning work, pulling potential readings, adding comments to Trello cards for the projects I manage or getting things together for upcoming events.

I take lunch around 1-1:30, which is apparently “very New York” of me. Most of my colleagues eat earlier. I try to take a walk around campus if the weather’s nice or do a little bit of knitting. I try to do most of my “peopling” work after lunch. Two days a week that’s leading a project in our Knight Lab: Studio class; the rest of the time it’s checking in on the student fellows I manage. I’m usually out shortly after five but sometimes I shift my time so I come in later in the morning and leave around 7pm since it can be tough to coordinate a group of students when you’re only available 9-5.

What skills/technologies help you succeed?

Technically, I alternate between web projects which use Javascript and projects that use the Unity game engine, where I write code in C#. I also do a lot  of research and information design and mentorship.

What’s the most fun or creative part of your role?

I love working with student fellows on experimental AR/VR projects. When I design a project for the fellows, I approach it from a place of “Okay, these are the technologies and techniques I’m interested in exploring; these are the skills and interests my student team has; and these are the experiences they need to acquire to be ready for the kind of jobs they want.” Those are really inspiring constraints to build around.

What are the biggest challenges you face in this role?

The breadth. My role is really multidisciplinary, which is why I love it, but it’s really demanding to maintain such a broad skillset.

What teams/individuals do you work with cross-functionally? Can you give an example of a time when you collaborated with another group/individual?

The big tent pole project for our lab is the Knight Lab: Studio course, a multidisciplinary course that runs every quarter. It’s team taught by a journalism professor and a computer science professor and I and the other staff developers act as project leads. Before registration, we all pitch projects that we want to work on and then we open applications to assemble cross-functional teams made up of students all across the university. We just opened applications for winter quarter where I’m running two AR projects–one is a user research project where we’re play-testing an AR game about climate change, and the other is a prototyping project where we’re reimagining what different storytelling forms might look like in AR.

What’s an area where you’re trying to grow in your role?

I’m trying to be more strategic. In a role like mine it’s really easy to be like, “Ooh, shiny!” and start exploring something new. I’m trying to have more big-picture vision and purpose to the things my team works on.

Aside from technical skills, what personality traits/characteristics make for an ideal candidate in your role?

The ability to be self-directed and learn new things. A high tolerance for ambiguity and willingness to fail. Also the ability to persuade people that they’re capable of things that sound kinda crazy comes in handy.

What skills (tech/non-tech) have you improved as a result of working in this role?

I used to struggle with feeling like my work had to be perfect before I showed it to anyone and I’ve really had to work on that in this job. Emerging technology moves so quickly that by the time you’ve done anything, there’s a better and faster way to do it. You can’t afford to be precious.

In your role, what metrics define success?

I don’t really have a quantifiable definition of success–which can be both liberating and anxiety inducing. I definitely consider any project we ship or research findings we can share out to be success. I also get really happy when students bring their parents in to the lab to try out VR.

Role Models: Heather Stenson, Technical Writer at Mapbox

Heather Stetson is a technical writer for Mapbox

Today’s Role Model is Heather Stenson. Up until three ago, Heather was a librarian at an art school. Feeling burnt out and looking for her next step, she began to reflect. She enjoyed the more technical aspects of her librarian job and knew basic HTML and CSS, so she enrolled in a coding bootcamp. Upon graduation, she expected to look for a job as a developer, but a friend pointed her towards a technical writing role at Facebook. After researching the position, she realized that it was the perfect marriage of her library background and her newfound tech knowledge. Heather is currently a technical writer at Mapbox, a location data platform.

What’s your official title and how long have you been in this role?

I’m a technical writer at Mapbox, a location data platform, and I’ve been here for about 8 months. Before that I worked as a hybrid tech writer/content strategist at a startup called CodeFights (now CodeSignal), and before that I was a tech writer at Facebook.

What attracted you to this role?

Mapbox is still a pretty small company, but its tool and product offerings are really wide ranging. I don’t like to work on just one thing, so the fact that I’d get to work on documentation for a lot of different products was really appealing. And the documentation team is really small – there are only two of us – so I knew that I’d have the opportunity to have a big impact on the organization. Even though the docs team is very small, there’s a really strong culture of documentation here. Everyone pitches in to make sure that our documentation is useful and thorough. It also helped that everyone I came into contact with at the company was super friendly.

Walk me through a typical day in your role. What activities do you engage in? What types of meetings do you join? When’s lunch?

Mapbox has a lot of different offices spread out across the world – San Francisco, Washington DC, Minsk, Helsinki, Shanghai, Beijing, plus a lot of remote workers. Since we’re so distributed, we communicate a lot using Slack. We also use GitHub issues to coordinate a lot of work! So when I start my day, I check in on my Slack and GitHub notifications. I have keyword notifications set up so that I can always know when my coworkers are talking docs! I make a pretty detailed to-do list for each day so that I know what to focus on. Then I grab an almond milk latte and get to it.

I’m usually juggling several different projects, and if they have regular meetings/scrums I’ll join in on those so that I can keep track of what’s moving. If I’m just starting a big project, I try to have a meeting with the stakeholders (usually a combo of project managers and engineers) early on so that I can get a good sense of the project’s parameters.

I try to leave the office at least once a day to remind myself that there’s a whole world outside the office. At Mapbox, there’s a rich tradition of the“cookie walk” – folks taking some time in the afternoon to go grab a sweet treat – but sometimes it’ll be coffee instead.

What skills/technologies help you succeed?

At every technical writing job I’ve had, the one constant skill that I’ve needed was being able to write markdown, a formatting syntax that can be converted to HTML. It’s the formatting syntax used in wikis, and it’s also pretty standard in a lot of documentation frameworks. Beyond that, it’s also been helpful that I know HTML/CSS. This allows me to have more control over how the documents I write are formatted.

At Mapbox, we use GitHub for everything, so it’s been critical for me to know how to use git and GitHub, and to feel comfortable doing things in the command line. Knowing how to “read” code is also useful – I can look at a snippet of code and get a sense for what it does, even if I don’t know the language it’s written in.

What’s the most fun or creative part of your role?

Every new product that I write about means another new toy that I get to learn how to use! Before I can write an effective guide or tutorial, I need to use the tool or product so that I can unearth potential user pain points and guide them to a good outcome.

What are the biggest challenges you face in this role?

One of my biggest challenges is juggling lots of different projects at once. Docs never stop, so I usually have at least five projects that I can work on at any given time! It’s really important for me to be able to weigh something’s potential impact against the time required to complete the work, and prioritize accordingly.

What teams/individuals do you work with cross-functionally? Can you give an example of a time when you collaborated with another group/individual?

The documentation team at Mapbox works with nearly all of the product teams! When a new product is released, or a tool is updated, this means that we’ve got work to do. We typically collaborate with a combination of product managers and engineers when we’re working on documentation – they provide background, technical details, code examples, and just generally help guide the work we do. We also work really closely with the support team. Since they are constantly interacting with Mapbox users, they are able to identify ways in which we can improve our documentation.

What’s an area where you’re trying to grow in your role?

Right now, we are in the process of moving to a new documentation framework that uses React. While I don’t need to know React in order to use the system, I’ll need to know it in order to build my own components! If I think of a cool new UI component that I’d like to be able to use across various documents, I really want to be able to build it myself.

Aside from technical skills, what personality traits/characteristics make for an ideal candidate in your role?

Good technical writers are naturally curious people! They want to take things apart and see how they work, then share what they’ve learned with others. Being detail-oriented and organized are helpful as well.

What skills (tech/non-tech) have you improved as a result of working in this role?

I have a tendency to try to power through problems to find the questions myself. In some ways this is a good thing. But when the subject matter expert for the problem I’m working on is a mere Slack message away, a lot of times it doesn’t make sense for me to spend hours struggling with a question! So I’m getting better at timeboxing problems – if I don’t reach the answer myself in a reasonable amount of time, I reach out to someone who knows the answer.

In your role, what metrics define success?

As a team, we’re still working on defining what “success” for a piece of documentation is, and how we measure that. We’re exploring a lot of different ways to capture user feedback and user actions, and then turn that data into a way of measuring success. Anecdotally, though, we get a lot of feedback from different channels that people love our documentation and find it to be really helpful, so that’s a good way of knowing that we’re on the right track!

Want more of these interviews delivered directly to your inbox? Sign up for my monthly newsletter.