If you asked a software developer to discuss compliance, you would probably hear some vague references to finance and healthcare, fair enough - but it so much more than that. While a trope to many, “Software is Eating the World”, the complexity and breadth of software is finding its way further and further into our lives.

Compliance encompasses federal, local and international laws as well as contracts between businesses, vendors, customers and stakeholders. Some contracts with customers might be extremely clear as internal lawyers have had discussions with their counter party to clarify situations and edge cases. There might also be cultural norms that an organization would incorporate into their boarder compliance landscape.

How do many organizations track & implement compliance into their internal and external product offerings?

Software projects have different risk profiles for managing their compliance. Here are some examples for thought (not exhaustive list):

  • A. Internal tool for announcements and vacation awareness for team members
  • B. Regional Credit Union - consumer facing banking suite (checking & savings)
  • C. Telemedicine application with insurance billing (Medicare & Medicaid out of scope)
  • D. Social Media application targeted at working parents that pivots to become heavily used by middle schoolers
  • E. Financial Reporting Software As a Service - reciept upload & processing

On first glance, B & C will most likely have compliance discussions before a line of code has been written by the software team - as mentioned earlier, finance and healthcare seem easy to spot in the big picture.

A to some might seem pretty harmless, however, it’s scope could quickly balloon to probaby take regional holidays and paid time off regulations into account if it becomes the source of truth for maintaining this information. Did you know that some localities require reporting and payment of the balance of Paid Leave at the end of the year if an employee does not take it?

D is an odd and probably extreme example. Many organizations can find themself in a situation where their product has either evolved over time to serve new markets or has been adopted unintentionally by others. In the Example of D - the team may have been aware of COPPA and considered it out of scope, then found themselves in scope due to their growth.

Finally, in example E, a particular enterprise client of this organization might have a custom contract stipulating that their data is not processed by third-parties without approval. If the service decided to add a new reciept scanning feature that implemented Mechanical Turk to process and review uploads, that would either need to be approved by the client, turned off for them, or an internal workflow would need to be built and staffed.

Every organization (hopefully) has good intentions for serving their users in the best way possible.

We view some of the protections outlined above as competative advantages organizations and products can offer their stakeholders. Product and Development teams can also take advantage of working in regulated projects as a skill set that will help their careers.

While it’s difficult to upskill each of your team members to the level they could provide master class level trainings for others in various regulatory topics in conjunction with completing their daily tasks. There are things you can do to help support their efforts to build product that aligns with your customer needs, which can be regulatory or compliance in nature.

A few recommendations:

  • If you are in leadership in your organization - you should acknowledge compliance exists, it will help you build a Moat that will help your sales and product teams thrive. Don’t push your teams for that quick & easy change that will devalue your compliance efforts.
  • Provide lunch and learns between industry experts and your product and development teams.
  • Provide a compliance cheat sheet
  • Your team should know where to receive help and guidance for regulatory questions. That might be an internal legal support desk, a product manager or a running google doc that the founder or director of a team will run by legal once a month.