As a software engineer with nearly eight years of experience, I’ve worked on plenty of teams in various industries and domains. Lately, I’ve been reflecting on the qualities of these teams, especially those that I would deem “great”. Today I’d like to share some of those reflections and their impressions on me. I won’t delve into how to build great teams, but I will share my observations on what qualities I believe need to be present in order to be highly successful.
Before we begin, let me acknowledge that the importance of these qualities may vary depending on the context, industry, and organizational culture. However, in software development, I’ve found these qualities to be generally crucial. Removing just one can turn a team from great to good, and removing a few more can push them towards being average or even poor.
Generally, these qualities are:
- Strong leaders
- Specialized “role players”
- Great culture
- Teams/Organizations that are fully-aligned
- Good technical choices
- Buy-in from team, organization, and stakeholders
- Agile
Now, let’s break down each of these qualities in more detail.
Strong Leaders: The MVPs of the Team
Leadership takes on many forms, and I fully admit I still have a lot to learn on this front. However, I’ve noticed some patterns in leaders I would deem effective.
First and foremost, we should acknowledge that leadership can take many forms and there’s no one ideal personality type that a leader needs to have to be successful.
A couple ways a leader can be great:
Technical prowess: Leaders with strong technical skills can effectively guide their teams.
Ability to delegate: Leaders that can delegate empower their team members and fosters growth.
Encourages questions: Leaders who create an environment where questions are welcomed enable a culture of learning and innovation.
Humility: Leaders who acknowledge what they don’t know and are open to learning from others inspire trust and respect.
Collaboration: Great leaders bring everyone together and facilitate teamwork.
Enforcing best practices: Leaders who prioritize and enforce best practices help maintain high standards within the team.
Kindness: Kindness goes a long way in building a positive and supportive team culture.
Decision-making ability: Leaders who promptly make informed decisions keep the team moving forward.
While leaders don’t need to excel in all of these areas, they should excel in at least a couple.
Specialized “Role” Players: Nailing the Positions
In sports, a role player excels at specific tasks or skills within the group. In basektball, it’s someone brought in to get rebounds, or perhaps make three pointers and spread the defenders out. Similarly, certain situations in software call for individuals with specialized expertise.
For example, you might need someone who excels at CSS, a performance optimization guru, a platform and pipeline artisan, or an expert in fine-tuning database queries. These role players (engineers) bring unique skills to the team, and I’ve often found myself in such a role.
You need these individuals. On the frontend for instance, sometimes you’ll receive complex wireframes that demand a high level of skill in CSS. There are plenty of engineers who work on the frontend of applications with a limited knowledge of CSS. And that’s okay! However, it’s important you find your role player when this situation arises. Some of you may be going, CSS? Really? That’s your example of a role player? Yes! This comes from firsthand experience on teams where styling UI got very complex and we needed someone to take charge on that front. It’s also why you see sites like CSS-Tricks with so many articles and readers.
Whatever your specific technical need is for the thing you’re building, make sure to find those role players who will not only build the solutions, but also educate and share to the rest of the team how they’re doing it.
Great Culture: The X-Factor
Defining a great culture can be challenging, as different engineering cultures can value opposing things and still find success. An example: one culture finds success in leadership at every level, while other cultures find success in top-down leadership. I guess it depends on how you define success, but this is part of the reason it’s so tricky to define.
A great culture, in my opinion, is one that encourages collaboration, fosters learning and growth, is supportive, and focuses on systems and effort rather than solely on outcomes. Oddly enough, I’ve found the teams that focus less on outcomes and more on process and iterative improvement achieve more results than those highly focused on output.
Oddly enough, I’ve found the teams that focus less on outcomes and more on process and iterative improvement achieve more results than those highly focused on output.
I’ve found the same holds true in my personal life. When I put all of myself into outcomes, often I’m left disappointed. Outcomes can be a result of so many factors, some of which are completely out of your control. The better approach is to commit yourself to process and a system. I like this article on the topic by James Clear.
Teams/Organizations that are Fully Aligned: The Power of Process
Remaining on the same page is hard, especially in the era of remote work. It’s hard to stay aligned with the other members of your team and organization, especially as you scale your team, but the best teams do. They have processes for remaining collaborative even when they’re not in the same room.
That’s why I think companies like Google are making the wrong decision when considering attendance in performance reviews.
Good Technical Choices: Striving for the Sweet Spot
Great teams make good technology choices. They consider product requirements and what tools/languages/frameworks will meet those requirements. They consider the current teams skills. Are you building a web app and the team only knows Laravel? Probably should consider that before going with the shiny new JavaScript framework. They consider community and maturity of the technology. I’ve worked on projects where we adopted the shiny new framework before it was production ready, don’t make that mistake. Lastly, great teams consider buy-in. Is the team highly-unmotivated to work in Java? Maybe don’t force them to work in Java.
For me, good technical choices involve selecting the appropriate tool for the job, ensuring the tool is mature and has a supportive community, considering the team’s capacity to adopt and utilize the chosen technology effectively, and prioritizing security, accessibility, and best practices. It seems like a lot to consider, but looking for maturity alone—especially when a new JS framework is created everyday—can weed out a large portion of the web technologies being adopted out there.
Buy-in: The Secret Sauce
Buy-in is when team members, teams, organizations, and stakeholders all align and buy-in to the process. It’s the secret sauce that achieves results. There’s no conflicting opinions on the best architecture, or the tech stack, or the platform. Everyone buys-in fully to the process and commits themselves to producing the best they can given these choices.
I think about it in the same way I think about professional basketball. A head coach may have had immense success with a previous team thanks to a well-defined strategy and playbook, but upon joining a new team with a similar makeup, their methods may not yield the same results. One possible explanation for this discrepancy is the level of buy-in from the players.
Consider a defensive-minded coach like Tom Thibodeau, who used to coach the Chicago Bulls. He was known for his intense focus on defense. In the 2010-2011 season, the Bulls went 62-20 and had the highest defensive rating in the league among 30 teams, leading them to the Eastern Conference Finals. This success was in part due to the players buying-in to the system Thibs laid out. There was full commitment to defense. Offense was secondary.
The same holds true in engineering. I posit a great team needs full buy-in from everyone responsible for the product.
Agile: Adaptability at Its Core
Agile is a popular project management approach that many teams claim to follow. I’m not suggesting that great teams strictly adhere to all the agile ceremonies such as standups, retrospectives, and sprint planning. Rather, what I mean by “agile” here is a team’s openness to learning, their ability to pivot and adjust quickly, and their focus on systems rather than goals. Great agile teams deliver outstanding results because of their flexibility, not merely due to the ceremonies they follow.
What Do You Think?
So, what are your thoughts on this list? Do you agree with my observations? Have you encountered these qualities in the great teams you’ve worked with? Is there anything you would add or remove? If you’d like to share your thoughts, let’s connect on LinkedIn!