Throughout my career, I've worked with countless development teams, and the difference between low, medium, and high-performing teams is striking. Interestingly, the most successful teams weren't always made up of mostly senior engineers. Quite the opposite: what truly set them apart was a balanced distribution of seniority, strong integration, familiarity, mutual trust, autonomy, and an unwavering commitment to delivery.
The lower-performing teams, on the other hand, frequently stumbled into traps that, at first glance, may not seem obvious. Let me walk through the most common ones.
Misguided Strategic Decisions in Team Formation
A common strategic mistake when building teams is adopting models like the inverted seniority pyramid or the "flat team".
A flat team is one composed mostly of low-seniority professionals. This usually happens due to budget constraints. It's worth noting that "junior" here has nothing to do with tenure; there are people with 20 years of experience who have stagnated, with no growth in either hard or soft skills. Teams with too many juniors and mid-level engineers tend to lack technical depth, as well as the leadership and management skills needed to solve more complex problems, whether technical or strategic. Let's be honest: it's rare to find a "Junior Pro Max," someone who defies the curve. As the label suggests, that person is the exception.
On the other hand, a team with an inverted pyramid is one composed primarily of seniors with very few other profiles. Typically, the initial justification for this structure sounds logical, and it's often a desperate measure to solve a problem, or it signals a lack of expertise in team management. This composition brings several issues, with friction being the most common. Friction can arise from ego clashes, arguments over "who's the best," "who has the better solution," or even "who gets the most attention." There are also cases of reluctance to take on more operational, low-intellectual-value tasks, among others. A deeper exploration of these dynamics could fill an entire article on its own.
The Heavy Hand of Organizational Governance
Excessive organizational governance often stops being about security and starts revealing a lack of trust in people, resulting in overbearing individual control and the constant need to justify every step. The underlying message becomes: "You don't understand this subject, you don't know how to do it, and you're not responsible enough." People end up being treated like children who need someone holding their hand at every turn.
This low level of autonomy creates a massive need for internal and external approvals. This model, justified by "security," demands multiple approvers who often have no real commitment to the final delivery. In this scenario, more time is spent justifying, coordinating, and requesting authorization than actually shipping software. Software engineering is a creative profession, and environments with too many controls and rigid step-by-step procedures tend to suffocate innovation.
In this context, three things can happen: the best talent looks for opportunities elsewhere, they are pushed out for not fitting the system's rigidity, or they give up on innovation and are flattened into the prescribed mold, which is usually far smaller than what they could contribute.
High-performing teams thrive in environments with psychological safety, where they have autonomy to make decisions and authority to implement them, resulting in faster flow and higher quality. — Gene Kim in "Accelerate: The Science of Lean Software and DevOps"
Team Structure and Organization
How teams are structured and organized directly impacts delivery speed, leading to a negative effect on productivity. This is where more traditional companies suffer the most during digitalization, modernization, or new product development. Back in 1957, Conway had already identified that an organization's communication model directly affects its systems architecture. Poor team distribution and organization leads to multiplied operational costs, with duplicated work (the same need being solved by different teams), infrastructure costs, and the complex need to orchestrate who deploys first, and so on.
It's not uncommon to find scenarios where several different teams modify the same service, often simultaneously. Or, during a modernization effort, the legacy project isn't "frozen" and continues to evolve and receive fixes, while another team works on a new epic or "modernizes" the same project. A project with different branches evolving concurrently in different directions is a prelude to chaos. The longer this drags on, the greater the chances of wasted time and effort, because eventually someone will have to decide whether to redo one of the branches (usually the one they didn't work on) or merge code fragments into the branch with the most changes.
Friction between teams and software delivery delays are usually symptoms of poor team structure. — Team Topologies
To mitigate these problems, organizing teams based on purpose and interaction mode, following the Team Topologies model, is a strategic approach. And structuring teams by isolating them into Bounded Contexts and applying Domain-Driven Design (DDD) provides solid guidance to justify and define each team's purpose.
Constant Team Changes
Frequent changes to team composition, whether due to high turnover, the emergency need to add someone to speed up a delivery or fix, or "lending" members to other teams (understaffing), are all harmful. According to Tuckman's Law, every time a team's composition changes, it tends to regress to an earlier stage, typically to Storming or Norming, moving further away from high performance.
Chasing Metrics Without Focusing on Behavior
Pursuing metrics without fostering capability building and behavioral change is another common pitfall. Well-designed metrics are like snapshots of the current situation. The best way to improve and hit them is to figure out what kind of behavior people (or we ourselves) need to develop to move those needles.
Think of the weight loss metaphor: there's no point in stepping on the scale every day. In a development process, just as you lose fat and gain lean mass, improvements may not be linear or immediate. For a while, it may look like nothing is "improving," and when you look at the numbers, you get false negatives.
On the other hand, forcing metrics to be met can produce false positives: it looks like test coverage went up, but the actual quality, which is what matters, hasn't improved. The rush will push teams to "find" ways to game the results, whether by ignoring classes or calling code snippets without actually validating the outputs. By chasing artificial results, you're creating a future problem for the organization. Principles like courage and transparency, which XP advocates, are extremely important here, along with modern management skills for delivering real value instead of merely lying with statistics.
Creating Tasks or Solving Nonexistent Problems
It's very common for teams with strong theoretical knowledge but little maturity, with the good intention of "anticipating problems," to end up increasing complexity unnecessarily. They spend a large portion of their time imagining problems that will never materialize, even before they start solving a real one. Designing and solving problems that exist only in one's imagination is an effective way to create "accidental" complexity.
Accidental complexity is one of the three types of complexity, and it's generated by the architect's or developer's "preference." It shows up in decisions that don't solve any problem the business actually has, often being a whim to apply something newly learned or to use a trendy framework.
It's the classic dilemma: "I'm going to start a project following best practices, with a microservices architecture, distributed caching, Kafka for asynchronous processing, service mesh, etc... and all of this for a project that's just getting started, has only one client, and a projected demand of 200 requests per month."
In many cases, for a greenfield project, understanding the real problem and applying a Lean Inception technique to determine what makes sense, where to start, and what should be left out helps guide decisions. In a refinement session, everyone knows what's important, but few know how to prioritize. Beyond the ability to prioritize, there's also the need, combined with other skills, to know how to negotiate and sell. Right there, those are three important leadership soft skills that a truly senior person possesses.
There are cases where modern tools arrive, but the practices still follow old thought patterns. For example, requiring a database schema for an unstructured database (NoSQL) is a clear anti-pattern. Besides losing the benefit of schema-on-read, this practice adds unnecessary complexity.
Failure in Knowledge Sharing
Knowledge sharing is a very common problem across many organizations. Among the various types, the most classic one occurs when people with low maturity believe that concentrating or hoarding knowledge is a power tool. They think that by having a problem "with their name on it," they become indispensable to the organization. In reality, this practice turns them into a bottleneck, even making it harder for them to change positions, get promoted, or move to new projects.
The lack of knowledge management can point to poor product and process quality, lack of team building techniques, weak documentation, and low-quality solutions or code. In fact, there's no upside to being called at 2 AM on a Saturday because you're the only one who knows how the system works.
In today's environment, hoarding knowledge ends up eroding your power. If you know something very important, the way to gain power is actually by sharing it. — Joseph Badaracco
Where Do All These Problems Point?
All of these problems converge on something that many people don't want to address directly: the lack of knowledge and maturity in software engineering and in the leadership skills of the bosses and leaders within the organization.
"Leadership ability is the lid that determines a person's level of effectiveness." — John C. Maxwell, The 21 Irrefutable Laws of Leadership
"The world needs leaders." — JB Carvalho
It's common, but not normal, for strategic positions to have more bosses than leaders. Most solutions for high performance in software engineering come from decisions or actions that are typically counterintuitive. And the question that remains is: who has the decision-making power to implement them? When these ideas, techniques, and principles are presented, they sound like "unicorns flying over rainbows," perfect in theory. But when it comes to practice, excuses always appear, when in reality what's missing is the knowledge and/or courage to apply them correctly.
Some companies today are hiring more technical people for strategic roles. However, the desired profile is extremely hard to find: someone who has technical depth, management knowledge, and people skills all at once. It really is very hard to find this complete package. You think you have all three, don't you? Of the three, the ability to lead, understand, and communicate with people is the hardest, and management is the easiest.
Proven Practices (That Are Hard to Implement)
I'll list some practices whose results and effectiveness are widely documented and that, for the technical community, are nothing new. However, when they are applied, their implementation usually falls short in most cases. The organizations that manage to implement them are considered Elite-level in the DORA assessment. Here are some of those practices:
- TDD (Test-Driven Development)
- Pair Programming
- Team Building
- Knowledge Sharing and Coaching
- Vertical, Domain-Oriented Teams
- End-to-End Autonomous Teams
- Small Daily Deliveries with Automation
- Testing in Production
- Openness to Failing Fast
- Safe Environments
- Culture of Learning and Continuous Improvement
These are, ultimately, some of the essential practices of Agile and DevOps.
Conclusion
At the end of this analysis, it becomes clear that high performance in development teams is not a fluke or the result of stacking senior talent. On the contrary, it is the direct reflection of sound strategic decisions, of governance that fosters autonomy, of well-defined team structures, and of a culture that values learning and sharing.
We've seen that the traps, from inadequate team formation and heavy-handed governance to a lack of focus on behaviors and resistance to knowledge sharing, are all symptoms of a larger problem: the shortage of leadership and maturity in strategic roles. Having "bosses" isn't enough. Today's landscape demands leaders who don't just deeply understand software engineering, but who also possess management skills and, crucially, the soft skills to guide and inspire people.
Proven practices like TDD, Pair Programming, Team Building, and creating safe environments with autonomy and a culture of learning are no secret. They are pillars of Agile and DevOps. Yet their effective implementation is where many organizations fail, whether due to lack of knowledge, courage, or the ability to challenge the status quo.
In short, the true transformation toward high performance in software engineering lies in the courage to change the leadership mindset and in the willingness to invest in a culture that empowers, trusts, and inspires its teams. Only then will it be possible to reap the benefits of teams that are truly efficient, innovative, and, above all, human.
