Advice for a young engineer

Last month, a young engineer left my team to join Facebook in Seattle. It was a fantastic move for her career and I wish her all the very best. When she left, I thought I'd give her some advice based on my own experience as an engineer, then management consultant, middle management in large corporation, back to being a manager of engineers. I thought these might be applicable to other young engineers as well, so I'm sharing them here. Here they are:

1. Sometimes the quickest path is not the shortest path

You understand the problem. You can see the solution right in front of you. You can lay out the steps it will take to get there. So let's do it! Except why are we taking the extra steps or even detour for the solution?

It turns out, often in business there are competing priorities. Some of them have deadlines that cannot be moved (e.g. competitor just launched a killer product, we have to come up with an equivalent in two weeks). In order to accomplish all of these objectives, you have to forgo the obvious straight path to the solution and accomplish the other tasks first, even if it means delaying known priorities or even repeating certain tasks.

2. In order to gain time, you have to lose time first

This is most applicable to recurring meetings with a group of executives who are not in your department. At the beginning of each meeting, before diving into the details of each agenda item, it pays to spend a minute or two setting the scene and remind everyone the context of the item.

Remember, while you've been working on the same task for the whole week, the other participants in the meeting have spent very little time on this topic. They are not aware of all the developments that have taken place since the last meeting. It's best to spend just a little time on context, get everyone up to date, before diving into the details.

This rule is also applicable for other tasks. Before jumping into a project or task, often it pays to spend a little bit of time just to understand the problem a bit better. Is the proposed solution feasible? Would it achieve the object? Does the model fit the data (at least visually)? Could it be delivered within the allocated time and budget? Doing a quick, back-of-the-envelope calculation can often save a lot of headache down the road.

3. Visualisation is an important tool for communications - less is more

This may be a surprise to you, but most non-engineers (or people who are not professionals in STEM fields) do not like looking at mathematical formulae. They don't even like looking at data. Visualisation - turning data into meaningful charts - is a much more powerful way to convey the ideas for most audiences. I learned this the hard way during my first management consulting case. The project leader almost had a heart attack when he saw my linear regression formula on a slide.

A very important aspect of communication is "less is more". Clear and concise communication means leaving out everything that is not absolutely necessary, and retaining only the most important idea. For example, if 2 decimal place precision is not needed, then round everything to nearest dollar. If the analysis on two year's worth of data doesn't show anything meaningful, then don't show it (even though it took you several weeks to analyse the data). It's all about the audience - if they don't need to see it, then don't show it.

4. Use more analogies, less jargons

When communicating with other engineers, jargons are a precise way to convey ideas. However, when talking to people in other professions, jargons can be difficult or daunting to understand. They might even make you sound distant or arrogant.

I am a big fan of using analogies to convey difficult concepts. I learned this from a mentor during my management consulting days. It makes the most challenging concepts more approachable to everyone. This technique is particularly useful when explaining mathematical concepts.

5. When hiring, don't look for exact copies of yourself. Instead, try to balance the team in terms of skills

We all do this - look for versions of ourselves when hiring. People with similar degree, similar school, from the same city or state, or even worked at the same company before. There is a level of familiarity and mutual understanding of how things work that is not shared with anyone else.

These biases can be dangerous when making hiring decisions. You end up reinforcing the same biases as before, and miss an opportunity to address a gap in the team (in terms of skills or background).

Be aware of your own hiring biases and make sure other team members are part of the hiring decision.

6. Be open minded - Not all solutions need to be engineering or machine learning solutions

Engineers have a bias towards [over] engineering solutions to every problem. I am guilty of this sometimes, especially earlier in my career. Now I have learned that not every problem can or should be addressed with an engineering solution. Often, an operational or commercial approach can be just as effective.

It also pays to trial the solution before implementing it in a software system. The "MVP" can tell you if the solution works, before you invest the time or cost. It can also tell you what you need to watch out for if / when you build the software solution and thus improve the chance of success.

7 . You can learn a great deal from non-engineers, if you are willing

I admire people with a desire to learn. We live in a world that the ability to learn is the most crucial skill - the world is changing too fast. In addition to technical skills, it's also important to learn other skills from non-engineers. For example, negotiation, project management, prioritisation, communication, stakeholder management - these are all skills critical for any profession. Do not lose the opportunity to learn from someone simply because he / she is not from your own profession. That would be a real shame.

8. Before you build any models, just plot it first to see what it looks like

[I mentioned this in my previous blog 7 Deadly Sins of Data Analysis (and how to redeem yourself)]

In the world of machine learning, there is an itch to build the model as quickly as you can and let the algorithm start optimisng. Before you do this, why not spend a little bit of time and plot the data in a simple histogram (or whatever chart that is most relevant). If the graph has a very long tail, then normal distribution will not be suitable. If the graph has two peaks (i.e. bi-modal), then the data need to be separate into different models. If the data has cycles, then seasonality must be taken into account. These properties are very easy to spot with a graph. It's easy to let the algorithm work on the problem straight away and start improving the outcome. However, if you start climbing the wrong hill you'll never get to the top of where you want to go.

9. Learn to make decisions with incomplete info

Engineers have a tendency of wanting or even needing every piece of data before a decision can be made. Unfortunately you don't always have the luxury of time or information before every decision. You have to learn how to make a decision with incomplete info. Start by asking - what are the most important factors? Do I have enough to make a call? If not, what is the most crucial piece of information I need and how can I get it in time? Can I get the information via a proxy or in a different way? These questions will help you assess the risks associated with the decision and the time / money you can afford to spend in order to make this decision.

10. Learn to solve open ended questions by clarifying and breaking down the problem

Engineers love working on problems with clearly defined scope. Better still, the requirements should be clearly defined.

In the real world, you have to work with people from all walks of life. Not everyone has the skill or experience articulating requirements like engineers. Often they only have a vague idea of what they want. It's your job to figure out an end solution.

First step is to decompose the problem into smaller, defined steps. By asking questions you can quickly refine scope by ruling specific items in or out. You can also understand the needs better. If the problem is too large, start by dividing into smaller chunks. This will help make the impossible seem not so daunting.

The most important thing is to be yourself. You will get a chance to work with many engineers, managers, and stakeholders from all walks of life. Some of them you will get along famously. Some of them you can barely stand in the same room with. No matter what happens or who you work with, always remember what you love and why you do the things you do. Because if you love what you do, then nothing is too difficult.

Originally published on my website, pricingen.com