These are some mistakes that I’ve made and I’ve seen others make on engineering projects:
1. Jumping to the “how” before understanding the “why”
My dad likes to tell the story of a man searching for something under a lamp post. A second man sees him and asks what he’s looking for.
“My keys,” replies the first man.
“Where did you lose them?”
“Over there,” the first man says, pointing a few yards away to the shadows.
“Why are you looking here then?”
“The light is better here.”
Don’t be that first guy.
2. Assuming the person you are talking to knows more than they actually do about your area of expertise
It’s not easy speak up and admit that you don’t understand something especially in front of a group or for superiors in front of their team. That may cause people to seem like they understand or agree when they were really just confused. Research your audience ahead of time to determine how much exposure they likely had to your area of expertise. It also doesn’t hurt to watch your buzzword count and compile some good analogies and metaphors.
3. Assuming the person you are talking to knows less than they actually do about your area of expertise
Want to be more charismatic? Make the person you are talking to feel smart. Ask some questions to clarify what they already know and where their gaps in knowledge are. It’s always awkward to hear someone explain a concept for 2 minutes only to be interrupted with “I knew that, I just wanted this one particular question answered.” Bottom line, don’t make assumptions.
4. Not asking questions or offering insights
As an engineer and a person you can provide insights to help direct the course of the product or system. Worse case scenario nothing happens. Best case scenario you add value/save a life/cure cancer.
5. Not understanding how you fit into the end-to-end product life cycle, architecture, or business model
Your brain power is underutilized if you only focus on solving problems in one step of one process. Understanding the context can help you not only contribute towards broader goals more effectively but also make your day-to-day design and analysis tasks easier.
6. Hoarding information
If you’re a knowledge worker you probably studied and learned on the job to accumulate your current knowledge. Share it. You’ll be seen as a thought leader, your impact will scale, and you’ll have more time to acquire new knowledge.
7. Communicating with stakeholders in your language, not theirs
If you want to shorten the time you spend in meetings and the length of emails with your stakeholders, learn what is important to them and the vocabulary they use. Then deliver questions, pros and cons, and options in that language.
8. Underestimating the influence of politics, funding, and organizational change on an engineering plan
Unless you are very lucky you won’t be designing products or systems in absence of political, business, financial, or regulatory pressures. It’s a lot easier to understand that landscape ahead of time and to incorporate it into your idea generation than to keep going back to the drawing board.
9. Becoming isolated
Surrounding yourself with only people who think like you and talk like you results in boring products.
10. Building for ourselves instead of the customer
It can be hard when you are spending 50-60 hours a week with a product to not feel like it is your baby. Our job as engineers is to use technology to serve the needs of people, which doesn’t always align to opportunities to test out that new technique or technology you’ve been dying to try. Start a side hustle, take a course, or run some design spikes to gain new skills.
Do you make any of these mistakes? Any other tips on how to avoid them?
2 thoughts on “Top 10 mistakes engineers make”
All the points are excellent. Point #1. really resonated with me. As an engineer, understanding the why/what in the beginning provides a context to the how. When I thoroughly grasp the why/what and always allow it to remain at the back of my head decisions about the how become much clearer and finite because the how becomes a means to an end and does not devolve to an end in itself. Thinking about “what are we doing and why are we doing it” first makes “how are we going to do this” much easier and if lucky even obvious. This is an excellent site/resource!
That’s a great point! Some people rush to the design phase to finish quickly but in the long run it’s much faster (and cheaper) to take the time to identify the need first. Without defining the problem space before moving to the solution space you could end up wandering around the solution space hoping you’ll eventually fix the problem. As you said, getting that clarity upfront can help narrow down the design options and maybe reveal some options you might not have otherwise considered.
Some questions to ask upfront: Who are we expecting to help? Why do they need our help? Is this problem just a symptom of something deeper?
Comments are closed.