Creating a structure to allow for optional teams of people rather than just individual people
Am I on the correct track of thinking here?


IMHO you are not. You are putting the carriage in front of the horse.
To get back on the right track, start at the beginning, with your data universe.
Let's list what entities you have in your game, and separate that from the business rules.
First question is: "what is it in the real world, which we are trying to model?". From what you said, I see the following - please fill in the missing pieces. the essence and relationships between developers - companies - teams - projects is not well defined IMHO.


Developers

A Developer is a Person which is identified by {Fill in}
A Developer contributes work to Projects
A Developer works for a company {True?}
A Developer IS a part of a team
A Developer may be assigned to zero or more teams {True?}

** You said that the developer 'may be part of a team', but it doesn't work that way. you can't have the cake and leave it whole. If your universe has a hierarchy of teams now, it is true for all. The way you keep 'the old way', is by creating a team of one person.
This will resolve the evil cyclic reference that you can see in the solution that Alfonso suggested, who was just following your specs. 


Companies

A Company is a legal entity which is identified by {Fill in}.
A Company hires teams of one or more Developers.
A Company owns Projects {True?}.
Developers are employed by Companies {True?}.
Teams

A Team is a logical container for developers which is identified by name. 
A Team can be assigned zero or more developers. 
A Team can be assigned to zero or more projects {True?}. 
A Team belongs to a company {True?}. 
Projects

A Project is a collection of tasks which is identified by name. 
A Project may be assigned to zero or more teams. 
A Project belongs to a company {True?}. 


Once you fill in the gaps and clarify what you have, we can continue on the right track.



-- Follow up to OP Updating Requirements --



Developers are not identified by ID. That is a surrogate key which does not exist in the real world. We will sort out the table keys later. The question is "How do you tell developers apart in the real world". I would assume they have a unique user name, or use their Email address to log on, so that your application can identify them, right? perhaps you use SSN?
A company, team, and projects are probably identified by their name, which is what tells them apart in the real world, unique in their respective scope of course - It seems that team per company, and project per company make sense. 

As for the entities, based on your reply I now believe that we have missed a few. Let me suggest something, and see if that works for you. 
I think the term 'Companies' is misleading, as you don't care if it's a company or an individual. What this represents is your customers, or the project owners, which are the legal entity which you issue invoices for. Since you already mentioned the separation of roles (developer / administrator / Read only etc.), I've taken the liberty of adding a couple of more entities that exist out there, and which you probably want to consider in your model.
Let me know if this makes any sense.

Customer:       A Customer is a legal entity identified by it's tax identification number (SSN/ITIN). 
                Customers employ zero or more Employees.
                Customers own zero or more Projects.

Employee:       An Employee is a Person, identified by his (SSN / User Name / Email Address).
                Employees are employed by a Customer.
                Employees can have zero or more roles in association with zero or more Teams.

Role:           A role is a description of responsibility area for an Employee.
                Roles are identified by name.
                Roles can be one of : Developer, Project Viewer, Project Manager, Adsministrator, Team Lead)
                An Employee may have zero or more roles.

Team:           A Team is a collection of zero or more Team Members. 
                A Team is identified by name.
                A Team may be associated with zero or more projects.

Team Member:    A Team Member is an Employee that is associated with a Team.
                A Team may consist of Employees from one customer only.
                Team Members have a single role in a Team.

Developer:      A Developer is an Employee.
                A Developer contributes work for projects.
                A Developer can be associated with zero or more teams.

Project Viewer: A Project Viewer is an Employee.
                A Project Viewer may access Projects, but is not allowed to make changes.               

Project Manager:    A Project Manager is an Employee.
                    A Project Manager manages zero or more Projects, and the Teams associated with them.

Administrator:  An administrator is an Employee.
                An administrator represents the Customer and has permissions to manage Employees, Roles, Teams, and Projects.

Team Lead:      A Team Lead is a developer.
                A Team Lead manages zero or more teams.
                A Team may have only one Team Lead.

Project:        A Project is a collection of tasks, which are to be executed by Teams.
                A Project belongs to one Customer.
                A Project is identified by name.
                A Project may be assigned to one or more Teams.