In some of the Tech Lead courses I have held, we sometimes talk about leadership styles and whether or not the Tech Lead role is essential. During these discussions, one of the biggest influences on both style and necessity is the style of teams.
This article represents my current classification of teams I have seen over my years in industry.
One man army
A lonely developer working on a project by themselves. Most likely they are working on multiple projects and consequently multi-tasking, because that’s the way the organisation works. Often seen in organisations that are siloed. Technically not a team but treated as a part of a team.
Distributed teams come in many shapes and sizes. Although distributed teams are similar to Off-Shore teams (see below), distributed teams tend to be a team spanning several locations. GitHub are an example of a distributed team (and organisation). Often seen with start-ups who are seeking talent not easily found in the same location.
A distributed team typically spans several timezone, making an “all-hands” meeting more difficult. Relies on asynchronous tooling such as chat software (e.g. IRC, Slack) and virtual task boards.
An Off-Shore team is a distributed team in mainly two locations. Often used by many IT organisations as a “cost-cutting” tactic trading communication effectiveness. Sometimes an off-shore team is a historical artifact (company acquisition or expansion) and necessary to keep essential knowledge alive.
Off-shore teams often have better overlap with time zones that fully distributed teams, but often results in an us-and-them mentality.
The “Pod” shaped team
The “Pod” shaped team is a co-located team who that has most of the skills they need to deliver a project. The team often includes a PM, developers, analysts, testers and sometimes operation and support people. They are all working towards the same project at the same time. This reduces co-ordination and communication lag and makes software delivery more effective.
They are called a “pod” because they are kept to a certain size (typically less than 12 people) to keep communication overhead minimised.
Functional silos are not representative of effective teams because people are grouped managerially and physically by skillset instead of by goal. Each group is managed by a separate person and in larger company, decision making and authority reaches several layers much higher into the organisational hierarchy. Collaborating and changing the way that a team working on the same project across functional silos becomes very difficult to change.
Typical functional silos often seen: PM (and their PMO), Analysis, Developers, QA, DBA, System Administrators, Network and Support.