I have an interesting roundabout way of getting where I am which I think a lot of people would also agree with from given their own experiences. I currently work in the data science space when I was an undergrad and in university, data science was not really a significant part of what the curriculum emphasized. I mean, obviously, we were focused on statistics, that was an area. But I'm an engineer by training, and I actually wanted to work for an organization like the EPA or Noah, I was an environmental engineer so I was more oriented around lab activities. Closing out my career in the university, I interned with the government and I realized I did not want to work for a government institution and like most people in my university, when you don't know what you want to do, you end up in consulting and within consulting, I started in financial services and I'm fortunate enough that our analytics practice was expanding right after a joint, and I quickly transitioned into that team and from there I was very fortunate enough to have been part of an innovation team that then expanded into our AI and machine learning capabilities so that's roughly how I got here today.

I'm the director of an innovation-oriented team so we're an applied research lab. Compared to most teams and consulting that spent 100% of their time with clients, I spend probably closer to 40 or 50% of my time with clients since a lot of our responsibility is around research, innovation, exploration, but also in the context of client problems. When we think about the decisions that we need to make at work, our decisions are shaped by where we see the academic community going, where we see our client's problems adapting and any other type of considerations around the technical aspects. Our team focuses on, it's an emerging technology team and I primarily focus on AI and machine learning but the team also has responsibilities in IoT and Blockchain, AR & VR, 3D printing, drones all those types of capabilities so we think about where we see those technologies going, how we see them working together, and I would see our client unique scenarios changing over time that's a fundamental portion of what we do. With clients, specifically, when we have a specific client that's engaging with us, I did want to build their own innovation capability or I want to do a proof of concept or help build a solution for them. The responsibilities and decisions always center on the client. What does the client need? What is going to work best for them? If there's no one to take that responsibility, does it make sense to have a more complex solution or do we owe it to our client to build something that they can then use and transition internally? So that the client and consulting are always going to be front and center to whatever decisions that you end up making. Most consulting firms, we do not spend a whole lot of time in the office we are mostly at client sites, or our team has research labs that most of our team is proximal to, so that would be in Chicago and New York primarily. I live in Los Angeles, so I do not go to the office every day, but we colocate one week out of every month and primarily Chicago which is actually where I am right now not in our lab in the office, to the side at a quite place and other times I'm either at clients or I'm working from home.

The data science side is the tool side which I am more familiar with, we have a lot of other tech stacks that we work with for the other technologies. We primarily rely on open source software, so primarily on the python stack, because that's where the academic community is these days, that's where the collaboration is in the data science space. I personally am not a huge proponent of using vendor solutions when so much of that technology is based on open source algorithms anyways and trained on open-source data sets. So unless there's a reason to use a vendor specifics tool, we typically don't. So the exceptions to that would be a few. One is for simulation modeling we use a tool called AnyLogic, which is Java-based software and the reason we use it is that its multi-method simulation, so incorporates different types of modeling capabilities really easily, and it allows you to set up simulation models quickly across a variety of different types that's just not easy to do in python and most of the capabilities you have to go to like C or C++ it's a little bit of a nightmare to get up fairly quickly, so that would be the exception. The other exception is in the DevOps space when you're building and deploying models specifically in a cloud environment for the purposes of continued use, our clients have specific cloud environments that they operate in, and so we need to be agnostic to those. But there are still differences across those architectures and across those cloud platforms that we need to be familiar with so we often have to operate within those requirements of those stacks, so that would be something like AWS or GCP but also, containerized software is like Kubernetes and all of the different flows for model deployment.