What is engineering?
I’m a graduate engineer. Engineering was just a job for me that deals with machines, construction, and electronics. The next steps in my work life were technologies and software development. Then I read about bioengineering and genetic engineering. And finally, I was surprised when engineering was mentioned in terms of management. Then I understood, at last, that engineering and management are not about machines and people, this is about problems resolving approaches. I decided to go deeper with the word management and I’m ready to share my thoughts about engineering.
Let’s get started with the definition. Here is what Wikipedia says “Engineering is the use of scientific principles to design and build machines, structures, and other items, including bridges, tunnels, roads, vehicles, and buildings.” I always say to engineers that engineering is a search for a solution to a practical problem. And I often use a metaphor of the left and right sides of our brain. We have knowledge, skills, experience, tools, methodologies, even gut feeling from one side and problem requirements, restrictions, environment from the other side. The art of engineering is to apply an appropriate solution to the problem within a limited time.
The wider the arsenal of an engineer, the better the solution will be. The deeper an engineer dive into the problem, the accuracy of the solution will increase.
Unlike scientists, engineers don’t create new solutions, or at least they shouldn’t. I don’t know about all the industries, but software engineers often tend to create their own solutions. Important, engineering is always about projects and the main restriction is time. I often say to software engineers, don’t reinvent the wheel, think twice if you can integrate or customize a ready-made solution instead of writing your own. There is a high probability that somebody already resolved a problem that is similar to your one.
So, the solution from the engineer’s arsenal is usually preferable. The pitfall here is the law of the instrument which can lead engineers to narrow specialists. They can be great masters of the tool or the skill or the methodology. And it can work for a specialist very well. It can be market-driven and can bring a lot of money. But if a specialist has the only way of problem-solving I believe it cannot be considered as engineering.
That’s why engineering supposes permanent knowledge and skills development. This is especially difficult to do nowadays because of the dizzying rate of technological progress. This is why a lot of software engineers tend to narrow down their specialisations. They forget that we are living in the knowledge economy. Sometimes I observe cases when skilled but narrowly specialized engineers lose market fit and opportunities.
Engineering is always about full-cycle resolving of the task. And requirements elicitation is a critical part of the job. Let’s say if a client asks an engineer to build a cable-stayed bridge. The questions an engineer can and has to push back are “why do you need a bridge?”, “what problem are you trying to resolve?”, “perhaps the best solution for your problem is a tunnel?”. For instance, this is a widespread situation in software engineering when clients or stakeholders just ask to build a solution without clarification of the business problem. From one side, it can lead engineers to the execution of tech tasks that don’t correspond to problems. They just do what was asked. On another side, it can lead to conflicts between engineers and stakeholders if engineers push back tough to understand the problem. A lot of engineers feel nervous if they are not able to discuss a business problem and feel their values diminishing. And many of them became someone who doesn’t care, they became just tech geeks.
To clarify a problem, to find a solution in a limited time, to avoid pitfalls, to develop skills is not trivial. It’s hard for any kind of professional, not only for engineers. And I saw many times that passion is a crucial part of engineers’ success. Even novice engineers can perform the job much better than their skilled colleagues. If there is a fit between the project/product and engineers’ aspiration the result can be unique.
Perhaps my vision of engineering is too vanilla. Nevertheless, this image of a tech specialist is often expected by different stakeholders and definitely, it makes sense for specialists to aspire to that ideal.
Engineering as an approach to problem-solving is really important even for managers. Cambridge dictionary says to engineer means “to arrange cleverly and often secretly for something to happen, especially something that is to your advantage”. Merriam-Webster goes further and says it means “to manage as an engineer”. What does it mean? If managers learn some instrument and apply it in their work they act as engineers in fact. It works well, but compared with technical areas managers got less predictable results. That’s why managers often hear “let’s zoom-out”, “let’s think out of the box” to create a unique and individual solution to the problem.
