I had a partner project meeting a couple of weeks ago. That project kicked off mid 2011 and came to an end with that meeting. That project started for me with a conflict and ended with a question: are engineers just pessimists?
That project combined hardware from the partner with software from my side. As many times, this project had as well the ‘make or buy’ and ‘use in-house or from external’ questions and the project partner was looking for a recommendation. Looking at the requirements, the firmware could built upon something we have available in-house. Even better, some parts of it I have coded myself. So you might think that should have been an easy decision? Nope. Definitely not. The conflict was: should I propose the own software and tools, or recommend something else?
If you are an engineer in the trenches, you see all the problems. In fact, your job is to deal with problems: multiple projects and commitments the same time, budget and resource cuts, tight delivery milestones, unreasonable requirements, hardware and software issues, in-existing or wrong errata; you name it. You are directly affected. You are in the middle of all the problems. You have to cut corners, make too many compromises in the design, implement inelegant workarounds, fixing and patching, you are constantly fire fighting. You always know “once there is time, I know how to do it right”. Only that there will be never that time. Never.
So as an engineer or anyone close to the product, you might get a pretty pessimistic view of it. For the question “If you know that an airline runs the safety critical software from your company, would you fly with that airline?”, you might get interesting answers, depending who you ask. Engineering? Marketing? Sales? Management? You might be surprised by the answers. Or maybe not :-).
The pessimistic view at your own products might even create a bizarre side effect: your company/department/management might start to think that the competitor product is way better than yours. Why doing something what others seem to do better, and you start thinking about outsourcing what they believe is not good enough: The grass is always greener on the other side of the fence thinking.
I think as an engineers I’m sometimes too honest. Not a bad thing, as long as I’m aware of it. Just be careful if your boss or bosses boss asks you for an honest engineering opinion: this might not be what he really wants as outlined in this Dilbert. So as an engineer I’m responsible to share the good news and good things of the product I’m working on too. To counter the honest but often pessimistic impression others might have.
Back to good part, the partner project mentioned at the beginning: The conflict was solved with honesty and with an engineering-to-engineering approach: There were several engineering meetings. Pros and Cons of our software and tools were presented. Additional time has been spent to explain the things which are not so great, and what are the workarounds. Not promising too much, and to tell about the known holes. To the point that a single known bug is worth more than ten features.
Result: The project partner decided to go with our software and tools recommendation. There were the usual challenges, and the project run to an end with the meeting mentioned at the beginning of this post.
An engineer from the partner company was so pleased with the result, that he made this comment:
I think you should have pointed out the great features at the beginning of the project. But you did not?
I shared with him my thinking about engineering honesty, pessimism and Green Grass thinking. His response was:
You know what: we have exactly the same thing in our company!