Engineering was once about creating technology that could solve problems or otherwise improve life. It was a careful combination of applied sciences and experimentation, leading to the invention, or perhaps discovery, of many great technologies.
The word engineering itself comes from the latin ingenerare, which means “to create”.
When thinking about the history of engineering, we tend to think about things like the steam engine, the telegraph, cars and planes, submarines and ships, space exploration; basically big complex machines doing things that seem incredibly hard. Common to those, and most other inventions, is failure. And loving failure. Failure is a step on the way towards success – although it may also be a step on the way towards an even worse failure. And we have perhaps come to focus too much on that latter scenario?
Five years ago I worked as an engineer on an oil and gas project at a shipyard in Asia. I was representing the technical safety discipline for the ship owner – basically a job of overseeing and guiding the organization contracted to engineer and build the product (which was an FPSO – a floating production, storage and offloading vessel). That deliverable is definitely a large and complex piece of machinery – requiring knowledge about marine engineering, chemical engineering, process control, risk management, pipelines, electrical engineering, human factors and ergonomics, rules and regulations, petroleum economics, project management, etc. And in the end, the project succeeded, the vessel was delivered (costing some 2 billion USD to build, approximately), and is now producing oil and gas in the North Sea.
This is all good, but what is a typical workday like for an engineer on a project like that? Is it solution oriented discussions, calculations to verify design parameters, testing of build quality, etc? It is definitely that too, but more time is spent on:
- writing comments on other people’s documents
- going to meetings where people are not prepared and there is no agenda, and there are no decision makers in the meetings anyway
- reading vast amounts of documentation, some of it of the type “manual for establishing procedures for testing of completeness of factory acceptance test plans”. Far too much of it is of that type.
OK, I guess you get the picture. Engineers spend a lot of time doing bullshit work, stuff that is definitely not “lean”, and that probably doesn’t contribute much to improving the quality of the deliverable. Long hours spent writing comments on close to meaningless documents – what does that do to the engineering profession? This is probably not very good for creativity.
It is a good question why it has come to this. Companies are now managing risk, and they tend to be afraid of getting the blame for defects, or “being liable” as a corporate lawyer would have said. I think that is an important part of the picture, leading to excessive “collaboration” by writing a ton of skeptical comments on things, where the real intention is no longer “to create” but rather to “cover your corporate ass”. We should fight this tendency – and to do that it seems necessary for companies to take larger risks, to take on an embrace “liability” and not to obsess over “corporate governance” at the expense of following growth and innovation focused strategies instead.
Don’t get me wrong, there is a lot of creativity in engineering still – but we stifle it with processes that do not support creation, nor do they create any real risk controls – they are just fueling the “we’re not liable” school of thought.
Collaboration systems: the good, the bad and the evil
Writing a ton of comments on someone else’s documents or other types of work has become very easy with the introduction of digital workflows. The comments are even searchable, traceable, and can provide a perfect solution for the liability-driven engineers to follow the “cover-my-ass” path. This is the evil made possible by commenting systems – and that evil has become more accessible as we have moved from “project comment forms” to comment fields in collaboration software.
Comments can also be good, in fact very good. They can point out things that are wrong with a description, potentially saving a project from complete disaster – that is real risk management. They can point out possible improvements, saving time, or money, or making a feature better. They can stir up new ideas, leading to new technologies, solving adjacent problems nobody really focused on. So, what separates a good comment from a bad one? Let us explore!
- The motivation of the commenter is to contribute to making work better
- The comment is short and concerning a specific idea, case or topic
- The comment raises a question that needs an answer, or provides insight that is not included in the original work
- The tone of the comment is positive
- The motivation of the commenter is to cover his or her ass (reduce liability)
- The comment is long and general
- The comment does not provide any new insight, or does not raise a specific question
- The tone of the comment is negative, seeking to establish the commenter as more authoritative than the person who has performed the original work
How can a collaboration system foster good comments and discourage bad ones?
Good comments are typically short and to the point, whereas bad comments are often long and general. Limiting the length of the comment field is therefore a potential remedy to the “long rant” type of negative influence.
Promoting comments that have value to make them stand out and be more visible is also a tactic that can increase the value of a collaboration system. Potential ways to do this is to include a “likes” function, such as used on most social media platforms, or to have some manual moderation of comments by someone who is very insightful. It is also possible to do this by giving commenters karma or credibility points, and value the “Likes” from authoritative collaborators more than those from others, such as seen on tech oriented sites like slashdot.org or stackoverflow.com. None of these systems are perfect, and they can be abused – but using “social quality checks” is quite efficient if the people commenting are not dishonest.
Labeling of comments can also improve the usability of a commenting system. A comment may for example be labeled “Question”, “Relevant Facts” or “Improvement Suggestion”. Then it is easy for other readers to quickly see all questions, or all improvement suggestions – depending on their goals when reading the comments.