From Controls Engineer to Product Leader 

BH:  Welcome to Enabling Automation. I’m your host, Ben Hope. Today’s episode is another installment in our Careers in Focus series, where we sit down with people whose careers have helped shape both ATS and the automation industry. My guest today is Javan Taylor. Javan has spent more than 31 years at ATS. He joined the company in 1995 after studying electrical engineering at the University of Waterloo. Beginning his career as a controls engineer, over the years, he’s held roles in software development, product management, project management, operations, commercialization, technical sales and today serves as a staff specialist. Along the way, Javan played a key role in the development of MACS (Modular ATS Controls System) and SuperTrak CONVEYANCE, where he led the early software development. This conversation isn’t simply about job titles or technologies, it’s about how an engineer’s perspective changes over time, how building software becomes building products, products become platforms, and experience becomes pattern recognition. Javan, welcome to the podcast.

JT: Thank you.

BH: So Javan you joined ATS in 1995. Take us back to the beginning. How did you end up studying electrical engineering at the University of Waterloo and eventually joining ATS?

JT: Well, it was a long path. I, got interested in, electrical behavior, I guess electronics through high school went to Dorchester High School. They had tech courses. I took electronics and really loved it. And then my dad actually was, building a log cabin and, I was about 17 years old, and he let me wire the entire cabin. And, I mean, he obviously gave me a lot of guidance. Yeah, yeah, he gave me a lot of guidance, but he let me do the entire wiring. And that actually got me really interested in I’ll say electrical behavior. And I decided I wanted to go into,  electrical engineering or technology. I applied to Conestoga but I also applied to, Waterloo, Carleton and Queens and ended up getting accepted to all of them. I wasn’t convinced I was going to get accepted to Waterloo because of the high  grade marks that they required. But I got accepted, and I jumped at it.

BH: Wow. Cool. And what was ATS like when you first walked through the doors in 1995?

JT: It was like brand new. They had just moved into the Royal Oak facility. It felt like I started at a new business.

BH: Cool. And then the work itself. What was that like?

JT: I’m going to say that they took a chance on me because coming out of university, I had studied basically high voltage with kind of a minor in controls. I thought for sure I was going to be working in hydro. I had three work terms in hydro. I expected to get a job, but when I graduated they were not hiring and in general just wasn’t hiring. So I couldn’t wait for them. So I applied in controls. I went to an interview with Rob Holl, Jeff Wilson, and we hit it off. I mean, they took a chance on me because my only real controls experience was, General Motors in 1992. And, you know, it was pretty limited. So, it worked out very well. They offered me a job, and, hydro then offered me a job the day after I signed with ATS. And I just stuck with ATS when I, when I say I’m going to do something,  I’m going to do something.

BH: Yeah. Cool. Okay. And you started out as that controls engineer. What did the job actually look like at that time?

JT: Jump in with two feet. It was really what it was like. I worked with some of the other, senior controls people to learn about the programing style, things like that. But I wasn’t there for more than a couple months before I had my own project that I really had to program. It was small. It was a small project, but once that one was successful, the next one was actually, in my mind,

was a fairly big project. And did the entire programing on my own, had a lot of guidance. I mean, there’s people at ATS that I would, credit with my success. I’ll give a shout out to Mark

Johannesson, Dennis Murray, Vince Mach. They really helped me succeed, I’ll say.

BH: As a young engineer, what did you think you were good at and what did you quickly realize you still had to learn?

JT: As a young kid, I’ll say, you think you’re good at everything. You know it all in those days. But, it became very evident my experience, the little bit of experience that I had in my first work term at General Motors did not qualify me for PLC programing and machine integration. It was a humbling experience. I needed a lot of help. I’ll say in the in the first months at ATS. Yeah, but it’s usually an invigorating experience when you have a lot to learn and there’s still. Yeah, I mean it was it was new, it was exciting. It’s keeping you engaged and thinking about it in the evenings, you know, all these cool things that you’re doing. I can remember one time doing, my first project was an installation in London, Ontario, and I ended up staying with my parents overnight. But, like, rather than going to a hotel. I stayed with my parents, and I remember pulling out the old I can’t call the laptop, it was a luggable like, and I’d set it up on their kitchen table and I was, working on the program at night, and, yeah, I was it was just fun. Yeah, it was just fun. It was new.

BH: What you wanted to be doing. Yeah. So you started by solving individual machine problems at some point, your thinking shifted towards solving problems once and reusing those solutions. And I think this is where the story really begins. So how did you become involved with standard products at ATS?

JT: Well, it was, an evolution. I mean, ATS is always been promoters of standardization. Even in those early days, I would say the standards weren’t set or anything but the programing standards, the code modules that we were using, it was about following, you know, what somebody else has already done on another project. Right. And taking that, trying to maintain as much of the similar code structure as possible and, and integrating that machine. So we did that. I did PLC programing for a few years. And then as the as the controls group grew, we all reported to Rob Holl was our controls manager at that time. And the team grew, they decided to implement team leads. So the idea was, you know, that the team lead would help manage a group of people so that Rob Holl didn’t have so many direct reports. And I, I don’t know if it’s luck or why specifically, but I ended up under Albert Kleinikkink, who was, in the Winder group, or he was developing software for winders, and I ended up getting involved in MACS that you mentioned earlier, Modular ATS Control System and, getting involved in that. And, after it was after the winder group that I ended up joining the formal standard products group.

BH: So you mentioned there was already a belief in standardization and reuse at ATS, and at that time, like the standard products, did you have to try to convince the rest of the company to utilize? Because maybe a background on standard products, like they did everything from little brackets or kind of sensor brackets, mounting things that are used time and time again all the way up to kind of more advanced technologies. Right?

JT: Yeah, I, I don’t think that there was any convincing required. I think ATS really, has always grasp the fact that standardization is going to help you save cost and time in projects. Yeah. Klaus Woerner was huge advocate for standardization. And like you said, we had all kinds of, standard products,  maybe more standard designs than anything. But the idea was that it’s reuse.

BH: Yeah. People were all on board. When did you first realize that we shouldn’t be solving the same engineering problems over and over and over again? Before standard products or…

JT: Oh, yeah, before standard products. I would say even, you know, before the Winder group in that, you know, we were programing machines. They have certain sequences they go through using the same structure for how we implement, a structured sequence of events, fault handling, that kind of thing. It became, I wouldn’t say routine, but it certainly became easier to think about a complex machine in broken down segments of PLC code. Right? So you can break it down easier.

 You could standardize on it. So I probably wouldn’t have called it standardization back. Back then, it was probably not until we got into, the wider group that, standardization really took hold in my mind is what a standard is

BH: And how powerful it could be. So we’ve talked about the history of SuperTrak before on the podcast, but I’d like to hear what it was like from the perspective of someone who was building it back in the day. So what was your role in the original SuperTrak development team?

JT: So in the early days, I’ll say around 1999 or 2000, we got involved, or I got involved with SuperTrak at a high level. I was more helping with, integration of SuperTrak into, like, a show machine, that kind of thing. Right. So it was more of the PLC programing end. After helping out with the PLC development, we got involved, more in-depth level with, agile systems, which was, one of our partners for developing the electronics and the magnetic coil arrangement. And it was decided at one point that we were going to take over the development. And it was at that point based on, I guess, my history with the Modular ATS Control System, somewhat embedded programing, that I was going to be the lead on the software development as we took it over and, so then it became, one or more of the developments that I was working on. It wasn’t a full time job.

BH: Yeah. So you led the software development then, and what were you actually trying to make the system do, like, what was your goal?

JT: So make it usable. The, initial product that was, I’ll say, planned as a beta product. It was just not usable. It required, you know, creating text files in a specific, very, very specific format and then converting them or compiling them into hexadecimal and then loading them into flash chips. Very, very manual.

BH: So you need a certain expertise to be able to use it.

JT: Yeah, the expertise was beyond me. I could never do it. Yeah. Correctly. The first time it took me a lot of time, they said, this is not usable. We’ll never be able to have to sell it. Other people within ATS use this product in its current form.

BH: And what were some of the hardest technical problems the team had to solve back then?

JT: Probably our biggest challenges were around the encoder feedback of the system.

BH: And what did you get wrong early on?

JT:  Got a lot of,  a lot of things that weren’t ideal. There was things that I probably got, wrong as far as how to best configure a track. I mean, it was definitely issues around, releasing software maybe too quickly. Right? I think that happened, a fair bit in the early days because we’re like, you know, new product. We’re trying to quickly fix things, we’d release a new firmware revision and then find out, oh, well, we broke two other things. Right.  And so, you know, I think, getting things wrong in the, release process was pretty common in the early days.

BH: Lots to learn. Was there ever a point where you genuinely questioned whether this technology was going to work?

JT: I think, you know, this story, yeah. We started out with an encoder technology and optical encoder technology that had a very tight reading range, I’ll say, and we struggled with machining tolerances in order to make sure that the optical encoder strip would be in a certain range and, it seemed like we were always chasing issues. We would solve it in one spot, and then we’d go fix it in another spot, and all of a sudden the problem would go back to the first spot again. We were continually chasing problems, and I, I think at one time I said something to the effect that this is never going to work. I told you that. But ultimately we actually do have one of those systems still running in the field today with that encoder system. So we did actually get through the major hurdles, but we did find a better optical encoder solution that gave us a better reading range and just made things more tolerant, made it easier for the end user. They didn’t have to do a whole lot of setup, so we did solve the problem.

BH: Yeah, I think every technology in development goes through that phase where you get so frustrated at some point that you just reach that point of, this is never going to work. I want to give up, but you never do give up.

JT: We didn’t have that option. You didn’t have the if you if you recall, we were working on actual projects with actual commitments to our customers. So but it was stressful. Yeah. In those early days. The very first projects were stressful.

BH: Yeah. When you’re building something completely new, how do you know whether you’re facing a temporary engineering problem or whether the fundamental idea itself is wrong? Kind of linked to the last question a little bit. Or do you know? Or do you just have faith?

JT: Well, I think, you know, eventually it becomes adoption. I think if there’s enough grasping of the technology or maybe it’s adopting the technology or commitment to the technology, maybe that’s a better way to word it. Like, you know, you think about SuperTrak. In the early days, we actually committed to selling this on multi-million dollar machines. Right? So the problems that we encountered, they had to be temporary, right? We had to solve them eventually.

BH: And Klaus would be coming down every so often to question whether the problems were solved.

JT: Yeah, yeah, we, Klaus liked to check in on things on a fairly frequent basis, especially SuperTrak. It was one of his babies.

BH: Yeah, yeah. Do you remember the first moment when you saw SuperTrak working and thought, wow, this, this is different. This could be something special?

JT: Yeah, I do, it would have been actually prior to beta version SuperTrak, we had a beta version. Again, this was before I had taken over the software development. It was, a beta unit, and we actually shipped it to, a beta customer in Texas. They offered to do an evaluation of the product and see how they might use it in their application, similar to the challenges that we were having. It really, we really struggled to get that to run reliably before we shipped it. We installed that machine, we got it running and we left it for, I think it was 2 or 3 weeks and it ran flawless.

BH: Wow, 2 to 3 weeks.

JT: We were all pretty shocked because we knew the challenges that we were still facing before we went to a production version, but that fact that it wowed the customer and it ran flawlessly really said, hey, you know what this is? This can work. If we can get some of these bugs worked out so that it’s they’re not, coming up all the time, we have something pretty special, really cool.

BH: And kind of moving from technology to product. This is where your career takes an interesting turn. You move from developing technology to thinking more about products. And those things obviously always aren’t the same thing. So why did you move from software development into product management?

JT: We went through a restructuring after, Klaus passed away in 2005. We had some new management. It was a lot of restructuring happening. And, most people that were in managerial roles interviewed for their position and interviewed for alternate positions. So it was it was basically trying to figure out where is each person best suited. So even though you’ve work your way to a certain point in your career, maybe, maybe you’re better off over in this department. Right? So it was really, rethinking of our organizational structure. And at that time, too, we were going through a lot of cost considerations, you know, so I interviewed for my role, essentially, and, well, in the product development role. And it was better suited that I was a product manager. And because we had also decided to reduce our development budget, there was, unfortunately some other people that were let go. So, I was I was asked to, be a product manager for the SuperBots, the pick and places, the feeders, and SuperTrak. So that did mean stepping away from a primarily software development role.

BH: And was it difficult to move away from kind of hands on development and kind of hands on work to a different kind of work?

JT: Absolutely. I probably never fully went away from it. I always tried to stay a little bit in touch with the technology. For from SuperTrak perspective, I always said that there wasn’t a screw changed or a dimension change, a drawing I didn’t know about for years and years and years. I like to stay right in touch with all the details, even though it was really wasn’t my responsibility to be involved at that level all the time.

BH: But, you had a good kind of perspective from multiple angles to understand if this is going to be valuable or it could cause problems down the road. And how do you, becoming a product manager, changed the way you looked at SuperTrak?

JT: Cost and schedule would probably be the things that come to mind right away, because in the development stages, especially, the early years never got pushed on timing or cost. It was always, you know, get it done as quickly as possible, but I wasn’t worried about costs. Yeah. You know, just get it to work is better once you become the product manager now you’re worried about, you know, how long does it take you to do something? What are your commitments? What are your costs? Right.

BH: And so when did you realize that making the technology just kind of work wasn’t enough? You needed to be more than that.

JT: Probably in the product management role. It’s like I tell people, the SuperTrak we didn’t set out to develop a linear motor like a linear servo motor. We set out to develop an automation solution for convenience. Right. So it’s not just about what does that technology do? You know? To move an actuator. It’s more about how can we make automation simpler for the, integrator.

BH: And kind of next question, which is, which is I think very relevant at ATS is, what is the difference between a successful engineering project and a successful product?

JT: That’s a tough one. I think the, engineering project is successful when you’ve eliminated all the bugs at the end, you’ve you basically checked all the boxes on the requirements for the that the end customer has put in front of you. The successful product is that we’re anticipating the customer needs. We’re checking the boxes before the customer even ask for it. This may be the way I’d put it.

BH: Kind of leads into the next question. Is there anything that you learned from customers about the product that you hadn’t maybe understood properly as an engineer?

JT: Yes. Specifics are going to be difficult. The it kind of goes back to, you know, developing a linear servo motor versus,  an automated solution. It’s, providing detailed specs isn’t always what the customer, wants. They,  really they think about it differently because they don’t understand the product at the detail level. Right? They understand the high level application, they understand the high level application. They ask questions differently. You know, what seems obvious for an engineer is not obvious to the end user.

BH: And then kind of moving to commercialization, it’s one thing to invent something. It’s another thing entirely to make it repeatable, scalable and successful across an organization. So what did project management, operations and commercialization kind of teach you?

JT:  Well, product management definitely taught me to think about the finances of the product. Commercialization taught me to listen to the end customer, listen before speaking.

BH: Moving on to technical sales, so working directly with customers changes the way you think about engineering. Suddenly you’re solving business problems just as much as technical ones. Did you ever imagine yourself working in technical sales?

JT: I don’t think I would have called it technical sales. I think, from the early stages of SuperTrak, specifically because it was a very small team that I think in a lot of ways we were doing some level of technical sales. It was convincing. And in the engineering days, you know, we’re convincing more on specs and, longevity of the product, things like that. I probably wouldn’t have called it tech sales. I think it really became technical sales when it became less engineering work for me, and more time spent with the ATS sales team in answering customer questions. And then it became very obvious that spitting out, you know, specifications was not what they wanted to hear. t’s not, you know, I mean, it’s important, it’s important, but you can you can spit out velocities and accelerations in 30 seconds and then you move on to how does this product actually benefit you?

BH: It’s following more of a traditional sales process, just in a technical kind of state of mind. What makes a technical person good at selling, do you think?

JT: Listen first, understand what is the customer actually asking and then answer second.

BH: What do you think engineers typically get wrong when they try to explain technology to customers?

J: Oh, goes back to spitting out data, specs, specs or too much information. Overwhelming technical details to, an audience that is maybe not familiar at the level that we are. I mean, that’s something that I’ve had to learn over the years is to think about it more from, the end users perspective that’s not familiar with how a servo motor works.

BH: Yeah, yeah, because everyone’s been through that experience where you’re presenting to a group of people something technical, and then you’re looking around, everyone’s falling asleep, and it’s never the greatest feeling in the world when you’re giving a presentation. How did speaking directly with customers change the way you understood SuperTrak?

JT: Well, that’s what got me turned around to let’s talk about the SuperTrak with how it can benefit your application. Right? What features do we can we provide to you or we have embedded in a product that’s going to make your life easier, make your make your machine run more reliably, save you time on integration as opposed to spitting out those specs again.

BH: Yeah yeah yeah. Now after seeing so many automation applications, what do you see today that you wouldn’t have seen when you were 25 in the industry?

JT: I think it’s the fact that things are changing so constantly and so rapidly, and they continue to do so. It’s pretty amazing to me that the changes never seem to stay static for very long.

BH: Things are always moving and then kind of moving to kind of reflection. After hundreds of automation projects, experience becomes something different than knowledge. It becomes almost a perspective. So after 31 years, do you solve problems faster or do you simply recognize them earlier?

JT: I would say recognize you recognize gaps in, you know, in a theory or, a project. You understand the technical gaps, quicker. Challenges that they’re at this point, if I’m seeing them as a technical problem, it’s probably more challenging to solve. So I don’t think we solved them any quicker. But you can you can definitely see past, through past, experience that there’s a problem here, but we solved it this way. So you can maybe guide that, guide the rest of the team through a problem quicker. But those I wouldn’t even call them problems anymore because we already know how to solve them.

BH: Yeah, it’s just kind of a challenge that you’ve encountered. You’ve solved it. And now how to understand when you encounter similar problems again and utilize similar solutions.

JT: Similar problems. It’s not really a problem anymore. It’s when you find something new, those are probably going to be very challenging to solve. So I don’t think there are I don’t think problems are actually solved quicker.

BH: Are there any mistakes you’ve watched the industry repeat?

JT: In general? Not necessarily, like in my world, but just generally I think sometimes technologies are held on to for too long, right? Not jumping into or not grasping that this technology is antiquated and we need to move on. I’ve seen some, you know, design specs that have come from customers, like, well, you haven’t done that in ten years, right. But they’ve held on to these technologies and these specifications for too long.

BH: It’s their comfort zone. Their comfort zone. It’s like anything, like you got to get out of your comfort zone if you want to move forward. Yeah. Okay. How do you know when to push an idea and when to maybe just walk away?

JT: Yeah, that one’s tough. I would say, you know, I’ve had ideas that I like to push and sometimes, not everybody is on the same, same bandwagon. So I, you know, you wait until you can build up your use case portfolio and say, okay, this this idea could have been used in these different applications, right? And try to push it forward that way. So maybe it’s, just step back for the moment. I mean, maybe you’ve come to realize that your idea is, yeah, not going to work, so then you just drop it. Yeah, yeah. But I sometimes you just walk away for the moment, build up a case for it.

BH: And kind of connected to that, has your relationship with technical risk change throughout your career, do you have more of an appetite than maybe you did early?

JT: I think you could look at that two different ways. I think in the early days I would not have been scared of any risk. I would have just jumped in. But I wasn’t responsible for cost and schedule. Right. And that’s where that new perspective of being project management or product management comes into play. So in the early days, no fear of risk.

BH: When you have infinite time and infinite money.

JT: Exactly. So, you know, once you once you get the other elements to your career in place, you know, and especially, you know, project management, then all of a sudden technical risk becomes schedule risk becomes cost risk. And so maybe a little bit, more fearful of it now than I would have been when I was younger.

BH: In your kind of observation, what do younger engineers tend to underestimate?

JT: How long it takes to do a development. We still we still do that when we get older, too.

BH: Yeah. Two weeks should be fine.

JT: Yeah. Yeah. Exactly. It often takes a lot longer to do a development than what you think.

BH: Yeah. And is there anything that you’ve learned from younger engineers and their approach to the job?

JT: You know what I like working with younger engineers because they’re enthusiastic and they’re optimistic and it helps me stay that way too, because sometimes you get a little pessimistic, because of, you know, all the roadblocks, you know, the hurdles in, you know, just working through or I’ll call it bureaucracy, right within the company. Yeah. And, you know, the young engineers just don’t have that when they come in. So that kind of excitement rubs off on you.

BH: Is there anything that you can see now that you simply couldn’t see 30 years ago?

JT: Well, first of all, that I’m still here. I did not anticipate that, honestly thought there would be other careers that would, evolve over time. I think what has happened at ATS has been that constant evolution of change that I guess I’ve been fortunate enough that the change has been positive for the most part, through everything that I’ve, had to go through. You know, I think that there’s people that would struggle with certain changes and that would cause them to want to move on. Right. I’ve been lucky enough that it’s given me opportunities to take on different roles that have been exciting, and I don’t think I would have anticipated that.

BH: Interesting. Steve Wardell actually said something very similar to that because he’s had a number of different roles within the company, but it’s the same company. But he said it’s almost been multiple different careers. Yeah, it’s been with the same company. It’s it hasn’t been boring for a second.

JT: Right, right.

BH: When you think about the next generation of engineers coming into automation today, what’s the one thing you hope they learn earlier than you did? I know I’ve said it before, but it is and is really listening to what the customer wants. What do they really need? And forget about the this that’s like not forget about it. But don’t just start spitting out technical specs. Really listen first.

BH: Okay. Well, thanks, Javan. This has been a fantastic conversation. Your career wasn’t defined by a single role. It was defined by looking at the same challenge from different perspectives. You started by learning how to control machines. Then you helped build platforms. Then you learned how to turn technology into products. And finally, you helped customers apply those products to real manufacturing challenges. It’s a reminder that engineering is about much more than solving technical problems. It’s about creating solutions that people can build, support, adopt, and ultimately trust. Thank you for sharing your experiences and the lessons you’ve learned over more than 31 years. And thanks to everyone for listening. If you enjoyed today’s episode of Enabling Automation, be sure to subscribe wherever you get your podcasts. Until next time, thanks for listening.