I was listening to Seth Godin’s book, Tribes, this morning. Again. As usual, some things struck me that hadn’t previously. One is that Seth describes where I am on my path on recovering curiosity when he writes, “It’s easy to underestimate how difficult it is for someone to become curious. For seven, ten, or even fifteen years of school you are required not to be curious. Over and over and over again the curious are punished. I don’t think it’s a matter of saying a magic word, ‘BOOM,’ and suddenly something happens and you’re curious. It’s more about a five or ten or fifteen year process where you start finding your voice and finally, you begin to realize that the safest thing you can do feels risky and the riskiest thing you can do is play it safe. Once recognized, the quiet yet persistent voice of curiosity doesn’t go away. Ever. And perhaps, it’s such curiosity that will lead us to distinguish our own greatness from the mediocrity that stares us in the face.”

So, the source of my new fears are explained and the promise is made; I just have to keep leaning in.

I just had the coolest job interview! I know, that’s as unexpected as hearing, “I just had the coolest root-canal.” It’s astonishing and it’s true. And it’s all thanks to a group of people who have made interesting and human a process that others typically make boring and impersonal. These remarkable people constitute an even more remarkable company called Menlo Innovations. Making interviews simultaneously fun and effective is only one of the many unusual capabilities I’ve learned about in my two visits to what they call their Menlo Software Factory™.

My first visit was three years ago and it marks the beginning of a personal journey. I had just been appointed the manager of a software testing team that unbeknownst to me was stalled on the tracks of an oncoming train. The train was a set of software development practices and principles called “agile.” The software development organization of the company for whom I worked was beginning to introduce these new agile practices without including the project management and software testing organizations. Conflict was woven into the very fabric of this attempt at organizational change, but, gladly, there is a happy ending.

Fortunately, I’m the kind of guy who wants to understand all sides of a conflict, so I began investigating agile. My first encounter with agile was what would otherwise have been a typical project for us. The difference on this occasion was that in order to learn more about agile, the development team chose to outsource the development of this product to a company that specialized in the agile approach. It went badly and ended with lawyers from each company “resolving” the problem.

This initial brush with agile left me with an unrepresentative, poor first impression of the agile process and its potential to be advantageous to our company. During the doomed project, I heard about Menlo and the tours they regularly conduct. I attended one and was impressed by the model they had built. It’s designed for Menlo’s business model, which is one of the reasons for its success. That fact also formed my reasoning about why it wouldn’t work for us: we had a different model, so it certainly wouldn’t work without modification and ultimately might not work even if modified. It turns out that I was right, but for a different reason; the culture at the business is more important to agile adoption than the business model. It took me a while to understand this. Meanwhile I learned more about agile; my impressions were improving and my opinion was changing.

During this discovery period, the conflict between the testers and developers continued to escalate. It was a dark period for everyone involved—the very opposite of how software development was supposed to be under agile. It was then that I realized I had moved far from my initial, misinformed skepticism to embrace and ideally apply agile. I became dedicated to bridging differences in an effort to better our working relationships, our software development process, and the company as a whole. This had to be an improvement over the fighting; we were wasting time and effort.

By this time I had learned a great deal more about agile and its related practices—enough to realize that what we were doing wasn’t actually agile. It was “cowboy coding” under the guise of agile. My new plan was to develop an agile testing practice in the hope we could steer the developers onto the agile path. That plan was recently foiled when my job was eliminated, as I did not have the opportunity to present and put into practice my ideas.

So now I’m sold on agile—what’s called an “agilist”. An underemployed agilist with few options. There are only a handful of companies doing agile development and only one or two of those has it down. As fortune would have it, Menlo is looking for more people and I was invited to interview.

As I’ve alluded to, interviewing at Menlo is very different. In fact, there’s a white-paper describing their first experiment with the approach. Many of the differences stem from a set of software development practices that preceded agile, called “extreme programming,” or XP: pairing, timeboxing, and frequent communication.

Pairing in programming is having two (or more) developers sitting at the same computer writing code and talking about the problem domain and their solutions. Pairing is central to Menlo’s approach to software development. Pairing was central to the interview process as well. In each of the exercises, the candidates were paired with another candidate and a Menlo observer (mine were Lisamarie, Thomas, and Megan). In this way, they could see how each of us would work when paired.

My interview partners were Joan, a mom returning to work (she had previously been in the legal field and had a mathematics and computer science degree); Bo, a new university student hoping for an internship; and Greg, a student finishing his (non-computing) degree. It’s interesting to me that the students are not the typical sort who would be looking for a job in software development. I think they were attracted because Menlo emphasizes the human aspects of a career with passionless computers and software.

I enjoyed the pairing. It was exciting to work with people of diverse backgrounds and challenging to do so after having just met them. Each of my partners seemed nervous, so I injected some humor to help put us all at ease. Interestingly, I made each of the observers laugh and none of my interview partners. That’s not important because I’m funny. It’s important because the people at Menlo are fun. All of them. It’s a side-effect of the culture.

In retrospect, I wonder how many people would be good at pairing if they had a little experience to get them started, but are at a loss for how to begin. Perhaps pairing with one of the Menlo team for the first exercise would produce better results.

Timeboxing is the practice of dividing a project into chunks, each with a small set of deliverables and a short duration. In agile, the product of each timebox is a releasable product. This results in features reaching customers sooner. Timeboxing was employed in the interview process too. Each of the three exercises we were given was limited to 20 minutes duration.

The exercises—ranking the importance of XP practices and principles, release planning, and resource planning—weren’t difficult and the people at Menlo know they’re not what’s really important. What’s hard and important is each of us being the catalyst for bringing out the best in everyone else. That’s what they test for and it’s hard to do, not because it’s unnatural, but because it’s unusual.

Timeboxing was completely comfortable for me because I’ve been using something similar called the “pomodoro” technique. A pomodoro is a 25 minute period of time focused on only one task (it’s also a tomato, but that’s a different story). The concentrated period is followed by a brief break—usually 5 minutes—then another pomodoro consisting of the next most important task.

Frequent communication is also central to XP and extreme interviewing. Each exercise was punctuated with communication. This kept us all on track and quite entertained.

I left the interview feeling excited and refreshed. This is the result that other organizations hear about Menlo. Representatives of these companies tour Menlo to copy what they’ve done, but that misses the point. As in mindfullness, what’s going on at Menlo isn’t so much about the doing; it’s about being.

You see, touring Menlo is like touring a Tibeten monastery—without the earthen floors, incense, and chanting. It’s fascinating because the practices and results are so alien to us. Like tourists, I suspect that’s where the sensing ends for most visitors and that’s why there aren’t more Menlos. People try to duplicate what the Menlonian’s accomplish by mimicing what they do, as if one could cultivate the equanimity of the Buddhists by tearing up one’s flooring, burning giftshop incense, and chanting. What’s going on there is below the surface.

Just as in my first visit to Menlo, I was changed by this one too. Perhaps the best way to explain the change is to tell you how my answer to a certain question changed. At the bottom of the page of questions I answered at the beginning of the interview was their version of the classic interview question, “So, tell me about yourself.” I wrote, “I’m an agile manager of techie people.” Learning some of the secrets of the Menlovians taught me more about myself too. My answer to that question now is, “I’m just a guy who likes helping fun people build great software.”

I’m between jobs now. The firm I was with just cut about 30 more positions and mine was among them. So, I just polished up my Manager-Tools resume and realized that I hadn’t shared the template I created for Apple Pages. Here’s the template which I make available at no cost and with no warranty (expressed nor implied, as they say).

I started working through the Django 1.1.1 tutorial and promptly ran into the following error:

ImportError: No module named django.core.management

I was trying to execute the following command from the mysite project directory:

./manage.py --version

I’m using python 2.5 on Mac OS X, 10.6.2 (Snow Leopard) because I’m learning Django to use in conjunction with Google App Engine.
The first change I made was to set an alias so that python 2.5 is used. The second was to move /Library/Python/2.5/site-packages to the beginning of PYTHONPATH. I made these changes by adding two lines to my .profile:

export PYTHONPATH="/Library/Python/2.5/site-packages:$PYTHONPATH"
alias python=python2.5

I started my next project. Actually, it’s a BHAG—big, hairy, audacious goal. I’m building a source-based genealogy application. It will be an Internet application, so your operating system of choice is irrelevant. Here’s my concise description:

An Internet application for recording, analyzing, and presenting chains of genealogical evidence and the lineages they document.

I’m calling it Lineascope™.

I’ve been reading Mihaly Csikszentmihalyi’s book, Flow: The Psychology of Optimal Experience. Many ideas in the book resonate with me. This one I encountered last night is a good example:

“When experience is intrisically rewarding life is justified in the present, rather than being held hostage to a hypothetical future gain.”

It connected for me because I’ve been thinking about unschooling lately and I think the truth of his statement helps to explain why unschooling is natural and compulsory education is unnatural. When learning is intrinsically rewarding, life is justified in the present. When learning is compulsory, life is held hostage to another’s desired future.

My son has been enjoying the Go, Diego, Go series over the past  couple of months. For the uninitiated, Diego and his sister Alicia are animal scientists who rescue animals. Logan likes playing animal rescue missions and has recruited his sister Paige.  He can often be heard saying, “I’m Diego and she’s Alicia.”

A New Name

Over the last couple of weeks Logan began correcting us when we called him by his given name, telling us, “I’m Diego.” This, even when he was doing things other than playing animal rescue. My wife took this in stride, going along with his desire for us to refer to him as “Diego” and his sister as “Alicia.” I, on the other hand, was typically reluctant; clinging unconsciously to the set of illusions I call reality.

I was happy to go along while a game of pretend was apparent. It was during the remainder of the time that I stubbornly referred to him as “Logan.” This past weekend it occurred to me during one of those times that I was the only person calling him “Logan,” that an examination of my reluctance was in order.

My Problem

The first problem I had with him wanting to be called “Diego” was: would it harm his sense of identity? Would he cease being called “Logan?” What’s wrong with being called “Logan” anyway? That last question clued me into another of my issues. I had my ego wrapped up in the name.

Carrie and I had spent hours deciding on a short list of names for our then unborn boy. The problem wasn’t paring down a long list—it was finding names we both thought suitable. As it turned out, we had not needed to pre-select a name. It was only upon seeing him that we would know what we wanted to call him. “Logan” was the name we both felt fit him. We needed only to prepare our minds with names we liked and that passed the, “How might other children abuse the name?” test. So “Logan” it was, and now it’s “Diego.” I’ve been working on my issues with Diego’s choice by applying two of my guiding principles.

Principle One: Intrinsic Value

The first is respecting intrinsic value. I believe all beings have equal intrinsic value and therefore are due equivalent respect. I am no more or less than a child or any other being. Just as my choice of what names I respond to is mine, my son’s choice is his. Applying this principle, if he wants to be called “Diego,” I must respect that.

Principle Two: Reject Fear

The second principle I’ve applied is reducing fear-based choices. I do this by identifying fear-based thinking, examining the underlying fears, and reframing to eliminate fear as a factor in making choices. I’ve identified the fear-based thinking in this situation. I was afraid of his pretending to be someone else. My underlying fear was that he wouldn’t develop a healthy sense of self and purpose. The reframe I have applied is one I have found is often helpful with fear: fear reframed as experiencing the limits of our ability to control. I trust children to develop themselves under their own direction. And it frightens me, not because I have incomplete trust, but because I know that I have no control over it (being stripped of illusion is scary). I now see my lack of control and I’m okay because I trust the process and know my part is to provide resources for my children to use in their development and to keep my mental baggage out of their way. Carrying out my part is the only way I know of to affect the process and its product for the better.

My son Logan and I have been playing a game called HarborMaster on my iPhone lately. In the game, the player controls the incoming and outgoing ships in a harbor. One guides ships into docks, which are sometimes color coded, and back out to open water after their cargo is unloaded. The goal is to get as many units of cargo unloaded as possible before any of the ships, which arrive at an ever increasing rate, collide. Logan has other ideas.

The Boy Likes Crashing

He tries to direct the ships into the rocky shore or the beach, into the mismatched docks, and into each other. He’s not gotten more than 7 cargo units unloaded in a game even though he undersands the mechanics. I know he does because his collisions and attempts to run the ships aground are carefully executed. These short games wouldn’t be a problem except that we take turns playing and my games take much longer than his.

I Like Order

To my surprise, he doesn’t seem to mind, but it bothered me. I pointed out to him that his turns would last longer if he would stop crashing the ships. Unconcerned, he said, “Sometimes I like my turns little.” Getting frustrated, I said, “But, that’s not how the game is supposed to be played.” This bit of “wisdom” was met with silence. Fortunately, I’m practicing the skill of quickly identifying when I feel frustrated then examining the causes.

Then I Looked Inside

When I explored my frustration this time I discovered that my reaction was tied into my sense of right and wrong. It was bothering me that he was deliberately trying to scuttle the ships. I let go of my desire for him to play my way.

It’s About Exploration, Not Competition

As I thought about this later, I had an important realization. I had blurred the line between fantasy and reality. There is nothing wrong with crashing ships in a game. I realized the point of the game for Logan is to explore it–to learn–not to compete, as I thought. That’s how young children view everything. It’s funny how young children intuitively understand this and we forget it as adults. This is a great example of one of the gifts that comes from being with kids: discovering what parts of ourselves to nurture to become whole again.