David Bryant Copeland

Chief Technology Officer and Co-Founder

May 2020 – February 2023

Oversaw all technology and product development for a HIPAA-compliant, remote mental health business. Technical portfolio included practice and prescription management SAAS, patient support portal, custom appointment management back-end, HQ and provider hardware, and custom integration with major health insurance companies.

• Integrated health-insurance billing to vastly increase customer acquisition, customer retention, and revenue

  Mood was initially conceived as a private pay service, however this made customer acquisition and retention extremely difficult. Working with a third party API (Candid Health), we were able to launch a full integration with major insurance companies in four months.

  Since we owned the patient experience and the patient support side of things, we were able to dial in internal processes for a good patient experience without creating a large burden on support staff.

• Increased appointment attendance with custom email and SMS reminder system.

  Our existing practice management system had only rudimentary logic for appointment reminders. We were able to use a custom back-end to send reminders on a different schedule (based on testing with our patients), as well as to use different channels and messaging, depending on the patient's situation. For example, new patients who didn't engage with reminders resulted in a patient support ticket to trigger a manual contact to make sure the patient understood what was going on.

  This reduced our no-show rates significantly. No-shows for first visits are quite expensive since they are long visits and hard to fill at the last minute. Further, some insurances forbid charging missed appointment fees, so we focused on getting patients to their appointments, not using late fees as a revenue source.

• Increased patient support efficiency and revenue with custom credit card decline resolution and automated patient support outreach.

  While we used Stripe to store cards and automate charges for service (or for co-pays), handling declines required a more customized approach. Working with patient support to understand patient behavior, we built a system that balanced automatic retries with patient outreach.

  We wanted to ensure no one was cancelled by an automated system without a real person trying to contact them, but we didn't want the billing team to have to manually triage all declines. We ultimately devised a process with some automation and some manual intervention that reduced billing team burden while increasing revenue and avoiding churn.

• Decreased billing and insurance specialist burden with custom insurance integration logic.

  It's extremely difficult to determine if the insurance info someone has provided actually covered the care we provided. Each insurance company works differently, and the system that provides feedback on who is covered for what is not well-documented, nor well-behaved.

  Rather than have our insurance specialists call the insurance companies for every new patient before every appointment, we created a system to automate coverage checks and analyze the results for confidence. Some patients were obviously covered, so could proceed to their first appointment with no intervention. Others produced nebulous results requiring manual intervention.

  The process we built reduced manual interventions significantly, and surfaced problems (patients who were not covered) quickly to avoid a bad patient experience.

• HIPAA-compliance achieved early by judicious use of simple controls and processes while allowing the team to remain agile.

  Despite our small size, we wanted to set the foundation for good security and privacy practices early on. We engaged with an outside firm to analyze our IT systems and plan out changes to reduce the risks of HIPAA violations.

  Much of the work was documenting processes and procedures for existing staff, however our custom IT systems I was building also needed addressing. As a team of one, I automated as much as I could through static analysis and scaffolding scripts, as well as lightweight documentation.

  I reviewed our systems quarterly with the COO, and yearly with the CEO. The overall effort was minimal for the impact and risk-reduction we achieved. We avoided onerous approval processes, and flagged solutions that would be affected by scale for yearly review.

Consulting CTO

June 2019 – May 2020

Consulted with startups and founders on technical & product strategy. Helped with technical architecture, hiring plans, interviewing, and roadmap planning.

• Designed high-level architecture to facilitate technology choice and hiring for a pre-revenue healthcare startup.
• Analyzed software architectural and database design for a Series-B consumer products startup.
• Created hiring plan & interview rubrics and performed interviewing for a Series-B consumer products startup.
• Design and build finance and accounting subsystem for a pre-revenue philanthropic startup.

Chief Software Architect

November 2016 – May 2019

Owned technical portfolio of 100+ person engineering team, set technical direction, drove development practices, and led company-wide technical changes such as SOX compliance, GDPR, and international expansion.

• Technical Lead on SOX Compliance in preparation for IPO. Led change across entire engineering org to maintain agile delivery but comply with regulations for a public company.

  In the lead up to our IPO, we engaged with a consulting firm to analyze all systems, processes, and practices in the company to then change them to comply with SOX. Most of the engineering team's systems were considered in-scope and some changes would be required.

  Further, the source of truth for much of our financial data lived in these systems and was inconsistently consumed and interpreted by downstream members of finance, planning, merchandising, and operations.

  My job was to understand the requirements for SOX and propose, then manage, a series of projects to make changes in our systems and update our ways of working. Technically, this was not a huge challenge. The hard part was addressing the underlying issues SOX-compliance seeks to solve without saddling the teams with onerous manual reviews and approvals for system changes.

  This also required a deep understanding of the finance and accounting parts of the business to ensure that the facts they needed to follow proper accounting principles were unambiguously available from our systems, changing them to do so if needed.

  We IPO'ed generally without incident. The only material weaknesses relevant to this work were financial controls from before IPO that were still being remediate. All software engineering and data management practices were compliant by IPO and affected teams were not sufficiently slowed down by additional process.

• Technical Lead on UK expansion and GDPR compliance. Delivered on time without incident, and without a death march.

  After IPO, the company decided to expand into the UK. Due to the way the fashion industry works, we had to launch at the start of Spring or Winter. The change required accepting multiple currencies, adding new logistics providers for the UK, and GDPR compliance.

  At this point in company history, we had over 100 engineers, and a microservices architecture of nearly 100 services. Many of them required changes to account for multiple currencies and the concept of customers being bifurcated by country - US clothes would not be shipped to the UK or vice-versa.

  I was given a team of 10 engineers plus a mandate to insert projects onto other teams roadmaps to get this done in time for a Spring launch. This required significant management of technical change. I had to balance getting changes made by my team against allowing other teams to maintain ownership of changes to their systems.

  Since there was a hard deadline, I also spent a lot of time setting expectations with non-engineering functions about what would and would not be completed at launch. This was a collaborative process where each department worked with me on prioritizing the changes they needed. We worked in priority order and launched what we had in the spring.

  The project was well over a year long and was completed largely without incident. Everyone was happy with what was completed for lauch. Engineering teams didn't feel we'd dropped a ton of code on them to own, and the dedicated 10 person team never had to do the dreaded death march or crunch time.

• Fostered development and implementation of engineering practices for a growing team. This included post-mortem/incident reviews, formalized process around design reviews, and the migration to a messaging-based architecture.

  With several teams made up of engineers from diverse backgrounds and levels of experience, it was clear that implicit processes and leading by example would only go so far. As the highest-level non-manager, I was able to coordinate people around areas where we needed improvement, and get those improvements made.

  For example, not everyone wrote design documents or reviewed them consistently. Not everyone knew when to write one or not. Rather than dictating the answer to the team, I built consensus across the senior individual contributors and managers to add small changes, then roll them out to other teams.

  I kept a list of issues like this and worked on them constantly while other work was going on. My approach was to identify problems and goals while providing political cover (and occasional expertise) so teams could devise and roll out solutions.

• Technical sponsor for migration from Heroku (PAAS) to AWS (IAAS). Migration was done without any downtime and no change to the developer experience.

  We were outgrowing Heroku, but benefited greatly from the consistency resulting from its constraints and the richness of its tooling. I hired a senior Platform Engineer and he and I worked to build a team of only three platform engineers to move us onto AWS.

  Our goal was to provide the same (or better) developer experience, and create the foundation for a Heroku-like experience, but backed by AWS (to allow for better control over scalability and performance). The team designed and built a system based on ECS and RDS that worked almost exactly like Heroku from the developer perspective.

  At the time, we had about 30 apps and microservices, a large shared database, and many private databases. The team created checklists for migrating each type of infrastructure, building support internally when needed. They built a command-line app to provide access to the running systems.

  The last migration was www.stitchfix.com. This was done without any downtime. No developer complained about the tooling changes - some probably never really noticed at all. The foundation that was built as part of this project allowed huge gains in developer productivity and drove consistency across our systems that made future projects such as SOX compliance, far simpler than they might have been.

• Planned and executed bi-annual engineering summits that brought together our remote workforce for teambuilding, knowledge sharing, and planning.

  Building a remote team solved tons of problems around hiring, diversity, and expertise. But there are only some things that work in-person. As the remote engineer with the most seniority (and thus a vested interest in remote work), I took the lead on engineering summits twice a year.

  While I didn't do it alone, I drove the organization, content, and activities to balance a diverse teams' needs against the company's budget-sensitivity. Events were highly reviewed in post-attendance surveys, and I established a pattern of trust in keeping these events relevant, welcoming, valuable, and fun. It didn't require much programming skill, but did require empathy, active listening, and leading through influence.

Director of Engineering

July 2014 – November 2016

Led engineering teams for distribution/logistics, finance, and platform engineering. Ensured product roadmaps met business goals while developing managers and the engineers below them as the business grew 10X. Worked to scale best practices established when we were smaller to a now larger team and larger technical portfolio.

Lead Software Engineer

February 2013 – July 2014

Starting from scratch, built custom warehouse management system that accomodated our unusual logistics and customer experience. The system was built with Ruby, Rails, Postgres, and AngularJS. It powered all shipments, inventory management, and returns. It scaled from a 20 person operation in downtown San Francisco to over 1 million square feet of warehouse space across the country.

I designed, built, and maintained this system, acting as lead engineer and product manager. I worked closely with the operations team, warehouse associates, and customer service specialists to meet business goals, improve accuracy of inventory data, and provide a smooth internal customer experience.

Lead Software Engineer

Oct 2011 – January 2013

Lead engineer on payments systems and purchase flow. Using JRuby and Resque, extracted credit card authorization and charging flow to a separate REST-based microservice. Performance improved 100x in order to handle Black Friday 2011. The system had near zero failures and no downtime during the event. Managed a team of three on purchase flow optimizations.

Principal Engineer

April 2011 – October 2011

Tech lead for Rails-based social app and API to help energy customers engage with their data in support of the company's behavior science methodology.

Engineering Lead

2009 – April 2011

Tech lead for web product aimed at energy customers of partner energy companies. Led team of three engineers and two QA analysts to establish development practices while meeting product design requirements as well as business development needs. System used Java, Spring, and Hibernate to integrate with existing back-end energy data and analysis.

Senior Java Engineer

2008 – 2009

Designed and developed new features for our energy-efficiency product, as well as the infrastructure to load and analyze fine-grained energy usage readings for millions of utility company customers.

Senior Software Engineer (consultant)

2007 – 2008

Developed REST API for Gliffy.com as well as various features and improvements.

Technical Architect

2006 – 2007

Worked with Maritime Administration (MARAD) at the Department of Transportation (DOT) to provide enterprise architecture analysis.

Senior Software Engineer

2002 – 2006

Development lead and senior engineer on a system for the US Marshals Service to manage databases and processes across all districts. Designed and built la system for the Department of State to manage Visa waivers.

Software Engineering Director / Software Engineer

1997 – 2001

Software engineer on various client projects including Toyota.com and Avery Dennison. Managed the software engineering team to ensure consistent technical practices.

Software Engineer

1997

Software engineer on company ecommerce platform.

Software Engineer

1994 - 1996

Designed and maintained cross-platform build system for company's document processing/OCR platform.