How Socrates taught me to talk to developers

When it comes to "most valuable tools for untying mental knots and figuring things out," two items appear at the top of my list.

The first is this clip from Benny Hill about what happens when we make assumptions. I saw it on (the opposite of a flat-screen) TV as a child years ago, and still reflect on it several times weekly. Its message—operating by assumptions is unlikely to end well, so don't—hasn't failed me yet.

The second is the Socratic method, which has helped me reinforce the open organization values of transparency, collaboration and sharing in my work and related extracurricular activities—making work more fun and rewarding as a result.

As Benny Hill might point out, reinforcing those open values when we're making assumptions rather than operating on a foundation of facts and concrete information can be difficult. While we might intend to be open, fiction will motivate our actions if we're operating on assumptions. The Socratic method helps us to create a foundation for being collaborative, challenging, and open—truthfully.

What the Socratic method is

The University of Chicago Law School, where Barack Obama taught constitutional law until making a slight career change, describes the Socratic method as an inquiry practice based on "asking continual questions until a contradiction was exposed, thus proving the fallacy of the initial assumption." A catchier description, offered by this quick how-to for using the method with children, is "clarify, synthesize, restate."

Here's how it works: Typically, a "protagonist" presents some scenario or question for an audience (a group or individual) to consider. A series of ensuing questions then points toward gaining a clearer understanding of the issue at hand—its subtleties, potential angles, logic, and possibilities.

We have Greek philosopher Socrates to thank for this exercise. He left no known writings (talk about taking the Agile Manifesto's call for "working software over comprehensive documentation" to an extreme!), but did impress his students enough so that they carried forth his legacy. (Eventually he was executed for "corrupting the young," so he clearly made an impression on authorities, too.) Today, you'll find the method at work in law school classrooms (it was a go-to tool for my professors), though usually not delivered in much of an "open organization" way. Luckily, those of us working in open or agile organizations can apply the Socratic method without sneers, jeers, and GPA pressures.

Why use Socrates' method

Even in agile and open organizations, we can become vulnerable to entrenched thinking that closes us off to new opportunities and ideas. Some members of our team will be louder than others and dominate decision-making. Some practices will become guidelines or standards by habit, even if they're not the best practices. Myths will emerge over time: "It's how we've always done it," "we need permission," "Rockstar Ninja Dev-man doesn't like it, so we shouldn't," or "I can't." In the race to finish projects, we might overlook our open values and rely too heavily on tools to get the job done. We're human, and we're fallible.

The Socratic method offers us a way to stay faithful to open organization values. As agile trainer Scott Duncan shared with the Scrum Master Toolbox podcast, it emphasizes "asking people what they think about things rather than telling them what they ought to think." In this way, it keeps us from going into prescriptive mode. Instead, people and teams have the space and opportunity to draw conclusions by themselves, based on their own thoughts and motivations. They own the content of the conversation, while the person playing questioner/protagonist makes notes, listens carefully to what's being said, draws connections, and points out contradictions.

For team or project managers, the Socratic method provides an opportunity to act as a servant-leader; clarity of purpose is the goal. If you're striving for self-managed, autonomous teams, then this framework allows you to help others examine their thought and work patterns to find answers they've derived themselves.

Collaboration—meetings, brainstorming sessions, retrospectives—becomes less emotional and much more driven by consensus based on facts. Rockstar Ninja Dev-Man—who might be brilliant with code, but not much of a team player or objective thinker—will be humbled when faced with his own fallacies and contradictions. Socratic questioning might uncover that the least-experienced member of the team offers the most practical, well-reasoned solution, so it also levels the playing field.

Socratic techniques also increase transparency by knocking down myths, ghosts, and assumptions that separate teams from the "real issues," or prevent them from achieving goals. For example, if you work in a large and complex software development organization like I do, you might hear teams talk about being "blocked" by another team. Team A will complain that, before moving forward, Team B has to make some change to a repository; until then, it's nothing but cricket noises, sighs, maybe another round at the ping pong table. Resigned to having someone else fix their issue, Team A develops an attitude of learned helplessness. With some communication and coordination, they could InnerSource with Team B to get their change made faster, or apply Socratic methods themselves with Team B to uncover that, hey, maybe everyone waiting around for each other is not the most effective delivery method.

Socratic thinking points us toward how we might solve problems when we feel stuck looking at an issue as either possible or impossible. For example, when challenging their own blockers, Carbon Five used the Socratic method to assess those "blocked" development tasks and find alternative paths forward. They discovered many of their designated "blockers" were, as Wikipedia notes, "concepts that seem to lack any concrete definition." In many cases, "we can't" is a concept that lacks concrete definition; "we can't" … because why? According to whose rules? Are there any rules? Or are we setting up our own invisible walls and imaginary authority figures who will stop us from trying to solve this problem? Challenging perceptions with questions like these will help you to better assess whatever obstacles you're facing, judge whether those things are real or not, then tackle them differently.

And lastly, using the Socratic method can help people become more comfortable with failure. In Germany, where I live and work, the belief that failure is a big deal/sin/source of shame is still common enough for people to talk about it. My company has been countering this by creating opportunities to talk about failures as learning experiences, and integrating Site Reliability Engineering's "no blame" stance toward incidents. But adapting to changes, even positive ones, takes time. One-on-one's are the best approach for reducing the potential shame-damage for the person who's fearful of failure; in a personal conversation, the risks and visibility are low.

That's where the Socratic method shines.

How I Socratic method'ed

Recently I used the Socratic method with several developer-colleagues on my team. We're still in something of a "storming" phase, but heading toward norming. It's a great bunch of guys: Productive, accountable, humble, and experienced—software craftsmen all the way.

We've needed to work on our communications flow: How much, when, by whom, and to whom. We've talked about communications in retrospectives, planning meetings, team autonomy health checks, and elsewhere, but communications is a broad topic that relies heavily upon people's personalities and comfort levels. Perception of what's possible is also a strong influence: In my experience, many devs are better communicators than they give themselves credit for. With this in mind, I grabbed a whiteboard and a spare room and each dev joined me for an intense round of Socrates and mind-mapping.

The first dev-volunteer and I started our conversation with a blank board and no expectations. Perfect. He's somewhat reserved, so my only agenda was getting him talking. He started sharing ideas and thoughts—which he always does, but in the context of a one-on-one his words seemed more completely his own. We explored some of the why's and how's underlying his ideas: Why are we not doing now some of the things we'd like to do? How could we make this new idea happen? What or who could stop us from doing it? And on and on, like this, until we had a full board and something of a "ladder of related concepts" related to communications blockers, outcomes, and aspirations. The concepts we'd covered ranged from emotional to tactical: The word "fun" at the top, signifying what's possible, and an unhappy-face (what happens when we don't ask for help or what we need to avoid taking on too much of one thing we don't like) at the bottom, in a kind of whiteboard-dungeon.

I brought in the key concepts I covered with the first dev to subsequent one-on-one meetings, and there I asked what those concepts meant to new participants. Each developer brought his own views and defined them in different ways, which helped me to become better acquainted with their thought practices and motivations. Some concepts drew immediate responses that we then investigated, while other concepts seemed unfamiliar. Narratives formed; I used the whiteboard to point out related steps or ideas, ask them if they saw the connections or not, and drew lines (including dotted ones) to point out relationships or contradictions.

For example, one of the concepts I scribbled on the board was called "taking one for the team," which I explained as sacrificing oneself at a level that engenders burnout, boredom, isolation, or frustration. I intended to probe deeper into what happens when we don't say "no," enforce boundaries, and ask each other to help us. Would the devs draw the connections between this concept and our efforts to communicate more effectively? They did, while bringing their own personal values and beliefs into the discussion.

While my colleagues shared their thoughts, I detached and aimed to show no emotion. Instead, I listened and wrote things they said on the whiteboard. As the thoughts flowed, I treated every word as the truth in that moment—until I heard something vague or possibly contradictory. Then I'd prod a bit further, ask for clarification, and synthesize points. The whiteboard provided a record for contemplating and deriving conclusions. If I saw or heard a possible connection or contradiction, I'd point it out, but in the form of a question: "You said this here, but you've also said this opposite thing there. How do you reconcile the two?"

Each conversation took about an hour and a half, and each was different from the others because each developer set the direction himself. Had I set the agenda beyond introducing a few simple concepts, the day might have turned tedious and repetitive. Instead, I focused on staying calm, neutral, and observant. This was incredibly fun, and at the end of the last conversation I felt energized (as an extrovert predictably would). It was such a rigorous, open way to get to know my colleagues better and collaborate for solving our communication issues.

At the end of every conversation, I asked the guys for feedback. Maybe they were being polite, but the response was favorable. I don't attribute their demeanor to anything magical I did, however, but to the discovery and exploration made possible by the Socratic method.

Closing tips

Even if you're applying the Socratic method in a private chat, you still have to be mindful of your own part in the discussion and the signals you're communicating. Thinking back to our great teacher, Benny Hill: Don't assume that your team is limited in its abilities or has negative intentions. Becoming emotional about people's responses is another way to get knocked off the path to enlightenment; you're undermining your power and distracting from the goal if you do. Focus on your partners: Pay attention to words, pauses (silence communicates loads of information), gestures, and tone.

If you're planning to use the Socratic method yourself, remember:

• Don't assume that you have all of the answers. Leave room for yourself to be surprised and informed (after all, you're also a student).
• Stay neutral and supportive, so the other person or team feels like they can be wrong or experiment with their thoughts without being judged or reprimanded.
• Keep in mind that not everyone in your team or organization will be ready to undertake this method of inquiry (my colleagues were generous enough to be open to it; that we all shared both a great level of respect for each other and a commitment to the team helped as well). If your entire team isn't ready to try this approach, "pilot" it with one or two willing team members.
• Promise everyone you'll stay neutral, but first be confident you can uphold this promise. Guaranteeing—and then reneging on your promise of—a safe environment can be harmful to the exercise. As part of this bargain, be sure that your participants know that gossip or unconstructive criticism are off-limits.
• Reiterate that your goal is to gain clarity and awareness, to help the team or organization strengthen its foundation for future decision-making or actions.
• Time pressures might inhibit you from finding willing partners, and even one long conversation full of inspiring "aha!" moments won't bring about total enlightenment. Much of what you're unearthing in a Socratic dialogue involves someone's thought patterns, which are shaped over lifetimes and become habits. You might have to arrange regular, brief one-on-one meetings focused on a single question at a time, before the awareness sticks.

But, hey—don't take my word for all this. Try it for yourself. All I know is that I know nothing.

This article is part of The Open Organization Guide to IT culture change.