The digital age is disrupting every industry. Business leaders understand the need to make technology part of their core strategy and recruit the talent that will make it happen. The rhetoric is very much do-or-die; adapt or fall behind the technology curve and into uncompetitiveness.

Those recognizing the need to act have already begun the scramble for technical resources and engaged in the so called “war on talent”. But securing technical talent is only a good start — not a victory in itself. Modern software development at scale is all about how well individuals collaborate. This is where the war will be won or lost.

Collaboration, however, comes in many forms. The kind of interactions that result in truly innovative solutions are not of the ordinary, genial kind that co-workers typically engage in. The best solutions are born of ideas generated through intense, energized discussions, and executed by capable individuals, carefully coordinating their efforts.

Thus, if first-class collaboration is the means through which we arrive at innovative solutions, all efforts should be made to ensure talented individuals find themselves in teams — real teams.

The ubiquitous “team”

In the business world, “teams” are everywhere. Co-workers and groups need not earn the label through achievement, performance or effort, but instead acquire it by default. Such “teams” are easily identified by their adequate results, half-hearted attempts to meet deadlines, lack of accountability and general mediocrity. In these pseudo- or non-teams the desire to keep stress levels low and interactions polite and cordial come at that expense of ambition and real achievement. The potential for talent to create, innovate, disrupt and exceed expectations is lost as individual performance levels average down to the mean.

Non-teams often proliferate in an organization to the point where low to modest performance levels are the norm. Management become so accustomed to this that they no longer know what real teams are, or that it’s in their interest to foster them. Many believe they already have teams because that’s what they call them.

Real teams are different

Unfortunately, a real team cannot be declared into existence. Co-workers that carry out work in close proximity of one another are not by default a team. Nor do they become one simply because they are assigned to the same project or task. A team will not automatically emerge from a group just because the individuals are smart or talented. Teams do not form overnight or after a day of “team building”. They cannot be created by management frameworks or elaborate software.

Real teams only form when individuals with complementary skill sets come together to create genuine dependencies on one another; when high levels of internal trust exist between team members; when mission goals are clear and in focus; and when individuals care about the team more than their own personal objectives. These qualities are forged in the heat of battle and over long periods of time spent together. There are no shortcuts.

Real software development teams

Professional software development in a business context is a serious game. Reputations, jobs, and sometimes entire organizations have been lost to software projects gone wrong. Truly successful outcomes are notoriously hard to come by. Even projects considered to have delivered value rarely tell the story of the hardships and struggles along the way.

The pressures are real and so must the teams be.

Teams are real

There is no basis for performance in a team that is not a real one. Software development teams are no different and must be real.

Teams persist

There is a cost to forming and dismantling teams. A real team needs time to gel before they can perform. Members of real teams will have worked with one another for many months or years on several projects. They want to remain together as a team.

Small in size

Communication is at its most efficient when teams are small. The most effective software development teams number from three to five developers and one or two business analysts depending on the complexity of the domain and size of the project. Though teams are supported (by other teams), the “core” team is the real team.

Set the selection bar high

Real teams will insist on choosing their own members and select based on skills and fit. They are looking for fellow professionals that they can count on rather than friends. New members are generally treated with a healthy skepticism until they have proven their worth and reliability.

Eject non-performers

Politely tolerating or working around a team member’s shortcomings is a trait of non-teams, not real teams. In real teams, inadequacies that persist are addressed and eliminated. If they cannot be fixed then these members are removed from the team. A team with a high attrition rate coupled with poor performance is a sure sign of a dysfunctional team but real teams that eject substandard performing members are not to be confused with this.

Communication excellence

Software developers are not best known for their communication skills, but real teams have good communicators across the board. Software developers that cannot express their intentions verbally, to both technical and non-technical people alike, write code that is equally unclear.

Team members interact frequently and outside artificial constructs designed to facilitate communication, such as planned meetings or time-boxed speaking sessions. Such constructs are wholly unnecessary in a real team and seen as a waste of time.

Mutual respect

When teammates have spent time together, internal communication gets stripped of all redundancy to the point where outsiders find it hard to follow. They may even perceive interactions as impolite or unfriendly but this is not the case. When a base level of respect between team members has been firmly established, polite interactions are abandoned in favor of efficient and honest ones.

Established way of working

“Agile” is not a way of working. Nor is Scrum. Real teams have no need to copy wholesale the management frameworks and methodologies designed to be accessible for the masses. Rather, they cherry-pick the best ideas and select only the processes and tools that contribute to better performance. They have typically gone through many process adaptations and iterations, experimenting with what works best and discarding what is of no use. All members have internalized the standard operating procedures, allowing them to work together with maximum efficiency and minimal confusion.

Recoil at traditional management

Real software development teams show resistance to any form of micro-management and indeed to most forms of traditional management even if it is considered “lightweight”. This is because there is little to gain (and much to lose) from attempting to control technical experts doing creative work. They operate under the assumption that they are hired for their expertise and because they know best how to do their job.

Guidance, facilitation, and support, however, is necessary and appreciated by real teams.

No nine to five

Some semblance of routine is no bad thing, but real teams understand that creativity and innovation are unpredictable and unlikely to slot nicely into the hours of nine to five. Instead, they do what’s necessary, when necessary. They will take any opportunity to maximize developer “flow” no matter the time of day.

However, working hard and long hours are not the means by which real teams measure success. The focus is entirely on results. The faster they can achieve results — all other factors being equal — the better.

Anchored to the real world

Real teams want to understand how what they do impacts the real world. This gives them purpose, direction and the motivation to perform. They will typically be highly inquisitive and continually seek to know more about the context within which they are operating. They are conscious of becoming trapped in implementation bubbles — building the wrong thing to perfection — or otherwise becoming unmoored from the purpose of the mission.

Shielding developers from the business so they can concentrate on technical things is a common management approach. It is also precisely the wrong strategy for real teams. Real teams must be fully exposed business pressures so that they can make appropriate decisions, balancing engineering and architectural purity against pragmatic solutions.

Strong leadership

In most cases a single, strong leader will emerge in a lead-developer or technical-lead role. This person is there to set the tone for the team, the standards to which they adhere to, and the general norms of behavior. The “best” or most technically gifted member of the team does not become the leader by default, nor does the oldest of longest standing member.

Sometimes the level of experience in the team is such that leadership is rotated. In any case, all members of a real team have the ability to lead and be lead.

Value a sophisticated customer

Real teams pay attention to the details. The intricacies and nuances of a solution matter to them and they expect their customer to be equally discerning. They like a customer that is highly engaged and confident enough to be challenged on every aspect of the build. Real teams will push back on requirements that they don’t understand or that might have a detrimental effect on the system as a whole. They point out when they think the time and effort to build a feature doesn’t offer value accordingly. Real teams do not appreciate working for customers that do not care or ones that accept sub-standard or run-of-the-mill work.

Unnerve weak managers

Management more accustomed to command-and-control styles that find themselves unable to direct, plan and track in the traditional way are unnerved by real teams. Some even worry that they have nothing to do or fear they will be considered obsolete. While this is actually not the case — teams always need guidance, information, facilitation, etc. — it is often a sign that a real team is in operation when management feel this way.

Teams that operate autonomously require management only to provide context and solve problems that are genuinely beyond the power of the team to solve. Managers of real teams are able to focus their attention on other parts of the organization that need it most. Good managers love real teams.

Seek out performance

Performance is not about some notion of speed, velocity or even efficiency per se. It does not translate into more lines of code or a proliferation of features. Most of the time the opposite is true. Real teams define performance by the extent to which they deliver customer satisfaction and business value. They drill down to the essence of what is needed and build only enough to fulfill that need. Nonetheless, a likely consequence of teams striving for high performance is that they deliver software at a faster pace and with better quality when compared with non-teams.

Thrive on pressure

The most rewarding challenges are the ones that have something at stake. Whether it’s the intrinsic difficulty of the problem itself or external factors such as time constraints or strong competition, real teams come into their own when the pressure is on. Most real teams have gone through at least one experience together where the outcome was uncertain, the stakes were high, and extra effort was needed to succeed. These are the true bonding experiences that galvanize a team and ultimately make it real.