Engineers are not taught to innovate.
Engineers are not taught to innovate.
No one is more surprised than I.
I walked amongst the brightly illustrated posters, inspecting each innovation with a practised eye. I had eagerly accepted my invitation to the show offered by the graduating engineers of a university. Each poster summarised 12 months of work by newly minted engineers, to offer an opportunity to enjoy their creativity and ingenuity.
Each young team bracketed their posters. Each smartly turned out in new suits that would no doubt see plenty of use in the rounds of interviews that most in the hall would soon endure.
My purpose was simple and direct. I had a question. I always have a question, and this one had arisen only after years of professional innovation in a large engineering corporation. This question is best demonstrated with an example.
I approach a group of friendly and welcoming youngsters, and peer in silence at their invention. A little boat, without a crew. Autonomy is all the rage, and the integration of boat with intelligence was clear. I turn to the young team, and they launch into a practised pitch.
This little boat was to join its siblings within the hold of a larger mothership that would sail the seas in search of something interesting. Once found, the mothership would disgorge this flotilla of little boats, and they would putter off to do their thing.
I listened attentively, and then asked my most basic of questions.
Why? What is this little boat for? Why is it little? What is the purpose of so many of them? Why does the mothership carry these little boats? These are all variations of the same question.
What problem have you solved?
The answer came quickly. This team of young engineers had solved the problem of controlling a small autonomous boat, so that it could sally forth from a mothership and perform its required function.
What function?
This team had no idea.
Problems and solutions reside on either side of the same coin. One engineer’s problem is the solution to another’s. Whilst one engineer might require a hammer to drive in a nail, another must design and build the hammer.
These engineers had been offered a brief to design a small autonomous boat. However, how could they design a suitable mechanism if they had no idea what function it should serve?
This team had only been offered a requirement and designed a mechanism to fulfil this requirement. Design a boat that can drive itself.
I thank the team for their time, and move on to the next group of young innovators. This poster summarised an unmanned drone that could take off from the helideck of a ship, and was similarly flanked by a team of young engineers.
Of course, the real estate of a ship that possesses a hangar, helideck and helicopter will be scarce. To add this unmanned drone will likely demand the removal of the helicopter. Does this drone do more than a manned helicopter? Does this drone do at least as much as this helicopter?
Once more a team of young engineers look at me blankly. They had been asked the design an unmanned air vehicle that could take off an land vertically from a ship. They had no idea why.
I offer an option. Perhaps an unmanned drone might be useful to launch and recover from the deck of a ship that doesn’t possess the infrastructure and crew requirements for a helicopter, like an oil tanker or some such other large vessel?
They all agreed.
Good idea.
This performance was repeated at every single presentation I attended. Engineers are taught to respond to a requirement. The efforts of these young engineers stopped at the edge of the requirement. Build something this size, this fast, this heavy, with these features.
None thought to ask what the mechanism was actually for. None had been taught to query the requirement, or to interview the customer in any depth.
A customer will often define their problem in terms of an imagined solution. They solve the problem for you, and yet they likely haven’t. Not one of these student teams had questioned the question.
They had not thought to because they had not been taught that this was an option, or indeed how to do so. The answers I receive to this particular enquiry often surprises me, and I am sufficiently jaded by commercial engineering to not often be surprised.
I have now enquired with a wide range of trained engineers, from those early in their career to those who have been doing the job for decades, and not one has reported that they were ever taught how to innovate.
None.
None of their university degrees taught them how to interview a customer. None learned how to transform this interview into a description of a problem. None sat for any course which described how this problem is transformed into a concept. None were taught how to pitch this concept back to the customer, and modify their proposal.
Consider the design cycle itself, which loops from customer discovery to technical development and back again. Two processes intersect, to pass information from one to the other through the definition of a suitable concept.
First we might dismantle the customer problem and develop solution strategies that are incorporated into this hypothetical concept. Observation, analysis, diagnosis and presentation. This cycle will continue until the concept is refined, and the proposal begins to become elegant but may begin to look like science fiction.
Loop around customer discovery too long and this science-fiction will ultimately provoke scepticism, and to mitigate this scepticism we will require hard evidence. Here the concept that we have developed now forms the basis of a requirement that is delivered to our technologists.
The boffins will transform your question into an experiment, or a prototype, and with this will determine whether your proposal truly can take flight. This evidence may modify the concept, which may raise more questions, and the technology development cycle will continue until we have a practical means to solve the customer’s problem.
With this prototype to offer the evidence that we need, we once more skip tracks to cycle around the upper customer loop. Here the technical prototype transforms into a minimum viable product, with which we can observe, evaluate and respond to the customer’s reaction to our solution.
Electives that do offer students an understanding of the bigger picture tend to focus upon the topics such as pitching to customers or the development of business justifications and plans. Typically, these tend to be electives that fill in some of the blanks on the top right of that figure 8.
What they don't tend to focus upon is a rigorous process required to transform the customer need into a formal problem statement and the logical mechanism required to transform that into a valid concept. That is typically achieved by the ubiquitous brainstorming, plenty of sticky notes and little more.
When I ask graduates about the details of their inventive process, they tend to look at me blankly.
In the main, it seems that to gain a qualification in engineering, one must competently reproduce the STEM skills required to exercise the bottom technology discovery loop. The rest is all learned on the job, assuming one ever encounters the need to do so. And besides, how would you examine and award a team of young students, if the solution is not to be found in the back of the textbook or in an agreed marking scheme or a list of requirements?
If engineers are only ever formally taught how to exercise the technology discovery loop, in which requirements are transformed into technology, then who is working out what problems we are all solving?
