Dr. B, PBC

We operate on two-week sprints - organizing everything through as few project management vendors as we can, so all of our engineering team have a strong holistic view of how the tech org operates. We use a monorepo, and GitHub issues together with project management software called ZenHub to project/sprint plan. We use GitHub actions for CI/CD, ensuring there's a single source of truth for the frontend, the backend, project management, business intelligence and technical documentation - the GitHub repo.

We have separate sprint and kanban board for Business Intelligence and Design, allowing new features to go from needs-design to ready independently of engineering work, while keeping visibility on work to make sure that engineers can pick up work and hit the ground running with it.

Code reviews are done via GitHub pull requests - code owners are assigned to sections of the project, using directory structure conventions. Since we use a monorepo, and both front- and back-end use typescript, style is consistently applied via a linter for the whole project, with enough flexibility to allow for different parts of the stack. The team is divided into front- and back-end engineers based on preference more than necessity. Engineers are able to easily explore and help out on different parts of the stack since the language and conventions are universal.

An extensive suite of automated tests run on every branch/pull request, and a preview URL is deployed to allow designers, product managers, and other engineers to view changes to the front-end. The front-end is composed of a framework of react components (corresponding to the equivalent design system in Figma). We use Storybook to showcase, and Chromatic to track visual changes and protect against accidental changes. We have a suite of UI tests which run against each pull request and before every deploy to ensure no integration between the front- and back-end, or critical user path is broken. We deploy to production multiple times per day, automatically publishing GitHub releases to communicate with Business and Product stakeholders.

At the end of each sprint, the tech team have a retrospective so that we can continually improve on our process. We have a lightweight, flexible sprint process - product features are made into Epics with individual work items broken down before bringing into sprints.

We're building a two-sided marketplace on a global scale. There are billions of people who need the vaccine, and millions who will be administering it. Building a system that can accommodate that scale, without compromising on privacy, security, or ease-of-use is a unique challenge on its own.

On top of that - we need to constantly adapt to the environment changing under our feet. We have to build systems that can predict where there will be greatest need, so that we ensure that we have enough providers on our platform to reach patients who need vaccines, and to contact patients before vaccines become available to make sure we only offer doses to those who still need them.