LinkORB Engineering

Recurring asynchronous check-ins

As a remote asynchronous-first team, LinkORB follows an ultralight asychronous approach to recurring check-ins between team members.

Most commonly check-ins occur between team members are their team lead, but the process is designed to support check-ins between any two team members. The overall goal of the check-in process is to:

  1. Highlight and celebrate what’s going well🎉 (required)
  2. Discuss areas of potential improvement or growth🌱 (optional)

The purpose of this guide will be to explain:

Highlights

At LinkORB, we believe in Holacracy and focusing on people’s strengths. This is why the first (and only required) part of the check-in is sharing what’s going well. In this space, team members should share examples of:

  • Projects and tasks they have found interesting and rewarding
  • Projects and tasks that have impacted customers, users, and other team members in a positive way
  • Communication practices and behaviors that are appreciated and helpful

Examples of highlights could be:

  • I really enjoyed learning about Kubernetes from Lindsey and then modifying our cluster performance.

  • Shipping the bug fix for community search was challenging but seeing the support requests decline felt amazing.

  • When you didn’t say anything on the PR, I was worried you didn’t like my approach on the new text messaging feature. Thanks for telling me you were just busy with the API breaking changes.

  • Thanks for responding to that frustrated user for me. I was worried about telling them we didn’t have a fix yet, but your workaround was genius!

Improvement and growth

Something else we believe at LinkORB is that everyone in the organization can improve and grow🌸. In this space of the check-in, we ask team members to share:

  • Potential areas for learning and growth
  • Opportunities to have a greater impact on customers, users, and team members in a positive way

To be clear, this is a two-way street. Both team members participating in the check-in are encouraged (but not required) to share areas for improvement and growth.

Examples of improvement and growth could be:

  • After working on the Kubernetes performance, I realized I really like devops and would appreciate more opporunities to work with Lindsey on similar tasks.

  • I think the community search bug could possibly have been avoided with more time for testing. Can you please share your test plan earlier next time?

  • Thanks for finding the breaking changes in production. If something like that happens again, please remember to get the notification banner on the site right away and inform support in case they get inquiries.

  • You did a great job handling that frustrated user. Would you be interested in helping plan the next version of self-help guides?

Initiating a check-in

Check-ins are facilitated through Cyans and designed to be ultralight 🐝, taking no longer than 15 minutes for each team member.

To begin a check-in, simply start a Cyan’s topic with the relevant team members titled [Check-in] team-member-A : team-member-B. For example, [Check-in] msmith : kjones.

For the message body, something similar to the below is suggested:

Hello kjones - let’s have a check-in to:

  1. Highlight and celebrate what’s going well🎉 (required)
  2. Discuss areas of potential improvement or growth🌱 (optional)

Highlights

  • Your independent research and recommendations on Kubernetes performance improvement saved the team a lot of time
  • The internal wiki page you created describing the best practices and testing methods helped everyone get on the same page and will be very useful for new team members during onboarding
  • Your last pull request showed great improvement in following our standards for commmit conventions and pull request title and description.

Growth

  • Thomas has shown interest learning more about Kubernetes. Do you think this is an appropriate backlog item we could assign to him and could you assist if he needs help?
  • Johanna did not know the production bug was the reason it took longer than usual to complete her change request. If possible, revise your estimate completion date next time or send her a quick note about why you had to reprioritize.

For the next steps, please:

  • Share your own highlights and potential growth areas (for either of us!)
  • Let me know if you have any questions about the above

Responding to a check-in

As mentioned above, the primary goal of the check-in is to highlight and celebrate what’s going well. So using the format above, shoot a note back with your highlights on recent work.

And if you see potential for your own (or the other team member’s) growth, share that too.

After sharing your thoughts on higlights and growth, you’re done! Remember, this is asynchronous and ultralight. If everything is clear, smile, put a kettle on🍵, and get back to the gig.

If further discussion is desired 🙋, no problem!. Keep chatting through Cyans and when necessary, a virutal 1:1 meeting is a nice break from the keyboard🔤.

Check-in best practices

  • Keep it lightweight. If completing a check-in takes longer than 15 minutes, take a step back and center on the 1-4 most important things you want to share. Don’t try to boil the ocean, but focus on what’s most meaningful. If you are still stumped, reach out to a trusted team member for help🌞.

  • Be specific. Reference and link to Cyan’s topics, Team HQ tasks, pull requests or other relevant examples when discussing highlights and areas for growth.

  • Make it recurring. Check-ins are expected to be recurring and are often more frequent for new team members. Once you’ve done one check-in, subsequent check-ins can happen in the same topic.

  • Check-ins aren’t just for team leads. Any team member can initiate a check-in with another team member at any time.