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.”