From team to company – founding issues


In my role as mentor at the MIT Venture Mentoring Service and the MIT Sandbox Fund I very often find teams that have been formed in academia but have the goal of founding a company if their business idea proves out.

There are a number of very important issues surrounding the formation and operation of these teams that I recommend founders consider carefully.

Goals of the team

While the goals of the team are often set out by an application process, as in the case of the MIT Sandbox, other teams that involve students and/or faculty may well not be. Even in the former case, goals may change. So I advise the members of the founding team to clearly set out their goals for the project and document them. An example goal might be learning the basics of doing a startup to prepare team members to do their own startups when they graduate. These goals may need to be revisited, but that’s ok. I find that when any disagreements or disputes occur it can help the team to revisit their “first principles.”

Personal goals of the team members

I have written elsewhere about the importance of alignment of the founders’ intentions. Each each team member gives careful consideration to their own personal goals for the project and then hold a team meeting in which each member expresses their personal goals. If there are major conflicts, such as one member is simply interested in learning more about the area the team will be working on, say machine learning; another wanting to turn the project into a startup company; and a third simply wanting to fulfill a course requirement, then the team is going to run into problems. At minimum awareness of everyone’s goals may help, but it may be necessary to change the makeup of the team, so that all members plan to turn the project into a company, or everyone is simply interested in learning – about startups and/or the topic of the project.

Team membership

A key issue with young teams is the makeup of the team. Often it is a mix of full time students from the same university, a team member or two from another school, and perhaps an experienced entrepreneur or a faculty member. Problems occur when some team members feel that others may not be pulling their weight and disputes often align along commonalities. “Hey we are all working on this full time, but you have a day job and we don’t think you are putting in the effort we are!”  Founders should give some thought before bringing in someone they just met at a networking event, for example versus another student enrolled in the same school and course. It is important that roles and responsibilities be clear. Issues like who is working full time on the project vs. part time or who is responsible for managing the team’s grant money  need to be clarified upfront, before becoming bones of contention.

Relationship amongst team members

Closely related to team membership is the relationship amongst the members. What are their connections? Fellow students? Attended the same school? Have the same major? The stronger the pre-existing relationships amongst team members, including friendship and having worked together previously, the greater the likelihood of success.
Y-Combinator has found that the most successful teams are lead by founders with a strong pre-existing relationship. If you have worked with or known a team member, look for commonalities, such as common interests or mutual friends. The more and stronger the pre-existing connections, the stronger team.

Duration of the project

This may seem simple, but it effects the focus and efforts of the team. Will this project end with the academic year? Will it end when key founders graduate and move on to other things? Or is the plan to transform the project into a company and the project into a business entity, an LLC or C-Corp?

Definition of the project

This is usually de rigueur for applications for academic funding or entering an incubator or accelerator. And it’s the item most likely to change as the project moves forward. But like the goals of the team, it’s useful to pin this down at the outset and revisit it when circumstances change, such as finding no interest from beta testers, or a founder leaves, or a major competitor emerges. Most startup ventures end up partially or completely changing their business model

Project deliverables

In trying to help mediate disputes amongst founding teams I’ve found that poor definition of who was responsible for doing what and by when seems to be a common problem area. It’s critical that the team agree on not just what the deliverables are needed to complete the academic project or get to early startup stage, but who on the team will deliver what and when. Steve Jobs instituted a role for all Apple teams called the DRI – the Directly Responsible Individual. The concept is simple, but requires effort to maintain. Read this article on Medium about how the DRI model worked at TripAdvisor.

“Any effective meeting at Apple will have an action list,” says a former employee. “Next to each action item will be the DRI.” A common phrase heard around Apple when someone is trying to learn the right contact on a project: “Who’s the DRI on that?”

Using the DRI system may be one of the most powerful tools you can have in your team’s toolbox. Equally important is the concept of KPIs: Key Performance Indicators. If you do nothing else after reading the article implement the DRI and KPI systems for your team.

What happens when a team member leaves?

Teams change. Students graduate, team members lose interest, others take a new job or join a new project. Dealing with termination, of contracts, team memberships, partnerships or any other relationship is amongst the most difficult issues any team faces. What I’ve found is that few team plan for these type of events. It is sort of like why I believe people didn’t wear seat belts: putting on a seat belt brought to mind you might be in accident. Who wants that awful thought every time you get in the car? Likewise who wants to think that a team member might quit? But this is where IP issues -who owns the intellectual property developed by the team – come to the fore and why ownership has to either be made crystal clear by the academic program, the accelerator or a founder’s agreement. Whether the agreement is that team members who leave give up all rights to IP created by the team or whether they have the right to make use of any IP created – software code, team name, written specs, algorithms, etc – isn’t so important as total agreement of the team at its founding.

How are disputes handled?

I’ve found this to be a weakness or more clearly a lacuna, a gap, in many entrepreneurial programs. This is understandable. Most people like to avoid unpleasantness and teams are left to their own devices, unlike inside a mature company that may have formal processes for handling disputes. Consider putting in a simple rule such as any change in the team’s direction, makeup or other major factor requires either a unanimous vote of the founders or a majority vote of the founders. A founders’ agreement may even include a clause that business disputes, like IP ownership, go to arbitration, not the courts. Like having a team member leave, planning on how to handle major disagreements may seem like focusing on the negative. But it’s an insurance policy. And like an insurance policy, you hope you never have to take it out of its file folder.

The differences between a team and a company

This is very, very important. So I’m just going to point you to a previous post on the subject and recommend you read it carefully.

The path from a team to a company

It may well be helpful to agree on what will trigger the phase change from team to company. Events such as a beta test that meets or greatly exceeds its targets, strong interest from an angel or VC investor, attracting a powerful and successful entrepreneur to the team, or a major scientific or technical breakthrough are the types of triggers you might consider. Again it’s important that the team agree on what will trigger this major change from team to company at the outset of team formation.

This stuff may seem dry, boring and unnecessary or distracting. But you’ll find that if you ignore all these foundational issues may become more than distracting, they can become distracted. A couple of maxims apply: forewarned is fore armed and an ounce of prevention is worth a pound of cure.









  1. path to a company
    1. founders’ agreement
    2. IP creation: copyrights, patents, trademarks
    3. creating a business entity: LLC, C-Corp

Author: Mentorphile

Mentor, coach, and advisor to entrepreneurs, small businesses, and non-profit organizations. General manager with significant experience in both for-profit and non-profit organizations. Focus on media and information. On founding team of four venture-backed companies. Currently Chairman of Popsleuth, Inc., maker of the Endorfyn app for keeping fans updated on new stuff from their favorite artists.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: