How To Make On-boarding Easy with Trello
When I started building the Product Design Team at ATTN:, I knew it would be important to nail the on-boarding process. Sure, you make a first impression (and probably a second or third) with a new hire during the interview phase, but I really believe that the way someone is brought into a team is the first step in establishing a good working relationship in the months and years to come.
I’ve seen a lot of various approaches when it comes to addressing an employee’s first day. On one end of the spectrum, you have what I like to call the “Walkabout Method,” where an employee receives their basic needs — equipment, desk, chair, email — and then becomes responsible for forging their own path as they get situated. Want to meet someone? Walk up and introduce yourself! Need access to something? Go find it!
On the other end of the spectrum, you have the manager who sits by your side to walk you through everything and anything related to your job. This can be somewhat effective — and definitely helps form a bond — but is a big time suck on both ends. Plus, it’s not very scalable as your team grows, and makes a manager the gatekeeper of, well, all of the things.
Obviously, I wanted our process to fall somewhere in the middle.
The Problem
Up until this point, our existing explainers when it came to team processes centered mostly around engineering talent, so while the premise of documentation was strong, the actual documentation wasn’t all that relevant to designers. Plus, most engineers were remote and relied on README files and wiki documentation for initial project setups when they were getting started. Product Designers would be onsite and expected to work with both Product Managers and Engineers pretty much immediately, which meant they needed to be as autonomous as possible.
A lot of our team-wide policies were buried in slack posts and emails, which made them feel fragmented and hard to find. I had started a Product Design Wiki in an attempt to cover larger themes like our design sprints, handoff process, and communication tools, and even included a checklist that new hires could complete— but something was still missing. Designers needed a way to grasp the micro and the macro concepts needed to not only gel with the team, but the company at large.
Deciding On An Approach
The folks at Trello are a smart bunch, and as much as I’d like to take full credit for this, I have to admit I was inspired their dogfooding of Trello boards for on-boarding purposes. At ATTN:, we also use Trello for the majority of our Project Management needs, including our engineering and design sprint boards. Thus, our On-boarding Trello Board Template was born.
How it works
We have a master template that anyone on the Product Design Team can contribute to. This allows us to keep it up to date, and share the responsibility of maintaining it. It also gives new employees the power to add something that might have been missing from their experience, so we can do better next time.
When we hire a new designer, we copy this board and label it with their name. This board ends up being private for only the designer and their manager, and serves as the designer’s home base for the first month or so in their new role.
Tasks on this board are split between the designer and manager, so both are held accountable to reach full completion. I’ve found that this board becomes a key part of 1-on-1's , promotes thoughtful communication outside of slack, and as a bonus, familiarizes the designer with our communication best practices on Trello.
The setup
We divide our columns by time as follows:
- On Your First Day
- In Your First Week
- In Your First Month
This helps orient and segment tasks, while also keeping an appropriate pace. We also have a column of “helpful tips” that is meant as a generic question base.
First Day Tasks
We made a designer’s first day basically a to-do list of things to complete before they head home. Most of their time is structured with a company wide orientation, team lunch etc. — but I wanted to make sure they knew what to do when they inevitably sat down at their desks.
Managers have a first-day checklist too! We pair this with pre-orientation tasks to keep everything in one place. Most of these tasks involve requesting the correct software licenses, adding members to our team accounts, and including the designer in meetings they’ll need to make a part of their regular schedule.
First Week Tasks
Everything in this column requires a bit more time to complete, but is still time sensitive. For example, understanding our file structure and naming conventions for our Product Design Dropbox is important, but won’t block you until you start designing.
I also encourage a lot of coffees and introduction syncs in the first week. It’s the manager’s responsibility to identify key people the designer should meet with on the team, but it is ultimately the designer’s task to schedule and prepare questions for these 1 on 1s. If there are important themes to discuss that pertain to specific job responsibilities, the manager can note this in the card to help start a productive conversation.
As a team, we also keep a running list of bookmarks and browser plugins that make our jobs a bit easier and tools easier to find. We include everything from our content API to various accessibility plugins in this list (one my favorites is Spectrum for color vision deficiency).
First Month Tasks
Items in this column will likely take the most time to feel comfortable with. This includes team and department meetings (some of which are held every other week), along with bigger picture items like setting goals with their manager and becoming familiar with submitting modifications to our pattern library.
Helpful Tips
Last but not least, helpful tips! Since all offices handle things differently, we found it useful to use these cards to nod towards some of the less explicit guidelines and help our new team members feel more comfortable. These include company-wide slack channel recommendations and good ways to meet people through social events that the company provides.
Other things to note:
- In the first drafts of this, I tried to summarize a lot of the company policies and procedures in an effort to keep everything in one place. Not only did this add a lot of reading, but it wasn’t practicing the DRY principle and ended up causing confusion when policies were updated. Now we point to the company-wide locations in which this information is stored, and leave it be.
- This doesn’t replace our team wiki! All team-wide process should be kept and noted there. Think of this as a “how do I even get started” and not a “how do I do xyz.”
Thanks for reading
If you liked this article then it would be great if you could tap the 👏 button below to show some ❤️.
