The title of this column is taken from a well-known Zen story about a master instructing a journeyman. The journeyman was full of knowledge and continually interrupted the master, going on about how he was taught and what he himself had mastered. After a time, the master invited the journeyman to tea. The journeyman was flattered and eagerly accepted the invitation. As the master performed the ritual tea ceremony, he began filling the journeyman's cup. But the journeyman noticed that he was filling it past the usual amount. The master continued pouring and soon the journeyman's cup was overflowing. The journeyman rose to his feet, incredulous. The master put down the teapot, looked at the journeyman, and asked him, "If you come to me with a cup that is already full, how can you expect me to give you something to drink?"
A Tale of Two Consultants
Technology consultants Carl and Andrew joined a team of software engineers with a client in Chicago. The team's project manager introduced the Agile process to the team at the project's kickoff meeting.
Carl, being a loud, passionate man, grew agitated and quickly made it clear to everyone that he didn't know anything about the Agile process. The more subdued Andrew, on the other hand, went along with the process explanation quite agreeably, even nodding at the appropriate times. When the meeting adjourned, the team separated into pairs to work on the various high-priority tasks. Andrew and Carl were paired with engineers Mark and Doug.
Carl began asking questions about how to proceed, and it appeared that his defensiveness about the unfamiliar process had mostly dissipated. As Doug modeled some of the standard Agile development practices, Carl followed with a mix of curiosity and incredulity. He interrupted often with long diatribes about the current system and "the way things really are," steering the focus toward the familiar.
As Andrew and Mark began working on their task, Mark asked Andrew if he was familiar with Agile. Andrew assured Mark that he'd read about Agile, had tried some of the practices, and mostly understood how the processes work. Mark relied heavily on Agile practices while leading the task, and Andrew followed along with little resistance.
Mark and Doug later discussed what it was like to work with Andrew and Carl. They worried that Carl's strong personality and ignorance of the Agile process might subvert its introduction, and that he might attempt to discredit the process by dominating the team. Andrew, on the other hand, wasn't much of a concern. Though it was clear that he didn't know as much about Agile as he claimed, he wasn't visibly resisting it.
A week later, the pairs shuffled. Mark, now working with Carl, continued to rely heavily on Agile practices. Carl's sense of curiosity had grown, but he interrupted less frequently. By the end of his time with Mark, it was clear that Carl's understanding of some of the Agile practices was deepening. There was even an air of excitement in his interchanges with Mark, as he witnessed the power of taking small steps and using mock objects, with a focus on implementing one class at a time.
Now working with Doug, Andrew continued to submit to the process and practices, but made it clear that he doubted their value.
A month later, Carl had wholeheartedly embraced the Agile process and taught other teammates what he'd learned. Andrew, on the other hand, had rolled off the team, maintaining a dubious position on the Agile process.
The Moral of the Tale: Staying Good or Becoming Great
There are many aspects of Carl's and Andrew's personalities and experiences that played into how they reacted to new ways of working; one is how they handled their ignorance. By feigning competence, Andrew closed himself to new knowledge. As a consultant, he may have done this because the client was paying a hefty hourly rate and expected him to know what he was doing from day one. Yet he was far less effective than Carl, who exposed his ignorance from the outset and was therefore in a much better position to learn.
This approach to learning is not an easy process, and exposing your ignorance can be risky, but the ability to stay open to new ways of thinking by accepting your limitations is what sets great developers apart from good developers.
