Good approach to organize your teams at GitHub

One of the most complicated things nowadays is how to maintain our workspace well organized. It’s not about plannings and projects at all, but in a single point  that we can improve everything continuously. And a great point is: everything that you don’t pay attention, maybe will be a problem in future and the things get bigger sometimes.

We have many developers and outsourcing partners working joined to our GitHub account. The company already started and is starting many projects at same time, so the developers manegement accounts must be made in a effective way. I thought in some strategies to handle that and I think that the better way to solve this little puzzle was to group developers by skills. Except to keep business security, maybe it’s interesting to keep just outsourced guys in a different group and give them the desired permission.

Why Skills?

At first you can have a skill mapping of your team. It’s a great overview to understand how your IT environment is established.

If you have a developers group organized by skills, you can have a clear map of what kind of developers that you need to maintain your applications running.

Let’s imagine a scenario that you have many teams working in different projects, and much of them are writing code using the same computer language. Just for an example, let’s say that this guys are using NodeJs for that, and to facilitate our example we are talking about group A and group B. So, if you organize your team putting all NodeJS skilled guys in a common group, you’ll have a good knowledge transfer and will be improving team’s relationship. As a matter of fact that they are working in distinct projects, they will be able to consulting each other codes and be opened to change and share knowledge every time. Your whole team will have better communication and they will be always at the same point.

When you keep the group A and B separated by the project, you just broken the chain that it would be continuous. If a guy from group A elaborates a good solution to his project, maybe it can serve as example and base skill to some guy in group B. It doesn’t matter the order that solutions come from, you’ll extend your knowledge base to all guys. You also can think that if a guy from group A made not a such good solution to some problem that he was handling, this can be identified, improved and suggested by a guy from group B. Coding review?

Another interesting point that you can keep in mind is that, if you needed to add more resources to group B, and group A is in a stable state of work, you could easily identify the right guy and move him to help.

When you already is using git, you probably have a good communication performance, and I think that if you organize your team as above, you can achieve more benefits that you already have.