Menlo Innovations is a privately held development firm that has garnered numerous awards as a result of its unique approach to designing, programming and delivering software projects; its unusual workplace; and its unfailing mission to spread joy among its employees and customers.

Richard Sheridan, Menlo Innovations’ founder and CEO, is an energetic entrepreneur who began writing code “professionally” before he could drive. He scored a full-time salaried position right out of high school, and while living at home with nothing else to spend his money on, decided to rekindle a deep childhood interest in aviation. He got his pilot license by the time he was 19. This “see and conquer” side to him led him to challenge the status quo when it came to forming his own development firm.

SD Times: Why did you model Menlo Innovations after Thomas Edison’s “Invention Factory”?
Richard Sheridan: I visited what was essentially the recreation of the Menlo Park, N.J. lab of Thomas Edison as a kid. It gave me goosebumps when I was 8 years old to think how this little energized room of a great team changed the world. I may not have been thinking about that when I was 8, but there was something electrifying about the atmosphere, and the goosebumps stuck with me.

Later, when I entered the work world, I became very quickly disillusioned because the career I thought I was going to have in software wasn’t happening. I began recalling those childhood memories and realized that was what I wanted to get back to.

You have a new book scheduled for release in mid-December. Tell me about “Joy, Inc.” your latest effort. What initially inspired you to write books?
“Joy, Inc.” is my first substantial book. The others were more team-oriented and evocative of Menlo directly as opposed to trying to bring a message about culture.

The first time I typed a line of code was in 1971. I was in high school. I typed in a two-line program, typed “Run” on a teletype hooked to a timesharing mini-computer, and this teletype typed back “Hi Rich,” because that’s what I told it to do. I was hooked. I knew what I wanted to do for the rest of my days. I saw code as the ultimate, sculptable material.

As I rose through the ranks in software development, I realized I was dying inside. I was convinced that I wasn’t cut out for this profession, and I thought it was just me.

Then I started looking around and realized our whole industry was broken. The Standish Group’s Chaos Report measures failures of our industry annually. Most projects never see the light of day. If they do, they don’t work right. If they work right, no one ever uses them.

I didn’t want to be stuck in a career where people hate what I do, so I was determined to find a new way of doing things than was customary. I remember talking to programmers who after 10 years of their career had never seen a project they work on ship or see the light of day. That’s sad, because too often these projects were created within death march cultures: programmers working 60-80 hours a week, jettisoning time with family and friends. One day the boss comes in and says “Oh, by the way, this project’s canceled.”

I wanted a different result. It was a personally selfish journey. Ultimately, I ended up defining the mission as one defined by joy. The joy of knowing that what we create gets out into the world and ends up being widely adopted and enjoyed.

How do other widely accepted development practices such as agile and lean development differ from the “Menlo Way” practice you have developed?
We borrow from many sources. We use practices from the Project Management Institute, lean, Six Sigma, agile and Scrum. We’ve knitted together an end-to-end system that influences how we interview, hire, report status to our customers and run meetings. Many times, the reason we use standard words is because we don’t conform to a lot of them. Dr. Jeff Liker, author of “The Toyota Way,” once said that “Any single piece you find at Menlo, you will find elsewhere. What you won’t find elsewhere is all the pieces working together in a system.” We never studied lean, but the lean world found us and began describing back to us why we are lean.

The table full of story cards in the video looks pretty daunting. How does the team break it into meaningful order and prioritize?
Our customers prioritize the story cards. Each card describes a feature they want added to their project. They review each card, which contains costs and other factors. The cards are of different sizes because we fold them to the size of the estimate. The customer places them by priority on the planning sheets.

So your clients own their needs and schedule execution into a specific week. How does this provide clarity for Menlo developers?
Absolutely. This is one way to get to joy, to be sure we’re building what our customers want us to build.

How big a role does design play in the UI, and at what point in the project do the designers get involved?
We have a set of people on our team called “high-tech anthropologists.” That’s our registered trademark for our user experience designers. Every project starts with them. The first three weeks to three months of any software project will start with high-tech anthropology.

We might do a couple of technical spikes along the way to eliminate some risk around some bizarre technical requirement, but ultimately it is our high-tech anthropologists who drive the projects. They are the ones going out into the world studying users as anthropologists do, learning their world, their vocabulary, learning their goals as human beings and bringing this intelligence back to infuse into pixel-perfect screen designs. After the screens have been laid out, the software developers begin to bring the screens to life. It’s a critical, essential role of every project.

How do you hire people and what do you look for in a candidate’s style?
The No. 1 skill we prize is whether or not our developers have good kindergarten skills. Whether they play well with others. If you don’t have these qualities, it doesn’t matter how technically skilled you are. This is not the land of individual heroes.

Because we care about teamwork, our hiring process is different. We never ask any questions other than whether a candidate is 18 and legal to work in the U.S. We mass-interview up to 50 people at a time, pairing candidates and putting them to work with another developer. They are given explicit instructions, and the candidate’s job is to make their partner look good. If they struggle, help them out. Make them feel at home so they can get some work done.

These pairings go on for 20 minutes or so, and partners switch out. At the end of the day, candidates are evaluated based on their ability to act like a Menlonian. Some will be asked back for a second interview. We actually bring them in for a paid, contracted, live eight-hour working day, and they are paired with two people for a half-day. It works for us because we have a chance to see how our potential hire works in a live production environment, and it works for the candidate because they have a chance to see if an open factory floor, crazy creative, talkative environment is one they’ll flourish in.