Everyone building a software-enabled startup is going to have some amount of software development, cloud infrastructure, and general IT-related overhead. This article will give you some high-level thoughts on how to action working with a non-founder (or even your technical founder).

Operational Security

OpSec refers to the methods and processes you put in place to operate your organization. These decisions should govern how you work with your team, internal systems, and external vendors. If you establish default best practices for your team, then it will be clear how others who join later should act. Also if you have any contributor internal or external depart your team, there will be little impact in terms of steps to remove access.

Default to Centralizing Access

This is a relatively simple approach for new organizations, but the first move is to set up a system like Google Workspaces. This then gives your organization a @myorg.com domain control for every contributor. Provide even your external vendors and contractors with a user@myorg.com.

This gives you a few benefits, you can rest assured that if you need to remove their access to many systems, you can simply remove them from Google Workspaces. You will further have to remove them from other systems but you can shut off access relatively immediately. This additionally helps your team know what users should have access when they are looking at any particular Access Control List (ACL) in any vendor application. If they ever see a non-@myorg.com domain, they should know to raise a flag and point out the discrepancy. If it's not obvious any external domain would imply that you have outsiders looking in on your operations. This may be appropriate and if so you can grant them a user in your system and remove theirs to disambiguate future reviews.

Require Multi-Factor Authentication

Multi-Factor Authentication is a great mechanism to ensure unwanted hackers and external users stay out of internal systems. Here is a list of Multi-Factor Authentication providers from most secure to least secure.

1. Duo

2. Google Authenticator

3. SMS

If you don't want to deal with Duo, request your team use Google Authenticator, and require SMS at a minimum in Google Workspaces. If you are willing to require Google Authenticator in Google Workspaces it'll give you an excellent default level of centralized security.

Source Management

Many non-technical founders will have no awareness of how to manage software development projects. If your team is delivering software and deploying it in a demo environment, it's a good indicator that they have source code. This should be required to be delivered and shared by default with the organization that owns it.

1. Setup a Github Organization

2. Setup a project in this organization for each project you have contributors on

3. Require that all contributors are members or collaborators in this org

4. Make sure all of them are using their @myorg.com domain

There are many optional changes you can make to Github Organizations which could be the topic of a full post in and of themselves.

1. Require Forking

2. Disallow force push to master/main

3. Pull Requests

You should delegate to your leadership in your development team to document their opinions on source management so it is clear for new and future team members. Any software engineer worth their weight will have an opinion on this matter.

Make it clear though, all source code for your organization, your startup, belongs in the Github Organization you and your technical co-founder maintain. This will ensure you are never in a bad situation wondering where your intellectual property lives.

Other Considerations

As you build your modern technological stack (tech-stack) you'll inevitably begin to involve more standard systems. Some examples are below and you should follow the basic set of rules:

Rules:

1. Always require use of @myorg.com users if you are required to setup users

2. Never allow non-internal accounts

3. Require Multi-factor Authentication

Best Practices:

1. Perform a System and User audit from time to time

2. Use a password manager

3. Create a Root account like engineering_root@myorg.com

   1. Not tied to any real person - save password in a password manager

   2. Owns all root-level access to AWS/Hosting/Continuous Integration/Organizations

4. Make sure at least two people at all times in your org know how to access the root account, but default behavior is to never use it.

I've used the above approaches to manage engineering teams at major organizations and funded startups. It's great to ensure continuity as your team changes over time and could save you from nightmare situations like a co-founder rage-quitting and outside attackers accessing your systems.