I've been thinking a lot recently about innovation and the challenges associated with trying to innovate. Because I work mostly with engineering companies, I focus mainly on the challenges in that area. This is a summary of some of my thoughts in this area and how my thinking is starting to change.

In the beginning...

I used to work for a major car company until 2005. Let me start by saying that despite the impression that this essay might leave, I thought this company was a great company and I still do. The point here is not about good companies vs. bad companies but about the dangers of risk aversion.

I want to start with a brief anecdote about when I first starting working in this area. Somehow (I don't remember how, because this wasn't my area), I ended up in a meeting where we were discussing collision warning systems. The basic idea here was that the car could be equipped with a sensor that could determine if the car was getting too close to an adjacent vehicle (this was back in 1995 when this was "new"). I remember saying at the time what a great idea this was and I remember getting some "hold on their young fella" push back. "It isn't that simple" was the message.

It was then explained to me that if you had such a system you had to find some way to indicate to the driver that this collision was about to happen. My response was "well that seems simple enough". But they didn't see it that way. The gist of their argument was you can't just add a light to the dashboard or an alarm sound. People might freak out. They might misunderstand. They might over-react.

You won't get any argument from me that safety comes first and we absolutely need to consider the safety implications of innovations before implementing them. After all, I put my family in these cars and so do other automotive engineers. In my experience, nobody at an automotive OEM is cavalier about safety.

But this was a case, ironically, where the risk of being sued was actually preventing an innovation related to safety from being implemented. I saw many examples of this. So called "intelligent cruise control" (where the car maintains a safe distance from the car ahead of it) was one example. I also saw prototypes of "heads up displays" that enhanced the drivers view at night so they could more easily spot hazards. These didn't make it to production and, at least from where I was sitting, the main obstacle was risk. Not only did you have to worry about what happened to drivers of cars that had these features suing you because they didn't work (in a way the driver expected), you also had to worry about lawsuits where people sued because their cars didn't have that feature. I say this because that was the case, at that time, with airbags. There were lawsuits from people who sued because their cars didn't have airbags. As a result, if you put a safety feature in one car (i.e., a luxury car where people were willing to pay the incremental cost of the safety enhancement), you risked getting sued by buyers of other (cheaper cars) for not installing those safety features in their cars. In such circumstances, it was actually less risky for the company to simply avoid innovation altogether.

All of this happened quite a while ago and I suspect that the corporate culture embraces such innovations a bit more now with the growing importance in-vehicle technologies. Furthermore, it is easy for me to throw stones because I didn't have to deal with the fallout of the risks and I didn't have any quantitative data on which to base my conclusions about the wisdom of any of these decisions. All of this is anecdotal, so take it with a grain of salt.

Silicon Valley

But one thing I learned while working for an OEM is that car companies in Detroit are full of very smart people. I tell people that whenever somebody says "Why can't Detroit figure out how to ___", the answer is always the same: cost. It might be manufacturing cost, it might be the legal risks. But the key point is that it was rarely the case that they didn't know how to do it, it was that they didn't know how to do it cheaply.

My experience was that it was a very common theme in the media to bash US car companies. I've seen plenty of unfair comparisons between Japanese and American car companies. So I suppose it was inevitable that, when companies like Fisker and Tesla started out, we'd be treated to a wave of "Detroit vs. Silicon Valley" comparisons as well. I heard plenty about "Silicon Valley is going to teach Detroit how to make cars" sentiment.

My response was always the same. I would point out that the car industry isn't so much about technology as it is logistics. Success is in building cars efficiently and cheaply. That means volume, marketing and supply chain management. To be a real car company, you have to be able to sell cars that a fresh college graduate can afford. Until then, you are running a boutique operation.

But people rarely recognized this. Instead, they always had a narrative about how Detroit was going to be "taught a lesson" by newer, smarter companies. For example, there was plenty of optimism in this Fisker announcement from 2009:

Production is scheduled to begin in late 2012. Fisker Automotive anticipates Project NINA will ultimately create or support 2,000 factory jobs and more than 3,000 vendor and supplier jobs by 2014, as production ramps up to full capacity of 75,000-100,000 vehicles per year. More than half will be exported, the largest percentage of any domestic manufacturer.

...it turned out that they were getting a bit ahead of themselves. After all, they went bankrupt in 2013.

Tesla is a different story. They are definitely a boutique operation (even today). But we'll come back to them. Let's talk a bit more about the US OEMs first.

Enterprise Thinking

I've worked for several companies in my career. I've worked for small companies and large companies. Even though I prefer small companies and I'm about to rant about the drawbacks of large companies, I want to make clear that I think these issues are unavoidable in large companies. I'm not faulting them for having these issues, but I will fault them for not recognizing them and/or doing enough about them.

When I worked for an automotive OEM, we used to have annual reviews and one of the things we were assessed on was "Enterprise Thinking". The criteria here was that you didn't base your decisions and actions on the potential benefits to your local organization but to the potential benefits to the organization as a whole.

I think this is an extremely important quality and it was an excellent idea to rate people on it. But I have to say that I didn't see much Enterprise Thinking. My experience (which may have been unique to me or my particular organization) was that if you collaborated with other organizations you were less likely to get a pat on the back as you were to be seen as a backstabber. This is an entirely natural and predictable consequence of organizational dynamics in a large companies. So I don't see this as a "character flaw" so much as simply a challenge to be recognized and overcome.

Organizations were very protective of their own and they tended to be pretty insular. Most of the people I saw in leadership positions had been with the company quite a while and they seemed more interested in riding out their time to retirement than on taking on challenges. It was usually easier to pass the buck to your successor than deal with difficult changes. We actually had a name for this: "R.I.P." which stood for "retired in place". Again, pretty predictable and probably no worse than in any other large organization.

So I accept that change in a large organization is hard. But that isn't an excuse for not trying. Many of my friends in large companies are so jaded now that they have given up on meaningful change in the same way that many of the electorate have given up on finding politicians who aren't complete narcissists. In the automotive business, we often talked about the need to avoid "change for the sake of change" or the need to focus on "continuous improvement, not continuous change". I agree that we sometimes embark on new approaches that don't actually produce any tangible benefits and it is easy to become jaded after witnessing that a few times. Nevertheless, another key leadership ability is the willingness to embrace and promote meaningful change in an organization. I always found that, along with enterprise thinking, in pretty short supply.

Strategy and Innovation

There is a point to all this and I'll try to get to it soon. But I want to introduce a few more observations. Although much of this is related to my experience in the automotive industry, I suspect there are many parallels in other industries. So hopefully people in other areas can relate to this (or hopefully not, I should say).

I found that within an automotive OEM there was a fair amount of strategy and vision related to the logistical side of manufacturing. Lots of energy was spent on figuring out efficiency in the supply chain and keeping costs low.

The Rockr moved Wired to headline their profile of the phone with the question "You call this the phone of the future?"

As far as "in-vehicle" technology is concerned, I think many people have experienced the frustration that the systems in their car seem to be so much more primitive than other consumer electronics they have. When in-vehicle phone integration first came out, it was pretty awful. I'd say it has risen to "not bad" in many ways with current Bluetooth integration. But I think you'll find that in-vehicle systems still lag behind their consumer electronics counterparts. Apple's CarPlay is an attempt to build bridges into that space. Apple's is clearly turning their attention to the car business and it is hard to know exactly what their plans are. But it seems entirely plausible that CarPlay is the Rockr of Apple's move into the automotive market. The question will be, are they just biding their time until they make cars of their own?

Where I really see these issues being the most problematic is the area of internal technologies. I've written before about some of my frustrations with the way engineering companies do IT. Not much of that has changed.

But an additional example that I've been wondering about more and more lately is the ineffectiveness of collaboration. Part of it is related to the issues surrounding "enterprise thinking" that I talked about before. But another aspect (related to this issue of risk) may be that people within these organizations are partially afraid to share what they are working on (or support the ability of others to do so) because of issues regarding "document retention". For those who aren't familiar with this how this works, companies frequently implement document retention policies to ensure that documents older than some specified amount of time are collected and disposed of. This isn't as nefarious as it might sound. I've been involved in plenty of such purges but I've never seen a case where it was driven by the need to destroy or cover up anything. It is more related to ensuring that there aren't "partial" records of things. The need to actively dispose of these documents also comes from the need to be consistent about getting rid of records so it doesn't look like you were intentionally trying to destroy a particular test result or design but were instead applying this process consistently to all corporate documents. But, of course, such policies are, again, mainly to avoid risk (of having it somehow be used against you). Whenever you make a permanent record of something within a company people will be concerned about the long term consequences for record retention and the potential to misunderstand or misinterpret that information (sometimes deliberately).

What is your point?

If you are still reading this, I'm impressed. Let me try to finally get to the point of burdening you with all this anecdotal material.

I said earlier that I always looked at a company like Tesla (or perhaps Apple) as not much of a threat to the legacy auto makers. The point of this article is that I'm starting to change my mind.

Of particular interest to me was Tesla's recent announcement of their Autopilot functionality. I have to say that having spent almost 10 years working for an automotive OEM, I never imagined I would see a day where somebody would implement this functionality in a car that was driving on ordinary roads. I always assumed this would come only with the advent of elaborate infrastructure that would require massive capital investments (which seems unlikely in the face of the US' crumbling infrastructure, but that is a whole other story).

Why did I never expect to see this? Risk. I still cannot imagine how Elon Musk got this past the legal department at Tesla.

Don't get me wrong. I think computers have the potential to be much better drivers than humans. So I am not personally that concerned about the risks associated with such functionality (and Google's self-driving car accident data seems to substantiate this).

While I historically found Tesla to be a boutique car manufacturer (and they still are, at least for the moment). What has really impressed me is their willingness to take risks. I've been to Tesla and I know that this willingness to try new things isn't just limited to the car itself, but also the process by which the car is designed and that, I think, is the existential threat to legacy car companies. I'm sure all the car manufacturers can get to the point of building self-driving cars on par with Tesla and others. What I'm not so sure of is whether they can transform internally so as to compete with the potential efficiency gains that I think rethinking the design process has to offer.

Do I think that this a case of the classic boiling frog? Probably not. I think that if car companies continued as they are going today, they could actually be toppled by newer car companies in the same way that seemingly dominant Research in Motion was crushed by Apple. But I don't think that will happen. I think legacy car companies will be forced to change. But not now and not without a lot of hand wringing and hard knocks. Change is difficult and takes a long time once you recognize the need to change. Not only that, it won't be enough to implement change internally. I suspect they'll also have work to do in getting their brands back on track in the same way they did when they first started taking fuel economy and quality seriously (i.e., they have to change the minds of consumers as well). The question I have is how long will it take these car companies to rise to the occasion and how tarnished will they be by their slowness to respond?

My hope is that this threat will stoke the flames of innovation within these companies now rather than later and that the engineers within these companies might finally start reaping the benefits of the amazing innovations in the software and IT space that could help transform their internal processes. I even dare to hope that they recognize that such transformations need to be driven not by existing large, monolithic legacy partners, but by companies who have staked their existence on innovation and transformation.

My Goal

As a company, Xogeny's goal is to find a way to bridge the gap between the technology sector and engineering. The technology sector is a veritable fountain of innovation and progress. On the engineering side, we don't really leverage all of these advancements. As engineers, we live in a world that is like a time capsule containing technology from 20 years ago (or more).

So I've tried to dedicate myself to finding ways to channel innovations I see in the software and IT world into engineering so that engineers can benefit from all the same kinds of advances that we see fueling the growth and innovation in the tech sector.

Easier Said Than Done

Of course, I didn't expect all this to be a piece of cake (otherwise we would see more of it). But I initially assumed the hard part would be identifying the engineering problem and pairing it up with the software/technology solution. What I was expecting (and is still mainly true) is that people coming from an engineering background really don't recognize that the solutions coming from the software/technology space actually solve some of the engineering problems they have. For example, many of the advancements that Modelica brings to the world of physical modeling are actually derived from graph theoretical algorithms from the computer science world. But this topic is hardly limited to modeling and simulation, I see it across engineering. As I've pointed out previously with topics like version control, things that are "solved problems" in the software world continue to plague us in the engineering world either because we don't recognize how to apply the technology or we frame the problem is such a way that we make it difficult for ourselves to leverage the solution (or both).

I have been pleasantly surprised so far that most of the people I've talked to on the engineering side have been quite enthusiastic about my ideas around web-based engineering analysis applications and cloud based engineering workflows that combine engineering problems together with software solutions.

But The Real Problem Is...

But even when I get engineers enthusiastic about how we can modernize engineering software, what has really stymied me is the IT organizations. Now I should say in advance that I recognize many of the challenges faced by modern IT organizations. I was the Global Director of IT for Emmeskay. So I know there are lots of operational details that need to be covered. Obviously, these organizations are constantly working to make sure all the hardware is functioning, that email is working, that viruses aren't spreading and that networks are up. Not to mention, for example, the various regulatory concerns regarding financial controls in publicly traded companies.

But in my discussions with a bunch of people in engineering organizations from different industries, the one thing we all seem to agree on is that there is an organizational issue between the engineering and IT functions. When I speak with engineers, it is almost universally the case that they see IT as an organization that largely rebuffs their requests. In a nutshell, it is (at least from their perspective) an organization whose job is to say "No".

This is not meant as a generalization about all IT organizations. I've seen several very forward looking organizations where IT and engineering work very closely to great effect. But in my experience, those are the exception, not the rule.

This is fascinating when you consider that I'm talking about engineering companies. Their entire value proposition rests on doing engineering work. And yet, that value proposition is in many ways diminished by their inability to leverage innovative ideas.

The bottom line is that you end up with engineering organizations being subservient to IT organizations when, in my opinion, it should really be the other way around. This is actually partly an organizational issue. The organizational part is that IT should have its deliverables set according to the engineering agenda. Of course, part of those deliverables will be functioning infrastructure. Part of them will be related to other essential functions like HR and finance. But some of them should be related to innovation targets set by (forward looking) engineering organizations.

But this is not entirely an organizational issue. There is a deeper issue. And here is where I turn the tables a bit. There are lots of good reasons for IT organizations to say "No". Engineers, left to their own devices, will likely tend to formulate quick and dirty (non-robust) approaches or seek out short-term (short sighted) solutions. Furthermore, they are not necessarily conversant enough in the technologies and approaches to really come up with concrete plans (or hire a consultant like me to help them). So part of the problem is that some fraction of the engineering side need to actually learn about the technologies that are available and the opportunities they afford and be conversant enough to really negotiate with the IT organizations in a knowledgeable way. In a sense, the result of this compartmentalization of engineering and IT is that it creates a communication breakdown where the requirements from the engineering side cannot be properly articulated and any objections from the IT side cannot be credibly challenged.

"Engineering IT" Manifesto

So my point here is not to point fingers. IT is a complex topic and implementation is hard. It is understandable that requests that further complicate the task are frequently met with a "No". On the other hand, we need to modernize the way we view the role of IT in engineering companies.

As such, I propose the following Engineering IT Manifesto as a way to think about how we move forward from this point. The essential points are:

#1: IT is an essential component of Engineering

We cannot deny this fact. The only consequence of denying this is dysfunction. The fundamental thread that runs through all of these points is the counter-productive compartmentalization of IT and Engineering. The first step in addressing that is dismissing the notion that they should be compartmentalized in the first place.

#2: Engineers must value IT

An engineers fluency in IT must go beyond email and spreadsheets. Fortunately, my experience is that the next generation of engineers seem to be more informed and interested in learning about how IT can add value to engineering. But we need to make sure that they are given the chance to explore this and that this exploration is valued by their management. My sense is that most young engineers I know are held back by generations of engineers who want to continue using legacy approaches. This is a lost opportunity of epic proportions, in my opinion.

#3: IT deliverables must be tied to engineering success

It seems clear that the power structure in engineering companies needs to reinforce the idea that the engineering groups need to take a more active role in defining the deliverables for the IT organization. This means not just that they have the authority to define deliverables, but that they have the knowledge (as per #1) to do so.

#4: Stop looking to vendors to solve your problems

What I often see is engineering organizations who don't want to be "distracted" by IT related issues. They see these issues as somebody else's problem (or at least want them to be). This not only reinforces the compartmentalized approach to IT, it puts them in a frame of mind to "outsource" their IT related issues. Sadly, this often means being coaxed into buying large, monolithic software solutions that do lots of things they don't need and only a few things they do need (poorly, in some cases).

One thing we, as engineers, can learn from the software world is to look for light, modular approaches. We don't want to have to create our own solutions from scratch nor do we want to embrace these monolithic solutions. The "sweet spot" is in composing solutions from "building blocks" that solve specific problems and then putting them together in a way that makes sense for our engineering processes. But this, of course, requires an understanding of how to put the building blocks together (see #1).

#5: IT and Engineering need to formulate a joint strategic plan

The final piece in this puzzle is to make sure that somebody is pushing a vision of the future that capitalizes on emerging technologies to benefit the organization. This vision needs to bring both IT and engineering stakeholders to the table to map these things out. Too often, engineers are content when they have processes that yield the correct mathematical or physical result and overlook the business need for competitiveness. For an engineering organization it is necessary that somebody be aggressively looking out for how to improve the overall efficiency of the organization and capturing value from innovations in the software/IT world.

Summary

We need to see this compartmentalization of engineering and IT as a bad thing and take steps to break down these barriers. IT people need to see their role as facilitating engineering innovation and engineers need to be better educated in these topics to help formulate solutions and independently evaluate the merits of different processes or strategies. I think there are many people on both sides who would love to work toward this kind of vision.

Of course, I'm biased. I spend a lot of time thinking about this nexus between engineering and IT. I see so much potential here and yet so little interest in exploiting it. So there is always the chance that much of this is just wishful thinking on my part. But based on conversations with lots of people, I still see this as an issue that could bear a lot of fruit for engineering organizations.

I would love to get feedback on this. Whether I'm right or wrong, I'd love to hear from you (or better yet, help you and your company address these issues). So feel free to contact me or share you comments below.

As mentioned previously, Xogeny collaborated on the development of an open source package manager for Modelica. This package manager, called impact, allows Modelica developers to easily fetch versions of their favorite libraries whether they are developed by the Modelica Association or third parties.

The latest version of the impact package manager is now available from PyPI and GitHub. Version 0.5.8 introduces, for the first time, full compatibility with both Python 2 and Python 3.

These improvements are due to the hard work of Dietmar Winkler and Matthis Thorade.

Background

I spoke recently at the NAFEMS Americas Conference. This group tends to focus on CAD, FEM and CFD stuff, historically at least. But I was really pleasantly surprised to see a tremendous amount of interest around two themes from my talk.

System Simulation

The first was system simulation. There seems to be a growing interest in the NAFEMS community about system simulation. Obviously, this is an area I'm really interested in. One topic many people were discussing was how to connect system simulation and other types of analysis that incorporated geometry. Since my Ph.D. was in FEM, this is a topic I've thought about quite a bit myself. Coincidentally, I just produced a series of webinars for Dassault Systemes and one of them is on this very topic! If this is a topic you are interested, I encourage you to fill out the form to get access to the video.

Reaching Non-Experts

One of my big goals is to try and extend the reach of simulation to non-expert users. As someone who worked on building complex mathematical models for a long time, I was always frustrated by the lack of "reach" these models had. This was another theme of my talk that seemed to be getting a lot of attention at the conference.

My Presentation

Since I work primarily on web-based applications, I chose to make a presentation that was web-based (using a tool I developed called cadeau, BTW). That means no PowerPoint, no PDF. This presentation was dynamic and included interactive web-applications embedded in it. As such, it wasn't really possible to include it on the USB handed out at the conference. But, because it seemed to be well received and several people asked me about getting a copy, I produced this video that covers all the topics I covered at the conference and a few more:

Video: Web-based Engineering Analysis at NAFEMS Americas 2014

(A lower-resolution version is available on YouTube as well or at least will be once they are done processing it)

Remember - If you want to keep up on what is going on at Xogeny (blog posts, book updates, etc), don't forget to sign up for the Xogeny mailing list.

I recently sat down with Jeff Waters from Modelon to discuss the importance of standards. I feel there are many lessons that we, as engineers, can learn from the world of software. This is a recurring theme in my work and on the blog. That same thread comes through in this discussion on standards in modeling, simulation and engineering.

Check out the Modelon site for this and other interviews recorded during the Modelica'2014 discussion.