The Best Team from a Developer's Perspective

Disclaimer

If you are a developer like me, we could say that daily, we go to our jobs, talk with our colleagues and friends, analyze and develop activities and products, solve bugs, laugh at jokes about technologies and frameworks, but we do not always feel in a quality environment, or working with interesting technologies and challenges that motivate us to always produce the best solutions.

Facing this scenario, it's not always exactly clear what are the characteristics that would improve the quality of life we have in our work, or what would be the challenges that would motivate us to build an amazing product.

If you are a CSO (Chief Something Officer) building a startup or a leader of a consolidated development team, you might have thought about how to form a high-performance team, or keep team members motivated to deliver the best solutions.

Well, for both cases, this post proposes some ideas and methodologies that make developers more engaged and motivated to produce incredible solutions while evolving as professionals and as people.

These ideas are based on a few years thinking about this, discussing with other developers who are less or more motivated, talking with tech leads, with the development community, and with company directors and owners.

To ensure that all aspects of a team are addressed, I will talk about the technical vision and also the people management vision.

Technical Vision

If the technology department has several teams, it is necessary that each of these teams respect the chosen technologies and are aware of the reasons why such technologies were chosen. Many times, I noticed that when this interaction of respect does not occur, teams begin to feel better than others, requiring more resources, or even not seeing the importance of what is produced by others. An interesting solution is to present the processes that each team follows, what is the roadmap, the importance of what is being developed, and why this is so relevant to the company.

The development team and developers need to have autonomy to make choices of the technologies that will be used within the projects, this lack of autonomy also leads to demotivation, or even lack of performance in the development process.

It is also necessary to have transparency about why such technologies are being chosen, making clear to all developers what are the strengths and weaknesses.

A presentation of defense about the technologies to the development team is a good dynamic to clarify doubts and facilitate the understanding of which technology will be chosen.

This also ensures that the technologies will be used in the long term, as deliberate choices, without the knowledge of the entire development, usually cause centralization of knowledge and a consequent abandonment of the technology when a certain developer leaves the company.

Pair programming among team members levels them better and decentralizes knowledge, code reviews without preciousness and egocentrism, following a coding style defined by all members also facilitates the understanding of all devs, it is also important to integrate the members, allowing emotional development of developers within the team. In my experiences doing this, it was very important for me to learn to say that I did not know something, and to reinforce trust among team members.

Promote Dojos and hackathons to solve problems faced by the entire team, think together with the team what would be interesting to be implemented and that excites everyone. This is an initiative that motivates developers a lot, we all like to create new things, or solve existing problems. The reward of creating something new, and being integrated with your work colleagues, is definitely very important for the evolution of the team.

Participate or allow your team to participate in technology events, and encourage them to go looking for more than just new technologies but also meet people. I currently work at a company that I met because of people at community events, this allowed me to know the company and also the professionals who worked there.

People Vision

If you are a leader hiring a new team member or even assembling one, seek to evaluate the candidate's profile, it is essential that he fits with the team you have not only by technological knowledge but also by behavioral profile.

To ensure that the best candidate is hired, establish in the hiring process, that the candidate spends a period of time with the team members, this interaction is the best way to identify if the candidate has the fit for the position, at the company I work today, I spent about an hour with the team that would work, this time was crucial for me to understand the team's profile, and also served for the hiring manager to assess if I had the desired fit.

The company's HR professional probably has knowledge in behavioral analysis and knowledge about cultural fit, he can certainly assist in this process. (as I write this paragraph, I'm thinking that maybe an article with ideas for a good dev hiring process makes sense)

And finally, you as a hirer can say: "The market is scarce of experienced devs, I don't have the luxury to stick to cultural fit and profile, besides, we can adapt this dev to our culture and work profile". Remember that not every professional will be willing to change, and if there is this unwillingness, in the long term this can generate friction in the team, and demotivate the members.

Developers need to understand what is the purpose of the product being developed, why it was conceived, what are the particularities of the market in question and what is the problem that the product proposes to solve. Some developers may end up seeing this point as something bad, "I'm a developer, I need to ensure technical quality, not care about the product", but we know that things don't work that way. Having in mind this awareness about the commercial viewpoint, increases the ownership of the product and also allows commercial and development to talk in better tune about new features, and prioritizations.

The results of a team that does not understand the commercial nuances can cause rework, delivering features that should do X and not Y, causing frustration for the devs as they don't exactly know the need to focus on a specific value delivery and increasing demotivation at a moment of pressure.

One strategy to improve this understanding is to promote communication between sales and development, bringing developers in to explain the technical importance of what is developed to the CEO and the entire commercial side (sales, marketing, pre-sales, directors). It also involves bringing this market knowledge to developers, showing how sales can evolve at that specific moment with that important delivery, etc.

• It's essential to have a tech lead who inspires people. Tech leads are usually known as very experienced seniors, and this is a crucial point to ensure that team members feel inspired to learn and overcome daily challenges. Therefore, this tech lead needs to have good soft skills, know how to guide the team, understand the team's peculiarities, and take advantage of each member's strengths.

• Have 1:1 meetings periodically. A 1:1 is essentially a round of updates and feedback between a tech lead/manager and a team member. The idea is that in a few minutes (usually 15), it's possible to address the frustrations and successes the developer has experienced in that period. This is very important as it gives the developer a voice to complain, congratulate, or suggest changes that make day-to-day life, processes, methodologies, or anything else associated with the work environment better. This is a two-way street and also allows the tech lead guiding the 1:1 to provide productive and constructive insights on the developer's progress. 5 tips on how to do one-on-one

• Establishing sprint reviews and plannings is very important. We are human beings, and as such, we tend to postpone activities that don't have very defined deadlines. For a team not completely aligned in culture, methodology, and development speed, this is a very good strategy to use. It's not necessarily about thinking in sprints or sticking to methodologies, but about making estimates with a delivery date in mind.

  Taking into account the team's capabilities is also important. You shouldn't excessively pressure all members, but creating an environment with some pressure can stimulate the evolution of the members and consequently the product.

• Promoting small rewards and recognitions is a strategy to keep your team focused and motivated. It's not necessary to have a regular frequency, but whenever there is a success, either in a completed sprint or a launched release, reward the team for the successful effort. This shows that the team was successful in that activity, and also releases endorphins that will associate the good work done with the reward.

• When a process fails, or a bug goes into production, it's important that there are no public accusations of the developer who caused the problem. Instead, the team should commit to understanding the problem, correcting it, and evaluating the process that led to its occurrence. Later, in an individual and private assessment, it's possible to identify the points that led to that failure.

  It's also always necessary to establish the importance of ensuring value delivery to the client, not just completing the feature.

Acknowledgements

Well, these are the points I've raised. If you disagree with any, or agree and strongly support them, don't hesitate to comment on my twitter (I haven't added a comments section here yet, this is the MVP of the blog) or send me an email. If you found an error in the text and would like to correct it, open a PR in the website's repo, I will definitely look at it and accept it :).

I want to thank the FloripaJS community, which helped a lot by raising, discussing, and commenting on the points of this article at the last meetup.

Thanks, everyone!