AI-Empowered Thinkers

Wade Erickson (00:04):

Welcome everyone to another episode of Tech Leaders Unplugged. Today, we're going to get unplugged with, with, Melissa Daley, the president and founder of Orca Intelligence. And our topic's going to be AI empowered thinkers. And so, you know, we get a lot of, media around ChatGPT and all these things that help us where the AI's doing all the thinking. Well, this is really about, you know, how the human is being assisted by AE and ai, and they're still, you know, driving the, overall flow of, of, of the work. And it’s, just enablement, of the, the person instead of the, the AI driving the solution. So, thank you so much, Melissa, for joining us today and sharing your experience and, your thoughts in this area with our community. And, yeah, let's quickly just give yourself, a little quick introduction to yourself, a little bit about Orca Intelligence, and then we'll jump into the topic.

Melissa Daley (01:14):

Sure. Not a problem. Thank you so much for having me, and thanks everyone for joining. I appreciate the opportunity to be with you all and share on experiences from my professional experience and being the founder and owner of Orca Intelligence. Just to kind of give you a background about where I've started in all this, I have about I don't know, 20 something years, 20 plus years in it specifically. 90% of that is in software de development, specifically digital transformation, whether it's systems integration or custom solution. And what got me here is it was really, it's really interesting because I had my first internship, yes, I'm, I'm dating myself. It's a long time ago. It was like when there was Windows three one and Lotus Notes. And so from IBM and during that first internship, I was told that, you know, computers are going to be the wave of the future. You should, you know, try to look at being in some type of computer field. And I was like, okay. You know, at first I've always just wanted to have my own business and so forth. So I was going to school, going to college in order to be a business major. And because of that internship, I changed it. I changed computer information systems, and I didn't know how good I was at being an engineer until I I, I would say not until maybe even recently, but when I changed my major gave me both the business side and the computer side. So I, and I've always wanted to be an entrepreneur. I've never necessarily, I've come from a line of entrepreneurs and so forth. And so this was an opportunity to look at an industry and say, okay, so how is this industry going to change within the next 20 years? And where can I put my foot in it? Right? So that's me. It's being a 20 something year old saying, I need to find the opportunity within this industry. That's really what got me to the Orca intelligence, right? Like, I've had a couple of businesses before this. But in order to really try to identify how I could be a player in the market, speci specifically this market, I had to think far ahead. So Orca Intelligence has been a vision for a very long time. And the vision of Orca Intelligence has always been to be a boutique artificial intelligence organization, right? Like, that has always been the vision before, you know, your generative AI and all of that, right? Like officially, Orca Intelligence did start in 2014, but there were plenty of other steps prior to 2014 of the foundation for Intelligence. And one of those things was working for organizations like Accenture and Booz Allen and ICF and some other, you know, nonprofits and other commercial organizations working for those organizations and switching between those organizations and finding out they were asking me to do the same things over and over again. And specifically one of those things as a systems engineer or systems analyst at the time, was to create requirements for software that were similar in nature, right? So when I say I didn't know that I was good at engineering, my engineering brain had to find patterns, right? So I was finding patterns in the documentation that I would either have to architect or write or design, and I would find those patterns through different projects I was on. So I would be able to leave a job and then basically take those transferable skills and build another job and do the same exact thing based off of what I did at another place. And I was like, okay, wow, these people want to pay me a lot of money to do the same thing. This is excellent. Okay, great, right. So I was like, well, I could make a business outta this, right? Like, why isn't there a briefcase per se, that I can take to every single project that I'm on and reuse this information in order to design some type of software? And so I was able to recognize that early on, but then I couldn't figure out how do I develop this? Like how do I, how do I, you know, create this type of solution? And for years, I'll tell you, for year, so when I had the idea, probably about maybe eight to 10 years before I started working Intelligence, and I had the idea, I gave up on it, I was like, I don't think I should do it. There's no way. I don't have the time I want to get married. I want kids, blah, blah, blah, blah. I don't think it should be me, right? And then I said, I still want to, you know, start a business. I want to do my, you know, my business and so forth. I started a nonprofit years ago, and a for-profit organization. They both kind of did the same things to a certain extent. And then I merged them into Orca Intelligence after dissolving those businesses probably about five years prior. Again, I still have the itch to try to figure out how can you streamline the information? How can I streamline the, the requirements management process, the requirements elicitation process, so that whenever I'm on these projects, I can just press a button and I don't have to be asked to do these things over and over again. The one thing that I don't like is to repeat myself, right? Like, I don't think anybody likes to do that, especially when you're an engineer, you're just like, I solved this problem. Why do I have to solve it again? Give me another problem to solve, right? So I, so that's generally the, the impetus to why I like to structure requirements that way is because I think requirements should have a framework, just like software, like software has a framework for you to pull from. If you're in, you know, GitHub and you need a, or any type of, you know like lamp framework or whatever type of framework that you want to design, mean, whatever type of framework you want to design your system in, there's a framework for software developers. There's a framework for testers. There's all these different frameworks, but the one thing that there was very, a generally small sphere of frameworks for requirements. And so I built the framework, which is Pam, so we'll talk about that. So the plan, analyze, manage framework. And so with that framework, I was able to create a repeal process, and then I did it in Excel first, and I did it in access, Microsoft Access and so forth when I was working for different companies. But I didn't do it to the level of detail that I really, really wanted it. And then that's when I, I basically jumped, I just quit my job and was like, okay, well, we'll find somebody's going to hire me to do some independent work. And then that's how work intelligence started. And then from there, I was able to really kind of push myself and try to determine whether or not I needed to hire someone to develop what is now called swiftly. So this automated tool, this AI natural language processing tool that was created by me to generate requirements in less than three minutes, right? And so I didn't want to create that tool. Again, it goes back to I have this idea, I don't really want to do it, but it's a great idea, I think. And so, essentially, I hired other people to try to develop it. And as we all know, if you're not really good at managing the requirements and managing your developers, you're going to, your scope and your budget is going to take a really big hit. And so that's kind of what happened. Initially, I did, I had developers that were not as determined and tena tenacious as I was in order to develop the solution. And so essentially, you know, I'm going to say this, that, you know, for those of you who have lost anyone during covid, my sincere condolences, but I would say for someone like myself who is a high level introvert covid was the best thing that could ever happen, absolutely. Best thing, because that is when I had the opportunity to build out swiftly myself, all the algorithms, collect all the data, generate the data, you know, do a lot of, like el it's like elementary data science, but it's still enough for us to develop requirements and I mean, detailed, pretty detailed requirements in three minutes, right? So you put the information in there, you're able to generate these requirements, and you're able to at least have almost like a punch list of what you need to have a, a conversation about. So it kind of templatize it, it's not going to be exact for the solution, but at least it gives you enough information for you to have a conversation for your release planning meetings, your sprint planning meetings, be able to prioritize it automatically prioritizes what the first one should be for you to implement. You can switch those around, of course, but then it gives you a foundation for you to think like a systems engineer, to think like a business analyst, to think like a systems analyst. Like how, like the steps in which you need to take before you actually hand that over to a developer and say, yes, this is what you need to develop. So it gives you that type of brain trust and framework in order to speed up your requirements process. So now, anytime anyone asks me to do something or anyone on our team asks us to do something twice, we've already done it. So we press a button and we give it back to you, right? And it's, and it regenerates it sometimes, sometimes it'll use it based off a historical information, but for the most part, it's regenerating for a new project. But we do have the framework and the algorithms in there that I created all through covid, and they have it.

Wade Erickson (11:57):

So it's interesting that you, you tackled the requirement side because you know, I go back to the government days. I worked in the defense industry where we had just piles and piles of very heavy narrative requirements. Of course, the waterfall days, right? And requirements were king back then, because you didn't get started until that requirements document was done. But that might take six months before we even freight the first line of code. Correct? And then agile comes along and almost requirements get tossed out the door, right? Everything goes.

Melissa Daley (12:28):

Which is not what Agile says, but yes.

Wade Erickson (12:31):

Yes. And so the user stories became more and more vague, less and less formalized, less and less structured, kind of taken a back seat. And, and, and, and we all know that if you don't plan, right, you're not going to build, you know, is in the mind of the people, the expectations. And a lot of times they can't even articulate what they want. They just know it and they see it, right? I mean, at times, have you heard that? Yeah. So expediting the requirements, and of course where the AI is coming in, is helping the, I mean, I've wrote full business plans and a day, you know, that would've normally took me weeks with generative ai. And I imagine prompting this stuff into these requirements, you can build a good, you know, shell of requirements that that's still very well written and and informative that can then take those and go into the user stories if you still want to use those agile modes.

Melissa Daley (13:29):

That's what we generate. We generate your user stories.

Wade Erickson (13:32):

Great, great. And so it fits right into the agile methodologies, but it, it, it, it is at least thought of comprehensively, you know? Yes. And completely based on historical. And then now of course, with these object-oriented kind of programming, you know, ChatGPT generated software, if they then can tie off that, you know, user story, you could really fast track stuff even with low-code, no-code now, so, correct. That was the missing piece was that requirements was not well captured. So you really, really jumped on a great, I think a big gap in the, the marketplace for software development. So so as you were developing this, you, you said, you know, covid gave you that gap to, to think about things and really spend time, focus time that the distractions that typically are in life were kind of quieted at that period, you know, how did you, did you have did you do it based on mainly your experience that built the product roadmap and the feature sets? Or did you go out to talk to others that have this problem and say, Hey, this is what I'm thinking, and get some feedback before you could act, because, you know, it was hard to get face to face with folks, so you haven't it done it virtual during that period. Tell me a little a bit about your skill style.

Melissa Daley (14:54):

So it was a little bit of both, right? So I, I, I took a master's program at the University of Maryland in order to validate this problem. And my thesis was basically, yes, this is a problem. If we could have predictive analysis for projects, it would be great, right? And so I said, okay, great. So at least I know that I validated this with specific project manager, systems engineers, systems analysts and whatever. But when I validated that information, that was in 2015, fast forward, COVID hit in 2020. So we're here five years later, and no one else has built, built this tool. And again, I was in the mindset of I don't think it should be me. And I was like, well, maybe it should be. So I built the tool with the intent that I would ask other people that are in my, you know universe of people that I can ask that are in the industry. And I did a prototype, like I did, I did a, a crowdfunding campaign, I believe, through, I fund women, and I asked for people's feedback. I showed them the raw version of swiftly at that time. At that time it was named something else, and no one liked the name. So I switched the name and everyone loved the name swiftly. So that was, it was a lot of rapid prototyping. Like I, so this, you know, I know this is going to sound backwards in terms of the reason why I created swiftly, but because I was the only person on the team creating swiftly, essentially, I didn't have, I like wrote my requirements on my window, right? So my requirements in my backlog was on my window in my, in my home. And so I would just wake up and just build the next feature and keep building and keep building. And I would wake up in the middle of the night and I would obsess about it and keep building and think about all the different patterns to put in place and how this connected to sustainability. Like just a bunch of things in terms of the way that my, my mind processes. And I did constantly ask for feedback and, you know, had interns and did the, you know, at least some, some a little bit us usability testing. And a lot of people didn't like the first version. They didn't like it, it worked for me, like on the projects I was working on, it was great. Like it worked for me. So a lot of people didn't like the first version. They liked the output. 'cause The output could go into Jira. So people always liked the output, but in terms of the user interface, it was kind of like, ah, we'll wait for the next one. And I, I think this new version that we just launched in January has really improved our framework and our architecture. And it's saved us cost wise, because the way that we architected it before, and the way I architected it before was not as cost effective, let's say that. And so now it's, it's more cost effective and a lot more stepping you through the process instead of giving you all the information upfront. So it was a lot of yes, involving folks and then also just kind of doing it from my experience. So it's, it's a little bit of both.

Wade Erickson (18:28):

And, but that sounds like the iterative development process, right? You put something out there, whether it was the MVP, you got feedback, you made adjustments, you presented something else that deviated from your original vision because you're getting feedback. And like you said, your brain process processes very differently than probably the average person coming at software development. And so you could take for granted certain steps that, that they needed. They needed the wizard, you didn't need the wizard kind of thing, right? Yes. And, and, and so but that's key is that you put it out there, you take your vision, you make adjustments, you put it out there, again, you make more adjustments. And sometimes it takes three or four iterations before it's actually, you know, monetizable. I mean, people could still use it, but, you know so so we've got an idea here that you're now, do you kind of throw epics at it and so it kind of can get.

Melissa Daley (19:28):

Yeah, it's, yeah. So in swiftly, it, it estimates a lot. It estimates the number of epics, it creates the epics, it estimates the features, it creates the features, estimates, the user stories, and it creates the user stories. And then it estimates the task. We also can create the task as well. And then we also create data elements. So the data elements that are going to be associated with user stories, we do a sketch of the wire frame for it. So it's like a templatized wire frame. It's not all that, you know?

Melissa Daley (19:58):

Sure. Basically you in the ballpark, you know, and then you give it to the UX designer and they.

Melissa Daley (20:04):

Yeah, exactly. And then it also does a roles matrix. It estimates the roles it predicts the roles rather. And then some messaging. So like your systems messaging, like your validation messages, or if some, some, you know, field isn't entered and all that other stuff. So it generates all of this information, and then you can say, yeah, that's right. No, that's not da da da, da. So when we talk about empowered AI experts or AI empowered experts, right? That's what it is. It's using this tool so that you're empowered to be the professional that you need to be. Because that was a part of it. It's like I was spending so much time creating all this detail that, that I couldn't think about all the other things I needed to think about to make the systems even better, right? Right. Whether I worked as a product manager or if I worked as a systems analyst or <inaudible>, whatever, I could, I could not, I didn't have the capacity to think about, okay, now once we're done with these features, how to make the system better be a little bit more innovative. Now this tool allows me to just do all the mundane tasks. Like I, if I had a, a junior systems analyst, right? And it does that for me. So now I can think about, okay, what's the future of that platform or solution?

Wade Erickson (21:26):

Yeah. And you know, obviously software, the administrative subsystems, you know, all the things that almost every software solution has, you know, creating users, managing users, all that stuff. Yep. I mean, how much do those really change from system to system?

Melissa Daley (21:41):

Exactly. And what our system does is splits it up, like what you're talking about is like the technical product roadmap. Versus the actual product roadmap. Because for every solution, if you're really going to go through this, you're going to need a product manager, right? Or, you know, product owner. And then you're going to also need a technical product owner as well. Or technical product manager. And so our solution like basically provides you with that. Like what are the things that, from a technical side, so if you're going to have integrations, if you have an integration with an ldap, we generate all those requirements for you so you can check the box. Yes. It does that. So if you're thinking about, you know, independent verification and validation, it's easy. You, we generate all the things that you need to independently verify and validate, and you just check that box and go, yes, yep. We got that in there for like, if you're thinking about a, a solution that's off the shelf, boom, boom, boom, boom, boom. You just check everything that we have. But even if you're thinking about a custom solution, now you can develop your roadmap, like, oh, these are the conversations I need to have with my product owner to make sure they understand that we need to create a contact, right? And how does create contact look, and what is that messaging for it, right? So it gives you this kind of like, oh, what are my questions? You don't have to sit and think about that anymore. It just generates it for you. Now you just check the boxes, you keep what you want, you take what you like, and you leave the rest basically. So it gives you that kind of, well-versed depiction of what you need when you're developing a solution.

Wade Erickson (23:26):

So of course, Logigear. We're, we're a testing company and by, you know, 30 years we've been doing testing for big companies, even even in Silicon Valley. We've touched a lot of, you know, brands that you are very well known that come out of Silicon Valley and name and name, drop 'em here, you know, NDAs and all that. The area you're talking about is very much affecting testing and test automation as well. So a lot of times we'r taking, now with ai, we're looking at the use case, the, the user stories and the validation in those, and generating the test scripts, at least the skeletons of what those test cases need to at least validate in the UI as time progresses and things get better. The, you know, AI's going to be able to look at the user interface, whether it's a sketch or it's actually the screens, and start to build skeleton test scripts for that. And we're not there yet, but, you know, and we're partners of all the big boys. We know the timelines of when that stuff's going to arrive, which is a couple years. But right now, the, the activity is around taking the user stories, which you generate and build the the test cases, not the test scripts, but the test cases. Tell me a little bit about the thinking you've had and, 'cause I, I think I, I've looked at a couple of the videos and stuff around this a little bit about how that then translates to the, the tail end, which people think about as test. It shouldn't be testing should be there in the beginning with everything else. But tell me a little bit about how you think about how this is going to affect the testing side of qi.

Melissa Daley (25:07):

So when I started out at Accenture, I started out as a test engineer basically. You know, everybody kind of rotates, but the intent was that once you have a requirement, the permutation of that requirement becomes your test case or test. And so that's it, right? So we create these user stories at its micro atomic level. You take that user story and you map it with another user story and another user story to chain it together so that you now have a, a combination for your test case, right? But then you can now permutate based off of that user story, all the other different scenarios that would happen for that particular user story based off of all the other users you have. So that, that was always the, the intent, the intent of swiftly is how do you take the continuity of the requirement from its inception? So from when the time it's born, all the way to time, to the time it gets into operations, and then one, or operations and maintenance. 'cause Once it gets into operations and maintenance, now it's matured, right? That requirement has matured 'cause it's already been developed and so forth. So then that then starts to execute into, now you have to evolve it yet again. If that particular requirement changes, then it becomes another iteration and it should flow through the entire lifecycle of the development so that you're able to continue to permutate that and make the different combinations based off of that particular requirement. So it's all like, at the end of the day, it's all about statistics and you know how to take one atomic thing and multiply it into and chain it and multiply it into its other scenarios.

Wade Erickson (27:04):

I'm excited to see the product. Yeah, I think there's, I think it's an area that you know, we're all very used to just jumping right in and building use case user stories. And just hacking 'em together and then it, it kind of has a feel like the systems matured, you know, as you're reading through 'em all and all the gaps are kind of filling in. But like you said, those are still epic ish, you know, they don't get down to really, then you hand 'em over to the developer and it's like, ah, okay, I what you mean designer now because I got to take this user story that doesn't really have a good complete design and you're expecting me as a developer to design against that user story. And there's still agile in the practices and methodologies coming through the days of physical creation. You know, in the defense industry, I, they don't dealt with weapon systems and stuff that people die if you don't do things right or people die. And software just was so loose, you know, it was so uncomfortable to me, you know, it's like, wait a minute here. There's such a huge distance from.

Melissa Daley (28:10):

Which is the fear.

Wade Erickson (28:11):

You have here to what you need to do, you know?

Melissa Daley (28:13):

Right. Which is the fear, right? Like my main thing is like I will never accept a full-time job unless I can change just exactly what you said. Which is, if we have doctors in place and they need to have a medical degree and they have to go through all this and they're getting reviewed by the boards and blah, blah, blah, we have buildings that are getting inspected and so on so forth. Although software is intangible, it's actually tangible. Our data is very important to us. Right. And as we can see, every day there's some type of data breach. And so if we don't start to really create those policies and frameworks and procedures just like we do when we are building a brand new building and someone has to come in and inspect it and approve it, make sure the lights are working and you know, all of the architecture and infrastructure is in place, we're going to have the same effects of if a building was not up to code in the software industry. So that is a very huge fear that.

Wade Erickson (29:11):

Getting worse and worse. I mean, software is running cars, you know, so. Correct. With the autonomous vehicle stuff, it's just becoming more and more critical that these requirements are treated like a weapon system in the military. You know? Yeah. Alright, well you know, we're already at the top of the hour. Things go pretty quick. You know, we talked a little bit about how you pivoted in your working career into deciding, Hey, I need to do something about this what advice would you then have for other people that have ideas with SaaS solutions? Software development. Obviously you can get a lot further in software than you can, you know, deciding you want to have a new building or, you know, physical Right. Cutting metal and stuff like that. Which I've been involved with both and believe me, I'd much rather build software off my own pocketbook.

Melissa Daley (30:05):

Exactly.

Wade Erickson (30:06):

Cutting metal. Right? So tell me a little bit about what kind of the process you'd give some advice and then we're going to probably have to wrap up here.

Melissa Daley (30:15):

Yeah. So what I would give advice for basically as one, as an entrepreneur is to find that niche, right? Find your sweet spot, find what you're good at, because constantly the universe is telling you what you're good at and sometimes you're just not paying attention to it, right? So find that and, and really hone in on your skillset. But then also if you're not looking at the entrepreneur route, if you are just a systems engineer or not, just, I won't say that. If you are a systems engineer or a systems analyst, definitely help the development team and the testing team because it's your job, right? Like it's, it's your job. 'cause That quality starts there. Once those requirements are as detailed as possible, the likelihood of the system and the scope or the sy the solution not being able to be delivered on time lessens, right? So making sure that you're able to negotiate what does not need to be developed by day one. 'cause That's a lot of it. Like everybody thinks they want to throw the whole kitchen sink and sometimes you don't need the little faucet on the side when you're building the kitchen, right? You just need the regular faucet. You don't need a hot water tap. So being able to negotiate those features and understanding how to do that is very, very important as a systems analyst or a systems engineer and taking it from there, being able to know how to negotiate, you know, being able to know how to define and manage scope and controlling it.

Wade Erickson (31:52):

Thank you so much for that advice for everybody. Alright, before we wrap up, I just wanted to just introduce our next week's show. It's Philip Eric I think I pronounced it right. And he is a developer relationships@replay.io and the topic's going to be about how to write a flaky test. And this is really about narrowing down bugs and demonstrate how to use a, a time machine debugger to identify the root cause. Very interesting. So again, root cause analysis against your bugs is critical and we're going to talk a little bit about that. So thanks again so much for Melissa for your time and you know, I look forward to playing with your tool, that's for sure. Maybe putting it to work.

Melissa Daley (32:38):

Yes. Yes. Sure. Thank you.

Wade Erickson (32:41):

All right.

Melissa Daley (32:41):

Thanks for having me.

Wade Erickson (32:43):

Have a great rest of your week and until next week, everybody.