So I got started in the software industry in 1988 and it was purely by accident. I was just looking for a job for school, something I could do to make some money. And at that time, there just wasn't any. There were hardly any software companies in the U. S. There were only a couple in Utah, and one of those was a company called Word Perfect. They made a word processor, and that was the first thing that was useful on a personal computer with obviously replacing the typewriter. So that's how old I am. It a word processor and it was amazing as I had typed on my papers on typewriters in high school. And so when I got into college that I finally had my dad bought her Apple IIe. Writing your papers on a computer was so much better. I didn't have to re-type it or you could save it and work on it later. It was really amazing. I got a job working in customer service and didn't know much about computers. I decided I liked working on Softwares. There was more to it than I thought and that led to me taking a job inside Word Perfect on the software test engineering team, and I started taking some computer science classes at the same time. That career just kind of blossomed there and it took off and not, maybe four or five years later, I got into leading engineering teams as a team lead. I switched over to the management track, and I've been on the management track ever since. So during that, I think I worked there until 1999. I went and worked for a Linux company because Linux was really popular. I had worked for Novell. We did networking for Windows PCs, and we got familiar with operating systems and then worked on Linux. Did that for a while. I think by this time I was probably a director level, working with large teams. 80-100 size teams and then at that time of the industry, we call it the dot.bomb years where the tech really took a downturn because of the stock market, and lots of companies were doing layoffs. And I went and I decided to go to work in health care because that was a safer place to be. They don't usually do the layoffs. They make a lot of money. So worked on some software for the health industry for medical centers and also insurance companies. And then I decided to start my own company, providing software services. Writing software and testing the software. Our company also did globalization work, so translating software strings into different languages. So you have a German, French, and Japanese version, and in about 2010, I worked with the company. Worked with the guy that sold the company, and we started a hosting company providing shared hosting. A product that actually got purchased by Endurance, which owns Bluehost and HostGator and all those kinds of hosting companies. I got really familiar with that part of the industry and cloud computing. We basically built a private cloud platform. And then once we sold that off. I took the job I have now, which is senior director of engineering, and I'm over about 100 people, have seven managers, and anyways that's what I've been doing that for three years. And the current that I have is in the software for the automotive industry. My whole career, I focused on working for ISVs, which stands for Independent Software Vendors. I've never built software for internal consumption. It's always been for consumer use or visit the business. It's a different place to work as opposed to say you work for a bank and you're making software for the bank. It's different than if you work for a Microsoft that you work on the office team where you're developing features for Word or Excel or something. It's a different discipline. Similar, but still a little bit more differences. There are just differences, but anyway, that's my story.

When you climb, the leadership ladder, things get more intense because you're you have more accountability, you're over-responsible for more things. If a project isn't going very well, then you're ultimately going. Right now, I have a responsibility for all the platform services, all the infrastructure, and our data analytics platform. The decisions that I have to make there are primarily just based on making sure that, architecturally we're headed in the right direction. I have architects that work with me. You have to make sure that the product requirements are in alignment, so we don't miss match expectations of customers after make sure the systems are performing. Our product is a SAAS based product. With the SAAS application, which is most applications nowadays, you have to have high availability, and it needs to be three nines or better. I'm responsible for that whole process. All the people, all the infrastructure we have built on cram and, software on AWS that we deploy. So it's a combination of all incriminating of us. Weekly hours for my position, it's assumed that you're gonna work 40 to 50 hours or more depends on what's going on. I do travel. I don't have to travel a lot, but I do probably once a quarter. I need to go to work with different teams across their company. We have little development sites, and so I have counterparts in different locations and have to visit with them for the teams that I'm over our entire division. We do have a work from home policies. So if you want to work on Fridays and your performance is good, then you get more remote and it's really kind of up to the manager. If there's someone that's not performing very well and they're kind of not doing much of their work from home day, then we will take the privileges away, but it's really not an issue. Most people are productive and they really like having Friday work remote day. If there's a really bad Weather, we tell everyone you were remote just to be safe.

Our company has done a good job with what we call career architecture. I'm at a higher level, I do work with all the disciplines inside of the software company. We have the engineering track, and that includes leadership. So if you're a software engineer, then you have a software engineer level one, two, senior, lead, principal, distinguished and fellowship. And that's nice because most companies don't do that. So you get to let's, say, senior or leadership level, and you usually don't have any higher positions. A lot of engineers get frustrated. But with our company, you can actually go as high as you can on the leadership track. On the leadership side, there's Manager, senior manager, director, Senior Director, Assistant V P., VP, Senior VP. A manager is the same as a grade level as engineering lead so that way if you wanna switch tracks you won't take compensation. The same thing applies to the architects they have a similar track as engineers. It's just an architect, senior architect, lead, principle, all the way up. We also have data engineers. We have a data science group, but we mostly have data engineers, and it's the same. Data Engineer I, II and so on. Then I have people that are systems engineers. It's the same levels. I think that's all of them. We also have test engineers, and it's the same. And the nice thing about the test engineering track is that compensation wise, it's no different than the software engineer, and it used to not be that way. I've been around for a long time. There was a time when the software engineers didn't have the same pay structure or salary bands as the engineers did. The engineers got paid more than than the software test engineers, and now that's not the case anymore. Because all of our test engineers have to write code. They all write test automation. What approaches do I find effective and working with those organizations outside of mine? So our company uses a practice that's called Agile Safe. Some people may have heard that it's somewhere to the Scrum, but it's actually Scrum, combined with some other practices that make it easier to work across boundaries. So you could boundary span from your organization to another organization. Everybody's aligned with this framework. And so we have organizations that are structured exactly the same. So I know who my counterparts are, I know who my team's counterparts are. So although I will say you always have the challenge, that may be a team in we have a team in Austin, Texas, might be writing something that is simple to what we're writing, and we really try not to duplicate technologies. If somebody has something they wrote, then we want to try to reuse it. But I'm gonna say that's the idea. It doesn't always work out that way in practice, and not necessarily, but we make it. We make it pretty easy to reach out. Everybody's friendly, we all use Slack and teams, and so we can jump on calls and talk to each other. Right now, we're collaborating with probably four different development sites across the U. S. We use outsourcing vendors in the Philippines, India, and Romania. We have those geographical regions that we deal with as well, and we use the same. We use the same framework to communicate and collaborate with those teams.