“10 Mistakes I Made My First Year As An Engineer”

Discover what you should and shouldn’t do in your first engineering job.

What does one year of experience in your first engineering job give you?

For a lot of people it can be many different things.

But one thing for certain is mistakes.

Nobody is perfect. We all make mistakes. And in your first year of working an engineering job you will make plenty.

But the most important thing is to learn from them.

In this post I will be sharing with you the 10 mistakes I made in my first year as an engineer. But more importantly, I hope you look at this post and understand how to avoid making the same mistakes.

The post is kind of long so you can skip to the conclusion if you want. But you will get more value out of the post if you read what my experience was.

Mistake #1: Communicating With Non-Engineers

What’s more important… knowing how to engineer really well? Or knowing how to communicate really well?

My very first engineering job that I got was a bit unusual. I was working in a startup incubator designing a hydro-turbine. A startup incubator is a place where startups can get funding from an investor and build their company.

This was a relatively new startup incubator so there wasn’t much of a huge team. I was hired by the main investor as an engineer to help the other startups when it came to engineering.

I was the only engineer there (there was one other guy but he got let go pretty quickly).

Things were going well with designing the hydro-turbine. I was reading books. I was making calculations. I was coming up with designs. Every week I would go in and give my boss a status update on how things were going.

One day I went to my bosses office to give a status update. He had told me that in order to move the project forward we needed to convert horsepower into watts.

Confused, I asked him why? That doesn’t move our project forward at all. Horsepower is a measure of power. Watts is also a measure of power. They are the same thing. My boss…just did not understand this.

After about an hour of going back and forth with him I finally explained the horsepower situation in the following way.

“Horsepower and watts are the same thing. It’s like if I told you to go walk 1 meter…and then said, no don’t walk 1 meter walk 3.3 feet….you still went the same distance. Meters are a measure of distance and so are feet. It doesn’t matter if you convert meters to feet, it doesn’t change anything.”

I remember this vividly. He sat there looking at his desk. Thinking about what I just said and finally came to the conclusion that I was right.

Here’s the thing, my boss at the time did not have an engineering degree. He had a business degree. He had no clue about physics.

Here’s the mistake I made. The problem wasn’t that my boss did not understand physics, the problem was that I did not know how to communicate physics to my boss. I did not know how to communicate engineering concepts to people who were non-engineers.

I had spent years in college surrounded by only engineers. If I was explaining that horsepower to watts situation to an engineer, they would completely understand me. But to non-engineers…they most likely wouldn’t.

This is when I finally understood that communication was an important skill to have.

95.5% of employers consider oral and written communication an essential skill.

I was always told communication was a top skill employers looked for but I never understood what that meant until that day.

Design skills can be taught. Engineering skills can be taught. Physics can be taught. But none of that matters if you can’t communicate these concepts to your team.

Mistake #2: Business Business Business

Not understanding how corporations work.

If you were going to build a business how would you set it up? If you asked me this question back when I started in my first REAL engineering job I wouldn’t have been able to tell you.

I was a few months into my new engineering job. The first engineering job I got after college with my bachelors degree (the job from the previous mistake was when I had an associates degree). This was a big company. Billions of dollars in revenue. Site locations all around the globe.

I had never been in a place this big before. I was walking down the hallway with one of the many managers my department had. He was new to the company too, but not new to working in industry.

We were having a good chat because we were both practically new and in the same boat. But then frustration came over me. I vividly remember asking him…

“I’m trying to figure out how corporate America works.”

I didn’t expect his response.

He just put his head down and laughed.

I remembered thinking in that moment, was this a stupid question? Or was there something he knew that I didn’t know? I came to realize that corporate America is imperfect.

I realized that the system I was in was pretty big and that most people at my level didn’t know all the ins and outs of how the company worked.

There are so many different departments. So many different layers of management. So many different job functions. So many different processes that it doesn’t really make sense to try and understand it all. Unless you plan to move up the management hierarchy or you just want to know for fun.

But there was a real issue here. I was totally lost my first few months of being in the company. I had no idea who to go to for resources. What typical resources did we have?

I was so ignorant to business that I had no clue what HR was or what that department did. I didn’t know what managers did. I didn’t even know what I was supposed to do my very first day!

I spent months not understanding how a typical business worked and how I fit into everything.

The mistake here was not that corporate America didn’t work, but that I didn’t understand how corporate America worked.

I took an MBA in a box course on Udemy to learn more about business. It was there that I got a high level overview of how businesses were structured.

Every business is made up of 3 main areas and different functional blocks at 3 main levels of hierarchy.

The 3 main areas of business are…

1. Operations
2. Sales/Marketing
3. Finance

The 3 main levels of hierarchy are…

1. Executive Management.
2. Mid level management.
3. Low level management.

Each of these functional blocks (called departments) play a different role in the company. These departments work together with one another to achieve only 3 things.

1. Get paying customers into the business.
2. Deliver products/services to the paying customers.
3. Make sure the money in the business is managed properly.

Each functional block (departments) are made up of two groups of people.

1. Managers — People who make sure tasks are getting done on time.
2. Specialists — People who actually execute and complete the tasks.

When you have these two groups of people working together you have a team.

I would love to go more into the business side of things but that would be another post for another time.

The point is, if you are going to be starting your first engineering job soon it’s important to understand how businesses are set up and operate because you are going to be working in one.

Mistake #3: Project Management

Getting things done on budget and on time. Managing my work.

Let me ask you a question. What is the biggest indicator of success? Is it smarts? Is it luck? Is it timing? I’ll tell you what… it’s none of those things. At the end of this section I will share with you what the biggest indicator of success is in your engineering job.

My very first project as an electrical engineer for a big company was making a hardware design in VHDL to be implemented in a CPLD.

When I got the project I was excited to get started. Then the wall of information hit me. My design was to be implemented in a larger system. And I knew nothing about this system.

There were input and output signals that I wasn’t sure what they did. There were acronyms that I had no clue what they meant. There was a lot of stuff. So what do you do? I just started learning about the whole system. To understand the whole thing.

Everyday I would go in, figure out what I didn’t know, and kind of pick a spot to just start learning. To speed this story up, I wasn’t doing so well. The project lead came to me one day and frustratingly asked me “Why is this project taking so long?”.

This was a low-complexity project and I had already spent 3 months on trying to design it. I had looked back at what I had done and it was practically nothing.

The mistake I made here was simple. It wasn’t that I was not smart enough to do the project, it was that I didn’t know how to manage the project. I wasn’t executing.

Project management is all about making sure progress is being made on the project.

Management is all about understanding what are the tasks that need to be done to get to the finish line, and checking every day that those tasks are getting done correctly. Helping out when necessary to remove roadblocks.

Here are a few key things that I learned to do in order to better manage what I get done in the time that I have.

1. Create a Kanban board. A Kanban board is really just a fancy to-do list. There is more to the idea of Kanban in project management but you can look up the details yourself.
2. Before you go home for the day, define 1–3 tasks you will complete the next day.
3. Be proactive. Don’t wait to start something.
4. Begin with understanding what “done” looks like for that task. How do you know when it’s complete?
5. When you are doing something, ask yourself “Is this moving me closer to completing the task?”
6. Complete one task at a time before moving to the next. Try not to jump from task to task (sometimes you have to jump to another task due to circumstances and changes).

Going back to the question I asked you at the beginning of this section, the biggest indicator of success is execution. It’s being able to get things done every day. The way you manage your execution, is through project management.

Mistake #4: Documentation

Not documenting what I did well enough.

Here’s another one that comes back to communication. Documentation.

Documentation is for you and for others. You need to keep a record of the following for all your tasks.

• What you did.
• How you did it.
• Why you did it.
• When you did it.
• Who you did it with.
• Who you did it for.

Here are a few examples from my own experience why documentation is important.

Example 1

You will often work on designs other engineers have made. I was working on this one design that was last updated in the 1980s. This was before I was even born. The original engineers who designed it are long gone now. The documentation wasn’t great on what they did, how they did it and why they did it.

A common question that comes up is “Well how did they implement this in legacy (meaning the original design)?” The response 90% of the time is “We’re not sure”.

We still have to find a way to design the system obviously but it would have been easier had we had all the documentation about what they did, how they did it and why they did it.

Example 2

When I first started as an engineer I would go to meetings and a lot would be talked about. But I wouldn’t write anything down. So naturally, as a couple of hours go by you forget exactly what was said and sometimes what to do.

I would speak with a lot of engineers in their office. We would spend sometimes an hour talking. After that hour is up I would go back to my office and think to myself… “What did he want me to do again?” I would forget something that we talked about towards the beginning of that hour we spent. It would have been easier to just write it down. Now I have to go back and ask the same person the same question again.

Example 3

I was recently audited on work that I had done my first year as an engineer. There was a lot of stuff people wanted. I had to piece together emails and reports and a bunch of other stuff to account for what I was doing. It would have been so much easier if I just took the time to properly document what I was doing and where things were, at the time I did them.

My girlfriend and I

My girlfriend works in accounting so audits are nothing new to her. She gave me some great advice. “Work today as if you are going to get audited tomorrow”. This is great advice.

The mistake here was that I was not documenting well everything that I did.

This is why I say with everything you do in your engineering job (design, testing, training etc.) you want to keep great documentation of the following.

• What you did.
• How you did it.
• Why you did it.
• When you did it.
• Who you did it with.
• Who you did it for.

It also wouldn’t hurt to have some proof to go along with your documentation. Sometimes you can’t get proof but try to if you can.

Mistake #5: Knowledge

I tried to learn everything but you just can’t learn it all. Only learn what you need.

Source: https://knowyourmeme.com/memes/math-lady-confused-lady

Here is another huge mistake I made that connects back to mistake number 3 (project management). In that story I was not making progress because I wasn’t managing myself and executing on the tasks that would push the project forward.

The reason that was happening was because I focused too much on learning instead of doing.

When I first started working I tried to learn everything. I tried to learn how corporate America worked. I tried to learn how the whole system I was designing for worked.

There was so much stuff that I didn’t know, and the documentation was either hard to come by or didn’t even exist. It takes time to learn.

I would go into meetings and come out more confused then when I went in. There was information that was discussed at other meetings that I wasn’t a part of so I had no clue what was going on.

I spent most of my time just trying to understand everything. This got me in trouble. Because work was not getting done.

After a few months I quickly learned that I wasn’t the only one. Pretty much no one knew everything. There were some people that had more pieces of the puzzle than others, but no one that I worked with on a day to day basis had the full puzzle figured out.

What you really need to do is only focus on the information that you need to complete a single task.

You don’t need information on the whole system. You don’t need information on the whole company. You just need the information that will help you to complete your task.

Once I made that shift and gave up on trying to know everything, I made so much more progress.

I’m an engineer. I like to understand how things work. But there is a time and a place for that. When you are working as an engineer for a business, you need to produce results.

Mistake #6: Results

Not knowing how to give a status report that pleased people. Have to know who you are talking to and what they care about.

Can you guess what this mistake was related to? I don’t know if you guessed it right or wrong but it’s related to communication.

As an engineer you need to keep people informed about what’s going on with the project and what the status is.

How do you communicate this status? I had no clue how to structure it. I would give status updates to people on the team and project managers every once in a while. My status updates would go something like this…

“Spent time checking out the 3.3V power rail today. It was not working. Going to figure out why.”

Looking back at this style of communicating…it was horrible. It was vague. It didn’t give people much information about what the status was.

I remember back when I was doing a project in community college for a professor I had made a big mistake.

I was designing an induction flashlight with a few other engineering students. I was responsible for the circuit.

One day I was walking with the professor who was managing the project and he asked me “How’s the circuit going?”. This was his way of asking for a status update. I told him “It doesn’t work.”

What he did next I will remember for the rest of my life. He taught me an important lesson that day.

He turned to me and said…

“Don’t ever go to your boss and say there is a problem without having a plan on how you’re going to fix it.”

I wasn’t expecting that kind of response. But as I started working as an engineer with project managers I learned more about why he was right.

The people that I was giving status updates to are project managers.

The thing that they care most about is if the project is getting done on time and under budget.

That is how their performance is being evaluated by their bosses.

When I told my professor that the circuit didn’t work that means there is an unforeseen problem that can interfere with the schedule of when the project needs to be done.

When I didn’t provide an answer as to what I am going to do to fix the problem, that means we don’t have a path forward to keep progressing the project.

If the project manager doesn’t know what we are doing to move forward, then it’s chaos. Because if he/she is asked by his/her boss what’s the status of the project…they have nothing they can give them. That makes them look bad.

The project manager needs to be informed about what was done, and what is being done to move forward. Then they can track the progress of the project.

So I learned how to communicate my results from watching how a more senior engineer communicated her results. She’s a really great engineer and I have learned a lot from her.

The easiest and best way to give a status report is…

• Make a bulleted list of statements.
• Say what you did in each statement.
• Show a percentage complete for whatever the goal is.
• Example “This board has completed 54% of its testing”
• Tell them what you plan to do tomorrow to move forward.
• If it’s a problem, tell them what test you are going to try or what person you are going to consult to move the project forward.

I would love to give an example of one of my status updates, but this post is getting long. I will probably go more in depth into this topic in another post where I can give an example.

Mistake #7: Taking Names. Kicking ass

I didn’t know how to do anything and nobody tells you how to do anything. I had to learn how to find out who the right people were and what to ask them.

So this mistake may sound a little misleading. The mistake is not taking names and kicking ass…the mistake is NOT going out there with the intention of taking names and kicking ass.

One big thing that I learned from my first year working as an engineer was that things really don’t get done unless you make them get done.

Back when I was starting I didn’t know how to do anything really. I didn’t know who I should talk to get things done. I kind of figured the senior guys would get things done and set things up.

I was wrong. If you want answers to your questions, no one is going to give them to you. You gotta go out and find those people yourself.

I made the most progress when I started doing this and it looked great to my boss and project managers.

You don’t want to be dependent on people and waiting on other people to contact other people for you.

You still let everyone do their respective roles, but you must go out and track things down yourself.

This means getting the names of potential people who can help you, and then going out and contacting those people right away.

I was a pretty shy person so this was not a normal thing for me to do. Also I was used to school where the only person I needed to communicate with was my professor.

I’m not entirely sure if this point will sink in if you have not worked as an engineer.

But if you have worked as an engineer for a big company you will probably know what I mean when I say you have to shake a lot of trees, knock on a lot of doors, take names and kick ass just to get the information you need to move things forward.

The reason why this is good because you start to present yourself as an engineer who can get things done and set their own direction with little intervention from management.

Mistake #8: Not having a clear path to where I want to get to.

Not knowing what to do to get to the next level.

If you read my last post “I’m 25, I Feel Lost In My Engineering Job. Here’s The 3 Reasons Why” then you will understand this point fully.

The biggest mistake you can make out of all of these is to not set your own destination. You need to know where you want to get to, and what you have to do in order to get there.

If you don’t set your path in life and in your engineering career, the path will be set for you.

Now your path is not set in stone. You can change it. So don’t worry about that.

I won’t spend too much time on this point. But when you start your first engineering job or you already are a working engineer, the very first thing you must do is set the next level that you want to reach. Then create a path to get there.

Otherwise you will just wander the seas.

Mistake #9: Feeling Afraid

When I started my first engineering job I felt a bit overwhelmed. I started to question my worth, my skills, and my ability.

Do I really belong here?

Do I deserve the salary that I am getting?

Much to my surprise, I was not the only one who was experiencing this.

I have the opportunity to speak to new engineers coming into the workplace. Some are brand new to the workplace and some have a few years experience like I do.

I spoke to one engineer in particular. She had a few more months experience than I had. She was switching companies. I sent her an email and welcomed her into the department. I asked her about how she felt when she first started as an engineer.

She told me that she felt unworthy. She saw how great the senior engineers were and compared her skills to theirs.

She eventually realized that she did belong there. She realized that her skills were good enough to hang with the giants.

I felt relief because I had felt the same way.

The mistake is in trying to measure your skill level to a senior engineers skills level.

They are going to have 5, 10, 20, 30 years of experience on you. You really can’t compete with that.

I was afraid to speak out in certain meetings with the fear of asking a stupid question.

I was a professional and people spoke to me like a professional. I felt like I needed to know everything and understand everything people were talking about.

I got in more trouble acting like I knew what was going on then standing up and saying “I don’t know what that is, can you explain it to me?”

There is no shame in doing this.

A majority of engineers (there are undoubtedly some bad apples out there) won’t look down on you for doing this.

If you tell them that you are new to the industry and you are trying to learn, everything will be fine.

If someone is explaining something too quickly, tell them to hold up because you are writing down what they are saying (documentation).

If they say you don’t have to write it down, I always say “If I don’t write it down, by the time I get around to it I’m probably going to forget some of the things that you said. Then I’ll just call you to explain the same thing again.” Most people don’t argue with that.

Don’t be afraid or ashamed of your skill level.

Mistake #10: Resource Cheat Sheet

Here’s the last mistake. In a business sometimes there is a lot of information and knowledge that only a few people have. It’s not written down anywhere and it’s not in any training manual.

Something as simple as how to access a certain tool.

Where certain forms are.

How to do XYZ.

For the first couple of months I would learn how to do certain things. Do them once. Then not have to do that thing for another 6 months. When you haven’t done something in 6 months, there is a good chance that you may have forgotten how to do it.

The mistake here is not creating a word document on how to do things.

There was one engineer that just had all the answers with how to do things and where things were.

I was working with him one day and found out that the reason why he knew how to do everything was because he had written down the process of doing certain one off tasks in a word document.

So as you go through learning different things in the company, you want to create a word document that serves as a resource directory on how to do many different things.

It helps to speed things up so you are not asking people for guidance or searching for answers all the time.

Conclusion

So there it is. These are 10 mistakes that I made in my first year working as an engineer.

Here is a recap of what those 10 mistakes are.

1. Not knowing how to communicate with non-engineers. You should explain things to people who don’t have an engineering background differently than if you were speaking to an engineer.
2. Not having a good understanding of how businesses work and what your role in it is.
3. Not understanding how to manage a project.
4. Not documenting well enough for yourself and others. You must keep all relevant information and keep good records.
5. Trying to learn everything at once. Just learn what you need to get the task done.
6. Not knowing how to give good status reports to project managers. They care about knowing if the project is getting done on time and on budget.
7. Waiting on people to give you answers to get things done. Go out and get your own answers.
8. Not having a clear path of where you want to get to in your career.
9. Measuring my skill set against that of a senior engineer with 20 years of experience.
10. Not making a resource cheat sheet.

I hoped you enjoyed this post! Until next time.

-Tyler

P.S Ready For An Upgrade?

If you are having trouble getting an engineering job then order my ebook “Get The Job First Then Send Your Resume”.

It has helped some new engineering graduates get their first engineering job in as little as 12 days.

Click here to check out the book.