When beginning a new job, being able to effectively communicate and understand your peers is vital for your success, and each organization has its own jargon and language that you’ll need to learn. Some of it might be unfamiliar industry standard terms that you can look up online, but other pieces of language might be purely internal terms that you just have to figure out from getting involved.
I recently joined Cryptic Studios as a project manager in the core engineering team. We work with custom technology supporting our live games that have been running for several years, while also supporting projects in development. The language that I’ve been learning comes from many different sources: general software engineering concepts, the names of architectural features in our engine, and our actual player-facing features. As our company works with a number different intellectual properties, there’s also language to learn coming from those fandoms and worlds, represented in our games in various ways. To make things even more fun, all of the above can be discussed using abbreviations or short hand, too!
That’s a lot of things to process, and I tried lots of things in my first few months to quickly bring my communication up to speed, each with a varying degree of success. Below are a few of the techniques that worked best for me, which I’d recommend to anyone who wants to come up to speed as quickly as possible.
I know that not everyone is good about taking notes, but I usually carry a notebook around to take notes in meetings and hallway conversations, and I find those notes invaluable. For the first month or so on the job, I wrote down literally every term I heard in every conversation, with a definition if I could get it easily. My notebook became a sort of glossary for me where I could look up terms as I wrote and read emails or sat in meetings discussing projects. I also usually spent 30-45 minutes at the end of each day searching the Internet and our internal wiki to fill in any blanks in my notes and improve my understanding of things I’d already documented. This extra effort and time allowed me to quickly start contributing to conversations and follow along in broader meetings.
As a side note- I also used my notebook to help learn names of my new co-workers. In every meeting I wrote down names and roles of people who were there, helping speed up the process of recognizing who those people were when reading and sending email. This was particularly important for my role, since our core engineering department works with every other team in the studio, and there were a lot of names, faces, and jobs to get straight!
One of the cool things about being new is that you have an excuse to ask questions. People generally understand that it takes a lot of work to get context as a new hire, and they’re generally willing to provide you that information. As I got to know people, I got comfortable asking the stupid questions (What was that guy’s name? What does she do again? How do I load into the game for this playtest?). From there, I worked to find a few people who I felt comfortable asking the broader, perhaps more sensitive questions (Why is the pipeline set up this way? Why is this the highest priority feature? What was the logic behind that decision?). Both kinds of questions were very important in helping me understand the teams I worked with, and the company as a whole.
One successful technique that one of my new co-workers suggested was to schedule an informal one on one meeting with anyone and everyone that I could. I focused on individuals that it seemed like I’d be interacting with most, and asked them various open ended questions to get their perspective on their job, their team, what they struggle with and how I specifically might be able to help in my role. I found that once I framed the conversation, most people I met with were more than happy to just talk, and that it was more helpful to listen than to specifically lead the conversation.
I’ve heard this often when discussing the job search, but it’s equally crucial once you actually begin to work. You can learn a lot about a company by playing their games and trying to determine how things are put together. You get a sense for what the teams prioritized, what they excel in, and you might get a sense for where they struggled. Playing the games is also a much easier (and hopefully more fun) way to learn about all the game-related jargon than reading wikis, and that’s one less simple question to ask.
Equally as important as playing the games is getting hands into the tools that the teams use or create and actually seeing what they’re working on. This technique was particularly important for my new role, since the custom technology is such a large part of our teams’ work. Looking at the tools allowed me to start visualizing topics of conversation as tangible things, which made the topics easier to for me to understand and discuss.
Learning a new role and a new company is a daunting process with many different elements, and this post only covers the part involved with learning the language of the new position. If you’re looking for more details and a broader view, there are a lot of good books I’ve seen. I found Michael D. Watkins’ book, The First 90 Days particularly helpful in getting a bunch of ideas on how to find ways to work toward the ultimate goal: becoming a reliable contributor as soon as possible.