Working on a project as a single developer can be a very different experience from having two friends working on the project or a team of dozens of developers. Working in a team has its benefits, but can also have its disadvantages, and may not work for everybody. It’s not easy to have a fully functioning and efficient team and to get to a point where the team is self sufficient, cohesive, and successful. But once all the pieces start to fall into place, it will be an incredible feeling. Not only will projects run more smoothly, but everything within the team in general will, too.

Here at Flipsnack we are at a point where we work together efficiently, as a well-oiled machine. Work gets done and we are proud of what we have achieved. We communicate well, have the freedom to decide how features are implemented, respect each other and our work, and we are happy to come to the office to have fun and create extraordinary things.

We’re not perfect but we try everyday to do our best, and above all else, we respect and trust each other. We are happy to have reached this level of trust and we can say that teamwork is at its peak. Learning to put the team and our users first is what drives our everyday work. We always help each other both at the office and outside work, and we never want to compromise this.

How the Flipsnack development team operates efficiently

Having a great team ultimately comes down to the people. Everyone needs to have common values, the right set of mind and attitude towards teammates, work, and life in general. Each team should have a common goal to strive for and core values that are reflected in their work. Obviously not everybody will be a good fit for the team, but that doesn’t mean that they’re unprofessional, mean, or incapable. It simply means that person would probably thrive in a different environment.

Once you have the right people on your team, you have to lay down the rules by which it will function. We went through the same process and all of us agreed on a set of rules that we should follow. These rules have to be followed by every team member, new and existing. New arrivals must mold to fit our team, not the other way around. Team members are in charge of maintaining the core values and culture, as well as making sure that every new team member embraces them.

An important thing to note is that these rules are not set in stone. Depending on the situations that may come up during our work, we may have more flexibility in enforcing the rules or even changing them if the need be.

Coding style guides

One of the important and most basic things we agreed upon at first was our coding style. A company-wide coding standard ensures that everyone writes code the same way and enforces consistency. Ultimately, this translates to a much more maintainable project. It allows your team to write code that everyone in the company can read and update.

Our coding style largely follows the one from Airbnb, with some changes that we thought were more appropriate for us. As I mentioned, we have a certain flexibility in setting rules and following them. In our case, everyone uses an ESLint plugin with their IDE of choice. The agreed rules are followed to the letter, at least until we believe that a rule may hinder our work. Only once we can all agree to making changes and then upon the change itself will, we actually make that change.

Our style guide is like a living organism - our coding style is still evolving according to our needs. It doesn’t really matter who’s style your team is following, it’s more important that there is a style and everyone in the team sticks to it.

Code review

An important process for our team is code review, as there are many ways to do it. We chose the code review as an extra step between a git commit and a git push. We use Arcanist and Phabricator to send the latest commit to code review. Once the code is approved, we can push it. This assures that the code getting to production is checked by several people and the possibility of a bug creeping into the project is highly decreased.

Pair programming

Often times when working on complex tasks it’s recommended to have an extra pair of eyes to help out, so we use pair programming as part of our development process. Some developers may be less willing to do pair programming for various reasons but we encourage it as much as possible. Keep in mind that this technique is very popular and helps share knowledge from more experienced developers to juniors. Also, it can help developers solve very complex or hard tasks together as a team, rather than having to sit for days in front of a screen to look for a solution. This also means that the best solution is usually chosen to solve the problem.

Here at Flipsnack we often do pair programming and we noticed that it does not hurt our efficiency. Instead, it helps us finish the most difficult tasks faster and reduces risks because… well… two heads are better than one.

Technical terms/ language/ terminology

Make sure you all speak the same technical language. It is imperative that all team members know the technologies used within the project and have some minimal understanding of them and the project itself. It’s really hard to have everybody in the team at the same level of experience and knowledge, especially since there are new members coming to the team and others leaving. But it is necessary for all of them to have a common language to communicate their problems, solutions, and share knowledge or ideas. This is done by having a system in place that lets new team members get up to speed with the project and technologies, either by having mentors teach and guide them or having up to date documentation about the project.

Here at Flipsnack, every new hire goes through an onboarding process during which they learn about the project, its features, the technologies we use, and are guided by mentors throughout the whole process. During this time, we also focus on helping new teammates better integrate with the team.

SCRUM

Another tool on our belt is SCRUM. We use Scrum to manage our day to day work and the development of our projects. This started a few years ago when we realized that the way we worked was not getting us ahead anymore and more problems started to appear.

Over the past few years we refined and customized the processes to suit our needs and to make sure that SCRUM doesn’t prevent us from doing our jobs properly.

For example, at first, during the daily meetings each of us were simply stating what we’ve done the previous day and what we’ll do the current day. We noticed that often times we started explaining various problems we encountered and got lost in details so that the meeting got longer and really unproductive. Now we are focusing more on the problems we encounter and how we can help push the sprint goal to finish. This has made our daily meetings more relevant, focused, and shorter.

Since we use SCRUM, we needed a tool to handle the management and flow of our tasks from new, to work in progress, to done. For this, we use Jira. Now, everyone in the team can see the progress and help others so we can finish the agreed goal by the end of the sprint.

Other departments in the company use Trello for task management simply because it’s more suited to their needs. The main point is that you need a system to manage your tasks. A system that is easy to follow and it’s suited to your requirements and needs.

We learned to communicate well with each other and with the other departments. Team building and monthly team bonding events also helped us achieve that. Besides that, we celebrate each birthday by taking a break as a team, having a few cakes and socializing. In the mornings, we also have our coffee together or simply have a chat for a few minutes before beginning work. Plus, many of us became friends and are getting together outside of work as well. Don’t underestimate the power of simple communication! It takes some time to get there, but it’s worth while.

How we learn from our mistakes

Trust is a crucial element in a team. I really feel safe when I know I can push any new feature to production without the stress or fear that something might go wrong. If that ends up happening, I know any of my teammates can jump in and fix the problems.

We try not to blame someone for a mishap. Instead, we fix the problem and learn from it so it won’t happen again. We encourage an environment of trust, respect and responsibility, each of us being responsible for our tasks but also with making sure the team is efficient and that the project moves forward. Everyone pitches in and we don’t blame anyone when things go wrong.

The most important aspect of any team

The most important aspect of a team are the people. If teammates don’t share the same values, are not interested in the project, or simply put, don’t give a damn, this could eventually affect the team to the point where it no longer can be considered a team. At that point, it’s just a handful of developers working on some tasks.

Communication and respect is key. If they lack, then that’s not a team.

Our culture is one of sharing: knowledge, ideas, improvements to our team, our workflow and ultimately our product. Everyone knows what to do or who to turn to for help. Everyone contributes in different ways to the welfare of the team and the project. If someone needs a vacation, the rest can very well cover their work. Our team is more than the sum of its parts.

Our conclusion

It’s not easy to transform a handful of people into a great team. We had a bit of a rough start and it took us a while to get here but we do not regret it. We tried different tools, rules and processes and noticed how the team developed after introducing or changing them. We discarded everything that slowed us down or did not help us. And finally, we were left with those that helped us improve our team and our work.

To summarize, the ingredients for a great team are only a few. You need the right people and to have some rules and processes in place so that they can help improve the team. Both in their own tasks and to help them or teach them to communicate as well as possible. At some point in time the team will start to evolve and improve by itself, iterating over the tools, rules and processes it uses.

Author Bio: Claudiu Neaga is a web developer at Flipsnack for 9 years with a love for web development. He is passionate about code and helping junior devs grow and reach their potential. During his career, he's been working with different programming languages but right now he really loves JavaScript and React and looking forward to TypeScript.