Your partner in navigating the ins and outs of prescriptions — at no extra cost.

Alto Pharmacy Technician

Alto Pharmacist

It’s official: Alto Pharmacy is a great place to work! We’re honored to join the community of Great Place to Work-Certified™ companies based on team member feedback and a rigorous assessment of our company’s culture and benefits.

Join us in delivering our industry-leading pharmacy care to millions of people across the country. As a member of the team, you’ll play an integral role in improving our customers’ quality of life and redefining what’s possible in pharmacy. 

Be Part of a Great Place to Work — Join Our Team

Hear first-hand from members of the Alto technology teams.

Read the latest Alto blog posts covering healthcare, family health, managing diseases, and other Alto highlights.

Blog | Alto Pharmacy

Justin Moy, Senior Software Engineer at Alto, explains how the engineering team developed a staging environment strategy that could keep up with our growing organization.

Creating Sandboxes: How to Make It Easy for Your Engineering and Product Teams

When we formed our Infrastructure team in 2020, our charter centered on scale, reliability, and the developer experience. Our first priority? Developing a staging environment strategy that could keep up with our growing organization.

Initially, we had a set of command-line tools for staging environments that could be run from an engineer’s workstation. However, this approach required significant manual effort to create and manage an environment which led to inconsistencies like outdated data and lack of full application coverage and integration. The required workstation dependencies and maintenance added to the overhead. These tools were also different from the ones used to create a production environment, causing drift between the two.

To address these issues, we focused on improving our tooling to create consistent and reproducible results for both our staging and production environments. Here are the five steps we took to get there:

Luckily, we were already here. Our deployment process involved creating and deploying Docker containers and using a Procfile to run specific parts of our applications (think separating out web and workers). Packaging our applications as immutable Docker images allowed us to ship consistent and portable code. These images are run as containers which can be executed on separate hosts and scaled independently of each other.

We wanted to increase our observability, mature our internal monitoring, and maintain our infrastructure in a more consistent and reproducible manner. Kubernetes, and its automated container orchestration (deployment, scaling, and management), allowed us to accomplish all of the above goals.

It was easy for us to get started in Kubernetes thanks to Kind, which allowed us to run clusters locally. This increased development speed and reduced the friction of learning a new external provider.

Helm makes it easy to manage packaged applications in Kubernetes. Some community-provided applications include: NGINX for load balancing and reverse proxying HTTP and other traffic; Prometheus and Cortex for metrics, monitoring, alerting, and dashboarding, Loki for logs; and Sentry for exceptions.

In order to ease the integration with other infrastructure components, enable rapid deployment, and, most importantly, provide us with the consistency and reproducibility we wanted, we created and deployed Helm charts for our applications.

From here, we could stamp out our applications for developer use in sandbox environments: complete end-to-end environments, separate from production, that enable engineers to rapidly develop and test their code. And if an engineer is working on multiple features, they can spin up multiple sandbox environments and manage their applications and data independently of each other. Victory!

We had already created pipelines in Concourse to automatically deploy and upgrade our infrastructure Helm charts. To eliminate the manual toil of spinning up new environments and to reduce the friction around sandbox adoption for our engineers, we extended these automated pipelines by building a Git-driven continuous deployment pipeline. When an engineer created a commit to a repo defining the state of a sandbox, our Concourse job would apply these changes.

At this point, we could deploy environments that resembled production but were separate from production and other sandbox environments. They connected to the rest of our observability stack, including metrics, logs, traces, and exceptions.

As we prepared to scale to the rest of the product and engineering organization, we focused on the following ideas: further reducing manual toil, removing barriers to entry, reducing cost, and optimizing the development workflow. The diagram below shows our sandbox architecture.

In Kubernetes, an operator acts on custom resources in order to automate a task or set of tasks. The custom resource allows us to create a well-defined entity and extend configurability options to users. The operator allows us to customize individual sandbox environments based on changes to the custom resource.

We utilized Kubebuilder to create our operator and CRD (custom resource definition). Kubebuilder was a great starting point and provides tools to ease rapid development of a new operator.

Using this pattern, we could easily perform CRUD operations (create, read, update, delete) on a custom resource using standard tools like kubectl, and the operator would handle updating our deployments in Kubernetes. These updates could include: updates to application configuration, deploying a new Docker container, injecting different secrets, etc. This flexibility allows for testing of many different scenarios like: developing a new feature, reproducing a bug, upgrading frameworks, and security and load testing.

Increase adoption by removing barriers to entry (admin web UI)

We built a web UI so users would be able to deploy sandboxes intuitively and easily without extensive knowledge of the underlying tools. The web UI interacts with our custom resource and lets the operator handle updates. It allows our teammates—both engineers and non-engineers—to easily spin up their own environments for development, demo, or training purposes without modifying production data.

In addition, we show helpful information about a sandbox to a user. This includes links to each of our applications; pre-filtered logs, metrics, tracing, and exceptions; and commands to connect to specific applications to ease debugging.

Because the sandbox environments are integrated with our monitoring stack, we have the full metrics and logging that we expect from our applications. We created an autoscaler service that performs queries against this information and scales our sandbox environments up and down. We’re able to decrease our costs by over 90% when these environments are not in use and are able to quickly scale them back up when they are being used.

Optimize the development workflow (image updater)

An additional feature we built into our sandbox environment is the ability to follow a feature branch in our applications. When an engineer pushes a commit to a pull request in Github, a corresponding sandbox will automatically update to this commit. This reduces several manual steps in the development workflow and allows engineers to test their code in near-to real time.

Sandbox environments have made an impact on the engineering organization and beyond.

Engineers can quickly desk check new code in a production-like environment during code reviews.

Shared sandboxes reduce the blast radius of bug bashes.

Non-engineers can spin up sandboxes to demo or provide training on features without impacting production data via the Admin UI. This has proven particularly useful for Product Managers and Designers on the team to be able to play with product features and better understand how they work in order to suggest improvements.

Teams have built use case scenarios into their applications. This allows easy reproducibility of critical paths and functionality.

With these five steps—Containerize, Kubernetes-ize, Helm-ify, Automate, Optimize—we’ve laid the foundation for deploying all of our environments in an automated and consistent manner. In addition to applying many of our learnings to improve our production environment, we successfully built core infrastructure that our engineers, product managers, and designers use each month to test their changes and reduce production downtime.

Interested in learning more about engineering at Alto? Follow us on LinkedIn. 

In this post, we'll share how we identified the problem of failing cypress seeds, what the culprit was, and three ways to make seeding test data more robust.

How to Debug Slow and Failing Cypress Seeds

End-to-end test failing before it even begins? Here’s how we timed, debugged, and sped up our seed data.

At Alto, we use Cypress to test our Rails application end-to-end. As our application grows, so does our end-to-end test suite — along with the seed data it requires. This led us recently to a perplexing problem:  when run in CircleCI, our end-to-end tests would mysteriously time out during the seed step, causing them to fail and block deploys.

Seeds can be painful to debug. They’re typically set up through a single request and, depending on how thorough the tests are, call upon most of the models involved in the application. If a model throws, say, a validation error because of bad seed data, you'll see it in your Cypress logs. If a model hangs, the request often doesn't show up in the logs at all. There's no status code, no error message—all you know is that somewhere, somehow, some process is failing to finish.

In this post, I’ll share how we identified the problem, what the culprit was, and three ways to make seeding test data more robust.

To Identify the Problem, Focus on Your Logs

We started by comparing logs from our failing CircleCI runs with those from local test runs. Turns out, our CircleCI logs in failed runs stopped after a specific log message. 

For example, when our test runs succeeded, the logs looked something like this:

...
LOG: creating model
WARN: foo with id=123 not found
WARN: foo with id=456 not found
WARN: bar with id=789 not found
ERROR: Invalid parameter to function `foobar`
LOG: model created
... rest of logs

But when they failed, they instead looked like this:

. . .
LOG: creating model
WARN: foo with id=123 not found
WARN: foo with id=456 not found
[end of logs]

This let us know where to focus: after the function that looks for foo, but before or during the one that looks for bar. Of course, this only works if you have enough log statements scattered around in the first place. I’d recommend logging the time it takes to create each model in seeds, which has the added benefit of telling you where to start if your seeds are becoming annoyingly slow. 

At the top of our file in db/seeds, we declare the following function to add timings to our CI logs:

@last_time = Time.now
def log_time(label)
    Rails.logger.info("Time [#{label}]: #{(Time.now - @last_time)}")
    @last_time = Time.now
end

We then call the function after each create statement in our seeds:

Product.create!({...params})
log_time(“Product Create”)

This prints logs in the following format:

...log metadata message=Time [Product Create]: 12345
...log metadata message=Time [User Create]: 1102
...log metadata message=Time [Address Create]: 105
...

These logs will help you figure out problematic model create calls, but each model may have a lot going on in its callbacks (before_save, before_commit, after_save, etc). You can follow a similar approach to time those callbacks:

# in the model file
Class Model < ApplicationRecord
	
...

before_save :foo

...

def foo()
   start_time = Time.now
   [ ... things that happen inside the function ]
   Rails.logger.info("Time [foo]: #{(Time.now - start_time)}")
   [ function return statement, if applicable ]
end

It’s important to note that the most time-consuming statements in your seeds often cause the most trouble, but that’s not always the case. If your seeds are hanging due to external API calls, it’s entirely possible for those calls to usually take a short time to complete. If you have hanging tests, I would recommend logging test runs in CircleCI, since you may not be able to find the problem locally. 

Through timing our seeds, we narrowed down our search to five of our most time-intensive models. We were then able to time the individual callbacks within those models. One callback  in particular—containing a call to an external database—raised the most suspicion. It took up most of the time it took to create the model, didn’t return any information needed in our test, and was not mocked or stubbed out. 

Requests to this test database would usually work, however, since we call on it multiple times on every CI run, with concurrent CI runs, these requests would sometimes take a long time to complete, leading to a test timeout. 

In our case, since we were making calls to a hosted database in our tests, we changed our test environment to create and refer to an isolated instance of the database. While this was the best approach for our specific issue, we also explored some other ways of stubbing out API calls and skipping callbacks from your seeds file, which we describe below. Use these approaches with caution, as the more you stub, the less true-to-life your tests will be. 

Ideally, you would have already stubbed out third-party API calls in your code using environment variables. An example approach:	

def do_the_thing()
    if Rails.env.production?
    	[ ...do the thing ]
    else
	[ ...do some fake thing if needed ]
       Rails.logger.info("We theoretically would have done the thing.")
end

However, you can also use Typhoeus to mock third-party api calls in seeds, similar to how you might in a test. Imagine that your Product model makes a call to "https://slack.com/api/foo”. We can then mock that call out as follows:

mock_response = Typhoeus::Response.new({code:’500’, body: {
    “ok”: false,
    “error”: ‘not_authed’
}.to_json})
Typhoeus.stub("https://slack.com/api/foo”).and_return(mock_response)
Product.create!({...params})

Again, I would advise you to stub check for environment variables in your code rather than stub out individual API calls in your seeds and tests. But if for some reason you need to do the latter, it’s possible!

Similarly, you might want to stub out a function you’ve written if it takes a long time to run and doesn’t affect the outcome of your tests. This can’t be stubbed out in the ways we mentioned above since (1) you might need it  for — and hopefully are testing it in  — other tests and (2) it doesn’t have a url. minitest has a tool for this. Imagine you’re trying to stub out some functions from a Photograph model.

require ‘minitest/autorun’

Photograph.stub :fetch_product_photo_url, ‘’ do
   Product.create!({...params})
end

This will return an empty string when Photograph.fetch_product_photo_url is called within the Product model’s callbacks. You can also replace the empty string with anything else you might want the function to return.

Last but not least, it’s possible to skip entire callbacks and validation. I wouldn’t recommend skipping all of them, as that can cause models in your tests to stray very far from how your models actually work, but you may find it useful to skip specific callbacks.

While all the methods that I’ve suggested above are possible and can be useful, remember that stubbing and skipping from your seeds may just be band-aids for issues you have elsewhere. In our case, we could have stubbed out a model function or created an isolated database for testing. While both methods would have been functionally the same, doing the latter allows us to have to worry less about that database in the future—if, for example, we write more functions that depend on it, or update the mocked functions to do more than they currently do. Keeping tests in line with how the product works also keeps it more in line with the actual user experience: if it’s taking a long time to create a model in your seeds, it probably takes a long time for your users, too. 

Since adding timing logs and creating an isolated database to our end-to-end tests, we have a regular source of truth for the efficiency of our models, are able to develop more smoothly with fewer spontaneous test failures, and have more confidence in our ability to quickly pinpoint and resolve seed timeouts in the future. 

Last year, we built a feature to show patients all of their medication pricing options, including when paying cash might be cheaper. Here are two surprising trends we've discovered since.

Two Engineers Crunch the Numbers: When Is It Cheaper to Pay Cash for Your Medication?

Tom Cahill and Ashley Qian, Sr. Software Engineers

In 2019, we launched a streamlined flow in our patient app to handle a surprising scenario: when the out-of-pocket price for a medication is less than the insurance copay.

Since launching our price selection feature last year, we've saved thousands of patients money by bringing this disparity to their attention. On average, patients save 30% off their total copay when their out-of-pocket price for a medication is cheaper than the insurance copay. The average savings per prescription is $23.30. 

While several factors impact how drug pricing works, here are two trends we’ve seen in the data so far.

These Two Therapeutic Classes Are Most Likely to Be Cheaper Out of Pocket

A therapeutic class is a method of categorization that groups medications based on the conditions that they are intended to treat. Here's what we found when we aggregated prescriptions by therapeutic class:

Across the 394,367 prescriptions we examined, roughly 0.5% had lower out-of-pocket costs. Comparing different therapeutic classes, anti-parasitic drugs (example: permethrin) appear most likely to have a cheaper out-of-pocket price by a fairly wide margin at 2.94% of cases. Cardiac/cardiovascular drugs (example: rosuvastatin calcium aka Crestor) and blood medications (example: tranexamic acid) stand out as well with over 1% of cases.

Looking at the results in terms of median percentage savings, a few classes stand out as having a fairly high disparity between prices: anti-histamines, contraceptives, anti-neoplastics and anti-infectives. 

Brand Medications Are Less Likely to Be Cheaper Out of Pocket

You're up on Family Feud, and Steve Harvey asks you to name some differences between brand-name and generic medications. The first thing that probably comes to mind is cost: In general, one expects generic medications to be cheaper than their brand-name alternatives. We might expect brand name medications to incur higher copays and thus a larger opportunity for Alto to provide savings. However, we see a surprising trend in our data:

In fact, only .01% of brand name medications we've delivered since shipping this feature had lower out-of-pocket prices (compared to .6% for generics).

So what gives? The cash price we’re able to offer for a medication is mostly determined by the cost we paid a wholesaler or manufacturer to buy it. The copay set by insurance plans, however, is often impacted by behind-the-scenes negotiations between the drug manufacturer and the pharmacy benefit manager, or PBM. As a result, the cash price isn't always strongly correlated with the insurance copay:

Among a set of equivalent products, the one with the cheapest cash price might not be the one with the lowest insurance copay, and that difference can be significant enough to make it worthwhile to forego using insurance.

As engineers who are tasked from time to time with investigating issues with our billing system, we've experienced our fair share of bewilderment at the surprising outcomes we sometimes see. The complexity of pricing is why we've invested so heavily in making sure both our internal tools and patient-facing applications present users with the information they need to understand their options and make well-informed decisions.

We have countless opportunities to help our patients achieve better health outcomes, save money, and be more informed about their choices when it comes to their medication. There’s a lot of exciting work to do, and if this sounds interesting to you, please reach out to us on LinkedIn. We’d love to hear from you!

We are building a pharmacy where every patient matters and is included. To do that, we need to foster a culture and company that is committed to challenging existing racism, injustice and prejudice, in order to create a culture and service that is inclusive. 

Diversity At Alto: Building an Inclusive Healthcare Company and Culture

At Alto, we are redefining the pharmacy experience which has been part of a very old, broken way that has fueled systemic racism. We are building a pharmacy where every patient matters and is included. To do that, we need to foster a culture and company that is committed to challenging existing racism, injustice and prejudice, in order to create a culture and service that is inclusive.  Our team consists of committed and passionate individuals who champion to effect positive change on issues related to race, injustice and prejudice.

This passion for equality is what we strived for when we first set out to build a team with a broad representation of diversity. Our goal was to create a community that reflects an inclusive culture regardless of age, education, gender, race, ethnicity, religion, sexual orientation, socio-economic status, or other dimensions of diversity. Yet even with the best of intentions we recognize that there is more work to be done to dismantle the systems and structures that fuel racism and inequity.

2020 has been a year like none other for so many.  HR professionals around the globe have stepped center stage to support our organizations, teams and communities in ways many of us could not imagine.  I wanted to write this post to share my personal journey on this topic while supporting others in capturing this moment.  I am a white gay cis man.  Many of my identities provide much privilege.  I am committed to educating myself. I am building an environment where our teams can push past their fears to learn and grow.

Read more about Why We Prioritize Diversity at Alto.  

In 2019 we initiated our focused DEI (Diversity Equity Inclusion) work with the goal of ensuring employees felt safe, and included, and ensuring that candidates and employees have equal access to opportunity for advancement in the organization. We learned a few things during the early days of this work including balancing listening while creating the right structure to move to action.  Fast forward to early 2020, in the midst of the global COVID-19 pandemic and the murder of Ahmaud Arbery, Breonna Taylor, Tony McDade, George Floyd, and Jacob Blake, we like many other organizations did not want another moment for action to pass by.

Read more about Alto’s Mission and Values. 

The week after George Floyd’s murder we hosted a series of listening sessions for Altoids.  We began them with a simple statement:  “We are holding this space for you.  Tell us how you are feeling.  Share your experiences.” The results were powerful moments of revelation, pain and heartbreak.  Black, Asian, Native and Latinx Altoids shared experiences of racism, sexism, and prejudice in their lives.  As a leadership team, we started to wake up to the enormity and urgency of the work we had ahead of us.

In reflecting on these tragic murders and Altoid voices, we realized we needed to expand the building blocks of our 2020/2021 DEI strategy. We recognized that we didn’t want to rely on the members of our underrepresented communities to lead us on this journey.  We do not expect underrepresented professionals to teach us, especially cis white men, about the history and experiences that led us to this moment. 

We made the decision to find a partner to help.  What struck me about Pathfinder and Trier Bryant, is their ability to push our thinking on this critical work while meeting us where we are (each one of us). Trier is a strategic leader with distinctive Tech, Wall Street, and military experience spanning across 15 years. Pathfinder has an unwavering commitment to advise leaders on how to create a more equitable, inclusive, and thriving culture to produce prosperous companies. I appreciate many aspects of Trier’s support including that she too is a Chief People Officer, she wears these shoes.  Given that experience plus Pathfinder’s work with clients like Equinox, Compass, SoundCloud, Gusto, and eBay, we gain perspective and lessons learned.

Our first half-day session with Trier focused on educating the group about the language of diversity (e.g. Is it okay to say Black? What makes up the LGBTQIA+ community?).  Next we spent time learning about key historical events starting from 1619 that have shaped our current society with respect to race, oppression, and white supremacy in America.  We watched videos displaying more covert forms of white supremacy [see Ellen Tuzzelo’s Pyramid of White Supremacy]. 

These are actions I could recognize in myself (i.e. not challenging racist jokes when told by my family members, not always believing the stories of Black victims).  I felt sadness and shame. Sharing these feelings and our part in the current state of our nation is an important step. We took time to process and walked away with an epiphany.  

Over the past decades, America and specifically Corporate America lulled itself into thinking that we’ve been fighting bias.  Our aim up until this moment was to reduce or eliminate bias.  We were wrong.   Our fight, our work is to eliminate racism and white supremacy in America. This work is neither a marathon nor a sprint; we’re committed to doing this work all our lives.   

With that realization in mind we got more specific about what diversity meant to us and where we wanted to focus our teams at Alto. Diversity by nature is very broad and inclusive. We used individual characteristics, experiences, and abilities consistent with our values and mission that includes but is not limited to:

*Sexual Orientation and language abilities will begin to be captured with Workday, our new HR system.

As a part of the above education, we learned that while we all have various identities and intersections that represent our Altoids, intersectionality is a term that must be clearly understood to comprehend unique modes of discrimination and privilege that occur in the workplace.  

Identity - the fact of being who or what a person is; affinity (i.e. Hispanic/Latinx, Black, Male, Female, Nonbinary) 

Intersections - a point at which two or more identities  intersect (i.e. Hispanic/Latinx Gay Male, Black Heterosexual Female)

Intersectionality -  the cumulative way in which the effects of multiple forms of self-identifications intersect, overlap, or combine to create unique modes of discrimination and privilege; intersectionality identifies advantages and disadvantages that are felt by people due to a combination of factors

While Alto recognizes a broad and inclusive definition for diversity of various identities, there are strategic priorities for underrepresented groups at the company. After benchmarking current tech and health care demographics, we decided to focus our DEI work for Altoids including our leadership, managers and independent contractors on the following underrepresented groups at Alto: 

Women in STEM (Science Technology Engineering Math)

The following month we read So You Want to Talk about Race by Ijeoma Oluo. What an incredible read! This engaged us in thinking about and naming our privilege.  In the next half-day session with Trier, we discussed the book to name our privilege and explored how it influenced our personal and professional development.  

We learned several lessons from Ijeoma and Trier including that we’re going to make mistakes and say the wrong thing; that is part of the journey yet we still must do the work.  Also that microaggressions are as damaging as overt racism and we must do better at calling these detrimental behaviors out everyday. 

Lastly, non-white people fear retaliation most when the topic of racism and prejudice comes up; we must create a space for everyone’s voices and perspectives to not only be heard but respected.

As I reflected on our second half-day session together, I saw the journey for our leadership team through four stages.

Stage 1: Self-Awareness-doing the personal work regarding racism and privilege

Stage 2: Awakening-acknowledgement of role of racism, privilege, and gressions,; doing the work in our professional life

Stage 3: Empowering-identifying the work to be done with our team, team members and building more inclusion on our teams

Stage 4: Advocating-taking our roles as a senior leaders at Alto to change behaviors and lead change at the company and our communities 

For the last round of workshops we split up our senior leaders into smaller groups so that we could focus on the work needed to be done with each of their teams.  In these sessions, we learned more about identities.  How do we identify?  What do we learn and acknowledge about our team members identities?  We discussed specific examples of how intersectionality shows up in the workplace and the role it places in each other’s experiences.  This pivot allowed us to move into Stage 3.

As we embarked on taking this work to our team, we felt more prepared and comfortable because of the time spent educating, processing and doing our own work ahead of time. This allowed each of us to live one of our core values “start with empathy.” Being empathetic is hard when you haven’t done your own work.

As a result of all the foundational work we’d done as individuals, as a team and as a company, in July, our leadership team committed to a bolder, crisper DEI plan that includes four strategies with clear goals:

Hire - ensure we have diverse teams and insure all are valued

Include - increase inclusion and community 

Develop - educate our leadership team and all Altoids

Invest - support initiatives with money and time  

This new DEI plan rallied the team and catalyzed us to make some significant changes with clear alignment, commitment and clarity around the problem we’re trying to solve. For example, one immediate change we made was to focus our executive search process on underrepresented talent. I’m excited to share that only a few months later (most searches take 6 months), we were able to hire several outstanding candidates from underrepresented backgrounds. 

Before, we had just been “hoping” for diversity and thus looking in all the wrong places.  Once hiring diverse talent  at the executive level became a critical mandate, that forced us to really seek the right kind of strategy. I’m excited to share some more of the significant changes we’ve made, over a series of posts over the next few months.

We are far from perfect.  We have work to do to meet our goals.  These are our first steps.

In January, we will share our first DEI Report including workforce demographics, success stories, lessons learned from 2020, and aspirational goals for 2021 and beyond.

We condemn the violence and systemic racism that has harmed marginalized communities, specifically Black communities, for far too long. At the same time, we commit to look inward and educate ourselves to continue to create safe spaces for Altoids and to act on what we learn. 

This will be a lifelong journey and we will continue to share updates on our progress. Our actions must be sustained and focused on keeping the momentum of enabling change now and for future generations. 

Last, personally this work is the most fulfilling of my career. There are days I am exhausted.  There are days I need help.  Yet there are many days I overflow with pride in our team.  I am most hopeful about the work ahead and seeing the early fruits of this work while challenging us each day to do more.

Mike McClay has spent the better part of two decades working in Silicon Valley. Here, he chats with software engineer Akash Gupta about the road from Software Engineer to VP, what it’s like to work in digital health, and his best advice to both independent contributors (ICs) and managers. 

Get to Know Alto’s VP of Engineering, Mike McClay

I'd love to first understand a bit about you personally. What do you like to do in your off time? What’s something most people don't know about you?

I grew up in Orange County, which is pretty suburban, so that afforded us a lot of time outdoors as a family. A life goal of mine is to do a solo hike of the John Muir Trail. The route starts in Yosemite Valley and heads south to Mt. Whitney. It’s about 225 miles and typically takes a few weeks to complete.

Currently though, I have a two-year-old and a four-year-old, and we have another baby on the way, so my outdoor activities tend to be much shorter and closer to home. I got into road biking about 10 years ago and transitioned to mountain biking a few years back when my family moved to Marin. Being able to get out onto the local trails a couple times per week is an amazing opportunity to get a great workout in, and unplugging does wonders.

Finally, a ton of family time with my partner and kids. A big reason I decided to join Alto is because it provides a great balance of simultaneously being a high growth startup but it’s also a company that has an eye on culture and achieving work-life balance. At Alto, we're playing to win, and we’ve got a lot of things to get done, but there's a lot of support and representation for people with families with kids. It's nice to be able to work hard towards an incredible mission but also not have to sacrifice too much on the family front; so outside of work, I’m mostly focused on spending quality time with my family getting outdoors, getting to the beach, and things like that.

That's very exciting, having another child on the way. How has COVID-19 impacted your responsibilities of being a VP Engineering and a father?

Life is a lot harder during COVID, though I say that with a fair amount of awareness of the privilege my family and I have. On the home front, we are constantly trying to find that balance of keeping the kids entertained and learning but also doing it in a safe way that protects everyone. My wife and I are pretty fastidious about keeping the house organized and clean but that’s relaxed quite a bit during this time; there’s a lot of resetting of expectations, and I try to do as much as I can to support my wife.

Professionally, probably about half of our engineering team has interviewed and onboarded since the shift to remote work in March, and I’d say we are still iterating and adapting each month to work better in a fully remote environment. It’s been incredible to see our teams adapt to this new style of work, and while it’s not quite the same as our in-person environment was, it’s been really cool to see the team grow and have our organization make a bigger and bigger impact for our patients each month.

I'd love to talk about some of your past experiences. You went to the University of California, Berkeley (Go Bears!), then Expedia, then Uber, and now you're at Alto. What prompted each of those transitions?

Yeah, I’m kind of an outlier in the tech world in that I’ve only worked at 3 companies since graduating undergrad in 2004. I think I’ve been fortunate to find myself at companies that have had no shortage of growth opportunities and that led me to stay for considerable amounts of time at both Expedia and Uber. 

Towards the tail end of my tenure at Expedia, I was managing the engineering team of a start-up that Expedia had acquired, and I knew in my heart that I wanted to move to a much smaller company. I spent a few months talking to a bunch of early stage start-ups but hadn’t found anything that felt right yet.

At the urging of my recruiter, I took a call with a company called Uber, which had seemed way too “big” for what I was looking for in that the engineering team was about forty people. Despite the role feeling different from what I was expecting, I was excited by the mission and the team, so I made the leap. Fast forward six years or so and it was an amazing ride, full of a lot of ups and definitely some learnings, but it was a truly formative experience for me.

Uber ultimately got to a point where I struggled a bit to pinpoint the impact I was making, and things overall at the company just felt slow. I wanted to work on something that was even more mission-driven, and one of my colleagues insisted that I chat with Alto. I was introduced to Jamie (Alto’s CTO). We talked over a number of months and found Alto’s needs and the challenges I was looking to solve aligned in a great way. So that's why I ended up joining.

Each of the companies that you’ve worked at have had large operational components. What are some of the key pieces to creating a strong partnership in a tech-enabled company?

What I would definitely say is that the tooling and the product that we built for ops at Uber was, at the time, world-class; it was just beautiful. Design was a first class citizen in our operational tooling because the workflow of our ops team was so critical to our company’s success. 

This is something that Jamie and I bonded over about Alto; our internal platform (called Wunderbar) powers the functionality that allows us to process our patient’s prescriptions in an efficient and effective way. Getting this right is critical for our patients, and the fact that we put so much time and energy into getting the technology platform right goes a long way to build a great working relationship with our operations team. 

Additionally, I’m passionate in general about operations since it’s often an area of the business that creates strategic advantages over competitors. And what I love about building software with operations is that it can’t be copied easily by competitors since there is no public surface area to observe. I view our task as an engineering team as getting to where we're crushing it as a business because we have nailed supporting operations with our product engineering work.

On that note, would you say Alto is an operations company, a pharmacy, or a tech company?

We aspire to a model of cross-functional leadership, whether it's between Engineering, Product, Ops, Growth, Marketing—whatever it is, the leads of areas and even the team members of each area need to be empowered to achieve the mission that they're setting out to do. If that's to enable, say, the flow of prescriptions coming through our system, maybe you could call that Ops-led, but at the end of the day, multiple functions have to come together to solve the problem. I almost want to call it vision-led.

There’s a time and a place where we need to be creating a faster horse, and there's a time and a place where we need to be thinking one to two years out about what the step up is from the faster horse: bringing the car into the situation, so to speak. Ultimately we need to be thinking on multiple time horizons at the company, and depending on the time and place and the strategy, you might see one function spiking up in terms of what we're rallying around versus another.

The engineering team at Alto has grown from eleven engineers and four managers when you started a year ago to more than fifty-five engineers with nine managers, directors, senior managers, and managers. What would you say has enabled that dramatic growth, and how do you plan on ensuring that that growth is well-managed?

For engineers, there are a lot of choices out there, and a big part of our hiring process is spent not only assessing technical skills, but also looking for signals that candidates align well with our patient-focused mission. From the beginning, we created an interview process that is fair and equitable, and that resonates strongly with our candidates. From there, we set out some really big goals that energized the team to push to make it happen.

I'm really proud that we've grown while maintaining a solid level-mix in terms of junior, mid-level, and senior engineers. Our engineering team is ~25% female, and while we only have single digit percentage points of representation of other underrepresented groups, representation is improving every quarter. Our goal over the next several years is for the team to achieve 50% gender representation and 30% from other underrepresented groups, so that our engineering team is representative of those we ultimately serve: our patients.

In order to make sure this growth is well managed, my philosophy is to hire or grow Engineering Managers well in advance of the acute need. On the manager side—and this was a big learning for everyone at Uber—we’d grow a team of fifteen to twenty engineers under a manager and not really have a great plan in place for how to bring in additional leadership and get the teams down to a right size of ten. When we approached that number, we'd battlefield promote someone and everything just felt strained. So I'm really proud of the fact that even at nearly seventy people now, we have a management team of nine that could actually support one hundred people pretty well. As the team continues to grow we’ll be making sure to stay ahead of the growth on the management side.

On that note, Uber has been reported to have an unhealthy culture. What have you learned from it to engender a more positive, inclusive culture at Alto?

Yeah, I’ve had a lot of reflection on this and a lot of learnings from my time at Uber. First, it’s that as a leadership team, we need to be vigilant about creating a team environment where team members feel they can do their best work. We need to always have great managers leading teams that are right-sized, and we need to have people-focused cultural values that help guide our behaviors and how we interact with one another. 

At Alto, half of our cultural values are focused on skills that foster an environment where folks can do their best work. Yes, we're thinking constantly about impact, but we make sure to hold ourselves to a high interpersonal bar. This type of behavior has also been institutionalized at Alto in our engineering career ladder. Culture amplification is one of the five skills engineers are evaluated against, and I think it’s a very strong signal into what we hold dear and how we want to roll here.

Finally, I’ve put a strong emphasis on making sure that interviews at Alto assess behavioral skills in addition to technical ones. We didn’t do this well at Uber for too many years, and I believe it led to some of the cultural negatives that you’ve likely read about in the news. To me, it’s critical that we hire really talented folks who can work seamlessly with one another. Getting signal on this during our interview process is a big part of growing a healthy engineering organization.

You've gone from being a Software Engineer to Tech Lead, Engineering Manager, Director, and now, VP. What advice would you give someone at each of those stages? What advice do you wish you had back then?

The main piece of advice I’d relay is to make sure that you spend enough time in each role to get solid proficiency. I’ve come across a number of folks in my career who look to move through roles as quickly as possible, and I think that doesn't allow for solid bases of knowledge to be built up. The foundation I built up in my experience as an engineer I believe resonates with engineers; I’m not just a people manager that helps coordinate minutiae. Additionally, a lot of the skill-building in these roles happens as you encounter various real life situations; the only way to accumulate experience is over time. So my advice is to be patient.

I would definitely encourage everyone to work at a company where there are clear career paths for both ICs and managers. You should never feel like you need to move into management to “grow in your career.” One of the first things we put in place after I joined Alto was a career ladder so that folks could reason about how they wanted to grow over time and come up with a growth plan with their managers.

Finally, don’t go too long in a role or at a company where you don’t feel challenged and don’t feel like you are growing. To me, growth and challenge are proxies for job satisfaction. I would say I've achieved it about 80 to 90% of the time in my career. If you're not in a place where you're feeling like you're growing, you should go somewhere else.

What would you say to someone considering working in digital health? What are some challenges and benefits in this space?

It's not so fraught with red tape that you can’t get anything done. There is a process to work through with HIPAA (Health Insurance Portability and Accountability Act) to ensure patient privacy; there is a massive set of opportunities that support all of the activity in the space; and there are seams where startups can begin disrupting entrenched players.

There’s also a massive opportunity to solve hard technical problems while achieving these amazing, mission-driven ends. I think sometimes it seems that those can be separated to where it’s almost mutually exclusive. While we don't yet have the volume nor traffic that you might receive at companies like Uber or Google, there are still meaty technical challenges that haven’t been solved before.

What disruption is good in healthcare and what may not be?

The good disruption comes in places where companies can plug into an existing experience that patients go through to solve a problem and figure out new ways to address that problem. In the pharmacy space, we are disrupting the brick and mortar pharmacy experience that is effectively in the business of selling you Coca-Cola while you wait for your medication. 

Bad disruption would be anything that goes against protecting a patient or their privacy. At Alto the engineering and security teams are tightly coupled so that we can best solve for the needs and privacy of our patients.

You mentioned technical challenges. What would engineers and other technical people get excited about in this space?

We don't yet have our architecture mapped out for scaling 100x on our business over the next couple of years, and it’s been really exciting to start to discuss our technical plans to enable that. At Uber, we went from a monolith to a full micro SOA (Service-Oriented Architecture)—both extremes that had quite a few problems as implemented. At Alto, we aim to find a better middle ground. 

Additionally, we need to think about what the pharmacy experience will look like five to ten years from now and start building some of the pieces that will work us toward that future. Safety and accuracy are incredibly important to us now, but at one hundred times our scale, we’ll need to be constantly innovating our technology so that we can minimize / eliminate errors in our operational process. 

We’re also bringing data silos together that have never been joined before. For example, as many as 50% of prescriptions are not picked up for retail pharmacies. Doctors have no idea which of their patients pick up medications or not. Insurers don't know what happens to patients after they take their medication. We are the interconnect between all of these customers.

As we grow, that data is going to grow inside of our systems. The information and the insights that we can derive from it is going to be incredibly powerful. But we're going to need a ton of awesome data analysis, products that allow us to collect the data while respecting patient privacy, etc. I'm really excited about that.

What are you most proud of from your time at Alto so far, and what are you most excited about in the next year?

What I'm most proud of is the team that's been hired. They are just amazing. Last year, we had a team of eleven engineers with such a large surface area: fulfillment, operations, customer app, customer website, our provider portal, etc. With so much to do across a team of that size, we were constantly making really hard prioritization decisions and were not able to tap into what we saw as our full potential.

Fast forward to today, we're now in a world where we have dedicated teams for surface areas, and we’re solidly parallelizing efforts. Seeing the bandwidth, the throughput that's going to be rolling out each quarter, is really cool. We're going to have orders of magnitude more output each quarter than we did a year ago. That's what I'm most proud of now.

What am I most excited about? There's the business aspect, expansion. We've really only covered six markets and are now looking at covering many, many more lives. The next couple of years are going to be a lot of fun.

Last question. Someone's considering working at Alto: Why should or shouldn't they join?

Alto’s at a stage where things are changing constantly. Folks who like dynamic environments will thrive here, as the work is challenging, and we are trying to solve problems that have not been solved before. Given that Alto operates within a multi-sided network, we have a lot of opportunity to create value, but it also means there are multiple players to think about when building a product. There's a richness to our patient, provider, and insurer base that makes it both challenging and exciting to make sure that we're finding the opportunities that deliver value to broad strokes of folks without leaving others behind.

Finally, engineers should join if they want to be part of a mission-driven company, enjoy working in an inclusive environment and diverse team, and like to be at the intersection of technology and the physical world, whether that's operations, delivery of things to humans, etc. If we succeed,  the way society thinks about health, prescriptions, etc, ten to twenty years from now will look very different because of the work we’re doing here. If that's inspiring to you, and you want to be part of that, you should join.

Interested in joining the team? Reach out to us on LinkedIn.

At Alto, we value effective communication across all teams. In our latest blog post software engineer Eric Leite shares how he set out to make it easier to understand how our repositories change over time while minimizing disruption to engineers’ existing workflows.

How (and Why) We’re Standardizing our Commit Messages

Have you ever tried to debug a production issue by looking at your commit history, only to find a bunch of commits that don’t seem to be connected to any specific feature? Or maybe you've pulled the latest version of a dependency and noticed a bug that wasn’t there before?

It’s hard to pinpoint where a problem might have begun if your project (or its dependencies) don’t rely on standards to commit and release code. This was a problem I set out to tackle in my organization: How can we make it easier to understand how our repositories change over time while minimizing disruption to engineers’ existing workflows?

At Alto, we value effective communication. We keep our pharmacists and operations team in the loop about every new feature we release to production on a daily basis. We also announce changes to our codebase in a dedicated Slack channel to keep our engineers informed. But that raises the question: How do we ensure that someone doesn’t forget to make an announcement? And can we reduce the time we spend writing one up? Introducing a commit standard would enable us to use automated tooling that makes communication about code changes effortless.

Consider an open-source repository with hundreds of contributors. Project owners often adopt standards and industry best practices because it makes the project easier to maintain as the number of contributors increases. Eventually, our engineering team will grow to this point—and, just like in an open-source project, we can’t expect engineers to retain all of our conventions in their heads when they contribute. Standardizing commit messages eliminates one of the many variables around how we commit code. It can give engineers more confidence in their releases, build trust in our codebase, and increase productivity.

Many engineers have a distinct working style. If you propose a change to their everyday workflow, you will likely encounter some resistance. That’s why identifying and working with key stakeholders before you introduce a new process can help ensure its success. One way to do this is to chart stakeholders on two axes—influence in the organization and interest in the project:

I used this chart to decide how I would direct my communication with the team. Folks who fell into the “low influence” and “low interest” quadrants didn’t need to be involved in the whole process. Instead, I kept them informed by using project-specific slack channels and documentation in Notion to communicate status updates and summarize meetings. Topics that required a team decision were discussed verbally rather than using Slack to avoid potential miscommunications.

The more likely someone was to push back on the project or give me valuable feedback, the more involved they were. I included those who fell into the “high influence” and “high interest” quadrants in almost every meeting. These folks served as a kind of litmus test for my ideas. They typically had high standards and expectations and needed to be convinced that a change was worthwhile if they were going to get behind it. Keeping people like this involved in the discussion is a great way to ensure that your initiative will produce value for your organization.

In a perfect world, we’d have standardized commits in every repository. However, given that Alto is a fast-moving startup, foundational changes need to be rolled out incrementally to minimize churn, validate impact, and allow us space to learn and iterate. There’s often not enough time or resources to do everything, and going all-in on something may require more effort than it’s worth.

We began by identifying the knowledge gaps we currently have about commit standardization and how we could iteratively validate the required process changes. We initially considered beta testing with the production app that runs our day to day operations because it had the most contributors and the most to gain from standardization. However, we didn’t want to risk blocking the majority of our team or experimenting with a project that was critical to business operations. The next best option was our internal component library—it had fewer contributors, so fewer engineers would be blocked if something went wrong, and more projects depended on it, so the potential impact would still be significant.

Given that one of our company values is to Focus On Impact, and that internal changes like this are difficult to measure, we quantified our level of success or failure using a team survey. We sent out a series of questions at the start of the project asking the team to rate their satisfaction with our current commit, review, and release processes. We plan to compare these results with a follow-up survey to measure changes in ease of committing code, confidence in releasing, and our developer NPS.

After closing our knowledge gaps and getting a baseline understanding of how the team felt about our release processes, we decided to adjust the scope to include the following changes:

Blog

Creating Sandboxes: How to Make It Easy for Your Engineering and Product Teams

How to Debug Slow and Failing Cypress Seeds

Two Engineers Crunch the Numbers: When Is It Cheaper to Pay Cash for Your Medication?

Diversity At Alto: Building an Inclusive Healthcare Company and Culture

Get to Know Alto’s VP of Engineering, Mike McClay

How (and Why) We’re Standardizing Our Commit Messages

How to Make the Most of Your Engineering Internship — Advice From Alto's First Interns

What to Expect When You Interview as a Software Engineer at Alto

Building an Engineering Career at Alto

Hims & Hers Partners with Alto for Same-Day Prescription Delivery for Primary Care Patients

From Your Pharmacy: What You Need to Know About Coronavirus

Breaking Open the Black Box of Medication Pricing

Switch to a better pharmacy.