I've worked solo, and in teams, for many years now, and in many different organisations. Yet I still feel dissatisified somehow.

While I enjoy working alone -- especially when I'm in the zone -- I have to acknowledge that individuals working alone in my organisations have produced some pretty quirky and unmaintainable code over the years. At least, that's what I've seen.

Moreover, I write better and more relevant code not when working solo, but when receiving regular feedback from others.

Sadly, I've found that working closely with others can be difficult and stressful, especially when personality clashes arise. The tragic human condition -- as I'm reminded every day when reading the news -- is that there are so many factors that can cause conflict in teams: gender, politics, religion, baby boomers vs generation-y, introvert versus extrovert, perl vs java, the list goes on and on.

Pair Programming

One of the drawbacks of being chosen to lead humanity's push to become an interplanetary species is having to give up your privacy. "You could hear everything else that happened in the dome, and they could hear you," Ms Johnston recounted.

-- What it's like to spend a year pretending to live on Mars (news article)

I've tried pair programming eight hours a day and hated it. Like the budding Mars astronauts, I discovered how much I value my privacy.

High Performing Teams

Despite my unfortunate pair programming experiences, I acknowledge the crucial importance of teamwork and effective teams. Though I've rarely experienced it personally, I know that the elusive harmonious, high performing team is certainly possible. How best to achieve it?

According to a recent gTeams study at Google the five keys to a successful team are:

• Psychological safety: Can we take risks on this team without feeling insecure or embarrassed?
• Dependability: Can we count on each other to do high quality work on time?
• Structure & clarity: Are goals, roles, and execution plans on our team clear? Do we have an effective decision-making process?
• Meaning of work: Are we working on something that is personally important for each of us?
• Impact of work: Do we fundamentally believe that the work we're doing matters?

Some ideas you might try from the Google study to improve teamwork:

• Google's gTeams exercise: a 10-minute pulse-check on the five dynamics above, a report that summarizes how the team is doing, a live in-person conversation to discuss the results, and tailored developmental resources to help teams improve.
• Google found that teams who adopted a "new group norm" improved more than other teams. An example of a new group norm is "Kick off every team meeting by sharing a risk you took in the previous week".

Feedback

I'd love to hear of your experiences. What's been your workplace experiences, both working solo, and in a team? Which do you prefer? I'm especially interested to learn what you feel is the key to working in an effective team.

References

• The five keys to a successful Google team
• Guide: Understand team effectiveness (more detail on Google's research on teams)
• Team Effectiveness Discussion Guide (google doc)
• Manager Actions for Psychological Safety (google doc)
• Fun retrospectives
• High-performance teams (wikipedia)
• Pair programming (wikipedia)
• Maker's Schedule, Manager's Schedule by Paul Graham
• Work Groups and Teams in Organizations by Kozlowski (Michigan State University) and Bell (Cornell University)

• Nobody Expects the Agile Imposition (Part IV): Teamwork
• Nobody Expects the Agile Imposition (Part III): People
• Nobody Expects the Agile Imposition (Part VII): Metrics
• Why Create Coding Standards and Perform Code Reviews?

References Added Later

• Conflict in Teams (follow on node to this one)
• Re: Working Solo and in a Team (Psychological Safety) (see this reply below)

• Top 12 things that destroy developer productivity (from anaxi.com collaboration hub)
• Engineering Productivity (from medium.com)
• Re^2: On Interviewing and Interview Questions (Beware of a guy in a room)
• Re: Google considers Perl a useful skill by hv (2022, code review too late)