How to Help the Newbie
For SXSW Interactive 2017, I was asked to give a 5-minute, rapid-fire talk on how (& why) to empower new team members. But, how much can you cover in 5 minutes? Here’s a deeper dive, based on my experience on the product teams of IBM Design.
The Challenge
Imagine a software company, growing their numbers through frequent hiring and acquisitions. New employees are then dispersed across the organization’s wide range of products. How do you equip these recruits for success on their new teams?
In my year and a half at IBM Design, I’ve seen many people struggle as they are placed into domains and teams they know little about. Here’s what I did to solve this problem—first on my own team and then scaled through product teams across IBM.
‘New Collar’ Workers & IBM
IBM works to solve complex problems. We build software tools for rapidly changing industries: security, analytics, healthcare, you name it. IBM needs to know to where each market is going, so they can disrupt it before their competitors.
Ginni Rometty, IBM’s CEO, has spoken to why bringing on ‘new collar’ workers—who lack traditional degrees in a field—plays a huge part in filling the needs of the changing market and IBM’s restless reinvention.
We are hiring because the nature of work is evolving — and that is also why so many of these jobs remain hard to fill. As industries from manufacturing to agriculture are reshaped by data science and cloud computing, jobs are being created that demand new skills — which in turn requires new approaches to education, training and recruiting.
Here’s where designers, like me, come in. IBM saw Design Thinking, with its focus on user needs, as the way to reinvent their approach to software. Over the past 4 years, designers from all backgrounds—industrial design, research, user experience, branding—have been pouring into IBM and joining product teams.
Falling into the Knowledge Gap
This doesn’t change the fact that you can’t build a product you don’t understand, for a user you’ve never met, against a competition you’ve never heard of. When designers are unfamiliar with market-space they are building for, how do you keep them from being lost and unable to contribute?
Take me for example: I studied print design in school. I had never worked with developers before landing at IBM—much less built products for them. You can imagine my confusion and learning curve when I joined IBM’s Cloud Infrastructure team. Within this team that provides IaaS (Infrastructure as a Service) on a platform for developers, I was working on the UX and visual design of block, object, and file storage offerings. Provisioning, virtual machines, OpenStack, public vs. local vs. dedicated—jargon was flying over my head. For months, I tried to decipher conversations and prioritize tasks—unsure who to ask for help. I sat silently in meetings—afraid to speak up in case I said something dumb. Soon, I realized mine was not a unique experience. As I talked to other recent design hires across IBM, I heard more stories of knowledge gaps and isolation.
But this isn’t just an ‘IBM problem’ or tech industry problem. Most businesses struggle to find time and resources to get new recruits up to speed. You’ve experienced this yourself in some capacity—struggling to find your footing in a new environment or working with a struggling new coworker.
Whose Job is it to Fix This?
If no one takes responsibility for fixing the newbie’s experience, it remains broken. But whose job is it to fix it? While the answer is going to be different for each job environment, a little initiative can turn the pain-points of new hires and their coworkers into opportunities. Here are 3 different entities that can tackle the problem:
- It Comes From a Corporate Level
For this route, company leadership creates and distributes the resources new team members need. While a smaller company (or one with teams working in similar domains) could pull this off, it isn’t a viable option for IBM Design. Corporate leadership can (and do) provide introductions to IBM’s rich history, best practices, and organizational structure. But can the team focusing on broader company vision speak to the daily operations and goals of thousands of product teams? It would be a nightmare to assemble and update programs for each of it’s every changing product teams. IBM’s solution needed to be scalable, and this—frankly—is not.
2. It Comes from Product Teams
Here, individual product teams set up conversations, time, and resources to prepare their new recruits. With each team responsible for the construction and upkeep of these efforts, this is ideal for teams around IBM Design. Because the initial effort seems daunting, this wasn’t happening when I joined IBM. My guess is it isn’t happening in your company either. Setting aside the time and focus seems difficult amidst the varying factors on each team. New hires join with short notice and have different product familiarity—not to mention you have your own job to do. Managers and teammates go through a guilt cycle, failing to prepare for newbie after newbie. As I’ll discuss later, empowering recruits doesn’t have to require crippling amounts of pre-work and planning. When done well, the small, initial efforts to will pay you back ten-fold.
3. It Comes from the Newbie
As people become busy, they develop amnesia about the pain of their own first months—and preparing for newcomers is easily overlooked. This leaves new team members with a choice: 1) accept the situation as inevitable or 2) create a solution. This approach transforms resignation to empowerment. As new hires gather resources for their own understanding, they pave the way to for the next newbie. And that is a beautiful thing—multiplying efforts of a few to help many. So, when I don’t have the tools I need succeed on a new product team, I build them myself—and you should too.
Creating a Solution
Determined to make the transition easier for those joining the product after me, I paired up with a teammate—the brilliant and talented Alex Hadick. We devoted a two-week sprint to planning the onboarding experience for six recruits joining teams across Bluemix only four months after we did. While studying the essentials to new hire success, three core needs surfaced:
- Inclusion in Team Culture
- Understanding the Domain
- Ability to Contribute
Applicable for any team or industry—these needs answer hopes and fears of those joining a team. Here’s how we addressed each within IBM’s Bluemix product teams, with pared-down examples that can be applied in your own team environment.
Inclusion in Team Culture
Newcomers want to be able to communicate well with their coworkers. However, they don’t instinctively know how to read each person—and don’t want to become that person by making a wrong move their first week. Something as simple as saying “Hi” to a coworker in the hallway can seem like a daunting task. Indirect forms of communication in the workplace abound, and one misinterpreted Slack comment can make you sound like a jerk. Creating situations for teammates to interact in relaxed environments help prevent months of backpedaling or isolation.
- Inclusion on Bluemix: The morning the six newcomers arrived, we brought them together with their new teams for a rousing game of Pictionary—fueled by donuts. This was a great way for the new folks to observe their teammates’ personalities and communication styles in an informal, low-pressure environment (and let them know what time they were expected to arrive their first day). Happy hours throughout the week provided opportunities to observe and be welcomed into the team.
- Inclusion on Your Team: You can make this simple. Ensure no one eats lunch alone on their first day, introduce them to each person on the team, or have coworkers leave encouraging notes on their desk. Although these things don’t require much effort or pre-planning, they go a long way to making a new person feel comfortable with relating to their coworkers.
Understanding the Domain
Newbies are aware that they have a lot to learn. Within the complexity of IBM products, the knowledge gap can feel paralyzing. Afraid to ask “dumb” questions and drowning in lingo—many don’t know where to begin. Having a foundational understanding of the problems you’re trying to solve is key to adding value to the team. It often takes six months—if not longer—to begin to ‘know what you don’t know.’ Providing a jumping off point for new coworkers gets them on their feet and contributing in meaningful ways.
- Context for Bluemix: Bluemix is a complex product, requiring a big picture understanding before a designer can build for their assigned services. During the newcomers’ first week, we brought in subject matter experts from across the organization to cover the basics of Cloud. After giving the context for Bluemix as a whole, we dove into the services and teams where each of them would be specifically working. Though full mastery of each concept in a week wasn’t realistic, ideas were reinforced through repetition and session leaders were identified for follow-up resources. To supplement the material and allow for learning at their own pace, we provided a Bluemix Welcome Kit PDF. Filled with long and short form articles on the domain, a detailed glossary, and organizational breakdown—the document worked towards cementing concepts longterm.
- Context for Your Product Domain: This is easily the most intimidating area for teams to address. Lack of time and focus—valuable and limited resources on fast paced teams—create a hard-stop for preparing resources prior to a new hire’s start date. Fear not! There are low time and energy ways to provide market context for newcomers. Here are just a few: On a new recruit’s first day, gather your coworkers to write a few words (2–3 sticky notes each) in response to the prompt “Words I Wish Someone Had Defined for Me on my First Day”. Post them on a wall and define them as a group. Or, every time you send a link to a new coworker (everything from presentation recordings to sites of competitors) save them in a document or folder, allowing you to have a concentrated entry point for newbies to come. Activities like these take less than 10 minutes but significantly lower the barrier of entry to build for a product.
Ability to Contribute
As my teammate, Jennifer Wright, recently pointed out, defining expectations prepares newcomers to contribute in ways their team will recognize and appreciate. When a newcomer doesn’t know what is expected of them—how frequently to share progress with teammates, where the team tracks tasks and files, what level of fidelity to work at, online hours of the team, and the like—they can’t be successful on the team. Trial and error methods often backfire, but so does excessive timidity caused by fear of doing ‘the wrong thing.’ Clearly defining the expectations of the new hire and their coworkers prevents frantic, after-the-fact damage control.
- Contributing on Bluemix: Workshops around the agile practices of Bluemix teams provided our newcomers with context into the expected pace and frequency of communication. Coworkers lead tutorial working sessions on commonly used tools like GitHub, Slack, and Sketch. Sessions like ‘Reality Check’—which discussed the unique challenges on Bluemix, like working with acquired companies, legacy products, and merging consoles—fostered candid discussions among the new and old teammates.
- Contributing on Your Team: Since many questions on contributing arise over time, one of my favorite methods is pairing new hires with a “Forever Buddy.” Match them with a person who works on the product they are deployed to (similar discipline is a bonus)—and establish an open line of communication. I tell newbies who join my product they can ask me any question—however small—at any time. Now, they have an ally on the team—and it provides a great catch for team practices you couldn’t communicate their first day. Here’s another easy option: set up meetings on their calendar with any mixture of disciplines on their team, and give them a prompt—What features were in our last release? What is your ideal interaction with your team members?—to get the conversation going.
The Payoff
When the initial contribution to these programs is a foundation for each new team member, the benefits are multiplied. Encouraging newcomers to improve the process for those who join after them not only brings a fresh perspective—it allows programs to live on. When efforts are hinged on one person, they easily die off if that person moves teams or leaves the company. I’ve witnessed the difference these efforts have made for myself, my coworkers, and product teams across IBM Design. Lack of time and focus doesn’t have to rob you of the benefits of equipping newbies. Because in the end, setting new team members up for success creates open communication, efficient teams, and better products. Who doesn’t want that?
