Amino’s Head of Engineering describes the values that shape our engineering culture.
Amino is like many companies: we have a list of core values. Taken out of context, they can sound a bit abstract and disconnected from the day-to-day work of building and running a startup: People. Impact. Challenge. Facts.
For all their abstractness, I have been impressed with how often these values seem to be embodied by our daily operations, and how deeply ingrained they have become in the ongoing culture of the company.
In my experience as the Head of Product Engineering, we have been extra thoughtful incorporating the “People” value:
People are at the heart of Amino. We are a diverse team, each with unique perspectives and contributions. We treat each other with kindness and respect. We hold ourselves to high standards of craftsmanship and integrity, especially when we are trusted with private or sensitive information. We encourage and inspire each other to thrive, both professionally and personally. We are united by our desire to help people.
That sounds great on paper, but how does that work in practice? From my vantage point as an engineering manager, here’s how.
We have a strong culture of mutual respect.
Mutual respect boils down to giving people the benefit of the doubt: we’re all here to learn and excel, and we make choices based on the best information we have available. That applies to both when things are going well, but especially how you react and collaborate with people when you encounter a bug, disagree with an implementation, or get buzzed by PagerDuty.
The Recurse Center, an educational programming retreat based out of New York, eloquently expresses some of the main ways to proactively create a positive growth environment in their User’s Manual. One big enemy to growth that they describe is fear:
We think this is one of the most pernicious impediments to education. In most of the world, but especially school and work, people are afraid of looking stupid. This fear frequently keeps us from asking important questions like "how does that work?" or even just "why?" Worse, it keeps us from saying "I don't understand." That means many of us muddle on with a half-baked or entirely incorrect understanding of core concepts. This is particularly bad with programming, because these misunderstandings compound, and over time become harder and more embarrassing to admit to and address.
At Amino, we believe that in order to best set ourselves up for success, we need to create an environment where people feel open and eager to learn and ask questions. As the Recurse Center explains, saying "I don't know" or "I don't understand" is seen as a positive thing—it means we’re getting closer to a real shared understanding of the problem.
We take the long view in terms of evolving our team’s expertise, and optimize processes to maximize the shared knowledge and effectiveness of the group. We have a strong emphasis on teaching and mentoring, and we have teams with mixed levels of expertise. More senior team members are expected to lead through supporting and mentoring others, rather than through virtuosic personal performance. When someone asks a question, people are generous with their time and give their full attention to help make sure the question is answered and the person fully understands the concepts. In code reviews, people are genuinely interested in giving feedback that shares knowledge and improves the codebase.
This also applies to when things go wrong. If a problem happens in production and the live site is impacted, we ask questions. We try to figure out how to improve the system that let the problem happen, rather than calling out or focusing on correcting the individual that made the mistake. When the Amino website went down for the first time a few weeks after launch, we toasted—it had to happen sometime, and it was good to get that mistake out of the way sooner rather than later.
We adopt human-centric development practices.
Problems happen, even in a healthy engineering culture. Errors are a fundamental part of doing complex work: misunderstandings arise, language is ambiguous, people forget things, and estimating software projects is a very hard task.
Being healthy doesn’t mean never getting sick—it means developing the right habits to avoid problems, deal with them when they arise, and gain resilience from them.
In the product engineering team at Amino, we’ve adopted practices inspired by a number of Agile methodologies. We’ve found this gives people the confidence to work fast knowing they are supported by their peers, in addition to reducing uncertainty and maximizing our ability to find and correct errors:
- Clarity of purpose comes from direct collaboration between product, design, and engineering teams, and we capture what we want to accomplish in User Stories.
- We estimate our Stories using points, and organize them in a backlog that makes it clear what our priorities are and what our expectations are.
- We write unit tests and integration tests to make sure our code is correct, and we don’t fear change. Tests get run automatically in CI.
- We do code reviews on all of our code. No code makes it into the mainline branch unless multiple people have seen it.
Standard stuff, but important. Beyond being industry standards for creating more accurate forecasts and more robust software, these processes all come together to have the effect of underwriting a healthy, supportive work environment. You don’t have to worry too much about making mistakes. Do your best work, and the process (and your coworkers) have your back.
Work-life balance is taken seriously.
Flexibility in work schedule is more than a perk, it’s a matter of accessibility and inclusion. A job that requires you to be in one physical location during a rigid set of hours is less friendly for people whose personal responsibilities come into conflict with a strict schedule. That often disadvantages people who struggle with physical or mental illness, in addition to making it difficult for people with parental or family responsibilities.
As a healthcare company, we design our work in a way that not only allows our people to work from home or take unexpected time off on short notice, but actively supports and encourages people to do so. That means having online tools for team communication (hello, Slack!) as well as providing people with the support and autonomy necessary to work away from the office.
Work-life balance is also about how you don’t work, which is an area where startups often fall short. Many tech companies advertise an “unlimited vacation policy” as a perk, which often in practice turns into an anti-pattern for balance. It can translate to, “no one knows how much vacation to take, so you take some and then kind of feel guilty and periodically check in to make sure you don’t miss anything.”
I’m much more attracted to mandatory vacation: you are expected to take some minimum number of days off in which you do not do work and do not check in. Beyond being centering and mentally restorative, this helps ensure that knowledge is not siloed into any single individual in your organization. Just as we don’t want a single point of failure in our software architecture, we want to avoid single points of failure on our team. Call it the “Yosemite factor” rather than the “bus factor”—if your team must continue to function when any given person is fully out of contact for two weeks, you will have a more balanced and healthy team.
We want a diverse team and our hiring practices reflect that.
Our Head of Talent posted his observations about Amino’s hiring and interviewing practices in general. We strive to find people who have shown a passion for learning, are rigorous and self-reflective about their work, and who have established the basic skills of their craft such that they can hit the ground running in our small, fast-moving organization.
We have a strong desire to hire people with diverse backgrounds and different ways of thinking, so we try to be mindful in shaping our recruiting and interviewing processes to reflect this.
When we write our job descriptions, we communicate the values of the company and try to be realistic and specific about what the role entails. We try to be mindful of the subtle ways that bias can creep in, and how overstating requirements disproportionately discourages women from applying. We also focus more on “value fit” than “culture fit,” and actively avoid confusing “culture fit” with “similar to all the people who currently work here.”
While it’s important to have mastery of the basic tools and a mind for writing efficient solutions, an academic background in Computer Science is not a prerequisite for success in our engineering teams. (I personally have an English degree, so maybe I’m biased.) It’s easy to accidentally select for this though, even if you’re not trying: many typical interview questions end up taking the form of something you’d find on a problem-set, which specifically selects for people with experience with solving these sorts of artificial problems.
To avoid this, we focus on asking questions that as much as possible directly evaluate how someone would tackle a problem we expect them to face—when we interview, instead of asking people to invert binary trees on a whiteboard, we draw our challenges and exercises from problems we’ve actually had to solve. If we can avoid the whiteboard entirely, we do. In the last round of frontend interviews for my team, both in-depth coding sessions involved having people working on their own computers, using their own development setup, with help from the internet to solve the challenges—that’s how you’d work on the job, so why not set up the interview to replicate those conditions?
We actively strive to create an inclusive work environment.
One thing that struck me when I attended Pycon this year was how diversity and inclusion were front-and-center in the Python community. Jessica McKellar, the diversity chair and former director of the Python Software Foundation, proactively published diversity figures on the percentage of talks given by women over the last six years. There were talks on patterns and anti-patterns for diversity within organizations, and most talks had stenographers projecting captions for the hearing impaired. Guido van Rossum wore a Pyladies shirt to his keynote and made offered mentorship to women who wanted to become core developers of the language.
One of the biggest learning moments for me was the emphasis on inclusion, beyond just focusing on diversity, and that there is a danger in expecting the job to be done as soon as you have made the right hiring choices. A focus on inclusion as a value reminds us that the real goal is a workplace where everyone feels comfortable and respected being who they are, talking how they talk, thinking how they think, and contributing how they contribute.
While we are definitely not perfect, and have blind spots we have yet to uncover, we try to proactively create a space where people feel comfortable making suggestions on how to be better about this, and pointing out areas we are inadvertently falling short of our values—and then taking real, concrete actions in response. Some of the small, but important ways we’ve tried to make Amino feel more inclusive, both as a product and as a place to work:
- We have unisex bathrooms.
- When asking for information to personalize your doctor search, our gender field is optional.
- Our data science team thinks about the ways in which we can use data to help transgender patients connect with doctors.
- We have an explicit discrimination and harassment policy.
- We have a parental leave policy.
As a manager, I have tried to contribute to making the place I work a more inclusive space. This has involved proactively educating myself about how to be an effective ally, and what my blind spots are. If you’re interested in reading about this further, Etsy recently published a recommended reading list for allies, and a guide to being an effective ally that are good places to start.
Parting thoughts
This attempt to live our values and make them a part of everyday work life has been a largely organic process that has drawn from the experiences of people here—much of what we’ve learned has come from people feeling comfortable pointing out areas we could improve.
A lot of the things we’ve found that work well for us have required trial, error, and ongoing iteration, and we still have a lot of work to do. If you’re interested in helping people, and working in an environment that values everyone, we’re hiring!
We are making the world a better place. But really.
