Professional Software Engineering Team
I have been thinking about this topic for a while and now I think now I have a better idea of what are the attributes of a professional software engineering team. Technical skills are table stakes so I will not spend any time emphasizing the importance of that. Listed below are the non-technical but critical skills a solid engineering team needs to have.
Predictability: A professional engineering team should estimate projects accurately and deliver on time. Businesses need accurate estimates from engineering teams so that they can effectively launch products. Top-tiered consumer products companies such as Apple and Samsung rely on accurate estimates in order to launch their devices. For consulting companies, the stakes are even higher since their contracts usually have deadlines. So it’s critical for engineers to develop skills around providing accurate estimates. Most software engineers spend a lot of time working on their technical skills but I can’t emphasize enough that the ability to estimate accurately is critical for tech companies to succeed.
Customer-first: Businesses hire engineers to add value to their customers (directly or indirectly). To help customers, it is critical to understand their needs. Therefore engineers should develop empathy for their customers by trying to think from their point of view. Many times, even technically-simple features can improve customer experiences to a great extent. And, I have also seen sophisticated products and features not getting used.
Collaborative Culture: A professional engineering team is one that is more dedicated to team velocity than individual members’ speed. The sum is greater than the individual parts. Having the confidence that your team is not going to let you get stuck on a problem is a huge safety-net for any engineer. This dedication to teamwork promotes working on parts of projects that other engineers are not that closely familiar with. A practical tip for improving collaborative culture is having new team members pair with other engineers at least 50 percent of the time for the first few months. This is a great way to share knowledge, build relationships, and learn about the domain.
Consistency: Software engineering teams these days are usually small consisting of five to ten people. Each team is usually managing more than one module or service. Therefore, it becomes important to maintain consistency in a project while also being consistent on multiple projects as much as possible. Otherwise, the context switching will kill productivity. A few concrete examples of maintaining consistency are all unit tests should follow the same structure, same commands to run projects, same commands to run CI/CD pipelines, and readme files should also follow the same structure.
Outcome focused: Again, Businesses hire engineers to solve problems. Programming is a tool to solve problems; it’s not a solution. The success criteria of any team should depend on the outcome more than the artifacts produced. For example, let’s say the goal of a project is to improve the signup process and increase the number of signups by 5%. I would say the team did a great job when the number of signups went up by 5%. If the UI or backend is looking modern but the number of signups did not improve, then we can’t call the project successful.