Whether big, small, or just starting out, all design teams stay on the lookout for tools and software that can be utilized to implement their ideas at an efficient pace in order to collaborate and manage projects. Software to deliver high quality content, but most importantly, a single source of truth.

The term 'single source of truth' varies for each designer, but overall it means a place somewhere up in the “cloud” where designers alike can find the latest design patterns.

When the document is updated or changed, anybody with access can also see. Sketch Libraries are convenient, and it ensures that the design team has access to the latest information across the board.

There was a time when the Sketch Libraries system didn't exist, and the term Sketch Libraries was only being used to indicate a Master Sketch file with reusable components organized as symbols that is their team’s “single source of truth”. Symbols help solve issues such as design consistency as having symbols make things easier to build out pages.

The “Master” sketch file is controlled by one person who is the “gatekeeper” as their job is to merge symbols, components, icons etc. from every designers’ files that have been approved. While copying these into the master document where everyone else can take and implement them into their designs. Having designs funnelled into a single “master” file helps us to ensure design consistency.

The gatekeepers job also means keeping everyone updated. When something has changed or has been added, everyone on the team, that uses the master sketch file, has to be notify. This would cause some difficulties such as: symbols were document dependent.

There was no way for them to be used in other sketch files besides the document they were sorted in. Copying and pasting also caused duplicates within sketch files due to naming conventions, artboard sizes, and if your teammates are working around the globe for people in different time zones, getting them up to date can be a task on its own.

Here Come Sketch Libraries

What are libraries you ask? Libraries are just like normal Sketch documents that contain symbols, but you can connect them to any document you are working on.. When someone on a team makes change(s) within the connected “Master” document, designers’ will be notified that there are change(s) and sync any document that uses symbols from that library. Keeping your team informed and up to date with ease. For any reason a mistake was made before updating, they can see the changes before they opt in.

The possibilities are endless! Creating a great document structure is key to making a fully functional Design System that your team will love while ensuring efficiencies of the work being created and shared.

What Makes a Design System? 🤔

Communication Is Key

Get your team together, have a jam section of what would make a great library, what components and elements would make their work flow better.

Decide What to Include

Compile list of what to include in the Sketch Library such: Primary Colours, Icons, Cta’s , Forms etc.

Naming Hygiene

Naming Convention Matters! Naming Convention Matters! Say it louder so the people in the back can hear Naming Convention Matters! When it comes to creating a Library, Design System for your team or Just for personal use.

Organizing layers and artboards in categories into a meaningful naming convention that can be easily spotted saves yourself and your colleagues time having to navigate through the hundreds of symbols, layers and artboards.

So What Does This Mean for Your Team?

If you’re working in a team, sharing designs day in and day out, working independently or even just looking for a way to streamline and manage on-going projects. Trying to incorporate a Master Sketch Document or Sketch Libraries into your workflow can help. It adds less stress and more productivity per project. This can push forwards your teams’ overall design process.

Try it out for yourself heres a free demo library to test out and play around courtesy of Playground Inc.

I hope these tips will be useful for your next project.

Do you have any tips on how your design team manages and maintains a design system?

Let me know in the comments below.👇 If you found this article helpful, please give it some claps⚡️ 👏

Happy Sketching Everyone!💎

So You Want To Build a Design System? was originally published in Playground Inc. on Medium, where people are continuing the conversation by highlighting and responding to this story.

In this article I’m going to tell you all about CSS Custom Properties, as well as give you some examples of how to use them and why they’re so awesome!

Variables in CSS are no new idea. We’ve been using preprocessors like Sass and Less for some time now, partly for the convenience that they afford us with variables.

Using variables in our CSS stylesheets has several benefits:

1. It allows us to keep any reusable values in one place. If a value changes, we no longer need to execute a find-and-replace to make the update. And as long as we have been using the variables for the appropriate CSS property values, we don’t have to worry that there might be a value lurking somewhere that was missed.
2. We can reduce the amount of typing we need to do to set our CSS property values. A great example here is saving your font stack as a variable. Now you don’t need to remember each specific font-family and their order in the stack — you can just set it to a variable and reuse that throughout your styles.
3. Variables can make our code easier to read. Now instead of mentally trying to decode a hex code in our mind, we can easily tell that it represents the ‘Primary’ brand colour, or maybe an ‘accent’ colour. And if we’ve been strategic in setting up our variables, the relationships between them become more apparent. (ex. column width & # of columns).

While preprocessor variables are an improvement over vanilla CSS, they do have some limitations:

1. Our preprocessor variables compile down to pure CSS. Once compiled, it’s almost impossible* for us to tell (except by our own knowledge of how the CSS was written) which values were which variables.
   * Source maps provide us with a way to link our compiled CSS to its uncompiled preprocessor version. Primarily used in development but they can be sometimes spotted in the wild.
2. Our preprocessor variables have no knowledge or connection to the DOM. We have no way of scoping or inheriting a variable. This means that all values are global, and they will always have a static value.
3. Related to the point above, media queries have always been a bit troublesome with preprocessor variables. Since we can’t scope them, there is no way to redefine them within a media query block, and typically we are stuck with just creating sm, md, lg variations of our variables and using them in the appropriate query. Additionally, we must redeclare our CSS rules in each breakpoint, leading to lots of repetitive code.

CSS custom properties bring us all the things that we’ve been loving about our old friends, preprocessor variables, as well as helping us overcome some of the limitations.

That’s great. How do I use them?

CSS Custom Properties are pure CSS, and they behave the same way other properties do in terms of the cascade and inheritance. Like other properties, custom properties must be defined on a CSS selector to be valid. To make a variable available globally, we can define it on the :root element.

Custom properties are defined with a -- prefix. Custom property names can be any combination of alphanumeric characters and — or _. Unlike regular CSS properties, they are case-sensitive.

:root {
   --my-new-custom-property: #BADA55;
}

To access the value of our variable, we don’t just use the property name as you might think:

/* DOESN'T WORK */

.selector {
    background-color: --my-new-custom-property;
}

CSS now has a var() function, which we can use to extract the value of our custom property:

/* WORKS! */

.selector {
    background-color: var(--my-new-custom-property); 
}

The var() function also takes an optional second parameter, which will be a default value if the custom property isn’t defined.

.selector {
    background-color: var(--my-new-custom-property, #ffff00);
}

It’s worth noting, that unlike with our preprocessor variables, our custom properties can only be used as values for existing CSS properties. We cannot use their values as property names, or CSS selectors.

Scoping Custom Properties

Scope allows us to define the value of a variable in a specific context. I mentioned earlier that CSS Custom Properties are aware of the DOM, so we can leverage the normal behaviour of the CSS cascade and inheritance to change the value of our custom properties.

This is very useful for theming components, or entire pages. In these cases, a custom property defined further down in the CSS, or with a more specific selector than the initial declaration will win out and be the value that the browser uses to render the element.

In this example, our .button styles are inverted when the button is hovered.

.button {
  color: white;
  background-color: midnightblue;
}

.button:hover {
  color: midnightblue;
  background-color: white;
}

We can clean this up with CSS Custom Properties. Let’s add in some variables and update the styles for our buttons:

:root {
  --foreground: midnightblue;
  --background: white;
}

.button {
  color: var(--background);
  background-color: var(--foreground);
}

.button:hover {
  color: var(--foreground);
  background-color: var(--background);
}

We’ve defined 2 variables to style our buttons, they are --foreground and --background. Now when we hover our buttons those values get inverted. We can utilize the CSS cascade to update those custom properties for themed sections.

.themed {
  --foreground: peachpuff;
  --background: darkslateblue;
}

Since the .themed selector is more specific than :root and is located further down in our document, the cascade and inheritance will overwrite these values for any child elements of .themed. Now any buttons within a themed element will get the new custom property values applied. There is no need to redefine the button styles with the new colours! The text and background colours of each section are also defined with these same variables, and there is no need to redefine the styles here either. Big wins!

For a full demo, have a look at this codepen:

Streamlined Media Queries

The current state of media queries with preprocessor variables goes something like this:

1. Decide which breakpoints you will work with
2. For each breakpoint, create a new variation of the variable that needs to change (eg. $gutter-lg, $gutter-md, $gutter-sm).
3. Work with the appropriate variable in each media query.

For example, to change the columns and gutters for our grid, we might do something like this:

$columns-sm: 1;
$columns-md: 2;
$columns-lg: 3;
$gutters-sm: 10px;
$gutters-md: 20px;
$gutters-lg: 30px;

.grid-container {
  display: grid;
  grid-template-columns: repeat($columns-sm, 1fr);
  grid-column-gap: $gutters-sm;
  grid-row-gap: $gutters-sm;
}

@media (min-width: 600px) {
  .grid-container {
    grid-template-columns: repeat($columns-md, 1fr);
    grid-column-gap: $gutters-md;
    grid-row-gap: $gutters-md;
  }
}

@media (min-width: 1000px) {
  .grid-container {
    grid-template-columns: repeat($columns-lg, 1fr);
    grid-column-gap: $gutters-lg;
    grid-row-gap: $gutters-lg;
  }
}

This approach clearly has some problems:

1. We have to define as many variables as we have breakpoints, just to cover the changes that need to happen within each media query, or we could define multiple values within a map — either way, it’s not as simple as it could be.
2. Our variables are all globally scoped, meaning that we can accidentally use the wrong variable variation in any breakpoint.
3. This is a somewhat simple example, and we can already see the repetition required to make our styles work.

With CSS Custom Properties, we can simply update our variables and let the CSS cascade take care of the rest!

:root {
   --columns: 1;
   --grid-gutters: 10px;
}

.grid-container {
  display: grid;
  grid-template-columns: repeat(var(--columns, 1), 1fr);
  grid-column-gap: var(--grid-gutters, 15px);
  grid-row-gap: var(--grid-gutters, 15px);
}

@media (min-width: 600px) {
  :root {
    --columns: 2;
    --grid-gutters: 20px;
  }
}

@media (min-width: 1000px) {
  :root {
    --columns: 3;
    --grid-gutters: 30px;
  }
}

Check out this example below to see what I mean:

You can compare the above example with a similar version written with Sass variables instead of custom properties here:

Other Amazing things we can do:

Calc()
The CSS function calc() was just meant for CSS Custom Properties (okay, so not actually, but they work so well together!). We can let calc take care of all the math and completely change our layouts by updating our variables.

:root {
  --columns: 2;
  --gutters: 10px;
}

.calc-cards {
  display: flex;
  flex-wrap: wrap;
  margin: calc((var(--gutters) / 2) * -1);
}

.calc-card {
  width: calc((100% / var(--columns)) - var(--gutters));
  height: 200px;
  margin: calc(var(--gutters) / 2);
  background-color: deeppink;
}

In the below example, try changing the values for --columns or --gutters and see what happens to the layout:

Update with JavaScript:
Custom properties don’t get compiled down to their values. Anywhere that they are used with var() as a property value remains when we view the site in our browser.

We can take advantage of this and update them dynamically with JavaScript!

Using JavaScript, we can update any of our custom variables on a selected element by calling .style.setProperty(customPropertyName, customPropertyValue).

Check out this CodePen, where we can easily update the CSS using HTML inputs and JS:

That’s great, but is this something we can actually use?

Current support for custom properties is looking really good!

If you need to support older browsers or IE, you can always set your styles for those browsers, then update your CSS to use custom properties within feature queries.

// set styles here that will be used in browsers that don't support
.selector {
   background-color: red;
}

// Use a fake variable to test if the browser supports variables
@supports (--test-var: value) {

   // Overwrite our previous rule to use custom properties
   .selector {
      background: var(--primary-color);
   }
}

Yes, if you need to support older browsers, it does take a little more work. But the features custom properties bring us make it so worth it!

We’re actually already using CSS Custom Properties here at Playground Inc — A while back, we created a Playbook to contain our policies. Each section of the playbook is themed a different colour, so it seemed like the perfect place to make use of custom properties. View the site here: playbook.playgroundinc.com.

Thank Yous

HUGE THANKS to Lea Verou, Una Kravets, and Wes Bos for creating such incredible resources for learning about the latest and greatest in web development. I would still be struggling to work these things out myself if it wasn’t for you.

CSS Custom Properties are here. was originally published in Playground Inc. on Medium, where people are continuing the conversation by highlighting and responding to this story.

I have recently completed a 4-month product design internship at Playground Inc. in Toronto, Canada. It was a rewarding experience that allowed me to gain valuable experience in the UX/UI field. I was immersed in various product design-driven projects, exposed to the digital design community and considered an integral member of a team of multi-disciplined, talented, creative and motivated individuals. This article aims to shed light on my experience as a design intern, and to impart a few words of advice for those planning on pursuing an internship in the future.

Humble Beginnings

During the first week of my internship, I learned more about the Playground team and went through the onboarding process. Being the new girl on the block, I remember being a nervous (and overly sweaty) wreck. This feeling, fortunately, didn’t last long as I started to feel at ease and welcomed within Playground. I got along well with the leadership team, fellow designers and developers not only because of our shared interests, but because the people who work there treat one another like one big family.

I have never felt excluded or singled out from anything, from Slack channel conversations to team lunches to asking my opinions regarding design decisions, to weekly stand ups to discussing the projects we are working on that week. It was evident from the start that Playground is an open and positive workspace that encourages people to express themselves however they see fit. The overall vibe of the company is relaxed and easy going, but professional and goal-oriented when it came to completing projects.

Getting used to the #InternLife

My tenure at Playground consisted of working on a variety of projects. A few of the tasks I was given but not limited to: creating weekly illustrations for internal projects and social media channels, participating in brainstorming sessions for the studio’s social media initiatives and beginning stages of projects, gathering notes and attending client meetings with the product design team, presenting ideas internally with directors and product designers during ideation workshops and jam sessions, assisting with user research such as field testing, surveys, interviews and usability testing, designing wireframes and app concepts under the direction of product designers and a design lead.

What really surprised me was that all that I have learned so far is just scratching the surface of the broad topic that is UX/UI. Being able to intern here helped me realize that I not only want to pursue this for a design career, but that there is a constant need for new emerging technologies, software and research methodologies to learn to successfully create great digital products for mobile and web.

Sharing a few things I’ve learned

1. Ask questions if you need help. Don’t be afraid to speak up.

Getting hired as an intern might be a bit overwhelming and daunting at first, but it doesn’t mean that the company expects you to know everything. There is also a huge difference between constantly asking for help on every task and reaching out for direction on tough calls and clarifying something on the design brief. Reaching out for help and asking questions to address an issue early is 10x better than doing something on your own and failing.

2. It’s okay to make mistakes… just as long as you learn from them!

You are in a good position to be a sponge during your internship, meaning you are able to learn as much as you can from other designers and applying it to real world projects. But another important part of being an intern is also making mistakes and learning from them, because how else can you improve and grow as a designer?

3. Working as an intern is different from being in school.

Your internship and school are two completely different things. In school, you are given a design brief in the form of an assignment and taught the necessary skills through lessons to thrive in a job. During your internship, however, you are expected to have these skills ready to apply to the projects you’ll be working on. Your project lead or manager will not hold your hand, so you must be prepared to be accountable for your work. That means understanding what is expected of you when it comes to tasks, understanding the brief and seeing the project through with your team.

Pro tip: It helps having good organizational skills and time management skills to thrive in your internship. Try using the apps Milanote, Asana, Monday or Trello to help with this!

4. Talk to the people around you. Build relationships with the team.

Most of what you’ll get out of an internship is meeting and communicating with other people. I was very fortunate to work for a company that encourages open communication, whether in the form of a 1-on-1, meetings or getting a coffee from around the corner. Do your best to show enthusiasm! Maybe join communal team lunches. Attend team building activities. Offer to help with other tasks around the studio. Join Lunch n’ Learns. Participate in brainstorming sessions. Looking for various opportunities to make an impression upon your peers and team members boosts office camaraderie, and shows them your curiosity and willingness to be part of the team.

After your internship is over, remember to continue being a professional and avoid burning bridges with people at work. Maintaining a solid relationship with the team will only benefit you in the long run. If they also had a positive experience and the feeling is mutual on both ends, they are more likely to give you a great recommendation letter/referral, consider you for freelance work or another position in the future!

5. Embrace the art of learning, even outside of work.

Just because you are in the workforce doesn’t mean you stop finding ways to improve your craft. It’s important to invest in your skills, and “level up” what you know. The design industry is constantly evolving, and it’s critical for designers to keep up, learn new software and gain new insights into design trends, emerging technologies and the future. Take advantage of online resources such as Skillshare and Udemy. If you feel that you can benefit from learning in a compact class structure, look into taking full-time or part-time courses at HackerYou, Brainstation, RED Academy or Bitmaker GA.

Improving your skills and investing in your growth can only benefit your goal of being a proficient, well-rounded designer after school, when you start your internship and eventually transition into an Associate Designer position.

Key takeaways from this opportunity

This opportunity further cemented my interest to pursue digital design, and was a wonderful segue into learning more about UX/UI both in my career and through additional learning in the future. Securing an internship here helped me see that it is important to: Be empathetic, prioritize work, listen and take constructive criticism, put the user first and design around their needs, be open to collaborate with others to find solutions and learn from the people you are working with.

My product design internship at Playground Inc. truly felt like a blur. I learned a lot along the way and I’m thankful for the mentorship I have received. I have gained new friends, new experiences, and most of all, a new perspective on what kind of career truly suits and excites me.

About Playground Inc.

Playground Inc. is a human design company. We build products that people use every day. We focus on design, strategy, and technology. We’ve been building unique digital products, platforms, and experiences for the past 9 years.

We are a diverse team of creatives from many backgrounds with a shared desire to help make the web a better place.

A Design Reflection: What I’ve learned from my internship at Playground Inc. was originally published in Playground Inc. on Medium, where people are continuing the conversation by highlighting and responding to this story.

I’ve been on the frontlines of interviewing all sorts of designers to help us make digital things. Personally, I’ve hired 40 design team members (so far) and I’m still not sure if I’m doing it right. Although there’s been substantial change in both the industry and what people think about design — my approach to hiring hasn’t changed very much over time.

We get the opportunity to work on some really cool stuff. Playground Inc. is trusted to design the flagship experiences and applications, take on large UX organizational tasks, and create comprehensive design systems for Fortune 500 clients and consumer brands across North America. We’ve thankfully managed to surround ourselves with designers who have not only been capable, but have excelled.

For context, we’re a 20 person design company that receives 5 unsolicited resumes a week and upward of 40 when were actively hiring for a role. Do we have a secret? Probably not, but either way — here’s our approach after 9+ years of meeting people:

All designers are multidisciplinary. Even if they don’t know it yet.

For the past 9 years, we’ve seen tools change, we’ve seen new roles emerge, and we’ve seen silos created. Good designers have the ability to learn, adapt and grow alongside this constant change. We’ve never hired anyone who specializes in information architecture or wireframing. We’ve also never hired someone exclusively for UI design, illustration, or motion graphics. Same goes for research, design thinking, or design strategy. We believe these are tools. Tools that can be learned, developed, and nurtured. To us, IA and wireframing are ways to articulate plans and design solutions. There are certainly people who are really, really, good at a particular discipline, but for our team — the most value is added when we don’t box designers in.

We focus on the current strengths of a person, their potential and the things that got them in the room with us in the first place. If someone is interviewing at Playground, chances are they’ve done a little bit of everything — even if they can’t articulate it. We try to pull it out of them with thoughtful questions. We have a ‘learn by doing’ mindset here, so it’s crucial to be around the right mentors in order to find where they will add the most value. We want our designers to develop their craft with an open perspective on the different tools available to make that craft stronger and more dynamic.

2. Stop hiring for fit — what will they add?

Hot take: Cultural fit is bullshit. Do they think like you? Do they act like you? Do they look like you? Do you immediately get along after a few interviews? In my opinion, all of these things constrain your ability to truly evaluate a person. We think of new team members as additions to the culture. What emerges should be a net positive for everyone here — but how can you measure that during an interview?

When we hire, we specifically think about what someone adds to our already dynamic team. We embrace differences in experience and personality. We want to be challenged and shown different perspectives on the world. We also welcome differences in expectation of work. For example, someone coming from a high pressure advertising or startup environment typically brings a unique perspective if given the right opportunity. Someone who is an empathetic thinker will teach others to ask better questions. Someone who prototypes in code, will shepherd others looking to learn. Empower people to bring something new to the organization, let go and allow the culture to emerge and evolve in unexpected positive directions.

3. Skip the resume. It’s not about their experience, but how they’ve gained it.

This may be controversial, but I only give resumes a quick glance. I want to see their work. If they have demonstrated they have the raw skills, they’ve got an interview.

We ask a lot of questions that hopefully encourage storytelling.

Here are some questions I’ve asked in the past:

• How did you find design? Did it find you?
• How did you get here?
• How do you learn?
• What type of designer do you want to be?
• What are you most excited to work on?
• To you, what’s important about the internet, technology and people?

Our industry moves so fast. If your portfolio looks and feels contemporary — that’s probably a good sign that you’re able to keep up. Past experiences can be so deceiving. They may not apply to the context of our organization or our expectations of a designer.

What I’m most interested in is how they afforded themselves those experiences? Did they teach themselves design until they had enough spec work for someone to hire them? How did they get their first design job? Did they learn from being on a team with other designers or were they a Lone Ranger? Why do they care about design? How do they learn about it? What are their first memories of getting started? Who are their heroes? Who do they learn from daily? The probes are specifically about the designer’s framework for learning and growth.

In my experience, even the most shy person will become comfortable if they’re talking about a topic they truly care about. Sometimes it’s one story, or the mention of one person that provides a clue into whether they would be a good hire or not. Find out if they care about their craft and determine if they have developed a framework for learning. Additionally, find out how they developed their design taste. There’s plenty of time to teach them new applications or processes later — so long as they have the desire and ability to learn.

4. Be transparent

During our first interview, I’ll do 3 things. Learn about the person, sell them on Playground, and tell them what to expect next. When learning about the person, we find out what their goals are, the context of their previous work, and how Playground can help them in their career journey. We’re first collaborating to understand if this is the right role for them.

The first meeting is typically with someone like me. The second is with our Creative Director, Ryan Bannon. The third meeting is with the team they will be working with everyday. During these three conversations — we’re able to find out if they are curious, if they love their work, and if they are going to work well with others. No interview is longer than 90 minutes, and most are shorter than 60. After each one, our internal team debriefs together.

5. Enough spec work

We’ve tried wireframing exercises and asking problem solving style questions. We’ve even tried a ‘solve out-loud’ type of approach in the past — but nothing has been as consistent in identifying great designers as learning about how someone learns. We allow our candidates the appropriate space and time to walk us through their work. From there, we will be able to ask how they’ve made decisions, how they asked questions, and what level of experience they have within our specific context.

Our work changes with every new client or challenge we take on — so we look for the drive to dig deep, understand nuance, and be flexible. That’s really it. From their portfolio, we should see evidence of that type of thinking and evidence of raw skills.

It’s our job to figure out if they have the raw skills, that’s the stuff we work on before inviting someone into the interview. Once that’s out of the way, let’s get to know each other, what excites us, what motivates them to keep up and push themselves. Whiteboarding and homework exercises usually lack context and are often solving unrealistic problems. On a project, we would never have a designer solve every problem by themselves, with limited information, in a short timeline — so why is that expectation during the interview? We are looking for team members, contributors and inspiring folks to learn from everyday.

Lesson Learned

This may seem obvious but the people who actively work on design every day should be reviewing candidates and the ones conducting interviews.

Know the candidate you are talking to before the interview. Take some time and do your research. Appreciate that this may be a big deal for them. Try to identify some unique questions that prove you give a shit about them. This goes a long way in helping build respect and trust. Never show up cold or unprepared.

Build lasting relationships. Perhaps the person isn’t the right fit today — but they could be someday. This is the perfect opportunity to give constructive advice and help them develop into someone we’d kill to have on our team.

Much like Sway, we don’t have all the answers. Being an agency has given us the unique privilege of working with a lot of different people, nourishing growth and practicing design in almost every context imaginable. This approach has worked well for us (so far) but we’re no strangers to insight-based iteration and change.

Marco Rogers shared his thoughts recently on hiring engineers for startups and we saw a lot of parallels. While our techniques are different, the human centred hiring insights stayed the same. You don’t know what you are hiring for, and get the whole team involved, always debrief and skills are to be nurtured.

I’m curious, how do you hire designers? Does it look anything like our process? From your perspective — what’s the single most important question to ask? Let’s talk about it.

What I learned from 200 design interviews was originally published in Playground Inc. on Medium, where people are continuing the conversation by highlighting and responding to this story.

A short while ago, our Technical Director, Maja, wrote a post here on Medium titled ‘How we approach 1:1s with the technical team at Playground Inc. and how you can too’. If you’re a manager considering bringing 1:1s to your team, I highly recommend that you give it a read.

If you are instead on the other end of the 1:1 meeting — or, if you’re a manager looking to further understand how this process can be valuable to your reports — this post is for you.

Prior to my career at Playground I had never participated in a 1:1. A typical meeting with my manager was for an annual performance review, or to discuss a specific technical problem I was having trouble with. And so, when first presented with the idea of meeting weekly for a 1:1, I wasn’t quite sure what to expect.

After going through a few 1:1 meetings, I could see some real benefits:

1. Having regular meetings made me feel supported. If I was encountering any issues, either technical or otherwise, I knew I had a safe space to voice any concerns. These meetings are also a great reminder that my manager is there to help me whenever I need it, and I can always reach out if I feel the need.
2. They allow time to get to know your manager and build trust. Not all of what is discussed in a 1:1 needs to be directly work-related. This is a great chance to get to know your manager better, and for them to get to know you as well. After all, we’re all human. Let’s treat each other as such :) In addition, having organic conversations that aren’t just about work might lead you to discuss new paths and opportunities you may not have otherwise been afforded.
3. I don’t feel stressed or panicked if I encounter a new problem. Knowing that I have support and that there is already time set aside for when I can talk gives me the mental space to focus on the solving the problem. If my 1:1 meeting comes around and I haven’t made any progress, I have an excellent opportunity to gain some fresh perspective. I am absolutely not saying that you should struggle with a problem for a week before getting help with it, but 1:1s can be a great opportunity to talk things out (and sometimes, that’s all you need to arrive at the solution).
4. I get insight into how I’m performing on my team and within the company. These weekly meetings are a great time to discuss any successes or shortcomings.
5. I learn about what’s happening at the company. 1:1s are a great opportunity for me to learn if there is anything new going on with the company. I spend much of my day coding or doing research, and have a tendency to really “zone in” to my screen. 1:1s are a time to break away from this, and give me a chance to hear about any new clients coming on board, new projects in the pipeline, or new members joining the team. It’s exciting to hear about new things happening!

How to have productive 1:1s

A successful 1:1 meeting shouldn’t just be up to your manager. They can be treated as opportunities to reflect, learn, and improve. Here are some things that have worked well for me to have great 1:1 meetings:

1. Make a plan. Take some time to jot down the points you want to touch on during your weekly 1:1. This doesn’t have to be a formal agenda, but can serve as a reminder to make sure you get what you need out of the meeting.
2. Take notes. Every week I bring my notebook into the meeting with me. This way I can keep track of anything we discussed that I want to remember for later, as well as keep track of anything that I have promised my manager I would look into or work on. I have also written here the points that I want to address and afterwards my notes serve as a record of our meetings.
3. Review. By taking notes each week you can look out for recurring themes in your meetings. Are you running into the same types of problems over and over again? Is there something you can do to break out of that pattern?
4. Celebrate your successes! For a while, I was noticing that I was spending the majority of my 1:1s discussing problems I was facing. In my job I spend a lot of time problem solving, and I’m constantly thinking about the current problems I’m facing — and how I can either work around them, or overcome them. This theme was so dominant I was neglecting to mention the things that were celebration-worthy. I started making a point of also talking about my successes at work to ensure my meetings had a positive spin and that my achievements weren’t going unnoticed (including being forgotten by myself). I leave my 1:1 meetings excited about the work I’m doing and what’s to come.

If you’re currently practicing 1:1 meetings and are feeling like you’re not getting as much out of them that you could, I encourage you to incorporate some of these points into your next meeting.

1:1 meetings are a valuable tool, but they need to be used effectively and with purpose to work. Let’s also keep in mind that we’re all different people with varied expectations and ideas of success. Your productive 1:1 might look different than my 1:1. What makes 1:1 meetings valuable to you?

Why I look forward to weekly 1:1s and how you can get the most out of yours. was originally published in Playground Inc. on Medium, where people are continuing the conversation by highlighting and responding to this story.

Be Present

Learn to speak without seeking validation. Learn to listen without formulating a response.

Be present so you can perceive patterns around you.

Be present so you can solve and predict the problems of those patterns.

Be Purposeful

Know what you want. More importantly, know why you want it. Asking why is a powerful tool. Use it often.

Building your dreams takes plenty of fuel, yet your energy is limited. Do not waste it.

Find ways to replenish yourself throughout the day.

Be Patient

Dream big, then work backwards to find a path.

On that path, be a farmer. Plant seeds and water them regularly.

Search for people who can nourish you along the way. Without space to deepen, you won’t grow very tall.

3 P's for Young Entrepreneurs was originally published in Playground Inc. on Medium, where people are continuing the conversation by highlighting and responding to this story.

At Playground Inc. we value having an open and nurturing environment for everyone. We try to instill this type of culture within all of our teams. Pull requests are usually associated with code review and an approval process for getting some sort of functionality into a project or to fix an outstanding software bug — at Playground, the engineering team sees pulls requests as an opportunity to teach, learn and foster different approaches to different problems we encounter in our daily work. An idea isn’t good or bad, it has different trade-offs.

Anatomy of a Pull Request

A pull request starts with an idea. Providing an explanation within the request is a good way of helping everyone on the team understand why the change is being made. We should be mindful and aware that not everyone on the team has a full understanding of the scope of the change. Providing a history of the problem being solved helps any new team members jumping on to the project get more acquainted with the project and the specific pull request in question. The more detail we provide for others, the more helpful it will be in speeding up the process of reviewing and ultimately approving the request.

To help everyone on the team, pull requests should typically only update one logical piece of the project. Introducing multiple logical changes in a single pull request could make it harder for the team to review and is more likely to introduce unexpected bugs.

Reviewer(s): The person(s) that are tasked with reviewing the bug fix / new functionality. As a reviewer we should attempt to keep the pull request approval list as short as possible. Having lingering pull requests could be hindering work on future functionality. A prompt review of a pull request also helps the reviewer if they have any questions for the author as the work of the author will be fresh in their mind.

Author/Reviewee: The person who created the initial pull request. As the author we should try to test the code to the best of our ability to ensure the reviewer(s) are receiving our best work and to help them do their job in an efficient manner.

Title: Providing a descriptive title (Feature/Bug Fix/Refactor) helps members quickly identify what the pull request is about. Many times pull requests are tied to a ticket in a project management software system (JIRA, waffle, etc.) and these tickets usually have an ID of some sort assigned to them. Including this ID in the pull request title is a great way for identifying which ticket it belongs to. The title may be different from project to project, and the team should identify the best format for the project.

Description: Using the description section of a pull request is a great place to provide the extra details that don’t fit in the title. Explaining why the change is being applied will give team members an overall understanding of the change and will help them understand the issue and in-turn help the process move along more smoothly. Another useful method for helping teammates navigate the pull request is to provide a list of the files being affected and a brief description of what has changed. While the pull request has the changelogs for all files, giving people a quick overview of the files affected is a great way of helping them navigate how the changes are related to each other.

Reviewing a Pull Request

Reviewing a pull request can sometimes be difficult especially if the person reviewing has no context as to what the bug fix is or the what the new functionality does. As a reviewer try to be in the right frame of mind when reviewing a pull request. Giving kind and constructive feedback takes time and energy, focus on yourself first. If you are pressed for time, not feeling well or hungry let the author know that you need to take care of those things first. You will be surprised how much of a difference mindset makes when reviewing a pull request.

Understanding the issue/feature will help you move forward in the approval process — before reviewing code try to understand the requirements for the change. If you do not understand something ask the author for clarification.

As a reviewer we should try not to jump to conclusions — instead assume that the author has done something for a reason. A general rule when encountering code / logic that you do not understand is to put yourself in the shoes of the author. Having empathy when phrasing your questions will go a long way in keeping them engaged and in a positive mindset to help answer any questions you may have. The feedback you receive from the author may surprise you and help give them a better understanding into the logic they used to solve the problem.

A reviewer’s questions should be as important as the pull request itself — as a team we should not be “nitpicking” stylistic code choices. We should be reviewing the logic and structure of a pull request while avoiding the trap reviews about aesthetics of code.

If the pull request passes all tests and is ready to be merged, providing a positive message is a great way to end the pull request process. Let the author know that they did a good job! Using gifs and emojis is a fun way to do just that.

Creating a Pull Request

As mentioned earlier pull requests should only be modifying a single piece of logic. Author(s) should keep changes small so that the reviewer(s) can review the change easily and quickly. Large pull requests can complicate the review process and can lead to some missed testing coverage by the reviewers. Help the reviewers by keeping the pull requests small so they can approve the requests with as little issues as possible. Another great method for the author to support the team is linking to any documentation that may be relevant to the changes whether it is a library being used or documentation written by the author. The author should try to avoid refactoring code in addition to any logical changes. Refactoring should be done in its own pull request to avoid uncaught errors that may occur. It’s great practice to also speak with the reviewers while working on the feature/bug. Getting early feedback from your peers about different implementation options may help relieve any stress that may come with a code review.

Be mindful when receiving feedback, the author should try to assume that the reviewer has the best intent in the feedback they provided. Giving constructive criticism may be the hardest part of a pull request especially if the code doesn’t pass certain tests or if the author has forgotten a specific condition required in the feature. Though we identify different people within the ecosystem of a pull request (author/reviewer), everyone should think of themselves as the owner of the project as everyone is working towards the same goal in creating amazing code!

In Conclusion

When creating/reviewing a pull request it is important to remember that it’s not only about the code. Remember that there people involved on both sides and that we’re all are trying to accomplish a common goal. This practice not only benefits the project but it can help you develop your listening and communication skills as well. This makes you into a stronger teammate who is capable of providing mindful, constructive feedback.

Resources

Here are a few resources that we found to be inspiring for us. They provide examples of technical pitfalls to avoid, communication guidelines to follow and an overall framework to use when creating and reviewing pull requests.

http://amyciavolino.com/assets/MindfulCommunicationInCodeReviews.pdf

https://www.atlassian.com/blog/git/written-unwritten-guide-pull-requests

http://blog.ploeh.dk/2015/01/15/10-tips-for-better-pull-requests/

Positive Culture, Pull Requests & Code Reviews was originally published in Playground Inc. on Medium, where people are continuing the conversation by highlighting and responding to this story.

For the first years of Playground’s existence we were afraid of too much management, of too much process. We’re all smart, capable and busy people. Let’s stay out of the way so folks can get their work done. If they need something, they’ll say something, right?

Maybe that works with a small team. A team that’s been there since the early days. Conversations are ad-hoc and we all learn by osmosis. But it doesn’t scale.

And how do you scale? By being intentional. By making space.

Having regular 1:1s is a practice that opens doors, that builds relationships. It’s never the only line of communication, but it provides a guaranteed time and place to connect.

Ok, so what are we talking about anyway

Ideally, a 1:1 should be led by your report. You have created a space where they can be comfortable expressing themselves and communicating with you about what’s really going on. How exactly to do that is probably beyond the scope of this post, but it’s a slow process of building trust and proving worthy of keeping that trust.

1:1s will likely be different with different people, and that’s okay. They may ebb and flow with the same person too. Maybe this time you need an hour, or maybe just five minutes. As long as you’re both communicating with each other, you’re good.

Until you’ve established a rhythm and cadence, it will be useful to provide an initial structure from which to work. It will also be useful to circle back on particular themes once you have a natural flow too.

A general structure

Pick and choose as you need and feel free to make it your own. Not all questions will be necessary at all meetings. These are presented in an order that seems to work, but there’s no need to be strict.

Getting started

Small talk. Love small talk.

Honestly, this is an important part of building that trust we were talking about earlier. This is an opportunity to demonstrate that you care, that you’re interested.

Following up

Anything brought up in a past 1:1 that requires revisiting.

Did I say I would take care of something or look into something?

• Here’s where we talk about how that went and any potential next steps.

Did they say they would work on something or look into something?

• How is it going? What’s next?

Checking in

Immediate:

• How are you doing?
• How do you feel about the project you’re working on?
• What’s it like working with the project team?
• How are you feeling about X’s leadership on the project?
• What’s it like working with the client?
• Is there anything you’re concerned about?

Me:

• Is there anything I can do to help you?

Rarely do people have a specific ask in response to this very open question.

Usually this kind of help can be identified in the context of answers to other questions. Maybe I help them think through a possible solution to a problem they’re facing. Or maybe I can see that there’s something going on that I should take the initiative on and deal with. A more specific offer, “Could doing X help solve Y?” can be very productive.

I think it’s still good to ask the open question straight up. And to ask it regularly.

• Is there something I’m not doing that I could be doing?
• Is there something I’m doing that I shouldn’t be?

People really seem to appreciate these questions. Again, maybe there isn’t always much that comes up but being open to and making space for feedback is important.

Big picture

• How are you feeling about Playground?
• How do you feel about your role here? The work that you’re doing?
• Is there anything about the company that you’re worried about?
• Is there anything we’re not paying attention to that we should be?

Goals

• We’ve set some goals back at the performance review. Where are we at?
• Does anything need to change?
• What are next steps?

Sharing

• What am I working on?

This may or may not be directly relevant and that’s ok.

• What am I thinking about or planning for the longer term?
• Is there something specific I’m working on that I can share and invite feedback on?

Feedback

Did something happen that’s worth celebrating? Did something happen that needs correcting? Did a client or team member say something nice about the person I’m meeting with and can I share it with them? Is there something I’m concerned about? How are we doing with professional goals? With the points in our performance matrix?

Always following positive feedback with negative feedback can establish a pattern where the positive gets negated, because the person is just waiting for the negative. Be careful about this.

Connecting

How are things otherwise? Maybe this is just more small talk. Or maybe there’s room to talk about bigger or more personal things, if the person feels comfortable. Never push for it, but make room if it needs to happen. Be a support. Build rapport. Maybe share something too, if appropriate.

Is there something big going on in their life? Could this affect work in some way? Is there something we can offer that might help?

An offer of help must only be something that can be delivered upon. Don’t make promises you can’t keep.

Wrapping up

Summarize the session. How is the person feeling? What are the challenges that we’ve identified and what steps are we taking to address them?

So people know they’ve been heard.

Reminder that I’m available to chat or support or work through anything outside of 1:1s.

Thanks for checking in!

Troubleshooting & tools

1:1s can include brief status updates, but that shouldn’t be the main focus. It’s about checking in, giving and receiving feedback, discussing performance, following up on goals people have set, and identifying opportunities for growth. They can also be a place to work through difficult problems, whether technical/design or interpersonal. But when it comes to working through interpersonal problems or challenges, how exactly do we do that?

Roleplay

If we’ve identified that the person needs to have a difficult conversation with someone and isn’t super clear on how to proceed, offer up a safe space to practice that conversation. Play the part of the person they have to talk to and try out the conversation. If it would be helpful, you can offer also to switch parts. Take a step back and break down the conversation. How did it go? How did it feel? What could be better?

It’s good to identify and brainstorm different ways of approaching the conversation, but let’s not be prescriptive. We can coach people and help them figure out how to handle what’s going on, but let’s not tell them a specific way as if it were the only way. There are ways.

Scenario analysis

Is there something big coming up, around which there’s uncertainty or anxiety? Let’s work through it.

What’s the worst possible thing that could happen? How will you feel when that happens? How might you respond? Is this even a likely scenario that could happen? Or is it a product of fear?

What’s the best possible thing that could happen? What does that look like? What’s the likelihood of things going this way?

What probably is the thing that’s going to happen? How will that feel? How will you respond? Do you feel equipped to respond?

Yes.

1:1s as a practice

It will take time. Time to get to where you’re going. And time to figure out where it is anyway that you’re going to be going. Take that time.

With thanks to Mike Ferrier who years ago shared a framework that the above is built upon. Nicole Chung for the thoughtful feedback.

How we approach 1:1s with the technical team at Playground Inc. and how you can too was originally published in Playground Inc. on Medium, where people are continuing the conversation by highlighting and responding to this story.