Rich Sheridan

Never Work Weekends Again: The Keys to A Sustainable Work Pace

An interview with Rich Sheridan


Samad:            Rich, how did you get interested in this topic of a sustainable work pace and why should project managers pay attention to this topic?

richardsheridanRich:                You know, I had been in our industry, in one form or another of the industry designing and developing software for my entire career. And I could so remember an early moment in my managerial career where my boss sat down with me one time and he said, “Rich here’s something we have to work on.”

He says, “You know, you look at any typical software project and there’s this sort of steady pace that occurs through 80 percent of the project. And then the last 20 percent of every project no matter how big it is, is this insane sort of—you know, nights and weekends and long days’ effort right at the end. You kind of put in the other 80 percent of the effort in the last 20 percent of the calendar time.”

And he says, “Wouldn’t it be neat if we could flatten that curve out throughout the course of the whole project?”

And that really intrigued me because the idea of killing your team right at the end of a project is probably what leads to so many quality problems in software development. You have that late push right at the end. So the question is how can we—particularly over a years-long project—how can we create this thing that Kent Beck first started talking about in his book “Extreme Programming Explained,” a sustainable work pace.

Don’t miss hearing Rich speak at the Project Management Telesummit: March 8-10, 2011. Find out more

Samad:            Define for us what you mean by sustainable work pace, and why is it challenging to achieve this state with the current ways we manage projects?

Rich:                You know, if you think about—again, I’m focused on the software industry because that’s where all of my experience is. [Laughs] Our industry is famous for applying the term “death march” into a business context.

There’s so many teams that labor into the night, over weekends, through holidays, over sometimes a years-long period. And quite frankly, you end up burning the team out long before the project is completed.

And the question becomes is there a way to reorganize the process, the efforts, the management of a project such that the team can maintain its—sort of spirit and energy throughout the course of a years-long project? So that by the time they get done, you haven’t killed the team in the process.

And that’s really what I look to for a sustainable work pace is looking at the humanity of the team, how can we really maintain the energy and spirit of that team throughout the course of a project?

Samad:            You know, I think most of us—and I also started in the software industry, and I grew up in IT shops. And I think most of us don’t know any different, you know? We just think that that’s how it is. And once in a while, some of us would work in an environment like [Laughs] your organization, and then you get the Aha moment: “Wow! We can actually do this without actually killing ourselves.”

So it’s really rare to see an actual model of a sane kind of environment sometimes. And you could go through your entire career never seeing it. [Laughs]

Rich:                Absolutely. And I found this has really struck a chord lately. It’s probably one of the reasons you and I are talking. And that is when I talk about Menlo, actually when I introduce Menlo to people, I say, “Welcome here. You are about to experience a company that has very intentionally-focused its culture on the business value of joy.”

And the notion that you can have a joyful software team is one that’s—quite frankly, people don’t believe you.

Samad:            Yeah.

Rich:                They don’t for a second believe you can have a joyful team. And of course, then they look at me funny kind of like, “Well what does joy have to do with anything Rich?”

Samad:            [Laughs]

Rich:                And I’m like, “Well, you know, [Laughs] let’s say that half of my team had joy and half of it didn’t. Which half would you want to build your software?” And they’re like, “Well I’d want the joyful half for sure!”

And I’m like, “Why?” And they’re like, “You know, quality, engagement, productivity, creativity, imagination.” So it doesn’t take long for people to realize how much business value there actually is in joy.

Samad:            And I think as we enter the field as young people, we have that energy, and we have all the time in the world, and we pour ourselves into our careers. But as we grow older, start raising families, we start looking for answers, and something like this.

And also, we need to know that it is indeed achievable.

Rich:    Yes. And we’re at the pace now, Samad, where it’s kind of interesting. We were doing a tour a day of Menlo. So there will be someone here this afternoon to take a tour. There were two groups yesterday that took a tour. And they come from around the country—some get on airplanes and come here to visit I think primarily because they want to believe that there is a possible way to do what we do as a profession joyfully.

They’ve never seen it and they want to come see it firsthand. Experience it. And ask questions about it. And so for the last couple of years, we’ve been on this pace where we’re doing a tour a day of our facility, and our process, and our team.

Samad:            Wow. That’s just a fascinating concept. I bet people walk around and they actually touch your people [Laughs] and see, you know, “Are they real? Or—?”

Rich:                Yeah. And ask them questions like, “Do you really like working here? Is it like Rich describes?” You know, and they want to hear it from the people who do the work.

Samad:            [Laughs] Oh, that is wonderful. Rich, at a high level, how does Agile—which is an approach that you follow in your organization—how does it enable you to maintain a sustainable work pace?

Rich:                Yeah. You know, it’s interesting. There’s so many different aspects of Agile and different definitions for it. And different forms of it, and that sort of thing. And the one that caught my attention back in 2000 was Kent Beck’s book on extreme programming.

And so we have adopted what I call 13 of the 14 practices Kent Beck talked about in his book. And one of them that’s quite [Laughs] fascinating to people in terms of how we work is the concept of Paired Programming. Two programmers, one computer.

And I’ll tell you: when I first thought about that as a manager, my managerial brain just kind of melted down. I’m like, “Well that sounds really dumb! You know, two people, one computer, cut your productivity in half. You know, what good is that going to do?”

But like Kent, I reflected back on my own personal career as a programmer. And I started to realize, “Oh my gosh! Yeah, there were times where I was really stuck. Or I really needed to get something done, and I grabbed another person.”

I said, “Hey, let’s focus on this problem together.” And we produced faster results, better results, higher quality, and I was more engaged during the process. And I realized, “You know, he’s really onto something here.”

And so my teams—the teams I have managed and led since 2000— have been using Paired Programming. And I will tell you, this is the magical component. In fact, we pair all of our roles here at Menlo now. I even pair when I’m blogging—that sort of thing. We pair our QA people, we pair what we call our “high tech anthropologists” who do our design, our programmers, and so on.

And so the way this fits into a sustainable work pace model is one of the biggest challenges in our industry—and the one that I think [Laughs] ends up killing most of the best performers in our industry—is this problem that I began to refer to as “the Tower of Knowledge problem.”

You know, you have those one or two people on your team that have this deep knowledge about a core piece of a system and they’re the only ones that understand it. And so as the project starts to evolve, there’s more work being pushed towards and through your Tower of Knowledge.

And all of a sudden that person—as the project gets further and further into it, and perhaps [Laughs] in tradition of our industry—further and further behind schedule, suddenly that person can’t take vacations anymore. They can’t go home and see their families. They have to stay the weekend. They have to work through the night.

I mean, I remember there were so many instances where members of my team would literally work around the clock. I’d come in in the morning and they’d still be there in the same clothes—obviously looking a lot more tired.

And so this Tower of Knowledge problem was a huge issue. But by pairing—and the way we do it here at Menlo, we pair our programmers together for example. They pair together for a week and we switch the pairs every week.

And we practice something called Code Stewardship, which means anybody on our team can go into any part of the code. And this is supported by a coding standard that everyone adheres to. which is, quite frankly if you’re at all familiar with software development, getting a set of programmers to all agree on the format of the code is almost a miracle. [Laughs]

Samad:            Sometimes it’s a religious discussion!

Rich:                Absolutely. And it’s all about, “Where do the curly braces, go?” Right? [Laughs]

Samad:            [Laughs]

Rich:                [Laughs] You know. Do they go over one another, or—? I mean, it’s just amazing.

And so at a certain point, if you practice this Pairing—in our world, Re-Pairing—and Code Stewardship, and coding standards, suddenly you’ve not built a single dependence on any one individual.

The interesting element of this is—what this means for me is—as we get closer to a deadline, or as more work might be arriving than we were anticipating because of “Now we understand the problem better,” I can actually add more people, can get more done. Which I could never do as a manager before because adding more people, according to Brooks’s Law, has the near-term effect of slowing everything down.

Samad:            Right. Right.

Rich:                Because suddenly you’ve got to start cross-training, and the person who’s cross-training is the Tower, and they’re incredibly busy, and they can’t take the time to do this. But as soon as we introduce Pairing into the concept, Brooks’s Law actually is defeated. We now can add more people and get more done, and I’ve been doing this for a dozen years now, and it works.

And so by being able to add more people when there’s more work to do, we have generated something that I think is unprecedented in our industry over the last 10 years. My team works 40-hour workweeks, they never work weekends, and in 10 years I have never had to deny a vacation request.

Samad:            That’s amazing. Because I think a lot of people can talk about some of these concepts just as “Pair Programming.…” And intellectually, you grasp it. It makes sense. Yes, sometimes you have to convince people to invest in it. But until you see it done—and done well—it’s an incredibly difficult concept to grasp.

Rich:                It is.

Samad:            And exactly what you said, throwing more people at a project historically slows it down.

Rich:                You bet.

Samad:            But it’s such an Aha moment to realize, “Actually now we could actually create more by adding more people once we have that shared knowledge and shared thinking.” Not just about the actual technical aspect of the project but about the entire philosophy behind what we’re doing, the business needs, you know. People really grasp the concept at such a deep level and not just at the technical level.

Rich:                Yeah. And I talk about this. Because I’ll tell you—people see it, they get excited about it, and then they’re like, “But we could never do that!” You know?

Samad:            Yeah. “Not in my company.”

Rich:                Even when I introduced this to my old team. I was the vice president at this other company and I came to my team and I said, “Guys, this is where I’m thinking of going.” The first reaction of one of my programmers—who quite honestly was one of the guys who spent you know, all the—over the nights, and weekends, and the time away from family, couldn’t take vacations.

His first reaction was, “Rich: blood, mayhem, murder. Don’t do it!”

Samad:            [Laughs]

Rich:                “Don’t make me share my code! [Laughs] Don’t make me share a computer with somebody else.” You know.

Samad:            Yeah.

Rich:                And yet it was amazing how quickly this had a strong impact on my team and their productivity, and their life and their life balance, and their work-life balance, and all that kind of stuff. And so it is very, very powerful.

Samad:            Rich, you describe current planning process in most organizations as “Emergency-Driven Project Management,” and I just cannot agree with you more on that. Describe to us what you see as inefficient ways of planning and contrast that with the Agile planning process that you have adopted.

Rich:                Well, yeah. I can go off in a couple of different directions here. let’s talk about planning  in general around any software project that—again, it was 40 years ago I first laid my hands at a computer keyboard when I was just a kid, to today. So I’ve kind of seen a lot over the last 40 years.

And most software teams, when I watch them get ready for a new project effort, they start with kind of the Must Haves, the Nice to Haves, and, boy if we have some extra time let’s put these features in too.

And most feature planning for any new software project or product is usually done in the absence of having estimates for any of those things. Like, “Well we don’t care how long how this takes but it’s really important, so it has to be in there. And we’ll figure out later how long it’s going to take.”

Well, when I talk to people I say, “Look, there is no other place in our lives where we prioritize things without knowing what the cost is. And yet we do this in software all the time.”

[Laughs] I give this funny example. I went to buy a 50-inch plasma display TV for home, you know, I don’t know, $800, $900, something like that. And the other day, [Laughs] just on the verge of going out to buy one of these at Best Buy—this is before the holidays—I had a minor plumbing disaster in my house that, guess what? Cost me about $900 to solve.

And there went my TV! [Laughs] I now have two beautiful ball-joint valves around my water meter that I didn’t have before, but I don’t have my flatscreen TV.

Samad:            [Laughs]

Rich:                And so I gather the family around the ball-joint valves and say, “Look at this, kids. Isn’t this fun?”

But the fact of the matter is I made a priority decision. I think having running water in my house is higher priority than having this brand new television. And we do this all the time. And yet in our software projects we seldom do this. We often make determinations about what should be in a product without the benefit of an estimate of the cost.

And I think Agile spends a lot of time focusing on doing estimating before you plan. And we have a very unique way of doing this with a paper-based planning system that makes it real obvious what the relative costs are between features so that the project sponsors can make some really informed decisions.

Because I think the greatest benefit of Agile when done right is the ability to create this very functional working healthy relationship between non-technical business sponsors and the technical team.

And it really revolves around “Can we describe the features in a way they understand—and not use our technobabble that confounds them—and can we describe that not only in terms of terms they understand, but in terms of putting costs down into these things so they can begin to make effective tradeoffs.” So I think that’s where we first go wrong in project planning for a lot of software projects.

The second is this Emergency-Driven Project Management. What I see—and I often refer to this first as “hallway project management,” right? Where you lay out a plan but then as you’re walking out of the conference room where the plan was approved by everybody, somebody pulls you aside and says, “Hey Samad: come here. Great, great session, great plan!”

Samad:            [Laughs]

Rich:                “Just one more thing!” You know? [Laughs]

Samad:            You know, I call those the “drive-by requirements.”

Rich:                Yeah, exactly! And it’s so typical, right? We all have words for it, we all know exactly how it works. And quite frankly, people in our industry, we just want to be nice guys, right? And we’re like, “Oh, just one more thing? Sure, we could do one more thing.”

Well the trouble is, as soon as we make that determination, silently and invisibly something just fell off the table without us realizing it. Because if we put something more on, something else has to come off. It’s just a fact of life.

I bought those two new ball-joint valves around my water meter and my television fell of the table. And I wish it wasn’t true but it was. And so then what happens is—and this is where I think we really get into trouble in our industry—the “Hey how’s it going?” kind of discussion where the boss comes in, you know.

I often do this little skit with people. I have this set of index cards in my hand. And I walk up to somebody that’s in one of our classes and I’m like, “Hey Samad, how’s it going?” And you’re like, “Oh, fine.” And I’m like, “Hey, what are you working on?” And you’re like, “Oh, remember yesterday we decided I was going to work on this?”

And I’m like, “Oh yeah, great. Great, great! Hey Samad, listen. I just got off the phone with a customer, and boy, were they hot to trot!” And you know, I throw something else on your desk and say, “Hey, could you jump on this?” And you’re like, “Oh yeah! Sure, sure. Yeah.”

So you silently set the other thing aside and you come working on that. And then I come back about half an hour later. I’m like, “Hey Samad, how’s it going?” [Laughs]

Samad:            Yeah. [Laughs]

Rich:                You know, “What ya working on?” And then, “Hey, I just got out of this executive team meeting. Holy cow! You know we’re going to that tradeshow next week. And boy, the team would really like to be able to show this.” And I throw something else on your desk, you know.

And now you’re looking at it like, “Okay, Rich. What do you want me to prioritize towards?” But there’s this silent sort of, “Well you’ve just got to get everything done, Samad.”

Samad:            Yeah.

Rich:                “And that’s why we give you stock options, that’s why you’re such a good member of my team, and all that kind of stuff.” Well if I keep doing this to you day in and day out, after a while you start going home really tired. You’ve worked really hard all day and you’ve gotten absolutely nothing done.

And that’s debilitating, right? In fact, there’s some studies that say the most powerful indicator of employee satisfaction is that you actually go to work and get stuff done.

Samad:            [Laughs] Yeah.

Rich:                And our industry is denied that pleasure. And then one day I walk in and I’m hot to trot. I’m pounding my fist on the table, I’m probably raising my voice, I might even be mean at this point. And I get you attention. And I’m like, “Samad where is that thing? We said it was going to be done, and you need to have it done!” And suddenly what do you do? You work late that night.

You get it done. You hand it to me like, “Hey Rich I got it done here, just like you said.” And suddenly what’s happened in that minor exchange is we have just defined our process, you see.

Samad:            Yeah.

Rich:                The process—you pick any process you want. Process wants, process desires one thing and one thing alone. Process desires a predictable outcome. And so what I just found out was if I walk into Samad’s office, pound my fist on the table three times, raise my voice, point to something, the next morning it gets done. That’s predictable.

Well now all of a sudden if setting things on fire produces results, now we set everything on fire.

Samad:            Right. And that’s the new process.

Rich:                That’s the new process. “I know how to get things done here. the person who yells the loudest, who screams the loudest, who sets things on fire, who makes it sound like an emergency, that stuff gets done. Nothing else gets done.”

And so now, all the formal planning processes go by the wayside. What I would declare with Agile—and particularly again, it has to be well done—is you begin delivering predictable results on a regular basis and you literally change behaviors of the rest of the team.

And then it becomes—we had a guy come in here a few months ago. It was actually a really funny story. He had been trying to schedule an appointment to come see me and he kept canceling it. And finally he shows up and he apologizes for both all the canceled appointments and the fact that this one he was late for. A potential client.

And he kind of comes in, he’s the CIO of the company he’s working for and he’s like, “Hey Rich, sorry I’m late, but I had an emergency last night and I was up coding.” And I’m thinking, “The CIO is coding?” I thought that was a little weird to begin with.

And he’s like, “Well, you know,” he says, “It was an emergency, Rich. You know about emergencies.”

And I smiled and I said, “No actually I don’t.”

Samad:            [Laughs]

Rich:                And he looked at me like he didn’t understand what I was saying, or I didn’t understand what he was saying. So I brought him into the room with our team and we just happened to get there for daily standup. And I said, “Hey this is Andre. He’s here to talk to me, but take it easy on him today. He had an emergency last night, he was up all night.”

And my whole team kind of giggles. And he doesn’t get why they’re giggling, you know. [Laughs] And I said, yeah, “Andre had an emergency. I told him we don’t have emergencies, but he doesn’t get that.” And the whole team giggles again.

Well eventually the standup token gets around the daily standup and gets over to John, a member of my team who’s been with us for almost the whole time we’ve been in business. And he says, “Rich, Rich, Rich. Come on now. Tell Andre the truth. I remember six years ago when we were working on the Organ Transplant Information System for the U of M Health System we had an emergency and we had to come in on Saturday to work on it.”

And I’m like, “John you’re right. Six years ago, yep. We had that emergency.”

Samad:            [Laughs] Oh, that’s hilarious. That’s interesting. There is definitely an amazing work environment, I’m sure. Because I’m sure that people stay longer with you, you don’t have probably any issues retaining good people, and it just totally makes sense.

Rich:                Yeah. It was funny. We do these tours all the time and there was this one young man that came in to visit us, and he was there for the whole tour. And he was really quiet, and he wasn’t showing any facial expression. And I thought, “This is weird. Most people who are in the tours are asking questions, or they’re emoting.” [Laughs] And he wasn’t.

And I thought, “Boy, I wonder why he’s here. He just doesn’t seem to be connecting.” And then finally I talked about 40-hour work weeks and never denying vacation requests. And he suddenly yells out really loud, he’s like, “Stop! I can’t stand it anymore!”

Samad:            [Laughs]

Rich:                And I’m like, “What’s going on?” I said, “You’ve been so quiet.” He goes, “I’m sorry! There’s too much common sense here!”

Samad:            Yeah.

Rich:                He says, “I don’t want to go back to work tomorrow and believe a place like this exists.” He says, “It’ll drive me insane!”

Samad:            Yeah. I think the first thing that comes to mind is that people really, after that initial shock and disbelief, I think people will get angry. I can see how people get angry, because they feel kind of like they’ve been robbed of their life. Especially when people start getting into building a family and start having small kids, and not being able to spend time with them.

I think people just feel sometimes robbed from a very important part of their lives. And I can see how people will really get angry. Especially those who feel like, “I’d much rather feel like this is impossible than see it. And now I’ll never be able to look at work the same way again.

Rich:                Well, and what’s interesting, remember I talked about joy at the beginning. And I will say this about joy in our profession. I’m sure you can relate to this. There is actually only one tangible version of joy in our industry. And that is that the work we do as professionals one day gets deployed out into the world and is enjoyably used by large numbers of people.

That no matter how long we work at something we want it to be deployed. And the robbing of joy that you talk about isn’t even so much that we took away your personal life, which is hurtful. It’s…imagine you worked for years on a project where it did take away your personal life. And then one day the boss comes and says, “Oh by the way guys, that project got canceled.”

Samad:            Right, right.

Rich:                Now you look backwards over the wreckage of your personal life, and now you get really bitter. Because you’re like, “Why did I do that if the project just got canceled?” And that’s when I think people start leaving our profession in droves. And that’s, I think, the saddest tale of all is people give up on the profession like, “I can’t do this anymore.”

I’ve literally had discussions with people where they’re like, “You get to deeply stuff?” He says, “I’ve been working in this profession for seven years and nothing I’ve ever worked on has gone to market.”

Samad:            Yeah. You know what? And I think that’s a really interesting point, Rich. Because I just didn’t realize it that a lot of people that I worked with really never have seen success. Seen something that they created actually get deployed and actually finish a project successfully. And there’s a lot of people that have just given up, and that’s where you get people to disengage.

And I think the lucky ones are those who actually escape—for example, the software industry or IT and find an escape route to something else. But I think the sad part is the ones that leave mentally but never actually exit the field.

Rich:                Right.

Samad:            So they remain there, and that’s just the saddest situation.

Rich:                They quit without quitting.

Samad:            Yeah.

Rich:                Yeah. Their spirit quits, but their body is [Laughs] still coming to work everyday.

Samad:            Yeah. There’s a lot of that. Because people have families, they need to provide for them.

Rich:                You bet.

Samad:            And I’ve seen so many cases where people get to a certain age where the cost of getting out of the particular field like IT or software development is absolutely unimaginable. They just cannot make that switch.

Rich:                Right.

Samad:            Because it takes years to be able to build the skills that you can take somewhere else. And just the fear of actually getting out of something that’s the only thing you knew. And so your message is really important. Because if we know that joy is achievable—and that not only it is achievable, but it is really a birthright—

Rich:                [Laughs] Yeah.

Samad:            —in a way, then we all have to demand it. I think that’s what’s going to change the way we do business.

Rich:                Absolutely. And I’ll tell you, I faced that moment that you described in my own career where I said, “I’m getting out. I don’t want to do this anymore. It’s too hard, it’s too frustrating, and there’s no joy in it.” And I was going to get out.

And then I said, “Wait a minute.” I probably contemplated what you just said like, “What the heck am I going to do now?” [Laughs] You know? And I just said, “I’m going to change it.” And I was a vice president at the time so I had the purch that I could make dramatic change to my team.

And I remember six months after this dramatic transformation of my old team, one of my longtime members—he’d been with the company for 30 years, and he came up to me, sat down, looked me in the eye. And he said, “Rich, you had no idea when you started this that this was going to turn out as good as it did.” Why were you willing to take that risk?’

And I said to David, “David, it was trivial.” And he’s like, “Really?” I said, “Yeah. Because here’s where I got to in my own mind. The risk of staying the same is far greater than the risk of changing. Once I got to that point in my head, racing towards change was actually trivial. It was racing towards safety, not away from it.”

Samad:            On my blog I talk a lot about mindset and self-mastery. And one of the interviews I did was with one of my—I consider him a role model. Doug DeCarlo, who wrote the book Extreme Project Management.” And when we were talking he said that, “You have to get to the point where you get so angry that you can never go back to the way you do things, or think in the same way.”

It’s almost like you get to that low point where you realize, “I’m never going to go back to that,” and that’s where transformation begins.

Rich:                You bet. And I’ll say, I’ll go back now 40 years. When I was a kid in high school I sat down at a computer terminal. [Laughs] It was a teletype back in those days. And I typed in a two-line program. And I typed the word “Run,” and the computer came back on this printed roll of paper and said, “Hi, Rich.”

Samad:            [Laughs]

Rich:                Because that’s what I told it to do. And I was hooked. I mean, to me that moment—it was like my brain chemistry changed. And I’m like, “This is the coolest thing ever.” I think software design and development is one of the most unique endeavors mankind has ever undertaken. And I think it should be and can be—and quite frankly I think must be—a joyful pursuit.

Because let’s face it. You can’t buy a cup of coffee at the coffee shop without the software working anymore. You can’t get gas at the gas station without the software working. You can’t do a transaction at your bank, you can’t get on an airplane, you can’t do anything in the world without the software working.

So software’s with us forever. We’d better figure out a way as a society to make this a more enjoyable, joyful, sustainable profession or all of society will begin to suffer.

Samad:            Yes. Exactly. And [Laughs] I think eventually we forget why we got into this field in the first place. Because I think we all kind of look at ourselves as, “This is a way for self-expression and finding ways to express yourself like a painter or a musician.” This is our music, this is our painting.

Rich:                Yes. Absolutely.

Samad:            But somehow the way we work manages to get that important part kind of undermined. And I think your message is so important. Because the more I talk to you about this topic, the more I think that in fact, creating a sustainable work pace has to become a mandate. Because that’s the only way we’re going to be able to keep interested in this particular, what I call art.

The art of developing something or creating something, and seeing some other people using it. It’s the only way we’re going to keep that energy, that engagement, and that focus.

Rich:                Well, and let’s see how this manifests as self in society, right? Imagine I’m that 40-year professional and I have three young children who are 12 to 15, to 18 to 20 years old. And they’re thinking about, “What should I do in my life?” And they go to their mom and their dad and they’re like, “Hey Mom, Dad, you’ve been a programmer your whole life. Is that an honorable profession? Is that something I should go into?”

And if the parents are so burned out from their profession they look at their kids and go, “Oh my gosh. Do anything else but go into our profession. It didn’t turn out well for me and I don’t think it’ll turn out well for you,” now we start robbing ourselves of our youthful future. Because now we’re diverting students away from our profession rather than towards it.

And then we start to lose the ability to sustain a whole profession. And I think again, this is really key to, well how do we think of our whole industry more systemically? And how do we sustain a whole profession and an industry?

Samad:            Going back to the Agile approach and Menlo Innovations, you use the weekly planning game. Talk to me about that, and about your Menlo Software Factory.

Rich:                Yeah. So if you come here, you see this wide open room. We call it Menlo Innovations in the spirit of the Menlo Park, New Jersey lab of Thomas Edison. A guy who literally changed the world and believed that it was possible to systematize invention. And he did.

And for me, it’s fun if you go to this little park here near Detroit called Greenfield Village, Henry Ford created this park called The Edison Institute—now called Greenfield Village. And he used it to honor Edison and a whole bunch of other inventors like the Wright brothers and so on.

And outside the recreation of the Menlo Park, New Jersey lab of Edison is this little brass plaque. And it said, “Edison’s goal in his Menlo Park, New Jersey lab was to create a minor invention every two weeks and a major one every six months.” And I think that is such a perfect expression of iterative and incremental, which is at the heart of Agile.

Because in our view, and it’s formed out of my philosophy of life, it’s that whatever we write down on paper, whatever we draw on a flipchart or a whiteboard, nobody can truly say that’s what we want until we see it expressed in working software. Until we actually see it on the screen, can touch it with a keyboard and a mouse, that’s when we start to get that sense of, “Yes! You’re headed in the right direction.”

So what if we could break a project down into weekly versions of that? what if we could get to the point where we could plan out a week’s worth of work using our Planning Game, have the team effectively execute on that week of work, and bring the client back in and show them in what we call a Show and Tell once a week what we did based on what we had planned the week before?

And they look at it. And I always tell people. I say, “There’s one of three things that are always going to happen when they see the working software compared to what they had planned for the week.”

They look at it and go, “Oh. That’s what you thought we meant!” [Laughs] “That’s not what we meant at all,” right?

Samad:            [Laughs] Yeah.

Rich:                Okay, that’s great, so we made a mistake, but we made it quickly. Okay. And then you correct it. Or they might come back the next week and say, “Oh! That’s exactly what we meant. It’s not what we need now that I see it,” right? “But I couldn’t tell you differently. You did exactly what I asked you to do but it’s not what I need.”

Great, we made another mistake, let’s correct it. Okay. In the whole spirit of lean manufacturing, this is a “you make a mistakes faster” kind of environment.

Or they might come in and look at it and say, “Oh yeah! That’s what we meant. And that’s what we need,” right? And so hopefully that’s the majority of the cases. But even if it isn’t at least we’ve only made [Laughs] a week’s worth of mistakes. And so this is where I think Agile is very powerful.

So in our system every one of our client projects goes through this weekly cycle. First thing that happens is when we start a project we ask a customer, when do you want to come and visit us to check on our progress? And our customers pick a day and a time.

So we have a client we’ve been working with for five years now. They come in Tuesdays at 3:00 to measure our progress. Now just so everybody can grab their breath, the five-year project has been out in the market for two and a half years. Now we’re doing multiple versions, and different models, and all that sort of thing.

But the project has been out in the marketplace for two and a half years. But for 263 weeks now, they have come in Tuesday at 3:00 to get a Show and Tell on the work we did the previous week. They actually show us the software. So there’s all these story cards they picked in the previous week’s planning session.

And they come in and say, “Oh! Well if you did this story card, then the software should work like this. Oh, if you did this story card, then the software should work like this.” And they show my team the work we did in the previous week. So it’s kind of a reverse Show and Tell. They show it to us.

Then as soon as Show and Tell ends, my team goes back to work and a subset of my team stays with the client, and they go through a weekly paper-based planning process to look at the plan they had decided on and update it using these little folded story cards we do on the table. So they review the plan, they update the plan, and then they leave.

And our project manager takes the plan that was updated and builds—in PMI terminology—a new work authorization board, putting it up on the wall. Very visually-oriented process we have here. We love the paper-based tools. Put these story cards up on the wall in swim lanes. So that when the team comes in the next morning they know exactly what’s expected of them.

They work on this process throughout the course of the week. And then Tuesday at 3:00 the next week, client’s coming in to see what we did. And so this whole Plan-Execute-Measure cycle is going on on a weekly basis for all of our clients. And they walk out the door with a DVD, or a CD, depending on the size of the application, with updated software so they can go play with it in their office, or take it out to their clients should they so choose, and so on.

So this whole weekly cycle is going on at every one of our projects here. And right now we have about 10 projects underway for different clients through this entire cycle that’s going on.

Samad:            Rich, can you walk us through the Agile tools that teams can use to increase resource flexibility and faster and better prioritized decisions?

Rich:                Sure. So, let’s break it down in a couple different components. I’ll talk first about some of the tools related to the project and project planning itself and then relate that to the human resources and how they execute on this.

So in our view, the first thing—the atomic element of our process, and I believe the well-functioning Agile processes in the world, is a story card. You know, PMI would call it a work package. It’s part of a work breakdown structure.

But this story card is some—in our world it’s a handwritten index card, 5 1/2” x 8 1/2”. Handwritten index card that expresses some new feature that the customer understands. I mean, and not that our team wouldn’t understand it, but we write it in words the customer understands. So it’s written with the non-technical business sponsor in mind.

So, “When this card is implemented, the software will be able to do the following things in addition to what it does now.” And so that story card then enters into an estimation process.

And so by estimating these cards on a weekly basis, we now end up with the fundamental building block of a project management system, and that is an estimated work package. An estimated story card.

And now in our world what we do is we actually take that story card and we fold it to the size of the estimate. So a two hour card is small, a four hour card twice as big, an eight hour card twice as big as that, a 16 hour card is the full size of the 5 1/2” x 8 1/2” index card. And a 32 hour card in our world is a big as a full size 8 1/2” x 11” sheet of paper.

And so now we’ve gotten all these little—imagine these little puzzle picas on a table, all folded to the size of the estimate.

And now we start planning against capacity and against budget, and against time. How many things can we do this week based on the size of the team and the budget that we’ve allocated for this project? And people start making choices. The project sponsors come in and they start picking these little folded story cards and laying them down on what we call Planning Game Sheets. And the Planning Game Sheets have this inscribed [Laughs] box on them that they have to fill up with these folded cards. So it’s a very spatially-oriented system we use to do this, but it’s very trivial. Because nobody has to do any math. So you pick up these little folded cards and start setting them down on sheets of paper.

And of course, every project we work on, everything doesn’t fit. It doesn’t all fit on these sheets. Well that’s really neat. Because now, we have this very tangible expression of what’s in the plan—what has been authorized, and what is not in the plan—what has not been authorized.

Most project planning tools do a great job of telling you what is authorized. They usually do a terrible job or no job at all of telling you what you’ve decided not to do. Our system makes it very clear what’s in and what’s out. And now as soon as that planning effort is done, now the project manager can take copies of these little story cards and put them up on a wall. And give everyone essentially what amounts to 40 hours’ worth of work in a week.

Because you see, if you want to work a 40-hour workweek, you shouldn’t assign more than 40 hours of work to the people who [Laughs] are actually doing work. Seems so fundamental, you know.

Samad:            Such a revolutionary concept. [Laughs]

Rich:                Yeah, I know. There’s the common sense again, you know. It’s just not so common. But it’s expressed right in front of the team. And so now we’ve got these estimated story cards up on a wall. And the team executes on them for a week. And so that’s in some sense the tools. And of course what I’ve described to you are simple, paper-based tools.

We’re small enough and lightweight enough that we can do multimillion dollar projects with these paper-based planning tools. It’s kind of fun to watch people’s minds twist in the wind as they’re like, “Rich, you’re a software company. Why haven’t you turned this into a website? Why aren’t you putting these cards into a database?”

And we’re like, “Well, because it works better for the humans.”

Samad:            [Laughs]

Rich:                They’re confounded by that. Now on the flipside of this is the human part of the equation. And this is where I think the real magic happens here at Menlo. Imagine every week there’s this other process that’s going on to manage the human resources of our team.

So we have a role in our team that Carol currently fills, and her title is Factory Floor Manager. And what happens is, because we’re working on 10 projects at the same time, all the project managers get together with Carol and sit down and do what we call resource planning once a week. And it basically answers three questions.

The first question is, each project manager needs to bring to Carol the numerical quantity of resources they need for the coming week for their project. So, how many programmers do you need this week? How many QA people do you need this week? How many high tech anthropologists do you need this week, how much resource do you need? So the first expression of building the right sized team for the work we have to do in the coming week starts with that numerical question.

Then the next question becomes, “Okay great. Now we know how many chairs in the room need to be filled with humans, which people are going to sit in which chairs?” And so now they answer the question, “Who is going to be on my project, who is going to be on my project?” And so on.

And you can imagine our project managers would prefer—you know, a natural human tendency—would prefer to have the same people on their project this week as they had last week. And by and large, that’s true. However, it might be the case that a client needs to get more done so suddenly that team needs to get a little bigger.

Maybe we’d add a Pairing. Well now we’ve got to get different people joining the project. Or maybe there’s a project that’s nearing its end and its starting to slow down. And so there’s some extra resource there, and that’s where we might get that extra pair from and so on.

And so now there’s a little bit of a shuffle goes on. And then oh my gosh, you know every once in a while, you know what happens? People take a vacation, or there’s some family emergency that they have to be away. So now we’ve got a chair that we would’ve filled with Ted, but Ted’s not going to be here next week because he’s going on vacation.

Okay, so we don’t get Ted. So who are we going to put? Or, we can put Keely in that chair. Okay. So now you have this ability to kind of right-size the team on a weekly basis.

And then finally we make what I call the most magical decision in the place. And that is, “And who is going to pair with whom?”

I can tell you there are people in the Agile community who are maybe even to the point of close to being offended by this next construct I’ll tell you about. We assign the pairs. We don’t let them self-select.

You know, people say, “Well, self-directed, self-managed teams, they should be able to do this.” And my team is the one that asked for this. Because what they said was, “Well, number one I don’t want to always be the last one picked, [Laughs] you know?” And so they wanted to remove that social pressure. And quite frankly it’s the most magical thing we do.

Because now we can say, “Hey who knows unit testing really well? Let’s pair them with somebody who needs to learn unit testing.” And so I get cross-training and mentoring every minute of every day while we’re actually doing work. And so I think teams always give lip service to this thing called “continuous improvement,” right? Or cross–training, or mentoring. Nobody ever does it.

I get to do it every minute of every day. Every week, my team is just a little bit better than they were the previous week because of this. And so this team continues after 10 years to just continue to grow, and increase their knowledge and their skills, they become good teachers and good mentors, they become good students and good mentees, and it’s really interesting to watch the personal growth you see people go through in an environment like this.

Samad:            It’s such an amazing process to hear about it being actually done in real life. As opposed to just talked about.

Rich:                Yeah. I’m always stunned when we go to Agile conferences. And we kind of expect when we go to an Agile conference that we’re going to be just like, ordinary, right?

Samad:            Yeah.

Rich:                You know, we’re just going to describe and people are going, “Yeah, whatever. That’s what we do too.” We go there and they’re like, “Oh my gosh, you’re actually doing this. We’ve only been talking about doing it!”

Samad:            [Laughs]

Rich:                And we’re like, [Laughs] “Really? Why aren’t you doing it? You seem excited, why don’t you try it?” And they’re like, “Well our management’ll never go for this.” And I literally challenge them. I say, “Have you asked them?” They’re like, “Well, I don’t know. We know they wouldn’t go for it.” I’m like, “Go ask them. You might be surprised by the answer.”

Samad:            Yeah. Absolutely. I really believe that a lot of what we talk about in Agile is just about that, is talking about it. Because what you’re talking about is really that you cannot forget the guiding principles and the human side. And all of the non-technical infrastructure, and the non-technical things that you do everyday.

There has to be a mindset behind it. And unless you have that mindset that drives everything, you’re basically going to be engaged in a lot of tactical maneuvers, but you’re really not achieving the real benefit of Agile.

Rich:                Well, and you know, if you go back and really read the Agile manifesto, I think this is a group of people that got together out in Salt Lake City and kind of all concluded the same thing. “You know what guys? We’re not having any fun anymore. This profession should be fun, it should be joyful. We’ve got to do something different. We’ve got to start treating the humans that do this work as humans and not as machines.”

And I think if you boil it all down it gets back to that whole joy thing. These guys—like the rest of us in our industry—wanted to start working on stuff that actually got put out into the world, had high enough quality that they could be proud of the work they did, and that someday later somebody stops them on the street and thanks them for whatever product or service they put together and says, “Wow. You guys worked on that? That’s so cool. You made my life better. It’s so enjoyable to use the software you built.” That’s what we yearn for in our profession.

Samad:            Rich, tell me a little bit more about how you use war rooms.

Rich:                Yeah. So our space is literally just one big open room. No cubes, no offices, no walls, and no doors. I sit right out in the room with everybody else. There’s no corner office for the CEO. It is a noisy, engaging, high energy environment. I can’t tell you, Samad, the number of people who walk in our room literally, and they suck in their breath and they’re like, “Wow!” They literally can just feel the energy of the room.

We had one woman come in one time, she was delivering mortgage documents to one of our team members. And she walked in and she does that. She’s like, “Wow! I don’t know what you do here, but I want to work here someday!”

Samad:            [Laughs]

Rich:                [Laughs] And so I think sometimes we lose sight of trying to create that environment of energy. And I think a war room sort of environment, this open and collaborative work environment, is critical to that.

Now, people often ask me, “Oh my gosh, how can you work out in this noisy environment?” It’s like, “Oh, no. No. The brain is an amazing filter for noise. If you pair two people at a single computer and they’re working on a problem together, their brain just blocks out all the other noise.”

And what I like to say is, when we communicate with one another in the room, we don’t use email. What we use is what I like to call high-speed voice technology: we talk to one another. [Laughs]

Samad:            [Laughs] Again, it’s amazing technology you’re using here.

Rich:                Yeah it’s really cool. There’s vocal cords, and tympanic membrane, and auditory nerve stimulation of the brain. It includes eyebrows and facial expression, and tonal inflections, and body language. It’s very high fidelity communication, and very efficient. And of course when we call meetings we don’t move. We don’t have conference rooms, we don’t schedule meetings in Outlook.

If I want to have a meeting with you I literally call out across the room, “Hey Samad.” You stay in your chair, I stay in mine. If I want to call a meeting with the Dawson team I say, “Hey Dawson.” And the whole team stops working, looks and me, and say “Hey Rich.” Now we’re in a meeting, and none of us moved. If I want to call an all-company meeting—I usually do this on our tours just to demonstrate it.

The room will incredibly noisy. Everybody’s working away. And I’ll step up and I’ll say “Hey Menlo!” And everybody goes, “Hey Rich!” And then it goes dead quiet. Now we are at an all-company meeting and nobody moved.

Samad:            [Laughs]

Rich:                And then I say, “Okay great that’s fine, go back to work,” and they go back to work. So our all-company meetings probably always last less than 45 seconds. Because there’s usually, “Hey Menlo we’re having a team lunch today. How many people are going to stay so we know how many pizzas to order?”

And you get 20 people raising their hands, and you count their hands like, “Okay, we got 20, great thanks, go back to work.” Right? No “cc all emails,” no scheduling in Outlook, all that kind of stuff.

Samad:            You know what you’re doing Rich, here. You are actually ruining work for us. [Laughs] That’s really what you’re doing.

Rich:                [Laughs] I’m doing it under a guise of trying to provide hope for the masses. We literally are trying to save an industry from itself.

Samad:            It’s better we don’t know that this thing existed because now you’re disturbing the entire ecosystem that’s been built over the last 30 years or so of how we develop things. So thanks, Rich!

Rich:                [Laughs] My pleasure.

Samad:            [Laughs]

Rich:                Yeah, it’s true and it is joyful. I can’t describe in words the feeling you get when you come here and see this in operation. I’d love to have you by sometime and show it to you firsthand.

Samad:            Yeah, I would love to visit you guys. And also the area where you live right now, where you guys have your team in Ann Arbor, that’s a beautiful area. And I have good memories of visiting there on campus in the University of Michigan.

Rich:                Well, and not only Ann Arbor. Yes I agree it’s a great town and I’ve lived here for 30 years. I’ve raised a family here. It’s a great town to raise a family in. But we are in the part of Ann Arbor that some people consider to be the most magical part. It’s a little district in downtown of 100 year old buildings called Kerrytown. So we have brick streets, and we’re in this 100 year old brick building.

Zingerman’s Delicatessen—I don’t know if you remember Zingerman’s, but it’s this world-famous deli. It’s literally right across the street from our office. And so it’s just a great part of town as well.

Samad:            Yeah. I have not visited them but I have read about them. And I understand that they’re an amazing little company.

Rich:                They are, yeah. A $35 million a year deli set of businesses. So imagine, no franchises. It’s all right here in Ann Arbor. I learn a lot from them about their culture, too. Because they’re very culture-oriented as well there.

Samad:            And that’s really important what you just said. I think what you have built with your team is not just a company or a team, or an organization. You really built a culture. And I think that for a lot of people that work for you, it’s probably going to be extremely hard for them to go and live somewhere else, and work somewhere else. Because that culture has become engrained in their DNA now, and they will not settle for less than that.

Rich:                Well, let me tell you the worst-case version of this. This is really hard. My daughter worked here as a project manager for about two and a half years, and then she chased love down to North Carolina. And so she’s not living down there. And she had to go out back into the work world and find a real job as a project manager.

And within a few weeks she calls me up. Because she’d never worked as a project manager in our profession except for here at Menlo. She came here right out of college. And she called me up and she’s like, “Dad, it’s just like you said! All those stories you tell, but I just never believed you because it just seemed like good stories. All those stories are playing out right in front of me!” [Laughs]

And she was really sad because she realized, she’s like, “Oh no, I may never ever experience this again unless I come back to Menlo.” And it really hurt—there was a little bit of smiling in my head about, “Yeah, I’m glad you realize now how special this thing is we created.” But it also hurt as her dad. I want her to have joy in her life too.

And I want it to be not just working for her dad’s company but wherever she goes in the industry. And so she’s trying to infect them but I think she learned real early on that she had to stop talking about Menlo. Because she’d get in all these meetings and she’d be like, “Now when we do this at Menlo it goes like this.” [Laughs] And after a while the team would look at her like, “Megan, stop talking about Menlo!”

Samad:            Yeah. [Laughs]

Rich:                So she realized she has to codeword things now and not talk about it like that.

Samad:            Yeah. That’s funny. That’s really interesting. No, it’s really true. I totally understand. Rich, what key takeaways would you like our listeners to take forward from our conversation?

Rich:                Well number one, we make this offer to everybody. Come for a tour. Literally, I don’t think you can truly experience Menlo without being here. So come on in. we do it all the time. We have public tours, we have private tours, we’re doing them once a day. So anybody who wants to come visit, just send me an email. And they can come.

There’s a version of the tour that’s free, there’s a version of the tour that’s longer and includes deeper diving. It’s paid for, but you can do either one. And so that would be one thing.

Number two, there’s lots of free stuff on our website that talks about this stuff. There’s a Free Stuff tab, you can read about us. We’ve got a really fun blog that if people really want to dive in deep they can look at all the blog entries we’ve put together. We’re very passionate about this and we do really want to share it with the world. It’s not like we’re trying to keep this a trade secret to ourselves.

We offer classes as well. If they really want to take a formal dive in we’ve got some 1-day, 3-day, 5-day classes that we teach people our processes. We’re not trying to keep any of this a secret. We have a couple of books out now. One is sort of a picture book guide with words describing each part of our process and then there’s one that’s just a compendia of all the white papers we’ve presented at conferences.

And so there’s a lot of ways they can very inexpensively—or even at no expense at all—learn more about what we do.

Samad:            Could you tell us a little bit about the type of work that you do as Menlo Innovations and give us some examples of the types of project that show how you help your clients achieve their goals?

Rich:                Sure. Yeah. So we are a custom software design and development firm. So basically everything we do is work-for-hire for other companies bringing their projects to us. And so we end up working in a wide range of domains and disciplines. We don’t focus on a technology and we don’t focus on a domain.

So we’ve done Hollywood fashion websites, we’ve done organ transplant information systems at the University of Michigan Health System. One of the big projects we worked on over the last several years is this really high-end data analysis system for a device called a Flow psychometer that counts cells in fluid at the rate of about 10,000 cells a second, 18 measurement per cell. And the scientists need to catalog the effects of drugs on those cells.

So this is an interesting project because the tool, the scientific instrument that we’re supporting with this software, is being used in AIDS research, cancer research cell biology, microbiology, that sort of thing. So very important for mankind that this product is successful in the marketplace. And it’s now deployed in 48 out of 50 states and in seven continents. They even have one of these devices down in Antarctica.

I would say that this particular project is very representative of the effect we have. A venture capital-backed startup who chose to use us as their software team rather than building their own. We had this unique business model that we employ in about half of our clients’ cases that we call a leveraged play.

That is, we will dial our rates down in half not as a discount, but as an exchange for some risk-based deferral. So we’ll exchange it for shares in the company, or we’ll exchange it for royalty. Or sometimes in some cases, both. And so of course that’s kind of neat, right? Because now we’re right in the canoe not only with our customers, but with their investors as well.

Now we’re willing to but our stake in the ground and say, “Look. We’re only really going to make profit on this project if the project actually gets deployed and gets shipped in large numbers, and is enjoyably used by the people for whom it was intended.” Which again gets back to that whole joy component. So we tied the joy right back to the business model.

And I think that’s a really important cultural norm that we have here is, we always look and say everything we do should get back to our cultural model. Our mission statement, if you will. Our clever tagline for a mission statement is, “Our goal is to end human suffering in the world as it relates to technology.”

Samad:            Wow.

Rich:                And so what’s fun about this Accuread psychometers software project that we’ve worked on for the last five years is we are now stopped by people on the sidewalk literally [Laughs] who know we work on that project for Accuread. And they stop us and they’re like, “Wow! You guys did a great job. I use that product everyday. It makes my life better as a scientist.”

And so for us, that’s where the real joy comes in. I mean, the fact that we’re doing this as a profitable growing business is great confirmation that we’re doing the right thing. But after all is said and done, the joy really stems from the users of the software we create stopping us on the sidewalk and thanking us for the work that we did.

Samad:            It’s like turning software engineers into rock stars. Just by the kind of work that you’re doing.

Rich:                Well, and everybody wants that in our profession!

Samad:            Yeah.

Rich:                We all want to be the people that create the thing that somebody says, “Really? You did that? That’s so cool!” You know, that’s what we want. I’ll share my secret. And I tell this to a few people, but one day what I want to do as part of my profession is, I want to build the Starship Enterprise—at least the software part of it. [Laughs]

Samad:            [Laughs] That’s wonderful.

Rich:                A computer you just talk to, you know. Doors that open automatically, you know, communicators, and transporters, all that kind of stuff. You know.

Samad:            Rich, give our listeners again information about how they can contact you and find out more about you.

Rich:                Sure. So I’ll give you my email address, So that’s a great way to get in touch with me personally. We have a couple of twitter IDs that they can follow our tweets. There’s one called MenloPrez, that’s me, And then there’s one just called MenloInnovation.

There’s a blog, And then go into our website. You’re just going to see a lot of free stuff there. There’s a lot of YouTube videos on us. So you can actually go online and search for Menlo Innovations on YouTube, and you will see a lot of videos so you can actually get a chance to get a live action video of our space at work and hear me and some of our team members talk about it.

There’s probably four or five or six YouTube videos online about us now. So you can check it out virtually in that way.

Samad:            Rich, I want to thank you so much for taking the time to speak with us today on the Guerilla Project Management podcast. I really appreciated the message you shared with us, giving us hope that actually we can achieve joy in the things that we do at work. And reminding us of the importance of using what we do and what we create everyday as a way of self-expression. And reminding us of what that’s so important.

I really appreciate your time and I look forward to a future conversation with you again.

Rich:                Great talking with you Samad. Thanks for the work that you’re doing trying to bring these kinds of messages to the rest of the world. You’re doing important work.

Brought to you by: