Simple advice for engineers

James Williams

Oct 27, 2020·6 min read

The task seems easy enough. Get better at JavaScript or some other programming language, and your career is set. After years of wielding my coding sword, I found this to be false. While this topic is tough to swallow, I assure you that this article is not what you expect. And I hope my lessons help you.

Let me explain.

I spent countless hours honing my craft in the early to late 90s while taking an engineering-centric approach to my career. The truth is I didn’t manage my career. I was fortunate to have lucky coincidences that turned into a career later.

I enjoyed learning the deepest layers of programming languages. I spent a lot of time diving into subject matters that most engineers wouldn’t touch.

And for a while, I made it work. I found joy in understanding esoteric topics and knowing them well. I zoomed to the top of a very short corporate ladder, and then I hit a brick wall.

My goal was to be the best of the best, technically.

But of course, as thousands of engineers know, nothing about how you code advances your career after a certain point. I worked with countless engineers who made more but knew less. And for some strange reason, the business thought highly of these engineers.

Why?

I began to study the behavior of well-regarded engineers. I paid attention to what made these engineers more valuable. I listened, and I learned.

The conversation about me that changed my approach

I recall overhearing a conversation about an engineer “who paid no attention to the business.” The company’s senior leader described me as a “techie” who didn’t understand business value. He went on to say that my impact was limited unless there was a hard technical problem to solve, and no one cared. He expanded his thought by saying, “I am not sure James wants to fix anything that earns us money!”

The impact of the brick wall was apparent and reflected in both my salary and stock compensation. And not surprisingly, I would relearn this lesson many times over.

I have shared the three key things that I learned below.

1. Coding is a low-value activity

“Just code” is nothing more than lines of gibberish to most people. Few people understand what code is, and those that do, don’t value it. Why?

Code without context and business value is genuinely useless.

I learned that I need to connect the dots and understand why. I need to explain the purpose of a body of work to myself and others.

The biggest aha moment for me was sitting in a meeting at Symantec. I remember one of the most famous Symantec fellows saying that a per-line cost analysis on code was silly. After all, “We should be writing the fewest lines of code possible to get a thing done.”

So let me get this straight. If I write more lines of code, each line of code is less valuable. But, if I write fewer lines of code, then the cost of each line is too high.

So why then is software so valuable? Is it the actual code?

No!

Why my boss was better than me

One day, my boss at Symantec eloquently explained a body of code in layperson terms. He told a story about the code. In Mr. Roger’s tone, with a smile on his face, he had people sitting on the edge of their seats. He told a story from a sixth graders perspective resulting in nods of approval.

A few months later, his ability to tell a story in plain English got him an office, more stock, and a seat at the decision-making table. He became a powerful influencer.

The takeaway is that he gave the code life and value by telling a story

2. Engineers devalue other engineers work

It baffles me that engineers are the first to devalue their work.

Here is the irony.

I’ve run many engineering teams, and most hate managing off-shoring. Engineers have a strong urge to choose their own people and are bothered by the headache of managing external resources.

Engineers put a premium on localized product teams. And more importantly, the team they build has an even higher premium.

What do you think happens when those engineers themselves become Vice Presidents and leaders at other organizations?

The first words out of their mouths have the stench of hourly rates. Oddly, they want to cheapen the cost of engineering work. And if you read anything I’ve written, you can probably hear me biting my lip.

All of a sudden, “You get what you pay for,” turns into, “I have crappy work that I want to hand to someone else, while I reserve the engineering goodness for myself.”

Guess what?

Not only has the engineer devalued the team they are working with but also themselves. Both the “lead” and the external firm are working on low-value activities, coding.

Engineers cast value aside, and all conversations converge to hourly rates. Engineering work becomes numbers — sprint points, burn down charts, tasks, deadlines, and junior versus senior engineers.

When was the last time you saw any type of in-progress productivity measurement system for any other department?

Let me help you never because other departments focus on results. Computer Science gets minimized to hourly labor. Think about it.

3. Coding doesn’t teach you business value

As I worked through C, C++, Java, JavaScript, C#, Python, Perl, PHP, Go, Dev. Ops, etc., I never learned how to read a capitalization table until later.

It was magic to me. Like many engineers, I took my 2500 shares and performed fantastic, futuristic calculations. All of them unrealistically made me rich, but of course, that never happened.

The truth is, until you have a financial event, you don’t learn how many people get their money ahead of you. And the real calculation on your 2500 shares amounts to the value of a used car.

After years of less than stellar results, I became obsessed with learning how companies worked. The mechanics of profit and loss statements became my new project. I studied them.

I pondered how sales connected to revenue and how different companies are valued. Back then, the most popular way to understand companies was Yahoo Finance. I studied financial structures and began to categorize the mission statements of each company.

Then, I tried to understand how engineers got paid. And, I mean paid based on the value of the company, not salary.

I found that most engineers spent the most hours working but were at the bottom of the capitalization table.

Why?

Because even in engineering companies, the business values engineers less. And, we do it to ourselves.

I recalled the same storytelling techniques at Symantec, and I began to tell my own stories. I started using the sales techniques of salespeople to sell myself within the organization. I engineered the process.

It was a game-changer, and I launched my real career.

A Few Tips

• Learn how cap. tables work. It’s essential that you understand if an IPO, sell or some other business event is worth it to you.
• Learn how to tell stories. I used to watch Steve Jobs’s speeches to learn how to tell compelling stories.
• Learn your craft deeply and the surrounding business.
• Applied software engineering will make you more money. Learn how to connect what you are doing to why you are doing it.