THE OMNI SHOW

Andrew J. Mason:
You're listening to The Omni Show, where we connect with the amazing community surrounding The Omni Group's award-winning products. My name's Andrew J. Mason. Today we learn how Mikell Taylor uses OmniPlan. Well, hey, everybody. Welcome to this episode of The Omni Show. My name's Andrew J. Mason. Today we have Mikell Taylor. She's a systems engineer and robotics geek, and she's an independent consultant in robotics and unmanned systems. She's worked with Rethink Robotics, Bluefin Robotics, and is currently the principal technical program manager at Amazon Robotics. She utilizes OmniPlan to get a lot of that done. That's why we're talking today. Mikell, why don't you say hi? Tell everyone a little bit about yourself.

Mikell Taylor:
Sure thing. Yeah. My name is Mikell. I have a problem with robots. I've been working in the robotics field my entire career. I started building robots when I was in high school. Somewhere along the way, I realized that in addition to the engineering part of robotics, I also really liked managing these projects. That is where I have ended up today. I'm currently a principal technical program manager at Amazon Robotics. Yeah. It's been all robots all the time for me.

Andrew J. Mason:
That's awesome. Tell me about the story arc that you say happened during high school. Do you remember your first interaction with anything robotic, where you just see something and you're like, "This is awesome, I need to see more of this"?

Mikell Taylor:
Oh, absolutely. I went to an all-girls high school in the Midwest. I was basically a charity project. These college students from Ohio State University in the engineering department came over to our school and then were like, "We've decided there need to be more women in STEM. We want to start a robotics team that's part of the first robotics competition, and we want to start it here. Would you be interested?" My science teacher was like, "You've got a free period this period. Go meet with these guys. Maybe you'd be interested." So I got lumped onto the team that way, but then I fell in love with it. It was my first introduction to what engineering really could be. Definitely my first introduction to robotics and programming and all of that. I had a vague idea that because I was good at math and science, I should be an engineer, but I didn't get what it was until doing it first. Then, yeah, the rest from there was pretty much history.

Andrew J. Mason:
This is so cool. I love hearing this story develop, where you are interacting with robots. You're having fun in this space. Talk to me about this transition that happens, where it's not just I'm doing the tactical day-to-day work with these robots, to now I'm looking at more and managing outcomes that have to do with the results that these robots produce. Talk to me more about how does that transition take place for you?

Mikell Taylor:
Yeah. That's a really good question. My first job for Bluefin Robotics, we made underwater robots. I started at that company. My college degree was in electrical engineering. I was doing some electrical engineering, quality engineering, debugging, that kind of stuff there on a big project for the Navy. They did defense contracting. I was merrily just doing my thing and then started joining some meetings with a systems engineer who was leading them, where it was like, "Oh, I'm getting a look at all parts of the system here. I'm learning about the software. I'm learning about the electronics. I'm learning about the controls theory and the mechanical design behind it." I was really interested in this. The project manager noticed, and he started pulling me in and deputizing me to the lead system engineer. That's when I first was like, "Okay. First of all, I know I like seeing a little bit of everything." I liked the work I was doing in electronics, but I liked seeing all these other aspects of it and figuring out how they fit together. That's why I initially transitioned to systems engineering. I compare that with Neo at the end of the first Matrix movie, when suddenly he can see the Matrix. He can see everything. That's, to me, what systems engineering is. I did that for a couple of years. The systems engineering role at that company was a technical leadership role, working very closely and almost tag-teaming sometimes with the program manager. The more I did the systems engineering and the more I worked closely with the program managers and saw what they did, the more I was like, "You know what? I actually think I like some of what they're doing, too." I was lucky to have a couple of PMs there who took me under their wing, taught me about that, and I found out that I did actually really like it. So I went on that path for a while, doing systems engineering on some programs, project management on others. Eventually, I had to make a choice. It was hard to give up the engineer title. It was hard to give up the engineering hands-on part, but I did it. I have been fortunate enough to be able to work in roles where, when I do want to get my hands dirty, there is usually an opportunity, and it's always a good day.

Andrew J. Mason:
It is really cool starting to hear this story arc emerge, where the previous experience with robotics is starting to inform your level of knowledge for what projects might require as you're beginning to see, okay, we need this amount of resources or this amount of planning, because I know how long these things take. Talk to me about the other side of that, though. How do you start looking into Gantt and more formal project planning? Is this something that you were mentored into or had formal training with? Or just over time, I'm just picking this up and realizing this is what it takes to manage a project at this level?

Mikell Taylor:
Yeah. It was really through mentorship. I don't think I had formal program management training until I did a PMP course when I was a good eight years into being a program manager. I'm on year 16 of my career this year, and I finally took an Agile Scrum Master Course three months ago. So better late than never, but it was very much learning hands-on, on the job. That first job at Bluefin where I had that mentorship, it was defense contracting. It was a very traditional waterfall methodology. Everything's in Gantt charts. They're fully resourced. You're doing earned value management system tracking, very traditional DOD project management. That's where I got my start. Through that, because robotics is, by its very nature, an incredibly cross-disciplinary thing to work on, there's obviously a very heavy software component, which doesn't lend itself well to that traditional waterfall methodology. I saw the struggles because this was in the mid 2000s, before Agile and the whole tech industry, being what it is now, really came into play, where everyone is still really trying to shoehorn a lot of software project management into this traditional model. So you could see the weaknesses. It'd be like, "Oh, we're going to track number of lines of code. We estimate that this feature is 20,000 lines of code, and we're 10,000 lines of code into it. Therefore, we're 50% done. The Navy was struggling with how to understand this. We were understanding with how to communicate it. The software team was like, "This is meaningless." I could see the holes there. That set me up to understand there is a future in figuring out how to do this vault for robotics specifically, where you do have the physical realities of material lead times and building physical things, but you have this incredibly complex self-work component that plays into it.

Andrew J. Mason:
I really like how your experience is informing this role as almost mediator, too, sharing, how can I serve, and what can I do to allow all parties to be in a clear level of understanding here? What advice might you have for somebody that is in project planning at this larger level, but they just don't know necessarily what the first tips or tricks should be? Do you have any go-to advice that you give people when they're just getting started?

Mikell Taylor:
Oh, man. I have so many thought bubbles. How much time do you have?

Andrew J. Mason:
Sure. Yeah, no. We got time.

Mikell Taylor:
I think that there's a couple stages of growth with project management. I will hubristically say it's from good to great. I think the good project managers, they have the skills down. They have the tactical skills down. They can use OmniPlan or Microsoft Project. They can use Jira or another one of those Agile methodology management systems. They know how to make a plan. They know how to understand dependencies. They understand how the scope. That's all table stakes. That is really important stuff to understand and to be good at. But it's not everything. That's just good. Better is when you can do all that, and then you also understand how to roll with the punches. This is actually the fun part of project management for me. It's when stuff starts going wrong. When everything is going right, it's boring. There's nothing for me to do. I just sit there and I'm like, "Good job, team." When things are going wrong, that's when it's fun because now you can use all your skills of rapidly replanning, thinking through, "Did we try this? Did we try this?" It's the debugging aspect, almost, like in engineering, that I enjoyed of how do I figure out what happened here, and how do I fix it? Basically, that's the engineering of a project that I can do that's really fun. Then, great, I think, is where you're really building on your emotional intelligence to build a healthy team, to build a productive team. You're encouraging the growth of their emotional intelligence. That means when you get into those stressful situations where things are going wrong, the team is working together as one, you're getting information you can trust, and they will follow your leadership and your vision.

Andrew J. Mason:
It's funny to me that some of the stuff that's most important that you left for the great category is not necessarily quantifiable. You don't see this information on OmniPlan or in an Excel spreadsheet anywhere. That's really cool to me. Mikell, do you have any recollection of when you first came across OmniPlan or The Omni Group more broadly? Do you remember your first interaction with them?

Mikell Taylor:
I do. It was in, I believe, 2008. I had just become a militant Mac user for the first time. This was when the original Intel-based MacBooks came out. It was very exciting. I had never been a Mac user before. These computers are beautiful. They were so much fun. I wanted to have them, so I bought one personally. Then, when I switched jobs in 2008 and the company was run by a bunch of academics, all on Macs, I was like, "I will also take a Mac." Then I sat down on the first day, and I was like, "Oh, God. I can't run Project." That's when I started looking around for what are my options here, and I came across OmniPlan. I don't know. I mean, if you can fall in love with a piece of project management software, I think I fell in then because it was everything I wanted out of Project but was a much prettier interface. I could work on the laptop that I wanted to. It just became an easy, natural changeover from Project. I've been using it over since.

Andrew J. Mason:
Do you mind placing OmniPlan in an overall context? Are there corollary software that you use that hooks into or out of it? How big of a slice of a pie is it? Can you place it in context there in the overall workflow for us?

Mikell Taylor:
Yeah, totally. I will preface this by saying that one of my tenets of good project management is be exactly as much of a project manager as a project requires. Little ones don't need the full gamut of stuff, and then big ones need all the complexity. So I will go with the worst-case scenario, which is the big projects, the really big, complex ones. In that space, and again, this is something that I think I've developed by way of working in robotics specifically, OmniPlan is about planning the project. It is not necessarily about tracking the project. The reason for that is that, especially when you have all of these different software teams and hardware teams and manufacturing and all these other things, trying to track things on a day-to-day or a week-to-week basis in Gantt form, when half of the teens don't even use that methodology, it's pretty well impossible to do. So it's just not even worth trying to do. What I do with OmniPlan is I create the project plan upfront, based on input from the teams. We have a whole Post-it note exercise we do to figure out the major milestones and dependencies and where they fall chronologically with respect to each other. That is what I start with, the skeleton of the plan in OmniPlan. What I like about OmniPlan is the ability to link all those dependencies in this way that makes sense to my brain. Maybe it doesn't to everyone, but it makes a lot of sense to my brain. It's the dependency management. I can see, okay, if we deliver this feature and do this integration at this stage, but somebody else expected us to have completed that three months ago, we have a problem here. That's what I find so valuable about things like OmniPlan compared to a lot of these other tools. The dependency management and visualization is second to none with that Gantt view. Once I have that and we've resolved any conflicts in the dependency front, then I can start filling in phases and effort and duration. At this stage, because I work so much with software teams, I usually don't resource load stuff. It just doesn't make sense. But at least for the bulk of the hardware work in particular and understanding what the software teams owe the other teams and what those teams owe the software team for integration, the Gantt view is very, very helpful for that. Then I take that. We review it with the team. We make sure that everybody understands it and it makes sense. The plan immediately becomes obsolete following that meeting because that's just how it works. But then we can move on to other tools to manage the day-to-day, week-to-week stuff. Now is the traditional task management, the sprint management, sprint planning sorts of things. Then we go back, and we check in with the overall program plan and OmniPlan once a month or once a quarter to say, "What has changed? Has any of the stuff flipped? If so, what are the implications on everything else?" Again, that view and those dependency links are so important for that.

Andrew J. Mason:
Does being able to see things at that level give you an additional perspective that other people find helpful? Yeah, part of it is your role to serve people in that way. But being able to see, okay, there's dependencies here. A, B and C didn't happen, so therefore X, Y, and Z can't happen. Speak to that a little bit.

Mikell Taylor:
Yeah. Understanding where things are blocked or where things are going to slip is, to me, much easier to see using OmniPlan than other tools. I've tried before to do all the dependency linkages and the visualizations and things like Jira, and it doesn't work. It's not as robust, and you can't do as complex of relationships between work as you can at OmniPlan. I think it's a really valuable tool to look ahead and prepare for the worst, hope for the best.

Andrew J. Mason:
You mentioned some of these unseen factors that show up when managing a team effectively and looking and planning for the future. Somebody doesn't pay attention to those things unless they really do care about being as productive as they possibly can be. What would you say makes you passionate about productivity?

Mikell Taylor:
I think it's the reward of hearing from the teams that I work with that I have helped them by implementing these structures, these mechanisms, and so forth. Prior to my current job, I worked almost exclusively at startups in very early stage companies. I've even been to places where I show up on day one, and they're like, "Yeah, I've never had a project manager before. I don't even know what you do or why I want you here. But we heard we needed one." So, to me, I love that challenge of let me show you how I can help you because I do want to help you. I see project management as a service role. I am in service to the rest of the team. No place I've worked has anyone directly reported to me in a sort of I'm-your-manager-and-I-hire-and-fire-you way. I have dotted line reporting. I have to influence without having the authority of your actual boss, which is really challenging. So, to me, that means I have to put myself in a position of I need to prove to you that I'm helpful. I need to show you that I am going to help you. I need you to notice that your job is easier now that I'm here than it was before. To me, that's why I love these organizational tools, and I like being in that role of doing this work. It helps me bring everything together into one picture and get the team to understand. Oh, now I see the Matrix, too.

Andrew J. Mason:
That's incredible. How much does automation play a role in the work that you do, Mikell? Do you see the same scenario show up every single time? There's only five scenarios. This is number three. We made a template, so here we go. Or is that level of chaos that you say you enjoy as a challenge showing up for you every single day?

Mikell Taylor:
No. Not across my career. I can't templatize it across my career. When I worked for Bluefin doing the defense contracting, there was a standard project template we could come up with because you have a certain work breakdown structure. It equates to certain kinds of work streams that are common since we did one kind of product. So there, I did have a template that I would usually start with. But as I've moved between companies, one of the things about robotics is every time you take a new job, you're in a new vertical. I do e-commerce logistics now. I used to do manufacturing robotics. I used to do telecommunications drone. I did underwater robots for the military before that. The kind of work you're doing, the customers you're delivering to, and the other inputs you have are so different. It's hard to templatize between company to company. Even within my current role, I think the kind of project I manage, it has evolved over time. I joined when it was early stage R&D and technology development. That required something completely different than now, when we're in full-on product development. We're releasing a product and fielding it. Again, I go back to my be exactly the project manager the project needs. For that reason, I don't like to shoehorn it into, wow, this is scenario and this template. I like to just roll with it.

Andrew J. Mason:
Thank you so much for that answer. One more question before we wrap it up. I'm really interested about, is there anything in your journey that you've experienced along the way that ... I always say failure is probably too harsh or not something that you would regret, but that you would just look back and say, "Had I to do this whole thing over again, I probably would have just skipped that slice"? Maybe it's instructional for somebody. Perhaps they can skip that slice, too.

Mikell Taylor:
That's a very interesting question. Yeah, no. It's a good question. I mean, oh, my gosh. If I said no, I would be lying and pretending that I have never screwed up. I think that I will come back yet again to my thing. Be the project manager the project needs. I think that was learned in a trial by fire way because earlier in my career, I occasionally came in swinging, being like, "Here is how we will manage this project. We must create a work breakdown structure. We must do this." It didn't go over well because it was people who didn't have the experience I had. It was different industry, different vertical. Even though technology was the same in robotics, it was people who weren't used to that style of project management. I lost trust and influence that way. Again, project managers have to influence that authority. If you lose that trust and influence, you're screwed. So I think that's it. Learn that lesson early. Learn different ways of managing projects. Learn different scopes of projects. Get a lot of that experience as quickly as you can so that you understand how to tailor yourself for what a project needs. That way you maintain the relationships and trust you need to be successful.

Andrew J. Mason:
That's awesome. Mikell, I'm really grateful for this mindset of service that you're really emphasizing here. Even though this is a software interview and, of course, we use the tools to get the job done, I really appreciate this focus on something that was taking a direction in the conversation I really didn't expect, but in a good way. If folks are interested in connecting with you and what you're up to, how can they do that?

Mikell Taylor:
Well, I am on Twitter for now, @MikellTaylor. You're free to follow me there for my unfiltered thoughts on robotics and project management and a lot of nerdy fandom.

Andrew J. Mason:
That's awesome. Mikell, thank you so much for joining us.

Mikell Taylor:
It has been a pleasure. Thank you for having me.

Andrew J. Mason:
Hey, thank all of you for listening today, too. You can drop us a line on Twitter, @TheOmniShow. You can also find out everything that's happening with The Omni Group at OmniGroup.com/blog.