Teams
A team is a small group with complementary skills whose members share one goal and depend on each other’s work to reach it. That interdependence separates a team from people who merely share a manager.
Interdependence also makes a team expensive: it buys shared knowledge and pays in coordination. Thompson is careful — teams “can outperform the best member of the group, but there are no guarantees … Teams are not a panacea for organizations; they often fail and are frequently overused or poorly designed” [1] (p. 29).
Types of teams
Four shapes recur in software organisations:
- Problem-solving teams are convened around one issue and disband when it is fixed. Example: a group convened for six weeks to cut deployment from a day to an hour.
- Cross-functional teams put developers, designers and marketers under one objective, so hand-offs happen in the room, not between departments.
- Self-managed teams own their day-to-day work without a supervisor allocating it; a Scrum team running its own sprints is the everyday one.
- Virtual teams are spread across sites and time zones, coordinating through chat and shared boards.
What goes wrong
Most lists of team problems are folklore; there is a measured one. 192 practitioners rated 33 human challenges for frequency (0–4) and criticality (0–3) [2]. The top five by the product of the two:
| Rank | Challenge | Freq. | Crit. | Mitigated |
|---|---|---|---|---|
| 1 | Insufficient analysis at the start of a task | 2.43 | 2.07 | 46% |
| 2 | Lack of leadership | 2.21 | 1.91 | 39% |
| 3 | Missing documentation of the project | 2.59 | 1.59 | 49% |
| 4 | Demotivation | 2.04 | 1.92 | 37% |
| 5 | Information is not made known to the team | 2.06 | 1.86 | 38% |
Two readings matter more than the ranking. Organisations mitigate the challenges that blame nobody — missing documentation 49% — against conflicts of interest at management level 13%. And rare is not mild: missing respect, changing members and harassment sit in the bottom nine by impact, yet each carries a criticality median of 2, the same as the top-ranked challenge.
That study is descriptive, self-reported by one member per team and 75.5% Germany-based; its impact score is normalised, so do not quote it as a percentage.
Where to go next
| Page | The question it answers | Anchor evidence |
|---|---|---|
| Team Performance | Does a team beat its members working alone? | Steiner; Lindsjørn |
| Psychological Safety | What a safe team does more of, and how to produce it | Alami; Buvik |
| Formation | What to settle before the work starts, and how a team develops | Thompson; Tuckman |
| Motivation | What makes engineers want to do the work | Herzberg; Beecham |
| Social Loafing | Why effort per person falls as a team grows | Ringelmann |
Deciding has its own area: Decisions — half that material is about how one person judges rather than how a group does.
Acknowledgments
This page adapts material from lectures by Eduardo Miranda and David Root [3] on software project management.
References
- L. L. Thompson,Making the Team: A Guide for Managers, 5, Global. Pearson Education Limited, 2015.
- M. Hoffmann, D. Mendez, F. Fagerholm, and A. Luckhardt,“The Human Side of Software Engineering Teams: An Investigation of Contemporary Challenges,” 2021.
- D. Root,Managing Software Development. Carnegie Mellon University / Innopolis University lecture series, 2014.
Disclaimer: AI is used for text summarization, polishing and explaining. Authors have verified all facts and claims. In case of an error, feel free to file an issue.