Cox Automotive Inc. Senior Director Software Engineering
University of Utah Master of Science (MS), Information Systems
Current Time 0:00
/
Duration Time -:-
Progress: NaN%

How did you get to where you are today? What is your story? What incidents and experiences shaped your career path?

Summarized By: Jeff Musk on Thu Feb 13 2020
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.

What are the responsibilities and decisions that you handle at work? Discuss weekly hours you spend in the office, for work travel, and working from home.

Based on experience at: Senior Director Software Engineering, Cox Automotive Inc.
Summarized By: Jeff Musk on Thu Feb 13 2020
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. 

What are the job titles of people you routinely work with inside and outside of your organization? What approaches do you find to be effective in working with them?

Based on experience at: Senior Director Software Engineering, Cox Automotive Inc.
Summarized By: Jeff Musk on Thu Feb 13 2020
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.

What major challenges do you face in your job and how do you handle them? Can you discuss a few accomplishments?

Based on experience at: Senior Director Software Engineering, Cox Automotive Inc.
Summarized By: Jeff Musk on Thu Feb 13 2020
The major challenges that I encounter are typically what any ISV company will. Usually, it's like this where you'll have someone on the product side, it's usually an executive or someone on product side that will say, "Hey, we have to have this software release done". And though they'll set a fixture least eight, they'll say, "We need it for this show that's coming up in a year and so we want it done by then", and that's never a great way. That's always gonna fail because it's too far to estimate up. When I'm always working with them, what I do is we pull, try to pull it back into our agile practice, and I try to explain to them, "Look when we did this recently with a project". So this is an example of a success where they had said a year and a half ago, In fact, the product is due. They wanted to do on the 14th of February, which is this Saturday, and I had to go and I told him eight months ago I had to pull everyone together and say, "Look, it's not realistic to have it released by them because we have a show this weekend for the automotive industry", and I just basically said it's not really it's not realistic to expect us to have that ready for general release. However, I think we could have an estate that will be really would be dimmable. We could do a not early adopter, start pulling awesome strategic customers and see if they like it. And everyone was able to agree to that. And in reality, we did accomplish that. So we're ready to go, and then and then it looks like it's gonna take us another three or four months to get it to general release. That's just an example of a challenge that can be really difficult to manage because there it is, depending on who the players are inside the company, that could be a difficult conversation. Another challenge is typically to do with technology choices, and when you think you have the architecture the way you want it until you start to implement it, you may decide that you've chosen something that's the wrong piece of technology, whether that's a component of AWS or the way we decided to design an API or something. And what we try and do make that easier is we would do the architecture. And then when we do the implementation we do, it's more of them a proof of concept, because that's something we do as well. But then we take it a little bit further, and we build a walking skeleton. We call it so it's a little tiny. It's little. It's basic. If you have an API write, you would just create this very simple FBI that needed to talk to, maybe the back end is a dynamo. And, maybe you have some step functions in between, but you're not sure about all this, so you kind of just lightly put it together to get something to get data going from, front to back or first vipers, and then you can see that we probably shouldn't do this thing like this or like that, and we might change the architecture a little bit, so rather than waiting until you're reading a whole bunch of code and spent six months out and then making architecture change. That's harder than to do it at the beginning. So that's something that I feel like we've been successful in changing in terms of the culture at our company, supposedly, that's helpful.

How do you inspire and motivate your team members? How do you foster creative thinking? How are ideas shared and implemented?

Based on experience at: Senior Director Software Engineering, Cox Automotive Inc.
Summarized By: Jeff Musk on Thu Feb 13 2020
I think the culture we have has improved over the years. Some of the things that we've done are we have implemented and we're consistent about holding our all-hands meeting with our staff, all the engineering staff. And we include product in that. And we always recognize the employees of the month award. We celebrate how long people have been there. We celebrate their birthdays. We also have a team award that we do once a quarter. And then we also have an employee of the year award. And doing these kinds of activities on a regular basis creates a culture where team members feel like they're appreciated. We also celebrate wins that teams have. They got something done on time or they accomplish something difficult. Then we will also highlight those and are all-hands meetings. We have a system called Spark Points, where you basically get points for things you can give out to different employers and you can trade the points for different things, like Amazon gift card or visa card, or something on. There's a lot of that. A lot of effort goes into making sure everybody feels recognized for their efforts, and I think that's something management can always improve. But I hope I feel like we're doing a pretty good job there and we are not sure how well we're doing. We have surveys once a quarter to tell us if our employees are happy and we're measuring that on a regular basis. In terms of creative thinking, we really do have a culture where we foster that by involving the team. We have what's called delivery teams there. Amazon calls them a pizza team or pizza size meeting. It's enough people that want a pizza to about 5 to 6 engineers. They all have their own team room, so they all have these really nice team rooms that are pretty big. They can close it off to keep quiet. They have their walls, are all whiteboards. The whole thing is painting so they can just go up on the boards. And so, along with their architects, we come up with design decisions and technology suggestions, but the team can decide the team. The team has some autonomy on how they wanna decide to implement and leave them a lot of room to suggest other ways to do things. Today I was in one of the sprints down and one of the engineers has come up with a really cool way to enhance react for an end piece that we have developed using GraphQL as a back end or our as an API layer and some of the things that he came up with were really creative and we're gonna actually use those going forward. When someone does something like that, we celebrate it and we get some props for a great job, maybe highlight it and maybe even dental it in one of our bigger meetings, where everybody can see that they can use this and that so and so did it. And so I think that helps a lot and the way that we share ideas, we probably could do a better job of this one. I think that by doing what I just described, a lot of people will hear about what people are doing. I still think we could do a better job here because it's really difficult to make sure that when you have over 160 engineers just in our sight here and in our company, we have over 2000 engineers. For this one, we struggle with because there's a lot of people doing a lot of different things, and it's hard to share those ideas with each other and make sure we're not duplicating first of all, and then sharing ideas. You come up with something new, that somebody else could use to solve a problem for them, but inside of here in Salt Lake, I think we do a pretty good job with it, just by nature or culture on the way and we try to highlight things people are doing. But it is something that you probably enhance.

How do you set targets for your team members? How do you measure their progress? How do you incentivize them to meet their targets?

Based on experience at: Senior Director Software Engineering, Cox Automotive Inc.
Summarized By: Jeff Musk on Thu Feb 13 2020
The delivery team participates in what's called quarterly planning and agile safe. You have a cadence of quarterly planning sessions where everybody comes together and it lasts over a two day period of time. And when you get there, obviously, we've done a lot of we try to do continuous planning throughout the quarter that we're working on delivering software. What we're doing is prepping for the next quarter, and that pine box of a quarter is what is actually put on what's called a release trains. We divide the delivery teams by release trains, and the really strange have common domains of software that we're delivering. The way that we measure and give the team's targets, is there actually internment? Will the product people build a backlog? You gotta grove it out best we can before quarterly planning. And then the teams get to come in for two days and they just work together with the product. The goal is to see how many sprints you can build out and schedule. You can't do all of the work. It's too much work. It will be inaccurate. They try to get two or three sprints of the five or six sprints in the quarter fleshed out and organized, and that's how they sign up for the work they're going to accomplish in a quarter. And then, of course, that's something that the managers can work with them on meeting and obviously, with Agile, things change. They always change. Requirements that are coming in that are different. And so it's okay if maybe something we did plan that quarter gets bumped out to another quarter. We'll make those adjustments. We will recommit the teams. So that's how the team members or managers basically propagate productivity. So each team member is expected to do around eight points for Sprint because the way we do performance is a little different than maybe other agile teams because we've mapped it to a number of hours. Some would argue that's not a good practice, but it works out based on the way we do track their hours. So if they're not, getting their eight points in. So the manager and I step in and try to find out what's going on, see if we can help him. The incentive is there because we do have each of the managers meet with their team members and make sure we understand their expectations.

What qualities do you look for while hiring? What kind of questions do you typically ask from candidates?

Based on experience at: Senior Director Software Engineering, Cox Automotive Inc.
Summarized By: Jeff Musk on Thu Feb 13 2020
I'll tell you how our process works. We have what we call an interview loop. On the phone screen, we'll typically ask questions around background and skillsets, just to make sure they're qualified to come in for an interview. If they are, then we let them know that it's gonna take most of the day. So we spend a lot of time with our candidates. We want that way to accomplish two things? First of all, we want to make sure they get to know us. They get to meet all the team members they're gonna work with and to see our building. And then, of course, us. We get a better feel for who they are and what they're looking to do if they're a good fit for the company and for the organization. It's a long time to spend, but we try to make it a positive experience. We take them out to lunch. It usually starts with the tech interviews or could be two or three techs, not three, usually one or two technical reviews, and those will require that the candidate will maybe do some coding on a whiteboard. Sometimes we have coding exercises that they could do on a laptop. But we want to see if they can play the guitar or not. If there are competing for a band, you would come to play the guitar. He wouldn't just show up to talk I can play the guitar. And then they'll go through different interviews. They'll talk to a couple of different managers who will tell them about the company or trying to accomplish what they would do. So there are lots of questions, but the quality that we're looking for is really people who are positive. They're outgoing. They seem interested. They're asking the questions and, mostly just to see if they have that they're gonna be somebody that has a good cultural fit with our group. Mostly that's just positive, outgoing, energetic people. That's what I'm looking for. I mean, I could go through the questions, but there are just so many questions that when it gets to me, I'm usually the end of the loop and I will ask our usual. I will ask them to tell me about an experience where they had a disagreement with a team member or their manager and how did they handle it? That's probably my favorite question.

What was the hiring process like for your job? What were the roles of people who interviewed you? What kind of questions were asked?

Based on experience at: Senior Director Software Engineering, Cox Automotive Inc.
Summarized By: Jeff Musk on Thu Feb 13 2020
When you get to the senior leadership side, you end up having talked to multiple executives. And I had to do an initial screening, two different screening processes. And then when I went on-site, they have you interview the people that will work for you. Some of the major that would work for me and also interview with some of my peers at the company here. Different sides sweeping and Cox automotive. Then I interviewed with some of the senior VPs. It was a very extensive interview process. A lot of questions were mostly centered around just leadership style. How do you build higher, high functioning teams? How do you overcome off schools that may have to do with people or processes? There were some technical discussions, but I don't have to. In my level, there wasn't any coding exercises. It's mostly around how do you solve problems and how do you build teams? What is your hiring process like? How do you build a culture? How do you change a culture. How do you implement agile? Because at the time, they didn't have a lot of our job. I mean, they had some, but we need to do a transformation, Dev Ops, transformation, agile transformation and those kinds of questions. 

What are different entry-level jobs and subsequent job pathways that can lead students to a position such as yours?

Based on experience at: Senior Director Software Engineering, Cox Automotive Inc.
Summarized By: Jeff Musk on Thu Feb 13 2020
The good news is there's still a lot of companies that need more resources, more people here in Utah. There are not enough software engineering resources in Utah. In fact, we're always competing and stealing each other. I just hired a guy away from a company, and I'm sure they're not happy about it. Someone just hired more guys away from me. There's not a lot of people. We have an internship program. A lot of other companies in Utah do have internship programs, and that's a great way to get some experience. You get to meet them and they like you, and then they want you to come on board to work full time. My recommendation would be to just do anything to do with software. Don't be too picky, because once you get your foot in the door and you can prove yourself and you can show your value, then it just goes from there. You just need to get in the door. We have entry-level job positions for everything I mentioned earlier software test engineers, software engineers, data engineers. There are junior-level positions for all those. Most are interested in the paid internship, so we don't expect people will work for free. It's out there, and we need interns.

What were the responsibilities and decisions that you handled at work? What major challenges did you face in your job?

Based on experience at: VP Engineering, Endurance International Group
Summarized By: Jeff Musk on Thu Feb 13 2020
I was responsible for a new cloud platform for their new product. It was challenging because we were using an open-source version. We're using open source technology called Open stack. That was mostly a technology challenge. And then, I had to kind of rebuild and reorganize some of the groups that were working on this product. And then the difficult part was that I was reporting to the CIO. When you report to a C-level person, things are a little more intense. There's more visibility than at the director level. Even though the director level you sort of exposure to the senior level people and in my current position, they all know who I am, my phone number. The higher up you go that, the closer you get to the C-level. I was in a lot of all of their staff meetings included C-level people, and it was a lot more visibility. Which means more stress, right? I think my major challenge there was just trying to build a new platform with people that I didn't know very well and finding the right people and pulling them together. It was a cross-organizational. We had multiple organizations in different states. And so I had to pull people from all these different groups across the company to get the project. It was fun. 

How did the program prepare you for your career? Think about faculty, resources, alumni, exposure & networking. What were the best parts?

Based on experience at: Master of Science (MS), Information Systems, University of Utah
Summarized By: Jeff Musk on Thu Feb 13 2020
This is an interesting question for me because I initially wanted to get the degree because it was a life goal. I didn't think it would enhance my career very much because I was set in my career. One could argue maybe a little bit too late to get your master's degree. I think I was usually the oldest student in the class and sometimes most times older than my professor. But what actually happened was I was surprised at how much I've learned and how much I didn't know about things that I was working on, and it was really, really beneficial. And the faculty was great. Different professors that really worked with me and helped me. I don't know if networking was really a big deal in terms of helping me out with my career. But I think just the content, the core, the core content and some of the class some of the elective classes I took were really helpful. I think It did actually enhance my career. I feel like I'm in a better position. I'm more able to work across, wider. Do you hear about the T shaped employees? I think I got a little. I've always had a certain focus, but now I can go a little further. I think that just overall just learning. I wanted to do a technology degree and I really enjoyed the technology part of the MS program.

How did the program prepare you for your career? Think about faculty, resources, alumni, exposure & networking. What were the best parts?

Based on experience at: Bachelor of Science - BS, Business Administration, University of Phoenix
Summarized By: Jeff Musk on Thu Feb 13 2020
This program I did back in the mid-nineties, and it was pretty well established by then. It worked great for me because I had little kids and I had a house payment and I didn't have time. I had a full-time job. I didn't have time to do day school, even though I've done a lot of day school, so I just finished up there. It was nice to do the classes at night. They made it easy to just do one class at the time. But I think probably what I got the most from that was just that when you achieve or work on getting your education and finishing it. I think this shows your employer or anybody that you are someone who can finish something. When you do get your degree, you have this huge sense of satisfaction that I accomplished this thing and it's done right. I think that's probably the biggest benefit from my undergrad that I learned a lot. I learned how to present. They have a lot of presentations and the business program. And I think it was also helpful when I got when I started my company and I ran the company. It was very helpful to have a background, accounting and finance, and marketing. And, I even used a degree in Rohit's class because I hadn't remembered all my statistics with our programming. It was good. It was a good program. The university does a good job catering to students who don't have a lifestyle that fits a daytime school. 

Would you like to share something that is not on your resume? This may include your passions, facing setbacks or adversities, a unique experience, or an unexpected help.

Summarized By: Jeff Musk on Thu Feb 13 2020
I have a little side career in abstract art. I'm a painter. I currently have passion around. Yeah, there were definitely some setbacks along the way. A lot of them are personal I probably don't want to share. But anyone, who has live life for a while, life kind of beats you up, and you just think the adversities are great. Though I will say I've had plenty of failures, and what I've learned is to just accept them and move forward because you can always learn something from failing. Like a lot of people, I think when you're young, especially, you're afraid to fail. You're afraid to admit that you failed, afraid to admit that you did something wrong and it's okay to say, "Hey, I did that wrong. I'm gonna do this differently and move forward." Yes, plenty of failures. But I feel like overall, I've had a lot of success to go. It's like a stepping ladder. You win and lose. That's life.

Do you have any parting advice for students and professionals hoping to get to a position such as yours? What 3 dos and 3 don'ts would you suggest?

Based on experience at: Senior Director Software Engineering, Cox Automotive Inc.
Summarized By: Jeff Musk on Thu Feb 13 2020
I think as far as the three dos go, really big on the kind of people that I'm attracted to in the workplace, I guess mostly in life, but especially at work. I'm attracted to people who are proactive there. I don't have to ask them to do very many things. I give them direction, and then they're just the kind of people that proactively just get stuff done. And they do more than I asked them to do and then come back and ask, "what else can I do?" That's the number one do for me. I'm attracted to people who are thought leaders. They're always thinking about how something could be better. They're always wanting to raise the bar and think about a better way to either enhance a technology. It's a process that they're never satisfied with something right, just this constant drug, him to think about a better way to do something, and then this is something that everybody does. When there's a problem, it's easy to just complain about the problem and talk about the problem, and I'm attracted to people who don't do that for very long. Instead, they focus on what the solution is. Whenever I present a problem, I always make sure I have a solution to go along with it. And it doesn't come across like you're just complaining. And I think the three don'ts just matched the three dos or the opposite, right? So I get frustrated with people who are passing when they just kind of just being okay with the norm. Or they're satisfied with dysfunction. Let's put it that way. They don't mind living in a dysfunctional world or a dysfunctional software application that doesn't quite work the way it should work. And, then also, I also struggled with people who are just negative all the time. So transfer negative and I think that just counterbalances positive. Then don't be unproductive. Try it. You try and just do as much as you can do. And, those are my three do's and don'ts that kind of match each other.