Being an Engineer
Being an Engineer
S7E1 A Joyful Approach to Product Development | Lisa Ho & Andrew Muyanja (Menlo Innovations)
This episode is a rerun.
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.
Download the Essential Guide to Designing Test Fixtures: https://pipelinemedialab.beehiiv.com/test-fixture
About Being An Engineer
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. We feature successful mechanical engineers and interview engineers who are passionate about their work and who made a great impact on the engineering community.
The Being An Engineer podcast is brought to you by Pipeline Design & Engineering. Pipeline partners with medical & other 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.teampipeline.us
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 floral 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, nor do they work with engineers. Although I guess Lisa does have technically an engineering degree, but we'll just kind of gloss over that part. They work at a company called Menlo innovations and innovate 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, I'll throw on Andrew Scott, if you've got an engineering degree too. And in your back pocket, right.
Aaron Moncur:Oh, the universe must have just pulled us out together.
Andrew Muyanja:Yeah. Yeah. my Bachelor's degrees in electrical engineering.
Aaron Moncur:Oh, my goodness. Okay. Well, this is just perfect. It's shaping up to be one of the best episodes ever. All right. 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 been at Menlo about six years. Like I mentioned before, my background is in electrical engineering. 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 and 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:to 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 kind of figure that out. And so I interviewed at Menlo for a project management position. And I've 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. 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 these Yeah, that's what I really thought I was surprised that Menlo 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, too, as Menlo calls it, the Menlo way and then later on in the conversation, maybe talk a little bit about how you've adjusted these processes to meet the needs of, of the virtual COVID. world in which we're all now living. So with that in mind, maybe Andrew, let's start with you. You are what Mendo 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 kind of 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 your intended end users, you know, I take for the purpose of high tech for the purpose of designing and developing products, I 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 there a noise? Where they're working from is any post it's themed around? How do they currently execute their job? If, for instance, if we're doing a project for logistics, we will go to shipping bays, and we'll observe inbound and outbound logistics coordinators to see how do 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, you know, statistical information around the performance of their orders over certain periods of time. And so from domain to domain, depending on what the project is like, we will go out and study and users bring that data back shared with the 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 or 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. Very well said.
Aaron Moncur: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 kind of 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 client 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. And I want to I want to change it from this material to this material. Well, we high tech anthropologists have data from the field that can help the client make such trade off decisions, that you know, it 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 Mendel 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 at least what 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 under utilized, I think, and it's, it's, it's interesting, and I think very telling that mental has a dedicated role to fill that need, because most teams, they just don't they kind of wing it.
Andrew Muyanja:Yeah, yeah, it's oftentimes. So there's a book called The inmates 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. They're not really wedded To Well, that's gonna 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've gone to and say, Wow, I don't think the software was designed with me in mind, because it's so difficult to use, right?
Aaron Moncur:human suffering.
Andrew Muyanja:Yeah. 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 that really consider what the needs of other people are? And we can share several examples as we go along, where we've seen that come into play.
Lisa Ho:Great, enter, I like to how we talk about how high tech anthropology is really a myth 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 Intel's your very frequently updating tasks and estimations. Can you talk a little bit about that?
Lisa Ho:Yeah, 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 until 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 does the next week look like. And we work with the 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, you know, 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 until I'm 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 scope or 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 is 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 is is really focused on two elements that is managing budget and schedule. Do you define your role any differently than that?
Lisa Ho:I so I kind of 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 ships who 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 to we don't have an HR department at Menlo. But yes, it is my job to manage the budget, manage the schedule on 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 Yampa project this week. And then 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 strength, strengthen 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 things like that, you know, there's there's a lot of opportunity for helping grow the team. And that's one thing I really love about the 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 integrated. The women are functions, I would say it's probably one of the one or two things that if you took away men or wouldn't be men or anymore, 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 who 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're able to do that, that the reason why Lisa is able to go on vacation, and I'm not have to worry about the backlog of the projects she's leaving behind is because we work in pairs, right? And they somebody else who can do what you're doing. So the pairing helps with co creation, 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:Right? And then you can't you really can't do anything about it right? And you will be surprised at how many projects come to manual because the key programmer has either died or moved on. Oh, wow. Interesting. Oh, 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 doesn't 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? If imagine if I had a project, it has three components to it, 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, you know, they make the greatest product ever, but then one of them just doesn't show up for a month he gets COVID-19. Right? That you can't, instead of even moving slowly, you can't really roll out the product because there's 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 were looking 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? The rich writes a 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 in life, there's more than one person who is involved. Like, imagine if you got onto an airplane, and there was one pilot, you're like, you know, hey, I'm your pilot, and I don't have a co pilot. But I know how to do this. By
Aaron Moncur:analogy, like, if you're going to
Andrew Muyanja:Jerry, right, they're usually, you know, there could be one main physician, but there are other people around them who support that, that life, you know, 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 programming, 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 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 think we find that we get less bugs and things when you got somebody there, you know, 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, you know, the back end, supporting the software and fixing bugs and things like that. And then as you mentioned is just it's more fun to work with. Yeah, 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 watched from that team, product,
Lisa Ho:especially even now during COVID. When we're all working, you know 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 Zoom or a you know, 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, and who are applying high tech anthropology to process change the, 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 grow twice as much in profitability, right. And so they can't scale up their current processes, because then they're growing the cost, 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 reduce 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 mundlos processes. They were very intrigued with the pairing process and making work visible, et cetera. 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 the hands are 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 know, 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 fixture design.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 yourselves 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 we worked with that spent about $2 million on a project, spent about two years building it deployed for two years, realize that thing wasn't working for end users and they killed it. After $2 million spent right, that's actually that's not joy. Right. So how do you avoid things like that? Right.
Aaron Moncur: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 of 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, you know, punished or scolded for that I would be walking on eggshells the rest of my time at Menlo. But instead, we sat down and 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 is 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 a part of 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 or now virtually 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. That team makes hiring, firing and promotion decisions. The criteria for that is very clear. You know, what happens when a mistake happens, right? There is 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, you know, 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 would 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 Menlo is 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 kind of 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 you know, 20 Andrews or 20 leases, we want one, Andrew and 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, at least a project management question for you, though, Menlo website states that there are no big surprises near the end of a project. And I 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, you know, 50%? Done 75%, or 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 movie MDP that we're looking to build. So we have, you know, 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 you know, it's probably only maybe 3000 of those will ever get played. The client asked 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 type of materials. Next, not fixed bed, but a lot of clients expect this is the budget that we plan for this is what we need to finish this product. And 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 cards. So my understanding is a story card is is, you know something? Previously, it was actually a card a piece of paper, but now maybe it's digital. And anytime a new task comes out for the customer mentions, I'd like to do this or maybe a team member suggests we should do that. It gets written down into 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've captured a card. Just because a card has been written doesn't mean it's ever going to be worked on, we're only going to work on cards that were authorized by the client. But it's a way of capturing and remembering a potential requirement. I think,
Andrew Muyanja:I'm sorry, I think that another, a lot of your listeners are engineers. So they will probably be very familiar with Lean, there's 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 Shauntel, etcetera. 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, of a system that allows John to book a flight instead of looking at it that way. And measuring Allah, you say, John can search for destination city, right, that's a storica small chunk of that, you know, 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 story cards 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 on a weekly basis maximum to weekly iterations around for one to two weeks, and evaluating what has already been done. And at some point, it ends up even being almost irrelevant what percentage of work has been completed, the percent percent complete metric itself sort of 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 release is sort of 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 product 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. 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 pair partner to complete this task. And then when the client authorizes tasks, I will assign whoever I assign it to, I will give them their estimate. Does that make sense?
Aaron Moncur:That makes total sense. Yeah. How much is kind of a subjective question, but I'd love to hear what both of you think about this. How much does mental rely on on people versus systems to ensure work gets done properly? Do you think you're biased? One, you know, 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 asked 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 do that's what makes us different, the mental processes what makes us different, because they the trick is that And Rick writes about this in his book, chief data officer when things go wrong. Some companies blame people. But really successful companies blame systems which failed us for this to have happened. 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, you know, did not catch the mistake sooner what systems allowed this incentivize this bad behavior to happen? That's sort of my thought on that. I'm curious what these are things?
Lisa Ho:Yeah, I agree with you that it's the system, 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, you know, 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, uh, 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 it 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's that all about?
Andrew Muyanja:I think I think midlaw 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 key? 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? Or 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. Giving critical feedback is difficult and, and giving 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? Rather than just defaulting to fundamental attribution error that that person is evil, because they did XYZ. 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. This, I'm curious what your thoughts are.
Lisa Ho:Yeah, I just love sometimes our CEO rich, he'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:Love that? Yeah. 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 the 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'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? Yeah, so
Lisa Ho: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've actually have done this is to take a virtual tour of Menlo. I have. It was fantastic. Yeah. 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 Menlo innovations.com, and ENL o innovations.com. You can look at our tours and workshops page and check out our virtual tours. We also have workshops that we do in in high tech anthropology and also in project management and those run every month. And recently, we've started doing a virtual book club, they actually 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 Menlo innovations.com. Is that right? Yep. Perfect. Okay. Well, Lisa and Andrew, thank you so much. Again, this has been this has been awesome.
Andrew Muyanja:Thanks for having us. Yeah, this
Lisa Ho:was amazing. A lot of fun.
Aaron Moncur:I'm Aaron Moncur, founder of pipeline design and 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 test fixture design.com Thanks for listening
