Expires 04/01/2021

Specialty Pharmacy

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

Alto Pharmacy Technician

Alto Pharmacist

For Black History Month, we’re recognizing pivotal Black leaders in healthcare who’ve paved the way forward for our country and the Black community.

Services that reduce travel and encourage social distancing are now more essential than ever, not only for vulnerable populations but all of us as members of our communities. Alto’s free same-day doorstep delivery ensures you have safe and reliable access to medications in this time of uncertainty. 

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

Alto / Blog

At Alto, we’re obsessed with our mission to improve quality of life for everyone who needs the help of medicine. Our mission guides us in all we do and every decision we make. 

Our mission and diversity work are tied together with one word from our mission -- everyone. Too often, only those with significant resources access the best and benefit from innovation in healthcare. We see it everyday in the data. Too many among us continue to struggle with solvable challenges, in our own wellbeing and in the larger healthcare system. These statements and environments have existed in the workplace as well, influencing the products, services, and policies that steer how the organization works for all of us.  Our work is to make Alto different.  Our work is to build and sustain an inclusive culture.  Our work is to attract, develop, reward and retain talent from all the communities we serve as patients and build a product that supports everyone. 

Today marks another step in our diversity, equity, and inclusion journey as we release our first annual diversity report. We share it because this work is central to our mission and in doing so, we use transparency to hold ourselves accountable, as well as hopefully play a part in raising expectations and norms throughout the healthcare and technology industries.

In 2020, across the company we saw a 13ppt increase in women and 7ppt increase in underrepresented groups (Black, Hispanic/LatinX and Native professionals).

As for women in leadership, we saw increases of 3ppts in Women Managers and 1ppt in Product, Engineering and Design driven by both hiring and promotion. At the leadership level, 32% of leaders identify as women.

In 2020, we saw 10ppt increase across our underrepresented managers to 13% Black, 16% Hispanic/LatinX, 2% Native/Indigenious.  In the leadership group, we saw an 8ppt increase to 15% Black and 2% Hispanic/LatinX. 

In 2020, we also established our Alto Advisory Board and our first two anchor members, who will help guide Alto towards our mission, advise on key decisions, and support strategic initiatives. We’ve formed the Advisory Board to support our leadership as we navigate the regulatory landscape, launch new features to modernize the pharmacy experience, and adhere to the highest standards of operational excellence and patient care.  

Dr. Hildreth is the President and Chief Executive Officer of Meharry Medical College, one of the nation’s oldest and largest private historically Black academic health sciences centers. He received his Bachelor’s degree from Harvard University, his Ph.D. in immunology from Oxford University as a Rhodes Scholar, and his medical degree from Johns Hopkins School of Medicine. He was the first Black American in the 125-year history of Johns Hopkins School of Medicine to earn full professorship with tenure and is internationally known for his influential HIV research.

Jennifer Kent served as the Director for the California Department of Health Care Services, where she led the second largest public healthcare system in the nation, with an annual budget of over $100B and serving over 13 million Californians. She oversaw the administration of 24 managed care plans as well as 56 county behavioral health plans. She has also held leadership roles in the Health & Human Services Agency, Governor's Office and has experience in the private sector as a lobbyist, consultant, and association executive. She has more than 15 years of health administration and policy experience in California.

Alto created our DEI strategy with our team aligned to four pillars – Hire, Include, Develop, and Invest.  Each pillar's actions tie to our people and our business. This means the return on investment is clear and goals are aligned to business outcomes.

Medical Health Care Premiums and Part Time Health Care Benefits in SF: 

In order to increase access and affordability to critical health-care services, we asked our broker to offer a special mid-year open enrollment 2020, reducing premiums for most plans by 5%. We reduced out-of-pocket maximums and speciality office visits by an average of 37%. We reduced co-insurance as well as costs for labs, x-Rays, and emergency room visits for our Cigna plan by 50%. Finally, prescriptions copays were reduced by 25% for Brand medications and 75% for Generic prescriptions. This benefits the employee with direct access to care and a better employee experience as compared to direct contribution to the city fund.

We increased our paid parental leave across all US locations to 8 weeks (up from 6 in 2020) for all parents requesting leave as of January 1st.  Throughout 2020 parents and other caregivers were impacted significantly as schools, daycare, and caregivers were closed, isolated, or unable to rely on pre-covid support. We offered laptops to parents who couldn’t afford them for each child to participate in remote learning.  We offered expanded benefits above and beyond FFCRA. Finally, we offered paid sessions for remote learning, tutoring, and experiences for parents and caregivers.

Finally, in December we launched Modern Health with 6 paid coach/therapy sessions and access to a digital wellbeing library and resources to all Altoids.

We launched six ERGs in 2020. Formalizing the work of our original Diversity Committee into six groups: Umoja (Black), Auténtico (LatinX/Hispanic), Women, Proud (LGBTQIA+), Asian/Pacific Islander, and Working Parents. These groups are focused on building community with both those who identify and allies. They support our education, development and investment in our communities. Each has been given a budget, an executive sponsor, and access to other company resources.

We recognized as a leadership team that we needed to educate ourselves. We were not going to rely on those from underrepresented communities to educate us. We embarked on four three-hour sessions focused on learning about diversity and inclusive language, naming our privilege, and starting the work each of us wanted to do. It was only after these sessions, with clear self-awareness and awakening; that began the work of empowering other leaders -- managers and other Altoids on this journey. There is more work to be done, as Neil Frye, Chief People Officer, mentioned in his blog post in late 2020 -- this is not a sprint, nor is it a marathon; it is life-long work.

Focus on Latinx Senior Manager to VP talent; with targeted outreach, activation and networking for opportunistic and open hiring

Expand employee resource group events throughout the year supporting inclusive environment, educating and investing in our communities

Get to full participation in DEI Workshops and launch additional sessions like What’s My Privilege and Moving to Action across the company

Explore new partnerships with Community & Higher Ed Institutions (i.e. Historically Black Colleges and Universities, Hispanic Serving Institutions, etc.)

2020 Diversity, Equity & Inclusion Report

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.

Blog

2020 Diversity, Equity & Inclusion Report

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

Airbnb’s Former Head of Business Technology Joins Alto

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

From Pharmacist to Professor: Sandra Aziz Spotlight

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

Building an Engineering Career at Alto

Switch to a better pharmacy.