Living Our Culture at Teem via Peer Reviews

About a year ago we set down to document the core values of the engineering at Teem. After a lot of discussion we narrowed it to three core ideas

1. maximize positive impact
2. communicate
3. be a good friend

I would add one more unofficial value: mentorship and continuous learning. About the same time we also started thinking about how we describe/define an engineers career path and we quickly realized that measuring progress is hard and that measuring commitment to our core values is even harder.

Why these values?

First a quick aside to breakdown what we are trying to convey in these three ideals. Maximize positive impact, communicate, and be a good friend are simply the short go to phrases we use to describe the overarching culture that we believe we live and strive for. They are easy measuring sticks that we can use in any scenario to remind ourselves who we are.

Maximize Positive Impact is our most aspirational value. It is the value you will most likely hear an engineer repeat during a discussion and has the largest impact on the what we are doing. We think that our engineers maximize their positive impact by

1. having a focus on the user. Our users are everything; without them, there would be no Teem. We are creating products that change how people live and interact with their work environment and ultimately with each other. Every engineer should strive to understand the user and the problems that they experience in the workplace. Thanks to brilliant leadership on the product team, every person at Teem has access to the data, research, and recorded sessions with our users. Read the summaries and watch these sessions. Better yet, ask to join the calls! Focus on the user and the rest will fall into place.
2. having a bias towards action. If you see a problem, fix it. Have a new idea, build a prototype. Communicate, but don’t rely on consensus before acting. Seek others’ input, but be decisive. Ultimately, we would rather test a hypothesis cheaply than be paralyzed by over analysis.
3. understanding that shipping beats perfection. We want and need to ship quickly, learning from our users and iterating. This is not an excuse for low quality nor skipping user research. In fact, it requires both high quality and research so that we are building the right thing from the start and so that we can quickly build on top of our previous work.

Communicate, this is the how we get things done. No person is an island, we are team of engineers building a product together. Good communication happens when

1. you seek feedback often. Feedback protects us from complacency. In what and how we build products and in our careers. Career development is called development for a reason. If you think it’s just going to happen, then you’re doing it wrong. You build your career the same way you build the products we deliver. Be proactive in seeking out candid feedback.
2. you listen well. Feedback only works if you listen. This is not the same as blindly following what others tell you. Hear people out, strive to understand their position, and act accordingly.
3. you are open, very open. Over communicate internally and don’t wait for permission or for someone else to do it for you. We expect every engineer to make an impact and to share what they are doing. Share screenshots in slack, proactively volunteer to demo to the engineering team or even to the company during our town halls, dive deep with a Lunch and Learn, or get others involved with a Lunch and Destroy. Building things is only part of our job – the rest is telling people what we did and the positive impact it will have on the team and ultimately our customers.
4. you voice your opinions. Anyone’s allowed to argue their opinions — even in areas other than their own. But we also listen, seek conflicting opinions, and flex in the face of new info. Have strong opinions, but hold them weakly. If you’re going to voice your opinion, be humble.

Be a good friend. There’s a theme here. We work with friends, we work for friends, act like a good friend. Anything that’s broken is an opportunity to make Teem better. Be the type of teammate you want to work with. Openly and productively acknowledge weaknesses. Talk about possibilities, don’t focus on negativity. “Don’t be a jerk” has been one of our core values from the beginning , but it goes beyond simply avoiding “jerk-ness”, friends go out of their way to help each other. At Teem we expect our friends to: foster learning, focus on impact not your ego, no half-ass helping, proactively protect your team’s time, don’t be subtly racist, sexist, homophobic, transphobic, ageist, or foster any other kind of bias, and finally don’t take your teammates for granted.

It is important to note that these values are not only ideas that describe Teem, but are aspirational. Teem is made up of people, we can get distracted or make mistakes. But these values are constant reminders and guide posts for who we are and who we want be.

Peer Reviews

Your core values are not simply statements you make. Sure you can make a statement that these are the most important values to you, but ultimately your true values are those things that you do and repeat. It is too easy to let your values slip and change over time, especially in a quickly growing startup. Teem was not even 30 people when I started; we just cracked 100 earlier this year. We have attacked this culture issue in two ways. First, you need to seed the team with the right people, i.e. hiring. Over time we have worked on the interview process and candidate assessment process to help us find those people that not only share but will reinforce our core values. But that is a one time event, we wanted a process that would let us remember and consistently live these values throughout the year. With a lot of help from Dal, one of our product managers, general bad-ass, and jack-of-all-trades, we developed a peer review system that allows our engineering and product teams self-assess how we are doing not only from a purely technical skill level but also in all of the other skills that make up and reflect the core values.

Half of the review form directly addresses our core values. On a simple 5 points scale, we rate each other for:

• Maximize Positive Impact

  • How well does this person focus on our users
  • Do they have a bias for action
  • How well do you trust this person to deliver on their commitments

• Communicate

  • How well does this person listen?
  • How well does this person voice their opinions?
  • How open is this person? Do you know what they’re working on?

The second half of the form address technical and leadership ability. This section has two twists. First, we use a Fibonacci scale to rate skill levels. We purposefully do this to recognize that technical talent and ability is not linear. Skills are cumulative and it is often easy to learn the basics but then much hard to gain and demonstrate high level mastery. The second twist, we have a little bit of fun with the scale, mostly because Dal is a huge Star Wars fan, by labeling each level of the scale with a title from the Jedi Academy: Padawan, Jedi, Jedi Knight, and Jedi Master.

• Given this person’s role - what jedi level would you rate their skill?
  • Padawan - learning the stack, learning to be dependable, takes a little bit longer to get sh** done but still delivers, teachable.
  • Jedi - owns our stack, gets sh** done, is teachable, teaches others, thinks critically & questions the status quo.
  • Jedi Knight - bamf, great teacher, mentor to many, constantly learning, constantly shipping or the equivalent.
  • Jedi Master - this person goes above and beyond Jedi Knight and you would consider an industry leader.
• How would you rate this person’s technical leadership?
  • Padawan - Ships fixes and features that require days of focus, but often needs guidance either technically or when communicating with the rest of the team. Most work receives direction from experienced teammates.
  • Jedi - can handle significant, multiple-week-long features all by themselves. If the patch they just submitted is causing a problem, they’re quick to fix it, add a new unit test, and communicate exactly what went wrong.
  • Jedi Knight - go-to person for at least one very large, well-defined chunk of the codebase. They own more than just a feature. They maintain this entire section by guiding design, training newcomers, managing contributions, and regularly fixing bugs.
  • Jedi Master - completely and repeatedly own the design of entire products. They see the edge cases coming, ask great questions, and in general are the person you want reviewing your work. This is related to but not always the same as their skill level in their chapter.
• How would you rate this person’s project leadership?
  • Padawan - Everyone starts here. Often relies on other to define project goals, most projects are with more experienced teammates, consistently delivers on reasonably well-defined projects.
  • Jedi - proactively communicates issues as they arise, able to prioritize tasks within multiple-week-long projects, you trusted to handle significant multiple-week-long features.
  • Jedi Knight - Regularly leads small teams of developers, is comfortable with and is able to remove ambiguity, you would trust this person to keep large months long initiatives moving.
  • Jedi Master - one of the best communicators of complicated technical subjects, tradeoffs, and decisions; they can assemble and guide the team needed to deliver a project, they can be set free with a poorly defined problem, go into a cave with their team, and show up on the other side with a shippable solution.
• How would you rate this person’s people leadership?
  • Padawan - This person is a good friend, listens well, and you trust their advice.
  • Jedi - This person helps remove confusion, they understand how we work at Teem, and is a good mentor to help onboard people to become Teem-mates!
  • Jedi Knight - They help you find the right challenges to help you grow,
  • they can de-escalate conflicts and build consensus between team members, and have gained your trust.
  • Jedi Master - Not only is this person a Jedi Knight, but they provide Yoda level leadership by actively finding and removing distractions and defines process that helps us get more done with less stress. Sometimes they need a piggyback ride through the jungle.

Finally, we end with an open feedback section: “Any advice or kudos for this person that will help them become or continue to be a good friend and coworker?”

Every six weeks we ask the everyone in engineering and product to answer these question for 3 – 5 people via a Google Form. At the very minimum, the peer review process let’s us remind everyone about our core values. But we have designed it to not simply remind, but also force them to think critically about these values, and simply participating in the process allows them to live these values by providing the opportunity to communicate as a friend to your peer and even a chance to practice a little mentorship.

Finally, every question has a corresponding point value that I then take and aggregate into a report so that people can track their progress over time. This part has long been a time consuming process, but I have recenty automated the report generation using Python, Pandas, and Jupyter notebooks so that the entire review process will take just about a 10 mins to generate all of the review packets for the engineering team.

We have done this just short of a year now and has been well received so far. Perhaps the most important factor in how well this has worked is that peer reviews are strictly used for self-improvement. While I facilitate the review process for the team, we do not document these in some employee file somewhere to drudge up and use against people during an annual review. These are more like a “blameless post-mortem” for the past 6 weeks. Ultimately, and by design, they are a tool to practice all of our core values, a chance to “communicate like a good friend and help your teammates improve and maximize their impact in the company and for our users.”