Recipes for successful team culture

Aaron Henshaw
Product, etc
Published in
8 min readJul 26, 2015

Culture is an essential part of any team or company. And it goes hand-in-hand with the processes they use. All of it adds up to the type of team or company you are. It’s part of your identity and the main influence on happiness and performance.

On the Maker Innovation team at Etsy, we constantly work on our culture and processes. Below is a list of what we do on our team for product development and culture, and why we find them useful.

1:1s (One on ones)

Frequency: 30 min-1 hour Weekly

1:1s are not for fighting

In order for 1:1s to be effective, regardless of the size of the team/company, the entire crew needs to be onboard. Otherwise they don’t work.

Our team does two types of 1:1s — Direct report 1:1s and cross team 1:1s.

Direct Report 1:1s
Initially I was skeptical of having to meet with every person on my team once a week. But I quickly came around. It is a great way to build trust with the people on your team. The meetings can focus on anything. Common subjects are inter-company issues, career and personal development. Technical discussions are generally off the table — we do that all day already.

1:1s make sure that information is always flowing up and down through the organization. If someone on my team encounters an issue that I can’t resolve on my own, there is a maximum of a week before I have scheduled time with my manager to surface that issue. Same goes in the other direction.

I have been informed of personal issues, hidden underneath what appeared to be slacking or general unhappiness. Once, an 1:1 exposed a UX problem where our teams work was in conflict with another teams product plan. 1:1s have surfaced problems with title and salary. In all these situations the 1:1 identified and helped to quickly resolve an issue before it got worse.

Cross Team 1:1s
Cross team 1:1s are meetings that we have between engineering, product, design, marketing and program management. They happen at all levels and they are focused on three things:

  • Collaboration: We often schedule 1:1s between design & engineering or product & engineering to talk through product decisions and discuss direction. This is usually a designer and an engineer walking through a product making tweaks and sweating the details.
  • Strategy: Sometimes shit hits the fan. 1:1s at the leadership level are instrumental in providing time to discuss strategy on how to handle organizational problems that come up.
  • Alignment: Etsy is a growing company — the leaders on our team deal with different internal stakeholders from other parts of the company. By making sure that we meet often we are able to provide a consistent message across the organization.

Weekly Fuck-ups

Frequency: 1x/week

We give two of these flags out every week to whoever fucked up the worst.

Once a week, everyone on the team discusses their biggest failure that week, and as a team we vote for who fucked up the most. The person who “wins” has to keep a flag at their desk for the week.

People get the flag for things like taking down a page in production, pushing bad code, or missing meetings. They also are given for personal fuck-ups like getting lost and missing their best friends birthday party. For more about fuck-ups, check out Kuan’s post called “Trust the Creative Process”.

It is playful but its really about owning up to your mistakes, admitting them and learning from them. Accountability is something that we take very seriously on our team and this is a fun way of making it part of our culture.

All Hands

Frequency: Weekly
At the end of the day on Monday we have a stand-up meeting focused entirely on feelings. No work talk is allowed. You can feel good about work or a project, but nothing can be said about the specifics of what you have done or are going to do. Mostly people talk about their weekends, or about things they are excited about.

The important thing here is that we are all people. Work is not life, it is just a part of life. Creating opportunities for empathy and a shared understanding of how everyone is feeling, and why, sets everyone up for a better week.

JIRA & Milestone planning

Frequency: Milestones/sprints every 2–3 weeks & interact with daily

“Oh, oh, and I almost forgot. Ahh, I’m also gonna need you to go ahead and come in on Sunday, too…”

When it comes to software development, you can’t grow a team past a certain size without using some sort of project management software. Nobody likes tracking software development, but unfortunately it’s necessary. To make it work for our team, we are open about not liking heavy-handed project management. We focus on iterating, always searching for the right balance of process and autonomy.

Our team recently completed and launched Fund on Etsy. Because we were building directly into a complex eco-system that needed consistency across 6 platforms we created a lot of feature tickets, sometimes one per platform per feature. They were very specific with requirements and implementation details embedded.

Product-wise, it worked well. People-wise, not so much. It was too heavy-handed for our team. It removed a lot of the decision making away from the individual engineers. Seeing that, we decided to take a different approach for our next project.

We refocused all of our project planning on short, result-driven milestones. At the end of a 2–3 week milestone the team has something new that is demo-able. The whole team works on smaller, discrete pieces, and every engineer is challenged to think through product problems.

Sometimes it feels chaotic. But that chaos is awesome. It is real collaboration. You can see the energy, excitement and engagement that everyone has when the team is all working together.

Milestone Demos

Frequency: At ends of milestones, every 2–3 weeks
At the end of a milestone, we plan an internally open demo where we present the work the team has done to anyone who is interested.

Our team demoed the first milestone to product, design and technical leads and everyone was blown away. What our team was able to build in only two weeks was remarkable. Creating tangible goals and realistic deadlines, where the team is accountable to stakeholders outside the team, is pretty powerful.

It was especially cool to see everyone rally in a way that was similar to a more public release, a couple days before our demo. We had a day or two of all hands on deck bug fixing and clean-up. We even had a code freeze.

Objectives & Key-Results (OKRs)

Frequency: Set quarterly, discuss monthly
We have started using OKRs on our team. There is a great deal of info out there for OKRs. I can’t say if they are right for us but we are going to try them and see what happens.

To start, everyone set their own OKRs for the quarter and went over them with their manager. So far its awesome. The objectives are diverse but they all build to a successful project or to individual development. They range from “Provide technical leadership for the team” to “Obtain a mastery of data and analytics reporting for products” to “Learn to run meetings more effectively”.

The goal is to push people in a way that aligns objectives between project work, team success and individual development. The part that appeals to our team the most is that the key results are measurable.

For example, Obtain a mastery of data and analytics reporting for products” has a key result of “Make sure our Q3 project has 100% event tracking coverage”. We can concretely measure success for that. The individual engineer, if successful, will get a new skill for their career. And it isn’t just important for them individually. It will impact the success of our project.

Field trips

Frequency: Every month or two
Every month we take a day off and do something fun around NYC — it is important to remind ourselves that we have relationships separate from work and to create opportunities to form new bonds. Oh, and its just fun. We have done things like Hack the MET, The Rain Room, Museum of Moving Image, Cooper Hewitt (yes lots of museums), beer gardens, Mission Chinese Pop-Up, movies, and eating live squid.

Design Weekly

Frequency: 1x/week
This is my favorite. Our designer, Kuan, created a meeting every week that is focused on creative energy and design. We stretch. We do improv. We talk about the specific products and UIs we are working on.

We do brainstorming sessions: once we broke into pairs and did individual UX research on how the other person liked to receive gifts. At the end of the exercise we had designed a gifting process specifically for that other person, tailored completely for their needs. Earlier on in building Fund on Etsy, Kuan brought color markers and paper to a design weekly, and we all sketched out different screens for the product.

We discuss design and product inside and outside Etsy, trends, typography, and much more. Once we learned about kearning pairs. Or the difference between a font and a typeface. It gives Kuan an opportunity to provide context around how she thinks about product design. And like everything else we do, its an opportunity for people to learn and grow.

Sometimes we do product demos. Individual engineers are encouraged to present their individual work to our team. We have recorded those demos and provided feedback on presentation skills. It allows everyone to work on getting better at things we don’t do every day as engineers. And who doesn’t love a good demo??

Overall, this is a great way to share, learn and give everyone an opportunity to be engaged in a design-focused way that doesn’t happen every day.

Team off-sites

Frequency: 1–2x/year
Taking a trip away from the office once or twice a year is very good for a team. Trips can focus on a work goal or they can be purely social. One off-site we had two new team members. Over the next two weeks, they became just as much a part of the team as anyone else. During off-sites focused on work we performed like a well-oiled machine. But whatever the focus was the team building was the important part.

Off-sites can seem excessive, but they aren’t. Do them. Effective off-sites are well worth the cost.

“Recipes not blueprints”

I came across this article about how DevOps is a recipe and not a blueprint. Just like with DevOps, what works for one team is not necessarily right for another. The company, the business, the project, the teams role and the personalities of different teams will determine what works. What is really important is that you design your culture and your processes for the specific needs and wants of a team or company. And that you reflect on the changes you make and continuously adapt them, always trying to make your team or company as great as it can be.

--

--

Aaron Henshaw
Product, etc

Founder & CTO of Bison Trails. previously @Etsy, @grandst.