Some parts of being a great Engineer

Much ink has been spilled in defining, or refuting, the concept of the 10x engineer.

Some parts of being a great Engineer

Much ink has been spilled in defining, or refuting, the concept of the 10x engineer.

A concept sometimes used in Silicon Valley to describe an engineer that is 10x more productive than an average engineer although the 10x metric is figurative.

10x or not there are definitely patterns in how strong engineers approach their work and career. Generalizing these patterns into lessons illuminates how to be a better engineer, and employee.

This draws from my experience as an programmer, team lead, manager and manager of managers.

Be reliable

This is the bedrock of you as an employee. Be careful when you say yes to something because you must now see it through to completion. You must be trustable.

Results > effort

Broadly companies care about problems solved well, not how. If you built it yourself, used a library or purchased something doesn’t matter. The company also doesn’t care how hard you worked, only what got done. The job doesn’t end at code, you must own the outcome even if means putting on a project manager hat.

Solve problems; look for more.

Your job is not only to solve X, its to be closer to the problem of X than anyone else in existence and surface further work. Over time this leads to a stack of better solutions. Problems are not strictly technical, maybe the new engineer training sucks and you could improve it.

Embrace ambiguity

Taking on increasingly ill-defined problems is something generally entrusted only to the most senior engineers. When your manager says “go figure out X” understand the problem, articulate a solution and get to work on it.

Make others better.

Lead the meeting when no one steps up to. Be the person to collect all opinions on something to inform a group decision. Email some persons manager when they did awesome work. Question why we are doing X if it feels suboptimal. Take on interns. Make your weaker teammates better. This effort betters you, them, and the company.

Do scalable things

Mentoring, documentation, training, libraries, crowdsourcing translation instead of hiring hundreds of translators. All these things make your entire team, company and sometimes world better in an efficient way.

Don’t be silent about your work

I did a lot of cool work for years that I made no effort to tell anyone about. I expected people to organically find and be impressed by it but that rarely happened. Don’t be an obnoxious self-promoter but tell people about your work so they know and may use it. Its unlikely they will seek it out themselves

Impact drives promotions

I define impact as the mark you leave on a problem, area, field, company, world, etc. Work that solves big problems is what you want to optimize for.

Don’t avoid discomfort

Human beings naturally hate conflict. If a timeline will slip or an idea didn’t work the worst thing you can do is hide it from your manager. This applies in many areas: don’t like a teammate? Feel underpaid? Other team blocking you on something? Got the flu? All of these are tractable problems once your manager knows.

Communicate well

Huge topic. Many of us love details which can make succinct writing hard. Know your audience and only include the essentials. The worlds best email gives context and a decision along with a suggestion for that decision. I view communication in 3 vectors/audiences — up (to my boss), across (to my peers), and down (to anyone who reports to me).

Clear and precise language is a critical tool for us. My favorite illustration of this is when a mathematician spends a week defining the word “context” for a room of people who all held different definitions

In the event, I never got beyond the first content slide. But not because I was thrown out. Rather, the rest of the session was spent discussing what appeared on that one slide…[I was told afterwards,] “That one slide justified having you on the project.”
So what had I done? Nothing really — from my perspective. My task was to find a way of analyzing how context influences data analysis and reasoning in highly complex domains involving military, political, and social contexts. I took the oh-so-obvious (to me) first step. I need to write down as precise a mathematical definition as possible of what a context is. It took me a couple of days…I can’t say I was totally satisfied with it…but it was the best I could do, and it did at least give me a firm base on which to start to develop some rudimentary mathematical ideas.
The fairly large group of really smart academics, defense contractors, and senior DoD personnel spent the entire hour of my allotted time discussing that one definition. The discussion brought out that all the different experts had a different conception of what a context is — a recipe for disaster.


These are far from comprehensive but they have helped me in coaching others and becoming a better employee myself.

There is lots of good stuff in this arena, some of my favorites are: The Effective Engineer, The Managers Path especially the part about “how to be managed”. Jackson Gabbard’s interview videos. Anything by rands.