A culture of learning & what it means for Thyme Care Engineering
Our recruiter Sarah Ruth recently reached out to a few of the engineers saying “I love hearing from candidates about the culture of learning. So I understand it better, how do you describe it?” Rather than just replying in Slack, this seemed like a great place to share publicly what we do.
One of the things that we are proudest of within the Thyme Care engineering organization is how learning and mentorship are core parts of our culture. We believe that investing time and energy into upleveling our engineering skills enables us to best solve hard business problems and to build a platform that will grow alongside our business needs.
Some of the ways we’ve built this culture are:
Hiring without regard to programming language - We do our coding interviews in whatever language a candidate is most comfortable in and don’t take what languages they know into consideration when hiring. We use Python on the backend, Typescript + Vue for web apps, and Dart + Flutter for cross-platform frontends, yet at least one of those has been new to nearly every engineer we’ve hired so far (for me, it was Vue and Flutter). We make sure candidates are excited to learn the tech we’re using and then make sure to build in time and tools for them to do so once they join. Most things in a new job will be new and we believe strong engineering fundamentals will let people pick things up quickly, regardless of language. We also believe sharing knowledge is critical to our success so we make sure candidates value mentorship as much as we do. More about our technical interview process is here.
Pair Programming - Many of us spend at least a few hours a week pair programming (and frequently, pair debugging). Each engineer has unique spikes of expertise about our tools and codebase. Pairing is often one of the most effective ways to share knowledge and help each other accomplish their goals and learn from each other. I’ve also found this to be a great way for exploratory learning where we’ll spend 15 minutes on a tangent about a small part of the codebase or language.
Engineering Guild - As we’re building out our applications and platforms, we often come across questions or challenges that could benefit from an organizational decision on how to approach them, either technically or tactically. What should our different environments look like? How should we handle on-call responsibilities when people are spread across time zones? Should we have database tables with compound primary keys? We have a biweekly guild meeting with all of our engineers where anyone can add agenda items and we discuss as a group to come to a path forward. We’ve found this to be a great dumping ground for aligning on best practice decisions across the org and a way to stay unblocked as teams. We’ve also split up reading through the DORA best practices and discuss them in guild to see where we’re aligning with best practices, where we could improve, and where we’re making intentional decisions to diverge.
Having people work on growth tasks - As engineers, we all have areas that we want to grow in, be it technical or otherwise, and areas where we’re comfortable and able to work quickly. When splitting up work, we try to balance the two, helping meet product and business goals by letting people work in areas they shine, while balancing that with having people do work that someone else may be able to do faster, but that would be a great opportunity to learn. We’ll also commonly have subject matter experts pair on tickets with someone who wants to learn to help spread the knowledge. We believe that the long-term investment in helping engineers grow is often more valuable than the short term gains in velocity.
The section of my Slack dedicated to learning channels
#eng-learning channels - We have a whole swath of channels dedicated to people posting articles and interesting things they’ve learned about, spanning lots of topics. Oftentimes the articles aren’t directly related to our work in the moment, but things that are interesting and helped them deepen their knowledge. Our #eng-learning channels as of today are below along with one of the most recent things posted in each for a taste of what they look like:
#eng-learning-culture-and-process (Better coordination or better software?)
#eng-learning-frontend (How to get $refs using Composition API in Vue3?)
#eng-learning-infra (Helm playground tool)
#eng-learning-mobile (Very good layered architecture in Flutter)
#eng-learning-python (So you want to be a Python expert? video)
Engineering Library - We have a virtual library where we list all of the books that people have physical or digital copies of that we can share amongst ourselves. These range from the technical (e.g. Microservice Patterns) to the interpersonal (e.g. The Manager’s Path or Thanks For The Feedback) with new books being frequently added as people are interested.
Eng learning goals workshop - One of the first things Laura brought to Thyme Care when she started was the idea of having a monthly check-in on our engineering learning goals to keep ourselves accountable. Everyone has goals for themselves, not tied to any kind of performance evaluation, of what they want to be working on, along with some playful ones as well. We also typically end this session with some kind of informal social game (like Codewords, Drawful, solving a crossword) to get to know each other better. Some example goals from the current spreadsheet:
Read Think Again: The Power Of Knowing What You Don't Know by Adam Grant
Declare tab bankruptcy. Declare email bankruptcy.
Contribute 2 new overviews of Thyme-specific infra to our learning library
Do more DJing
Stand up a new service in our infrastructure
Deep dive into python packaging + poetry with Meriah
Finish painting office?
Team-specific knowledge sharing - We have two teams of software engineers that have significant freedom to explore different ways of sharing knowledge and context with each other. For example, one team presents demos every Friday after standup. Engineers, PMs, and designers are all encouraged to demo their work early and often, whether it’s an application, Figma, command-line, spreadsheet, dev tooling, or code demo. As well as being a great way to celebrate our wins and stay up-to-date with different projects, we end up learning a lot of design patterns or tooling tips from each other.
Design docs - Personally, one of the ways I’ve learned the most while at Thyme Care has been in reading the technical design docs that my co-workers have written while building out features and our platform. People put a lot of thought into their technical decisions and reading about their considerations has been an invaluable way to not just learn about our codebase, but about new tools and ecosystems. People are also more than happy to talk through designs even further which is a great chance to ask questions and learn more about a topic than from just what is written. Writing design docs has been the same – I get to deeply explore a technical topic and then try to distill it down on paper for others to consider, which deepens my own learning.
There are plenty more one-off ways that people learn from each other, but hopefully this gives a sense of how learning and growth is embedded into our day-to-day. Importantly, this isn’t an expectation of something that happens outside of work hours – it’s a core part of the job and workday and we make sure people are given the space to learn on the job, not outside of it.