We'll see | Matt Zimmerman

The third day began with a discussion on personality types, based on the Myers-Briggs Type Indicator and Keirsey Temperament models. Over the years, I’ve taken a few different tests with some variation in the results, most commonly INTP with the occasional INTJ. With this data in mind, I hadn’t taken another test prior to the course, but then, the morning of the third day, I decided to take the short web-based one provided. To my surprise, it indicated a type of ISTJ! Although it reported that I was quite close to the border between S and N, I’ve never received an S result before. Since I was taking the test under atypical circumstances (on a trip to a new country, in an academic setting, etc.) I decided to disregard this unexpected result for the moment. I took the same test again just now, in a more typical setting at home, and received the same result.

We plotted the types of everyone in the class, which curiously turned out to be very heavily biased toward N (intuition) over S (sensing). I wondered if this was typical for a roomful of software folk, but this was not the case for previous PSL workshops. We discussed personality types with regard to teams and roles, and what people of different types contribute to group problem solving.

One idea which stuck was that people have different communication preferences, and that it can make a tremendous difference to account for this in formulating a message. For example, N types are said more readily digest general principles when presented explicitly, while S types fare better with facts and examples which illustrate them. When addressing an N one-to-one, it might be better to clearly illustrate concepts than to provide a lot of data. In a group setting, it’s a good idea to present the information in multiple ways, such as a principle followed by some examples (as in this paragraph). As usual, Jerry was armed with powerful examples in the form of his own stories.

The rest of the day was taken up by an exercise which simulated a multi-level organization. This was one of the highlights of the week for me, as I found it an extremely rich learning experience, from the selection of a leader through the final debriefing. I volunteered to be a candidate “CEO”, which was atypical for me, as I tend to avoid being the center of attention in such circumstances. I had reflected on this earlier in the week, as the workshop included some guided writing in a journal. I was concerned this would limit my opportunities to learn in this setting. Because of this, I consciously chose to depart from this pattern and try something different, and was very glad that I did.

During the simulation, the room seemed so much larger, as we organized ourselves and information was accumulated unevenly by different people and teams in the “company”. I was surprised by its complexity, given the small scale (about 20 people and a few hours). We experienced stress, uncertainty, power struggles, even a threat of layoffs. The simulation was very clever, having clearly evolved and improved over time, and has already been a rich source of analogies in my work over the weeks which followed.

We concluded the day with a temperature reading, which provided a framework for the group to process their reactions to what had happened. Another gem from Virginia Satir, this technique does much more than assess status, as its name implies. It helps the group to connect emotionally, bringing them closer together through the shared experience of learning from what happened

Seen on a bus shelter in south London:

The second day began with an introduction to the MOI model (Motivation, Organization, Information), familiar from Becoming a Technical Leader.  We analyzed our actions from the previous day’s activity in terms of this model, which triggered a series of discussions about the actions we take as leaders and how they impact the team.  In particular, I remember talking about “organic” information flow in organizations (coffee breaks, lunchroom, smoke breaks, etc.) and how new members of a team assimilate the team culture.

One simple example of the latter is the difference between two ways of trying to spread a strong team’s culture to others: bringing an individual from elsewhere into the team, and separating members of the strong team to become part of other teams.  The former tends to result in the individual acquiring the knowledge and culture of the strong team (good), while the latter results in the loss of a strong team (bad).

We also discussed the Satir change model, and how it plays out in familiar scenarios, like adopting a new software development methodology.  A good tip for introducing a change was to start small, with the team most likely to succeed, and build on that success to spread the change further in the organization.  We talked about what managers need to do to support teams which are going through a change (for example, reduce pressure by adding more time to the schedule the first time through).  There was also a great deal of interesting discussion about technical reviews and retrospectives: how (not) to conduct them, how to decide what to review, and so on.

In my experience, the biggest obstacle to solving most problems is getting that first grip on it: if I can manage to define the problem well, and hold it consistently in mind for a period of time, solution ideas start to flow.  We are our own worst enemies where this challenge is concerned, and will invent ways to avoid accepting the problem and getting close to it.  Getting control over our own reactions is often the key, which Jerry encapsulated with an aphorism: “The problem is not the problem.  Coping with the problem is the problem.”

Later the same day, we took turns observing a group as they solved a problem: what they said, how they moved, the different actions taken by different people.  We then presented and interpreted this data as a group, which led to a rich discussion about how to assess what is going on in a team through observation.  Doing this well is difficult and requires much practice, but some techniques I found useful were:

• Watch the people who are not speaking, to see how they are reacting to the speaker
• Notice when questions are asked, and how the group responds (do they answer?)
• What happens when someone makes a joke?
• Focus on observing one type of behavior at a time (this is hard enough!)

We worked late into the evening, discussing problems faced by the group in their work and generating ideas for how to approach them.  I felt very curious, and was recording a steady stream of thoughts in my journal regarding my own work.

Read more: Day 3

Apparently, they are also makings spellings errors.

On the morning of the first day, we trickled into the classroom, which was laid out in parallel rows of desks facing the front.  One of the facilitators asked the group if this was how we would like to have the room laid out, and invited us to change it if not.  They seemed as interested as I was to see what how the group would behave in response.

After a quick ad hoc decision making process, the room was rearranged, and we all sat down again.  We were then guided through a discussion about what we had observed and how we responded to it: this pattern of experimentation and retrospective analysis set the tone for the remainder of the workshop, which was designed to provide opportunities for us to learn through shared experiences of working as a group.

Around this point, I began to notice the pace of the course.  We spent most of the first day getting organized: setting up the room, reviewing the schedule, self-organizing into teams, learning each other’s names, and so on. A particular question or observation in the class would remind Jerry of a lesson learned, and he would deliberately retell a story (or three) from his life and career. It seemed positively glacial at times compared to my day-to-day work at Canonical, which continually demands my attention for a vast array of tasks, information and problems, and seems to leave little time for analysis.

I realized, of course, that a more considered pace is much more conducive to learning and improvement because it permits reflection and organization of one’s thoughts and feelings—but I was not applying this very well in my work. Stepping outside of my established pattern of work made this easier to see, and this was to become one of a series of such insights, increasing in both depth and number throughout the week.

For our first small group exercise, we competed in teams of four to construct “houses of cards” which met various criteria. The analogies in this exercise were painfully clear to us from our software and consulting experience. Through the exercise, and reflections on it from myself and others, I learned a great deal about organizing teams in pursuit of a goal, such as:

• adapting approaches to fit the team and circumstances
• organization and prioritization (both in advance and in response to change)
• testing assumptions and constraints
• effective listening
• the effects of stress on teams
• gaining perspective on the work
• supporting continuous improvement

Some of the lessons were entirely new. Others involved the transformation of abstract principles into practical habits. All of them were applicable to my life and work, tailored for me through my individual experience of the course. The most valuable lessons were those which came to me through observing what happened around me and to me, and which were therefore written in my internal language, rather than in a textbook. Few ways of learning “stick” quite as well as reaching your own conclusion.

Read more: Day 2

I recently traveled to Sweden to attend Problem Solving Leadership, a recurring workshop which was first offered by Jerry Weinberg in 1974.  Having found Jerry’s books to be uniquely insightful into the nature and challenges of software teams, I had high expectations for this small workshop: 5.5 days with 24 attendees and 3 facilitators (Jerry Weinberg, Johanna Rothman and Esther Derby).

When I first arrived, I was curious to see what the other participants would be like.  PSL seems to be more regularly offered in the United States, and I wondered whether this one would attract mostly residents of Sweden, or a broader crowd from Europe or even further afield.  When the group assembled for drinks before dinner, it became clear that most of us were Swedish, and that quite a few of the participants were professional colleagues or knew one other through the local community.  Many seemed to be consultants helping software teams to implement agile development methodologies.

Over dinner, I got acquainted with some of the other participants who were seated near me.  We got our first taste of what the week would be like when someone announced that they had found a stray bag and had placed it in a certain place to be claimed.  In response, Jerry addressed the room from his seat at one of the banquet tables, pointing out that this individual, in trying to help, was taking responsibility for a problem which could have been more effectively solved by simply turning the bag over to the hotel staff.  The manner in which he understood the pattern of the situation and presented it as a learning experience was familiar to me from his books, though there was an edge to it which I had not expected.

I went to bed feeling curious about what the rest of the week would be like.

Read more: Day 1