Andrew and Lisa are Menlonians (team members at Menlo Innovations). They do things different there. And even though they develop software products, the processes they use are supremely applicable to developing hard goods products, as well. Join us as we discuss “the Menlo way” and paired work, kindergarten skills, storycards, and other methods of producing the right product, on budget, and on schedule.
The Being An Engineer podcast is brought to you by Pipeline Design & Engineering. Pipeline partners with medical device engineering teams who need turnkey equipment such as cycle test machines, custom test fixtures, automation equipment, assembly jigs, inspection stations and more. You can find us on the web at www.testfixturedesign.com and www.designtheproduct.com
Andrew and Lisa are Menlonians (team members at Menlo Innovations). They do things different there. And even though they develop software products, the processes they use are supremely applicable to developing hard goods products, as well. Join us as we discuss “the Menlo way” and paired work, kindergarten skills, storycards, and other methods of producing the right product, on budget, and on schedule.
The Being An Engineer podcast is brought to you by Pipeline Design & Engineering. Pipeline partners with medical device engineering teams who need turnkey equipment such as cycle test machines, custom test fixtures, automation equipment, assembly jigs, inspection stations and more. You can find us on the web at www.testfixturedesign.com and www.designtheproduct.com
The Being An Engineer Podcast is a repository for industry knowledge and a tool through which engineers learn about and connect with relevant companies, technologies, people, resources, and opportunities. Enjoy the show.
Aaron Moncur:Hello, and welcome to the Being An Engineer Podcast. Our guests today, plural, are Lisa Ho and Andrew Muyanja. And I should mention that our show today is going to be a little different than it usually is. Lisa and Andrew don't work as engineers know, nor do they work with engineers. Although I guess Lisa does have technically an engineering degree, but we'll just gloss over that part. They work at a company called Menlo Innovations , an innovative software company in Ann Arbor, Michigan. And I've actually mentioned the company a few times in the past on our podcast, because I'm such a huge fan of their operational style. And we will certainly get into that today. Menlo stated mission, which I think is just fantastic is to end human suffering in the world as it relates to technology. So with that, Lisa and Andrew, welcome to the show. And thank you so much for joining me today.
Lisa Ho:Yeah, thanks for inviting us. Yeah, also, Andrew's got, you've got an engineering degree too. And you're right.
Andrew Muyanja:I do, I do.
Aaron Moncur:Right. Oh, the universe must have just pulled us together.
Lisa Ho:Yeah.
Andrew Muyanja:Yeah. my bachelor's degrees in electrical engineering.
Aaron Moncur:Oh, my goodness. Okay, well, this is just perfect. This thing is shaping up to be one of the best episodes ever. Alright. Oh, can can each of you. Maybe Andrew, we'll start with you. And then Lisa, just take a minute or so and give us a quick intro as to who you are and what your background is.
Andrew Muyanja:All right. Thank, thank you. Thank you again, Aaron. My name is Andrew Muyanja. I'm a Senior High Tech Anthropologist at Menlo. I've been at Menlo about six years. Like I mentioned before, my background is in electrical engineering. What that's what I did for bachelor's. And I didn't really practice electrical engineering. I went straight into it and user experience design. I did my master's from the University of Michigan in entrepreneurship. So quite different from engineering, but somewhat related. I'm very excited to be here. This is my first podcast. So it's pretty interesting.
Aaron Moncur:Mine too. Let's see how it goes.
Lisa Ho:I'm Lisa, and I work at Menlo as a project manager. And that was it was my first job out of college. I've been there for about 13 years now. I also have a engineering degree and got into engineering. After talking to my dad and being like, I don't know what to do in college. And I knew I liked math and science. He's like, well, you should go to engineering. And I was like, Okay, so that's how I ended up studying that and realized my senior year, I don't think I want to be an engineer per se. I got really interested in project management, just reflecting on a lot of things I had done growing up that were really project management. And I didn't realize that until my dad helped me figure that out. And so I interviewed at Menlo for project management position, and I liked it so much that I'm here 13 years later.
Aaron Moncur:Fantastic. I'm curious, Lisa, what were some of the things that you did growing up that you didn't realize were project management that actually were?
Lisa Ho:Yeah, the one that really stands out was in my high school, we had a program called the Coca Cola Project where they had basically a project for us. And we were helping promote Coca Cola in the school and doing different things working with Coca Cola, and I got to be the operations director. So I was in charge of the operations department. And so I started a recycling program in the high school and, and looking back, I was like, Oh, I was managing a project through that. And then planning my wedding. Like that was a huge project. But I I enjoy doing those kinds of things. So I was like, Oh, I think this will be a good a good fit for me. So
Aaron Moncur:Cool. Did you even realize back then that there was a profession called Project Management, like that was something you could actually do and get paid for?
Lisa Ho:I did, but I thought like you've got to have tons of experience and all these degree like all this stuff that you've done to get into that, as opposed to this. Yeah, yeah, that's what I really thought I was surprised that men that would interview me straight out of college for a position like that.
Aaron Moncur:I love it. All right. Well, I'd like to start the conversation by talking about a few of the core processes that are so unique to as Menlo calls it, "the Menlo way" and and then later on in the conversation, maybe talk a little bit about how you've adjusted these processes to meet the needs of the virtual COVID world in which we're all now living. So with that mind, maybe, Andrew, let's start with you. You are what Menlo refers to as a high tech anthropologist. Can you share a little bit with us specifically what your role is, as a high tech anthropologist? And the the part that you play in a project?
Andrew Muyanja:Yeah, absolutely. So high tech anthropology is actually a play on words. So anthropology study of intended end users, high tech for the purpose of high tech for the purpose of designing and developing products that work for them, right. And so what we do is if Menlo gets a project, we are responsible for going out into the world to study the people who will be using the end product of that project, it could be a software, it could be a process change, to understand how they currently operate, to understand what the constraints in their current environment are, is their noise? Where they're working from? Is there any post it's themed around? How do they currently execute their job? If we have, for instance, if we are doing a project for logistics, we will go to shipping bays. And we'll observe inbound and outbound logistics coordinators to see how they place orders right now, how do they monitor the progress of those orders? How do they receive products when they show up? How do they look at statistical information around the performance of their orders over certain periods of time? And so from domain to domain, depending on when the project is like, we will go out and study and users bring that data back shared with a client hypothesize on what potential solutions could look like. And then mark up multiple potential ways of solving the problems we identified and then take them back to end users and basically, evaluate conduct what we call design assessments to evaluate those solutions before they ever get into production. So in a nutshell, that is what high tech anthropology is about.
Aaron Moncur:Very well said. I'm curious, as a high tech anthropologist, does your role come into play just towards the beginning of a project? Or are you involved throughout the entire project?
Andrew Muyanja:So that's a great question. We will most of the heavy lifting is done at the beginning of the project, but we will remain central part of the project, because during the development phase, the clan may need to make trade off decisions. So it's like designing a house and then you realize, yeah, maybe I won't be able to afford those countertops that I want to I want to change it from this material for this material. Well, we high tech anthropologists have data from the field that can help the client make such trade off decisions, that he doesn't have to look this way or function this way. But maybe you could do this, because that still meets their needs. And so, and then we also play the role of explaining design intent to developers, whether they're men or developers or developers on the clients team that we're partnering with, well, why did we choose to have the design this way? Right? Because there's always a method behind decisions like that. It's not just what we made up in a conference room somewhere.
Aaron Moncur:I think it's very, very cool that Menlo has dedicated high tech anthropologists I mean, another word for that, at least in my world is an industrial designer, or human factors engineer, human factors designer. And, but at least with the teams that I've worked with, and I've worked with a lot of teams over the years, that role seems to be under appreciated or underutilized, I think. And it's, it's, it's interesting, and I think very telling that Mendel has a dedicated role to fill that need, because most teams, they just don't they wing it.
Andrew Muyanja:Yeah, yeah, it's, oftentimes. So there's a book called, The Inmates Are Running the Asylum. It's a very interesting book. And basically, the thesis of the book is around the troubles of letting your programmers define how the system should work, right? Because the biggest trap in all of that is that they will build what is easiest for them to build, not what is best for the user to use, right. And there's a very, very big difference there. And so, they there is need for a role we have found in order to have a successful project. There is need for a role instead of people whose only concern is to study the user needs is to study the constraints within which they operate is to basically hypothesize potential solutions and test them before they are built. And that's all they're doing. I'm not really wedded to, well, that's going to be very difficult to implement, right? Because the focus is on the user. And we do try to balance business and user needs, right. But the voice of the user is central to that process. Right? Because I think all of us can think of systems we're going to understand. Well, I don't think the software was designed with me in mind, because it's so difficult to use, right?
Aaron Moncur:Human suffering. Yeah.
Andrew Muyanja:Yeah, right. In cases like that, the the engineers designed and built the system the way they wanted to do it, right, potentially doing what we call mirror persona, where you do something that works for you, but does not really consider what the needs of other people are. And we can share several examples as we go along, of where we've seen that come into play.
Aaron Moncur:Great
Lisa Ho:Andrew, I like too how we talk about how high tech anthropology is really missed or risk mitigation strategy. So what we don't want, it's really expensive to build software, we don't want to get to the point where we're building it. And then we realize, oh, it doesn't work, or it's not what they are expecting. You guys do all the hard work to figure out on paper before we spend lots of programming time you work through designs meet with the end user so that by the time the software developers start building something, it's already gone through multiple rounds of user feedback, and we know that what we're building is going to be widely adopted.
Aaron Moncur:That's a perfect segue, Lisa, I wanted to talk a little bit about the PM role at Menlo Innovations, specifically, at least to start with how you communicate with customers, you have these weekly show and tells you're very frequently updating tasks and estimations. Can you talk a little bit about that?
Lisa Ho:Yeah, yeah, um, the, the client is really, I would say, like my pair partner on a project. So I'm working with them, to understand what they're looking to do for the project, what their goals are, and we meet with them, as you said, in this weekly show, and tell them planning. We just had two of them yesterday for some projects. And so in the show and tell meeting, the team is presenting, here's the work that we've done over the past week. At times, we're even handing the software over to them. And they're demoing to our team, the work that we've done. And in that meeting, it's great because we're very transparent, and they see, okay, this is what you did. And then after we show them the work, then we plan what is the next week look like. And we work with a client to lay out the things that they want us to work on over the next week. So we have this weekly cadence where they plan work for a week, then we meet, we demo it, then we plan work for the next week. So it's not, hey, here's the spec, you guys go do the work. And I'll come back in six months and see what the software looks like. So it's, we can, it's really a strong partnership, where we're collaborating with you and making those difficult decisions, every client is going to have, hey, there's not enough time and budget to get all the features done that I want. And the planning game is where they have to make those decisions about, okay, here's all of these tests that I have what's really the priority, what's going to fit in and what's not. And the thing we like about planning game is it's a very visual activity with a client, where they can see the size of tasks, how big they are, they can see their budget, they lay out cards on a sheet that blocks off time for them based on the budget they have. So it's it's very much working, partnering with them. And then throughout the week, when we don't have the after the show and tell them planning game, I'm really representing the client's needs and any conversations with the team. So they'll come up to me to say, Hey, we're going over estimate on this card. And my job, which is really important for our culture is to smile, and say thank you, thank you for letting me know. Because at Menlo, we want to really pump fear out of the room. If I was to say, Well, why are you going over your estimate? Why is this taking so long? What's going to happen the next time the developers go over estimate there? They're not going to tell me? And if I don't have that information, I can't do anything with it, right? So when I have that information, I can talk to the client talk to the team say alright, should we revisit the scope on this? Hey, this card's going over? Do you still want to work on this? So I help to facilitate conversations between the client and the team and help the team with any roadblocks that come up during the iteration?
Aaron Moncur:I think of project management as really focused on two elements and that is managing budget and schedule. Do you define your role any differently than that?
Lisa Ho:I so I like to think about my role a little bit like a wedding planner, or like a cruise ship director. So it's like my job to make sure that everybody who comes to the wedding, they're all happy their needs are getting met, and the wedding is going off like the vision of what was planned and are the cruise ship director who's making sure that everybody is taken care of. So there's a little bit of a HR element in the PM role at Menlo too. We don't have an HR department at Menlo. But yes, it is my job to manage the budget, manage the schedule in the plan. But a big part of the job is also working on being there to support and help the team and serve the team. So there's a servant leadership aspect of the role. One of the things that as a project manager I do is resource planning. And I work with the other project managers each week we decide, okay, who's on what projects who are they pairing with, because we we pair at Menlo so that developers will work with another developer, same with the high tech anthropologists, and all the work that's being done. And we switch the pairs. So Andrew might be on the yocto project this week, and the next week, he moves on to the Bucky project. And that's important, because we don't want to have towers of knowledge, like Andrew is the only person who can do this thing on this project. Because then Andrew goes on vacation, then the project stops. So in that resource planning, we're thinking about, okay, who's looking for opportunities to grow in this area, who really wants to work in C sharp, who's working on growing their consulting skills, or who's got strengths in this reporting tool that would help on this project? So there's a lot of that aspect to or even just observing in a show and tell like, Hey, I noticed that when you are presenting, you seem to be looking at your partner a lot and not looking at the client you're presenting to or, or things like that, there's there's a lot of opportunity for helping grow the team. And that's one thing I really love about the pm role at Menlo too, and supporting the team, like my job is like, how can I help the rest of the team and the project as a whole?
Aaron Moncur:I think you put it really well, using the phrase servant leadership, so manage budget and schedule and servant leadership. That's fantastic. Andrew, Lisa mentioned pairing, and that is one of the core elements at Menlo, that's part of what makes your process unique. Can you talk a little bit about pairing? What is paired programming? Just pairing in general? What, why do you use it? And what are some of the benefits that that you've seen?
Andrew Muyanja:Sure. So pairing is actually quite integral to the women are functions, I would say it's probably one of the one or two things that if you took away men or women or any more, I'm part of the reason for that is we our mission, our mission and human suffering in the world as it relates to technology, right? Touches on a couple of stakeholders, the customers, the users all use the products that we build, the stakeholders will fund the project, but also the software team that does the work, right. And we believe in work life balance a lot, we work 40 hours a week, we don't work nights and weekends. And and the reason we are able to do that, that the reason why Lisa is able to go on vacation and not have to worry about the backlog of the project she's leaving behind is because we work in pairs, right? And there's somebody else who can do what you're doing. So the pairing helps with co0creation, right? You're building quality into the process, as opposed to testing for quality at the end, you're co creating the somebody else, the source and inspection are close together, right? You're spreading the knowledge around and reducing the risk of project failure because a tower of knowledge has won the lottery not hit by a bus. I think winning the lottery is a better example. Right?
Aaron Moncur:That team member goes away
Andrew Muyanja:Yeah, , it goes away, right? And then you can't you really can't do anything about it right? You will be surprised at how many projects come to Menlo because the key programmer has either died or moved on.
Aaron Moncur:Oh, wow, interesting.
Andrew Muyanja:Or he's about to die. And it's like I need somebody to come and help take this over. Right.
Aaron Moncur:Okay, so let me play devil's advocate a little here. So if you're pairing on all your work, does it end up costing twice as much?
Andrew Muyanja:That's a great question. And we get asked that a lot. Right? It depends on how you're measuring, right? Imagine if I had a project, it has three components to with this database guy who is the best in the world, right? There's a front end design front end designer who is the best in the world. And then there is a front end engineer, right? The three of them working together all independently, that they make the greatest product ever, but then one of them just doesn't show up for a month it gets COVID-19. Right? That you can't, instead of even moving slowly, you can't really roll out the product because there is a key component of that, that you cannot you cannot ship the product without right and so do you. It depends on how you're measuring risk and where you want to mitigate your risk. Right. And no, it doesn't cost twice as much in the beginning there is a cost to ramping up right to spreading the knowledge around but once the team gets the hang of it then then really the effectiveness, we will look at, not in terms of efficiency and effectiveness, right? You could be, you could be working efficiently on the wrong things, or using the wrong approach, right. But are you being effective at what you're trying to do? What problem are you trying to solve? Right? Like I mentioned before, a lot of the clients that have come to us have have suffered great consequences because of towers of knowledge. Right? They reiterated their story in the book of a program of a private equity group called Knight Capital Group. He executed code late in the night when he was tired, and traded billions of dollars worth of securities, and the company lost $500 million, and went out of business. Right. And if you think about it, most of the things that are really important in life, like are really like life critical and life, there is more than one person who is involved. Like, imagine if you got onto an airplane, and there was one pilot, you're like, hey, I'm your pilot, and I don't ever have a co-pilot. But I know how to do this. Relax, we'll be fine.
Aaron Moncur:Good analogy.
Andrew Muyanja:Or if you're going to start a jury, right, they're usually, there could be one main physician, but there are other people around them who support that, that life, life and death situation. So it depends on how you measure risk, and what problem you're really trying to solve and your prior experiences. But no, it costs more, but it's not twice as expensive.
Lisa Ho:And I think I'd also add answer to that the solution that we get through pairing is a lot more robust and of higher quality. So your pair partner is there, noticing, hey, you forgot you forgot about this edge case, or helping you think about the problem in a different way. So a lot of the work that the programmers the designers are doing is a lot of problem solving. Like the the program, it's not just sitting at the computer just clicking away at the keyboard, it's alright, how are we going to tackle this problem? What changes are we going to make to the architecture and having somebody else there to work on that problem with you, instead of spinning your wheels, for a long time trying to figure out it makes a huge difference. Like I've noticed certain things where I pair and it's like, oh, my gosh, this would have taken me forever, if I had done this on my own, but your pair partner like helps you like, and you both work, there's energy like working off of each other to come up with a solution. And then like, we find that we get less bugs and things when you got somebody there, reviewing the code as it's been written, we get more quality from the work that we're doing.
Aaron Moncur:So it gets done at least the the risk of it not getting done correctly, the first time goes down, and you end up spending less money on the on the backend, supporting the software and fixing bugs and things like that. And then as you mentioned is just it's more fun to work with others.
Lisa Ho:Yeah, that's right.
Andrew Muyanja:Yeah
Aaron Moncur:There's something to be said for that. A team member that's working by themselves through some drudgery, they might get bored, they might not be very motivated, but a team member who's working along with someone else that just brings some energy to the equation and, and probably the joy I learned from that team, product.
Lisa Ho:Especially even now during COVID, when we're all working remotely from home, we're still pairing. So you're not just by yourself at home all day, you're working like a screen you're up on and zoom or a a call all day with someone and it just makes it easier. And it's less lonely, getting to pair with someone all day
Aaron Moncur:Interacting with another human.
Andrew Muyanja:Yeah. And I think also the flexibility, right, so we work with a company down in Tennessee, who are applying high tech anthropology to process change, they, they have a huge business directive from their headquarters out in Asia, that you have to grow twice as much in the next three or four years, right. And you have to work twice as much in profitability, right. And so they can scale up their current processes, because then they have growing because they just do, you don't want to just keep on hiring people so that they can grow because every engineer you hire is X amount of dollars, no release from your bottom line, right? So they have to be able to do more work and increase their profitability with less people. And they were very intrigued with minerals processes. They were very intrigued with the pairing process and making work visible, etc. And part of what we're telling them about is not measuring the individual efficiency of a single person, because if you optimize for the efficiency of one person, right? It's again, imagine if they handle optimizing their efficiency, but not really thinking about the rest of the body, you can't really drive the car right? Or if you have the best engine and you have the best. You have to work as a system, right and, and so pairing helps us optimize for the efficiency of the efficiency and effectiveness of the entire organization as a unit, not one single engineer who is really really good. And if they're there, then you do work. If you're not there, then you can't really do anything. So that workforce flexibility is ultimately what we ended up helping them with. How do you create a flexible workforce, right? To be able to execute on the things that you need to do?
Aaron Moncur:Well, this is a good time to take a quick pause and share with the listeners that test fixturedesign.com is where you can learn a little bit more about our company pipeline and how we help engineering teams who need turnkey custom test fixtures or automated equipment to assemble, inspect, characterize or perform verification or validation testing on their devices. Today, we're speaking with Lisa Ho and Andrew Muyanja of Menlo Innovations. And another key principle at Menlo Innovations is developing a culture that fosters joy in your work, what what are some of the tools that your team uses to do this?
Andrew Muyanja:So I think joy for the end user is high tech anthropology, right? You make sure that you consider the needs of the people you're designing for, rather than competing amongst yourself to discuss who is the best designer since Steve Jobs, right? Because the customer doesn't really care about that, right? That's joy for the user. Joy for the business that is funding the project is avoiding stories that we've had over and over and over again, where one insurance company will work with the ad spent about $2 million on a project, spent about two years building it, deploy it for two years, realize the thing wasn't working for end users and they killed it. After $2 million spent right, that's not that's not joy. Right. So how do you avoid things like that? Right.
Aaron Moncur:Lisa, I'm sorry to interrupt. And Lisa, you had mentioned something that was really interesting. Fear kills joy. How do you pump fear out of the room?
Lisa Ho:Yeah, the biggest way I see us doing that is mistakes. We say make mistakes faster. So we encourage it's okay to make mistakes. Not the same mistake over and over again, obviously. But if a mistake is made, there's no punishment. There's no like scolding. Or why did you do that? And and that's huge. When I first started at Menlo, I remember a few weeks into the job, a person I was pairing with. And I sent an email to a client that the client was not happy with, I found out afterwards. And if, in that moment, I had been, punished or scolded for that I would be walking on eggshells the rest of my time at Menlo. But instead, we sat down said, Okay, here's probably why the client interpreted this email in this way. And next time, let's think about doing it this way instead. And it was a learning opportunity. And I just felt very supported by the team. So when a mistake is made, it's owned by the team. And the team helps each other, we coach each other. We are responsible for giving each other feedback, but it's done in a way where you know that the person's giving you feedback, because they care about you, and they want you to succeed. So even though it's hard sometimes to give critical feedback, when I do it, it's because I care. So I think that's a huge part is that I feel very supported by the the team.
Andrew Muyanja:I think I'm the fact that I would add to that will be transparency. It's very one every every team member knows exactly what is expected of them. When you walk into Menlo, well, now virtual we come into work, you know exactly what tasks you're supposed to be working on, you know exactly who you're supposed to be working with. You know exactly what the priority of those tasks is. You know exactly how you get promoted at Menlo. The team makes hiring, firing and promotion decisions. The criteria for that is very clear. You know what happens when a mistake happens, right? There's no ambiguity and reducing ambiguity and making it an increasing transparency removes the, because, you know what is expected of you?
Aaron Moncur:That so that's really interesting. You mentioned that the team contributes to personnel, hiring and promotion decisions. How does that work? How do you as a team decide that okay, this person is going to get promoted, but that person's not, and we're not going to hire this person, but we are going to hire that person. What are the some of the tactical details surrounding how that how that process works?
Lisa Ho:Yeah, that's a good question. I would one thing I have a call out and I would say is it's not easy and we don't have it perfectly figured out for sure. I would say there's a lot of values and guiding principles that we have defined as being important for men, Lowe's culture. So there's certain things that we're we're looking for in people. And when we are interviewing, a lot of it is through pairing. So even interview candidates, we pair them together and we observe how they pair because pairing is such an important part of the mental culture. It's important that as we see that you're able to pair with someone. And I would also say in terms of promotions, it's the people that are working with you that are observing the skills that you're bringing the ways in which you're growing. It's your peers that are making those decisions. So we're all looking out for each other. And we've set some guidelines of this role. These are the things we're looking to see. But everybody, we also recognize everybody's different. And they're all going to bring different things to the team. And we don't want 20 Andrews or 20 Lisas, we want one Andrew, one, Lisa, and we know that you're each gonna bring different things to a project and and to Menlo, as a whole. But I think we look to see patterns of behavior, and we're ultimately looking to see, are you providing more value to the client? And are you also helping grow the team? So to be a senior team member at Menlo is? One of the big questions we ask is, does the rest of the team perform better on a project when you are a part of that project? So it's not about you, and just what you are skills that you're bringing, but it's how are you helping grow the rest of the team?
Aaron Moncur:Okay, Lisa, a project management question for you, though, Menlo website states that there are no big surprises near the end of a project. And I've found that developing tools to communicate to the team internally and also to the customer. What percentage of the budget has been spent is is fairly straightforward. But something I found to be much more challenging is determining what percentage of the project has realistically been completed? Right? I mean, I can say that half the budget has been spent, but how do I really know that half the project has been completed? Do you have any tools that your team uses to gauge whether you're 50% done? 75% done? 90% done? How do you, how do you manage that aspect of a project?
Lisa Ho:Yeah, that's a really great question. Especially because a lot of times everybody has different ideas in their head about what it means for the project to be done. So there are a lot of tools, I would say that we use, and it really depends on the client, and what they're reacting to what helps them to see where I'm at on a project, sometimes what we'll do is have the screenshots of the application that we're building, and we will actually mock up and indicate for them on the screens, what parts of the application have been built out. Other times, we'll use a tool called a story map. And a story map is a really nice tool that lays out different layers of functionality across an entire application. And you forced the client to make the tough decisions to say, what is going to be in and out for this, maybe MVP that we're looking to build. So we have, with our process of writing story cards or work packages for everything that could be done, we'll have maybe 10,000 story cards for our largest project. And it's probably only maybe 3000 of those will ever get played. The client has to decide which 3000 of those story cards are going to make it so that Yep, this is the complete product that we need. And story mapping is a tool that we use sometimes to get them to go through all of those. And they have to say, Yep, this one's in this one's out. And it's something that we're revisiting every week when we do that planning game with them. I would say it's easy to say, yes, this this product needs to have reporting. Okay, but when we get to all the details, okay, does the report need to display up to how many decimal places? Does it need to handle different languages? Does it all of those little nitty gritty decisions? That's what's helping form? What percent? Are we done or not? Can we consider this feature done? And a lot of times for us the A lot of times we have here's a budget, or time and materials next not fixed bid, but a lot of clients expect this is the budget that we plan for, this is what we need to finish this product in. So a lot of times the budget that's left is also helping them inform their decision of what does it mean to be done for this product? Like maybe we wanted to get all these these features in but we're not going to have time to do it. So what is complete look like we're constantly revisiting each week, what is what is done?
Aaron Moncur:Tell me more about the story card. So my understanding is a story card is is something, previously, it was actually a card a piece of paper, but now maybe it's digital. And any time a new task comes out for the customer mentions, I'd like to do this or maybe a team members suggest we should do that. It gets written down onto a story card. And then what at the end of the week, or maybe the beginning of the next week, you review these story cards with the customer and they tell you what they want to do.
Lisa Ho:Yeah, yeah. So we'll estimate all of the story cards so that we can provide the client with a sizing of how how much would it take to do we think that it would take to do this feature. And a feature might be one story card and might be a number of story cards, and then normally do the planning game with the client, they're going through the story cards and deciding which ones they would like to prioritize. And which ones they say, Ah, yeah, this is nice to have, but we're not going to play this right now. So it's the nice thing about the story card is you can capture anything, you can capture any like, oh, here's a bug, we just saw, we're gonna write this down, it's not a big deal. It's a low priority, but at least we're capturing the card. Just because a card has been written doesn't mean it's ever going to be worked on, are only going to work on cards that were authorized by the client. But it's a way of capturing and remembering a potential requirement.
Andrew Muyanja:I think, I'm sorry
Aaron Moncur:Go ahead
Andrew Muyanja:I think that another, a lot of your listeners are engineers. So they will probably be very familiar with lean. This is a principle in lean that if you want to increase the flow of work through a system, you have to do three things, you have to make work visible, you have to reduce your batch sizes. But you also have to build quality into the system, right, we've talked a lot about pairing, and that's building quality into the system. And we have several other steps like that shawntel, etc. But reducing batch size is really what storica is all about right? It is much easier for you to see more tasks executed if you break them into smaller chunks, right. As opposed to saying, go build is such engine for I don't know, a system that allows John to book a flight instead of looking at it that way. And measuring a lot you say, John can search for destination city, right, that's a story got a small chunk of that, John can indicate his desired departure date and time, that's a story card, right. And so because the chunks are smaller, you can catch mistakes faster, you can you're going through the loop, the plan, do check act loop several times, probably up to 1000s of times on a project. And so that's storica does allow us that that level of granularity allows us to be able to catch mistakes faster to increase flow, for client for the client even see the progress of the work, right, because they are involved in a weekly basis, maximum to weekly iterations run for one to two weeks, and the evaluating what has already been done. And at some point, it ends up even being almost irrelevant, what percentage of work has been completed percent percent complete matrix itself, so becomes somewhat not as important as what they're actually seeing and using and what's available to be rolled out. Because you don't have to roll out the entire project at once you could roll out a release that has a small subset of features. And then you can keep doing the incremental releases, like what DevOps proposes?
Aaron Moncur:And what what role do individual team members play in deciding what that task is? I understand. Sometimes the task comes from the client, or sometimes it's suggested from the internal team. But when one of these tasks is assigned, is it the project manager that says, okay, team member a, I want you to spend 10 hours doing this this task and team member B, you spend 15 hours doing that task? Or is it the team member that says, Okay, I see what the task is the project manager, you need to assign me 12 hours to get this done? How does that interaction work?
Lisa Ho:Yeah, so the developers are the ones determining their estimate. So I do not have a programming background. So I don't ever tell them, You need to spend this much time and get this done. They we do estimation session with the team each week and the pairs that will be working on a project and the next week, they're the ones doing the estimation of tasks for that project. So I will have a list of cards that the client might be interested in playing for them. And each pair will estimate how much time do you think it will take you and your partner to complete this task. And then when a client authorizes tasks, I will assign whoever I assign it to, I will give them their estimate. Does that makes sense?
Aaron Moncur:That makes total sense. Yeah. How much is, it's a subjective question, but I'd love to hear what both of you think about this. How much does Menlo rely on on people versus systems to ensure work gets done properly? Do you think you're biased one, towards one side or the other? Is it pretty even split?
Andrew Muyanja:That's a that's a great question. I think that if I was to choose, where does it skew towards? I think it is systems systems thinking a lot of our processes really middle and runs on those processes now that people play in those systems, right? And the people define what those systems are the people can change what those systems are, right? But the systems are really what that's what makes us different. The mental processes what makes us different, because they, the trick is that, and Rich writes about this in his book, Chief Joy Officer when things go wrong. Some companies blame people. But really successful companies blame systems which
Aaron Moncur:Inside, yeah.
Andrew Muyanja:Failed us for this to have happen. Right? Because people are not in there's no one who's like, inherently bad. I guess there are people like that in the world, but it will be very difficult for such people to make it through to Menlo. Right. So if we have good team members, and we have good staff, right, what systems went, What went wrong? What systems did not, did not catch the mistake sooner what systems allowed this incentivize this bad behavior to happen? That's my thought on that. I'm curious Lisa thinks.
Lisa Ho:Yeah, I agree with you that it's the system, the the system's thinking. I think that all the systems that we have in place is what allows us to all work so well together, because we have the same shared understanding of how we're doing the work that we're doing. So I think that I've seen when we've done projects where a part of our we're not following a part of our process, for some reason, it always call it causes us challenges. And but I think we rely on this the systems and that's what allow us to work together so well.
Aaron Moncur:All right, I have one more question. And then we'll wrap things up here. Can each of you tell me about or doesn't even have to be both of you feel free to jump in whoever feels more strongly about this. But tell me a little bit about the kindergarten skills? What, what's that all about?
Andrew Muyanja:I think, I think kindergarten. Menlo, we are very intentional about what kind of culture we want to be right. We're very intentional. We know that collaboration plays a very big part of that culture. It's a decision we have made as an organization. And having kindergarten skills is critical to being able to collaborating with others, right? Do you share the keys? So we do pairing right? One keyboard? One mouse? Right, two people? Are you willing to share the load of passing the keyboard back and forth? Or do you want to drive the whole time as we call it? Right? Do you want to if we had a conversation, right? Do you want to dominate the conversation and talk over people all the time? What do you allow them space to also contribute? Right? So the kindergarten skills are really about being a good human and being considerate of those around you? Are you willing to receive feedback, right? If you if you mess up? Are you are you willing to receive feedback and take action on it? Right? And are you willing to give feedback, even though it's very uncomfortable, it's probably one of the toughest things I've had to do. And giving critical feedback is difficult. And I'll give it in a way that is useful, right? That is focused on the behavior, and what the behavior made you feel rather than the person being bad, right? Right, right. And just defaulting to fundamental attribution error that that person is evil, because they did X, Y, Z. No, they did this. This is a story I told myself. And is that story true, and you give them a chance to explain themselves as opposed to you just jumping to conclusions? I think that's what kindergarten school is all about. Lisa, I'm curious what your thoughts are.
Lisa Ho:Yeah, I just love sometimes our CEO Rich, she's actually asked team members to bring in their kindergarten report card, or their child or their parents and so he's actually read out loud some of what's on a kindergarten report. And if you read it, it's Yeah, do they play well with others? Do they listen? Well? Do they wait their turn? Just like all those things that you read it? You're like, yeah, these are actually pretty important skills to have.
Aaron Moncur:I love that.
Lisa Ho:Yeah.
Aaron Moncur:And that's actually part of your your interviewing process, isn't it?
Lisa Ho:We tell him it's interesting in the interview process, we tell people this is exact this is what we're looking for, like your job is to make your partner look good to work with your partner. And, and even though we tell people that you can, you can observe Who are the people that are really are demonstrating those kindergarten skills and who are the people that are steamrolling their partner or just trying to get their work done as quickly as possible or things like that?
Aaron Moncur:That's huge. Yeah, that's such an important mindset. Well, Lisa, and Andrew, thank you so much for spending some time with me today. This has been fantastic. I just I I'm a huge fan of the Menlo way. I'm still learning more about it. But everything I've read everything I've heard, it just resonates really strongly with me. So thank you for sharing some of that. You actually have at Menlo, a very strong and robust training program or set of programs. Can you tell us maybe what are some of the more popular training courses that you have? And how can people learn more about that?
Lisa Ho:Yeah, so we, in the move to fully remote work, have started offering a lot of the in person activities that we did and workshops are now offered remotely. One of the easiest ways to get involved. And Aaron, you actually have done this is to take a virtual tour of Menlo.
Aaron Moncur:I have. It was fantastic. Yeah.
Lisa Ho:So we love to show people. How are we still collaborating as a team working together to solve problems accomplishing work? What does visual management look like? remotely? All these things through our 90 minute virtual tours? So if you go to menloinnovations.com, menloinnovations.com, you can look at our tours and workshops page and check out our virtual tours. We also have workshops that we do and in high tech anthropology, and also in project management, those run every month. And recently, we've started doing a virtual book club, actually, I think might have been Andrews idea. Or people that have read our CEO Rich has written two books, one called Joy Inc, which is about the business value of joy. So it's a book on joyful culture. That's offered once a month. And we're also soon going to be offering a Chief Joy Officer book club as well. That's Rich's second book that's about joyful leadership. So we'd love to have you guys check out any of those things.
Aaron Moncur:Fantastic. Thank you. And for those who are interested in engaging with Menlo on software development projects, the website is menloinnovations.com. Is that right?
Lisa Ho:Yep.
Aaron Moncur:Perfect. Okay. Well, Lisa and Andrew, thank you so much. Again, this has been this has been awesome.
Lisa Ho:Thanks for having us.
Andrew Muyanja:Yeah, this was amazing.
Lisa Ho:A lot of fun.
Aaron Moncur:I'm Aaron Moncur, Founder of Pipeline Design & Engineering. If you liked what you heard today, please leave us a positive review. It really helps other people find the show. To learn how your engineering team can leverage our team's expertise in developing turnkey custom test fixtures, automated equipment and product design, visit us at testfixturedesign.com Thanks for listening.