EP 1: Insights From a Leading CIO-The Next 10 Years in IT w/ James Rinaldi


James Rinaldi, Chief Information Technology Advisor, Jet Propulsion Laboratories joins us for a fascinating walk through his commanding career heading up IT for Marriott International, the Internal Revenue Service, U.S. Food & Drug Administration, and JPL.


His current role at JPL gives James a new perspective, and he shares his projections for where the tech is headed, as well as some impactful leadership insights that CIOs both seasoned and new won’t want to miss. 


We talked about where IT is heading for the 2025-2030 timeframe;  how the fluid nature of IT displays itself in an IT organizational structure; and, leadership reflection and advice for new CIOs. 


To hear this interview and many more like it, subscribe to the Unleash IT Podcast on Apple Podcasts, Spotify, or on our website.

Cybersecurity was one that kind of drives through all architectures, whether it's business, whether it's, you know, technical or whatever, and gets into the human element. And there is the missing element, in my opinion, about architecture. It's the human experience. Welcome to unleash it, a podcast where we discuss the experiences and ideas behind what's working in enterprise architecture and digital transformation within the IT landscape. Unlock Your Business has digital capabilities. Transform your enterprise architecture. Unleash it. Let's get into the show. Welcome to unleash it, where we talked with leading IT professionals about what's going on in their worlds and where they see the future of it heading. Today's guest is James Vinaldi. James, welcome to the show. Thank you, I'm glad to be here. So why do we first start with? Why don't you give us a little bit about your background and where you're from, and maybe even a little bit of how you got into it in the first place? Okay, sure, well, I've been in it my whole career. It was at the time graduating from high school and going into college, it was a choice between business management or it and at back in the least, it was called something else and I decided I didn't want to. I love computers and I want to be around computer technology, and so I chose that at path, and both academic and math, I might add, and then professionally. So been in it from the early days on till now I've been associated with it and employed for that purpose. See if been both in the private sector as well as the public sector as well as I have, I have actually never been in the same kind of business more than twice the same kind of industry government. I don't consider you know, I wouldn't lump at all as one industry, because I was with irs, which is totally different than FDA, which is totally different than NASA, and so it's like three different companies and three different industries because their purposes are so different and they don't run alike. And plus being in the public side or the private industry with Marriott for almost sixteen years, plus some companies prior to that, you know I've got a good view of all sides. It looks like now. And what's your role today? What's your current role? So I'm with JEP fulsion laboratory on a Caltech employee. Caltech is on contract to manage JPL and I've been there going on fifteen years, majority of it was CIO. In October I stepped out of the CIR roll after fourteen plus years and working with the Office of the Director and particular the deputy director, on looking at the future strategies for it as as an advisor in individual contributor role, which was new for me, managing people since one thousand nine hundred and eighty two. So it's a great opportunity for me to do that, plus squawd in my experience doing other things.

So it was hard stepping away because I really enjoyed the organization I had built. On the other hand, I was starting to see it's time, you know, to do something different in the step out and I had a very good deputy I'd hired who could step in and and so things just work naturally that way. And so today working on what something I call future it and looking at what things could look like and what jpl should prepare for for the two thousand and twenty five to twenty thirty time frame really and what are some of those predictions that are insights that you're deriving from. So, in particular, looking at the maturation of AI andml. The trends are showing invest in those now, because the fruition or the payoff is going to be big time. And you know, another five years of maturation. You already get seeing some games today, but it'll be fully embedded into technologies by the two thousand and twenty five time frame. And also looking at date architectures that can take advantage of that. Looking at, you know, where compute is going, at the advent of Guandom computing. Is that going to usher in a new realm of computing that is maybe a thousand times faster than what we have today? And what does that mean for robotics? What does that mean for processes that today may seem fast but are too slow for where we're going to need to be? And so I'm in joying looking at that. As a CIO, I looked at those kind of things. Of course I have some people helped me, a very good cto for example, and so I'm really enjoying looking at what the future can bring and hopefully have an impact, continued impact on JPL, even past my time at JPL. So you must have seen when you were CIO. Over the past three years there have been a lot of shifts and what I've seen is the emergence of the CTEO and an organization. I've seen the emergence of a chief digit, locosar any organization. Were you examining some of these types of organizational shifts? Well, you are, CIOS. I will. I will tell you this. When I got to JPL, you know, I built an organization that I knew would change every year, and it did, and it's because of the nature of it changing so rapidly and being so pervasive that you had to create the environment and the jobs that people could continue to grow and take the organization in and CTO was one of my first ones. I've always believed in a CTO, not an operational CTO, as some have it's more of one who looks at emerging technologies in positions as well for what we should invest in for the future and working with our customers as well to do that, and that work really well for me in the past, but also work well for me JPL. Yes, of what kind of responsibilities with that CTO have and bringing to the table for you so many and primarily looking at emerging technologies, prototyping those technologies with strong...

...customer participation and input so we know what we're dealing with. JPL's made up some very, very smart people, and so getting their time and getting their input is quite valuable and we were able to take a lot of prototypes. We were earlier doctors, for example, in cloud way before was fashionable, because we saw that that could offer capacity that we could not otherwise acquire in a different way. And so the CTEO drives those kind of changes and drives those evaluations of technology. One of the key elements of any it organization, in my opinion, is that for your customers, who are very smart, to come to it, they've got to trust it. It knows about it and it's not just an operational organization running email and providing desktops in laptops, and so that was one of our goals. Has Become the organization that people want to come to and we can give them our opinions on technology and where it's going and then work with them to get the right technologies in to support their functions. Yeah, did you run into a lot of shadow it while you were there? I mean, JPL was very fractioned in terms of its it. When I got there, and so shadow it was a necessity because the way there was no strong, necessarily central organization. I was the first executive level CIO at ap all and and you, so I had brought in a sense of purpose to the job that was little different than what they had prior and so and doing that, you know, you certainly run into people having to do their own it because there was just no other way to do it. And so I didn't fault that. I never faltered the customer for trying to get their job done and took that as great input for us to what we need to overcome, not by control, more by persuasion and by doing the job better than they could. And over time I knew we would. It's just can't keep up with all the changes and so in it. So that was our model and it I think it worked pretty well and the awards we've been given over the years have taught me that we must have been doing something right. Yeah, so it was that, the collaboration between you and the different business units that was going on. I mean, how often did you talk to them? How did you get to the root and there every week? It was some conversation every week with either the leader or some of the organization. Having that customer outreach was very important. It's not easy to communicate across of broad range of customer. You could do a broad, lad wide or enterprise wide email, but that doesn't really reach people. I believe there's segments of customers. There's, you know, customers who work a certain way and they not. They may not even be in the same organization, but they work a certain way. And for I to provide an effective delivery of services, not just efficient effective, it's really important for it to...

...know what that set of customers needs that may be completely opposed to what another set of customers need. Now that creates an environment of potentially overlapping technologies and services. Nobody likes that because it seems very inefficient. My argument is if your effective first, then over time you get more efficient and you look for those efficiencies. But if you're not effective, it doesn't matter how efficient you aren't, you're not going to last law. So I just did the math that way and it seemed to be a very effective way of working for the CEIO the last fourteen plus years. Yeah, now, how would you measure the effectiveness I mean efficiency is one thing. There's definitely key indicators there, but we have an effectiveness. How are you measure is a customer being able to do your job. Of first foremost is the systems we develop, the infrastructure we put in place, the services we deliver. Are they satisfying the customers needs, anticipating their needs, because there's not always going to be the same, and then being responsive in the delivery of those services, and it could be anything from the latest iphone to, you know, MAC windows, all those kind of variations out there, but delivering them in a way that the customer going to say, we're going to get them on time. I'm satisfied with what, then we measure, you know, satisfaction. But the best way I found is to talk to people. And you know, I sat on the Executive Council, which is our highest level council, and, believe me, people are not shy things aren't going well. And so you know, for the most part things went really, really well and we delivered very responsive services. People could call me directly, was fine and I would make sure things went well. But we had a good infrastructure in place and a good set of providers that made sure that you know we were delivering toward customer, because you set the tone at the top and I certainly hope that's what I did now. So I just want to take a little bit deeper in there. So one of the areas that I've been following closely, of course, as enterprise architecture, I'm trying to learn more about it, is used to be very framework oriented. You had Toba, you had a lot of these frameworks going on and what I've talked to see Iowa is in particular. They always look at enterprise architectures being somewhat ivory terwerish, and I think with the cloud and everything that's going on in today's world, you still need to have an enterprise architecture be much more dynamic. What are your thoughts on that? Oh, I totally agree. I used to call our architecture chaotic architecture, not enterprise architecture, and to some degree it was on purpose, because we did not have to have the same tools for everybody, the same systems for everybody. Again, what was effective for this organization, say the Engineering Organization, may be totally different for the science organizations or the research groups, and so you had to be responsive in that sometimes would create some conflict.

So we try not to have more than two or three of the same kind of technology. So there's no reason to really have more than one email system. But you know, we were challenged. We had over a hundred twenty when I got there. So you don't really need that and you know you don't need that many. But on the other hand, you know what I found an architecture. First of all, I tried to downplay the term enterprise because it often connotes one size fits all and that definitely is not true for the type of company and the type of place that JPL is. On the other hand, could we again strive for efficiencies where it makes sense in our Networkfra structure and things of that nature? Of course we will, and of course we have to live within our budget. So part of the architecture is thinking like a business, and so we ran it as a business within a business, you know. So we had our financials, we had our workforce, we had our services and we had the governance to help us make decisions and we set on all the governance councils with a laboratory as well, and so we tried our best to make sure that we had inclusion in the decisions we make. But there are CIO decisions you make that you don't necessarily want everybody's input, and that tends to be more the infrastructure. You know, we're a data driven organization, so having strong and reliable networks is imperative. So if I didn't invest there, you know, it didn't matter. What was the endpoint if they couldn't communicate? So the architecture. There's the IT architecture, there's also the business architecture. How the business work? What are the things that we do in JPL, or any company for that matter? You know, I would look at it the same way, is, what are the things that the business does that creates an architecture that it should be responsive to? They're not necessarily going to be always aligned or always the same, because it may have to do some things in the architecture that the business doesn't have to do. And so this is where I do have problems with certain frameworks in architecture because they tend to be either very technical are very up to when it comes to people understanding what they mean. So we talked in different terms and talk, you know, and try to develop things that we knew architecturally would work for us, leveraging capabilities we'd are used many times, but that the customer doesn't care about that. That's how it becomes efficient behind the scenes. And but the customer cares. Are they getting the functionality they need? Are they getting access to the data they need and can we make it as seamless to find? Search was a big deal. We wrote our own search because finding information was so hard that we decided we would take...

...advance to open source capabilities and create our own search and that's been a huge delivery for us for the years. Yeah, we that where other projects like search that you also ran into that you had a tackle outside of the maybe prescribed architecture. Well, it's well, you always have to meet. In our case we also had to meet some compliance. So balancing, you know, the government compliance that they asked us contractually to meet with the way we tended to want to do things as an FFRDC, you know, that made us a little different than say, some of our colleagues in government, you know, could be challenging, and so we had to be very creative and how we met the intent of the requirements we were given and sometimes we had to create opportunities to do that and we were pretty successful at proving our case and that cybersecurity was one that kind of drives through all architectures, whether it's business, whether it's, you know, technical or whatever, and gets into the human element. And there is the missing element, in my opinion, about architecture. It's the human experience. And what does that mean? Are Is that person getting what they need out of what they're doing? What's the experience for them? Is it easy to do something or is it more difficult? Are they getting what they need? And if you start with that, you could build or configure a better it, regardless of whether it's cloud or our less awarees, where it's at. It could be local, it could be whatever, as long as you're thinking about how do you meet that human experience that people want, and we all get frustrated with it. I get frustrated shopping online if it's not quick, if it's not intuitive, and that experience is how people are growing up today. That's they're used to it, and so why can't I do the same thing? All of that that I just discussed falls into the realm of an architecture and the way it should be. Thinking in terms of delivery of capabilities, meanwhile continuing to it always improve what it's doing and looking at always trying to disrupt itself so that it doesn't get complacent and it's way of delivering services. Yeah, that' doesn't another shift that that I'm seeing is going from where project based it and to product based it and actually looking at the the services being delivered as an ongoing it's not just like a one and done. We get something stet up and we move on, but it's really this continuous improvement, continuous development that's happening within the IT organizations are cloud but I would also Harken back to when the first iphones came out and we got we started becoming application Orient there's an APP for it. Remember, we used to say that all the time. Well, the real meaning of that is you could find the functionality you need in an application that you can quickly acquire, and the people who develop those applications had to...

...continuously keep them updated or they would not last. And so that suite of technology is really ignited and then empowered more by cloud computing, has ignited this whole thinking about delivering services like a product and then continuously improving them versus having this big, very costly phases of improvement and instead have more incremental my experience has taught me if you let something legacy as the killer of any it organization, quite frankly, and if you let the legacy age without frequent updates, the cost of upgrading that legacy becomes phenomenally high and it keeps you from investing in some of the newer things that people need. So I like this new wave. I like of continuously developing, continuous improvement, and again, the newer technologies allow for that. Yeah, we're seeing a lot of people moving towards micro services. And when the challenges, and I know you face this yet, but when the challenges is managing all these micro services now, instead of just having two, three thou applications that you're managing now, you had tens of thousands of these microservices. Is this something you guys are running into? Are Starting to see? We were starting to see a lot of that and I started worrying more, first about where all my data is. And Yeah, you know, so by by definition your you know, for a company says they're not into using the cloud, they probably don't know they're using the cloud because of all the SASS offerings, all the you know, Microsoft Office, you know, one drive, Google Suite, you know, those are cloud offerings. And if you have data in those things, how are you managing those things? How are you accessing it? Can you find it? So it's imperative that people understand that part of it. And then all the services that you mentioned, the micro services. It's complexity is certainly there, but what you get out of it may be worth it. And the fact that you can build you know, in the cloud today you would taking a legacy system and just moving it into the cloud doesn't accomplish a whole lot. But if you take advantage of the cloud capability, whether using micro services or you capabilities or you know, platforms that are service now for that matter, you know, provide an opportunity to do things in a more cost effective way by taking advantage of it. That's not new. That was true back in mainframe days as it is today. It's just there. Wouldn't there's only people like me back this day. So so so it's a lot different today and it's actually so much fun. I'm not as technical as I used to be, but I love being in those meetings to hear those kind of things and to hear you know, and one of my favorite meetings of all time has been our quarterly project reviews, and they started becoming more product oriented,...

...but they were still projects to get the work or they get the service built, and I would go eight straight hours it was, you know, or more, because I enjoy seeing what we're doing and hearing what we were doing and how we were doing it. So those were exciting days for me and now I'm doing more exciting things, so fewer to give some advice to, say, a new CIO, someone who's just moving into a position or starting out as a CEI adit new company, but what some of the advice that you would give them? Yeah, I think first of all, leverage what you have. You can't build a better past. So, you know, if you see something that doesn't make sense, they're probably at one time it did make sense. So if you see we're okay, we can improve something, then put that out there. But coming in and looking at the past and saying why did you do this, why did you do that? It's really not very fruitful. How do you go forward? Is really that the way to think about it and be thought of? Is that seeio who wants to drive things forward and there's always something to fix, but there's always an opportunity to push things where the company could get value out of it, and I would focus more on that. And also communicate. Learn how to communicate, to be social as much as you can. A lot of it folks are introverts, but if you can walk in a room and make a friend, do so. Develop relationships the best way you can with your colleagues inside it and outside of it. And then external. This one sometimes gets overlooked. You have a lot of folks, there's a lot of cios in the same boat and if you can reach out and compare notes, you'll gain confidence, you'll learn some things and you'll observe styles, and different leadership styles can really help, especially new CEIOS, and learning how to communicate, both written and verbally, but also just socially interact so that you fit in with that c sweet versus looking like the tech guy that you know got promoted. Well, that's great advice. Well, James, thanks so much for being part of our show and carrying on this discussion with me. Really valuable insights that you brought to the show today, and thanks everyone we'll see you in another two weeks. You've been listening to unleash. I T to ensure that you never miss an episode. Subscribe to the show in your favorite podcast player. If you'd like to learn more about enterprise architecture and tools to help unleash your businesses digital capabilities, visit lean ix dotnet. Thank you so much for listening. Until next time,.

In-Stream Audio Search


Search across all episodes within this podcast

Episodes (24)