How to develop a great engineering team

The most important tips to focus on when building and maintaining your engineering team

Filip Kralj
Nov 5, 2020 · 9 min
Share on facebook
Share on twitter
Share on linkedin
Share on email

As we move towards automation more and more each passing day, with many tasks being delegated to computers, one fact remains: great work is done by great people. Behind every single business success is a team of dedicated individuals with a common passion and drive to accomplish more than their competition. To ensure the continued success of a business, we need to make sure this group of individuals stays strong and connected: a collective with a value greater than the sum of its parts. Building and maintaining a great team is especially important in the context of modern software engineering, where deadlines are notoriously tight, problems are ever present and ever changing and competition is ruthless. How the engineering team operates under pressure, deals with demands from management and navigates any other obstacles of the modern time, can make or break a business.

Here at easy.bi, we often deal with many complex problems at the same time, which means our engineering teams need to be especially stable and flexible. Our engineers are tested in various and often subtle ways, and over time, we have learned the most important steps to ensure success. That is why I’m writing this story; our findings might also help you on your path to building a truly strong engineering team.

Educate your team about the product they are working on

This tip seems obvious, and most team leaders actually claim that their team members have a good understanding of the developing product, but this is often not true at all. There is a big difference between knowing all the basics of a web application and understanding how the application is actually used by the end user. The team needs to understand what the customer actually wants. If developers only look at features from their perspective, they often miss key pain points of the customer, which results in an unsatisfying user experience. Even worse blunders might happen, where less informed team members might attempt to fix some problem in a way that is not in line with the general flow of the application, resulting in longer code reviews, additional fixes or even a lower quality end result. Detailed understanding of the product is also key in the context of onboarding new members. If someone is tasked with teaching a new developer specifics of the app and they themselves don’t understand the reasonings behind them, it might give the newbie the wrong motivation and ultimately result in even more problems.

Allow your team a high degree of autonomy

Software engineering is an incredibly complex process that often includes many unforeseen problems, development blockers and communication issues. Even a rock-solid development roadmap cannot save the engineering team from unknown situations. Developers are bound to discover some new usage corner case or a design crossroads where two (or more) options seem equally as applicable. Giving your engineering team autonomy means empowering them to handle these tasks in a self-contained manner. While the actual goal and user story should always be put forth by the product management team, giving your engineers freedom to make micro-decisions is important. In addition to decreasing time wasting, by waiting for input from management teams, it gives the engineering team ownership and greater responsibility of the product, resulting in higher team motivation and morale. The engineering team should also be encouraged to experiment with productivity boosting practices among themselves. Lastly, we must not forget that autonomy, while important to a team’s flexibility and the ability to approach tasks in an agile way, can become problematic. Before a team can be allowed a high degree of autonomy, we must ensure that team leaders align closely with the goals of the overall business. Otherwise, we might run into problems where the team starts mishandling important business resources.

Allow your team a high degree of autonomy

Software engineering is an incredibly complex process that often includes many unforeseen problems, development blockers and communication issues. Even a rock-solid development roadmap cannot save the engineering team from unknown situations. Developers are bound to discover some new usage corner case or a design crossroads where two (or more) options seem equally as applicable. Giving your engineering team autonomy means empowering them to handle these tasks in a self-contained manner. While the actual goal and user story should always be put forth by the product management team, giving your engineers freedom to make micro-decisions is important. In addition to decreasing time wasting, by waiting for input from management teams, it gives the engineering team ownership and greater responsibility of the product, resulting in higher team motivation and morale. The engineering team should also be encouraged to experiment with productivity boosting practices among themselves. Lastly, we must not forget that autonomy, while important to a team’s flexibility and the ability to approach tasks in an agile way, can become problematic. Before a team can be allowed a high degree of autonomy, we must ensure that team leaders align closely with the goals of the overall business. Otherwise, we might run into problems where the team starts mishandling important business resources.

Build a culture of mutual respect and commitment towards management

If the second tip was essentially about breaking free from management meddling, the third one is its counterpart: what management says is final and has to be respected. While the engineering team should definitely be present in the product decision process in some capacity (by providing technical input and warning against implementation problems, among other issues), they have to understand it is the role of management to select the final course of action. Engineers should exercise humility when their decisions are questioned or overruled, and understand that regardless of domain, both engineering and management people are on the same team with the same goal. Even if they don’t agree with a particular decision, they should understand that the motivation behind it is the same as their own: to make the best possible product. This understanding is not easy to cultivate. Special care needs to be made to ensure that engineers are respected for their input and that their decision contributions are considered. When this mutual respect is achieved, backlash against management decisions tends to decrease.

Look for skills as well as professionalism

Another tip that seems obvious but is often painfully overlooked. This is an oversight that happens most often in new candidate interviews. The interviewer might make the mistake of focusing primarily on resume achievements, such as GPA, a list of allegedly mastered programming languages or frameworks and any fancy sounding internships. While programming skill and knowledge of modern programming language practices are normally the most popular metrics, on which to evaluate potential new team members, professionalism is a more subtle quality that sometimes receives less scrutiny. Sticking to deadlines, taking responsibility for tasks and not taking critiques personally are all the markings of a professional worker and sometimes matter even more than raw programming skill. This, however, does not mean that technical skills should be valued less. Remember, we are still in the business of building applications, and that’s impossible without very smart people behind the code. Our goal should therefore be to always strive for technical excellence, but galvanized by professionalism. The latter can be a bit difficult to deduce from something as superficial as an opening interview, but proper care when constructing the interview process is key. Asking more open ended questions is often beneficial, because we can see how a candidate communicates and approaches difficult situations. As the name suggests, a job interview should be treated as an actual interview, where the interviewer gets to know the candidate, their values and tries to understand their motivations as an engineer.

Get to know individual team members

As mentioned in the beginning, a team is essentially a group of connected individuals. Sometimes the only way to fully understand and lead a team is understanding each individual and recognizing their unique strengths, weaknesses and motivations. These are often surprisingly different from team member to team member and usually connected to their experience, technical background and even temperament. For instance, one team member might be highly talkative and open to communication with external account managers, while another might be more introverted but otherwise experienced in following certain implementation specifications. It is obvious that the two profiles would perform very differently on different tasks even with hypothetically equal programming skill. Recognizing such differences can be crucial to making team members feel valuable, comfortable and properly utilized.

Conclusion

We can summarize our goals as fostering a positive team atmosphere, promoting education, maintaining individual as well as team motivation and cultivating respect among members. These values are ultimately the reason we at easy.bi can easily tackle diverse problems on a daily basis, but we are aware that this is no one time job. It is a process. I could tell you many stories about difficult technical issues we’ve had to tackle, critical blockers that we’ve had to swoop in and resolve, as well as other challenges we’ve had to face. In the future, new situations may arise, situations we might not foresee. What matters, however, is that we face those situations together, as a team.

What challenges do you face with your team? Did you come to any similar conclusions? If you applied our steps to your process, please let me know how it worked out! I’m always up for a cup of (virtual or real) coffee.

Let's work together!
Contact us