BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News A Brief History of High-Performing Teams by Jessica Kerr

A Brief History of High-Performing Teams by Jessica Kerr

Bookmarks

If you're looking for an early example of a high-performing, agile team, then study the Florentine Camerata, a group formed in Florence, Italy, around 1580 that reformed their contemporary music with the creation of opera. Their gatherings were more like a meetup than a formal team, and embodied the definition of cross-functional, including musicians, artists, poets, astrologers, philosophers, and scientists. The lessons of the camerata were the subject of Jessica Kerr's keynote presentation at Explore DDD 2018.

The camerata believed the best way to reform the polyphonic music of the day was to renovate the ancient Greek practice of setting words to music. While they didn't actually have any recordings of Greek music, this concept lent legitimacy to their work, much like modern software architects cite computer science papers from the 1970's. The group also behaved as more than simply an open forum for discussion. Rivalry between sponsors caused disagreement between musical styles. Ideas were challenged and defended similar to a code review, with defenders and censors nominated for the occasion. The resulting outcome was the invention of opera, consisting of a single melody with a single representation of music.

If the story ended there, it probably wouldn't be the subject of a technical conference keynote. The real lesson comes from seeing how the invention of opera influenced all the members of the group, who went on to have interesting achievements as individuals. Kerr cited the article "Collective 'Problem-Solving' in the History of Music: The Case of the Camerata," written by Dr. Ruth Katz in the Journal of the History of Ideas.

This same effect of an individual benefiting from a group is observable throughout history, notably in scientific fields. While we like the simplicity of pinning a scientific discovery on one individual, this is rarely the case. Often overlooked are the others that person worked with, and who provided criticism. As an example, we credit Ben Franklin with the discovery of electricity, when he was really just one of dozens of early electricians. The "indivisible college" he belong to provided criticism to one another. Failure to have this community can mean that important ideas are lost. If no one understands your idea, how far is it going to go? A community that can advance the idea, tell others about it, and adopt it, is just as critical as who invented it.

Kerr highlighted several notable historical examples of the benefits of a collective. One member of the Club of Honest Whigs, which met in a London coffeehouse during the enlightenment, was Joseph Priestley. His discovery of oxygen led to the entire field of chemistry. The salons formed in Paris became breeding places for artistic creativity. These were places where artists, critics and dealers could meet, recognizing that they don't become great alone. These were not exclusive to artists, as one salon was run by Gertrude Stein, a writer, philosopher, and mathematician in her own regard. More recently, in the world of software, we can find examples such as ThoughtWorks London, from 2003-2006, where people including Jez Humble, Dave Farley, Dan North, Nat Pryce, and Sam Newman gathered, shared ideas, and went on to provide invaluable ideas that influence software development teams around the globe.

Great teams make great people

Kerr's major takeaway from all these examples is that "Great teams make great people." We always say we want to hire great people, when it's actually the other way around. If you're having trouble hiring productive developers, you're never going to find them. They aren't trained, especially not self-trained. Rather, they are a product of teams that learn together.

Kerr presented the term "Symmathesy," first proposed by Nora Bateson, derived from Sym, meaning together, and Mathesie, meaning learning. While originally coined to describe ecologic systems that are constantly changing, the term can be applied more generally. A system is not the sum of its parts – that would be an aggregate. Rather, the parts of a system are the sum of their past interactions.

Kerr argues that a software system is even more of a symmathesy than these historical examples. It's not simply the software team, but also includes the customers, as well as the running software, the database, the hardware, and all the tools the team uses. These parts all interact with each other and create mutual learning, making the team, and its members, grow and evolve.

Participating in such an environment requires showing up to work with your whole self, prepared to be part of the living system. Kerr says this is why adopting such a mindset is so hard. Beyond thinking about yourself or just your team, you have to think much more broadly, ab your organization, division or company as a whole, creating bridges to other teams where necessary. Because a symmathesy cannot exist without changing its environment, Kerr argues that you can't put a box around a team. The system requires people with influence and connections outside the team to be successful, resulting in symmathesies all the way up the organization. Because of the learning nature of all the parts of the system, Kerr says you cannot hire these people directly. Because your system is unique, and becoming more unique every day, you must hire for the potential to be influential to the system.

Kerr also discussed the importance of a team versus an individual with regards to reasoning about the model of a system. As individuals, doing the cognitive work to determine what needs to be changed in a piece of software is an exercise using our personal mental model of the software – the changes in the code are simply a byproduct. In reality, everyone's model is out of date, and incomplete, in different ways. A team is required because one person can't hold the entire model in their head. Because of the discrepancies between individual models, the team must collaborate to make sure the models overlap and are kept consistent. By doing so, a team can ensure the right change is made in the right place. Kerr admits that this state is harder for a team to acquire than you think it will be.

On a related note, Kerr said these incomplete models often lead to the idea of throwing something out and rewriting it. She said, "It is easier to build up a complex system from scratch, than to come to an existing complex system and figure out why it works," then joked that this explains why we have so many JavaScript frameworks.

Kerr said making a team successful requires looking at the incentives that motivate the team members. If you have a reward system based solely on individual developers, it will lead to a closed mindset. The worst thing you can do for a team is keep your ideas to yourself. Therefore, look for ways to maximize learning across the team, and find ways to give credit when mutual learning occurs. Because "the limit is not how much we can do – it's how much we know," Kerr loves mob programming, as it maximizes the learning taking place and brings all the mental models together.

Kerr wrapped up her presentation by returning to the Renaissance. Before the Renaissance, we did not have the concept of Art. Between 1200 - 1600 AD, the recognition of art evolved from just competence of vocational skills (and only those allowed by guilds) to a level of excellence (now taught in academies and cultured circles). The Renaissance was a period of decompartmentalization, breaking down the barriers that had kept thing in order, but also apart. The "new style" emphasized expressive qualities over beauty of design and craftsmanship.

Using the Renaissance as a guide, Kerr tried to classify software, starting with what she feels it is not.

Software is not a craft. Kerr doesn't consider herself a craftsperson, and programming is a skill. Software isn't about the code we write – it's the impact we have on the world.

Software is not an art. Software is changing our physical world all the time, in ways that art does not. Also, software is a different medium than we've ever worked in before.

Software is not engineering, nor any other "respected" profession from the past. It's something new.

Symmathecist in the medium of software

Kerr believes "software is the next thing after art." Ongoing software development is the practice of symmathesy, and a practitioner can be referred to as a "symmathecist in the medium of software." This idea doesn't belong to one person – it takes a community. We're all symmathecists, and this is the next age after the Renaissance.

Kerr has written more about the Origins of Opera and the Future of Programming on her blog. A recording of her keynote presentation is available on the Explore DDD YouTube channel.
 

Rate this Article

Adoption
Style

BT