3 min read

Don't (only) look down.

Don't (only) look down.
Photo by Daniele Colucci / Unsplash

Years ago, the engineering team launched a new API at one of my previous jobs.

Several customers had requested it, and we had worked hard to ensure it was easy to use and understand.

We had various errors we had to account for, and some didn't fit neatly inside the 400 to 404 range. So, we used the error code 420 to represent one of the errors. The engineers all had a good laugh about it.

And then we shipped.

When a customer ran into the error code, they weren't nearly as impressed. And then, they reached out to our executive, sales, and customer success teams to ask what the heck was going on.

The engineering team hadn't communicated what we had shipped.

Imagine the other team's surprise to hear from a customer what the API was doing.

The other teams came over and were very frustrated with us. At the time, I was annoyed. It was just a joke! It's a number, and we didn't really mean anything harmful by it.

But we had made a mistake. And the mistake could have been easily avoided if I hadn't just been looking down.

Tony Fadell in Build writes:

The job of an individual contributor (IC)– a person who doesn't manage others – is usually to craft something that needs to be completed that day or in the next week or two.

...

However, if an IC is constantly looking down, their eyes exclusively on their own tight deadlines and the minutiae of their job, they may walk directly into a brick wall.

That's what I had just done.

If I had looked around more and gotten the other teams' perspectives, I would have known that the engineering team was about to ship something very stupid.

Our customers were no longer cute startups but larger companies. We needed them to trust us, and we jeopardized that trust by shipping jokes. Our sales and customer support team – people who deal with customers daily — would have given me that perspective.

But I had my head down and didn't look up.

To make the most impact as a software engineer, you need to care about what happens beyond your contributions.

This isn't the most comfortable thing. It's very easy to get assigned work, crank it out, and spend the rest of your day on Reddit.

It's harder to care. It's harder to look beyond the work you are immediately doing.

But if you want to make an impact, it's critically important.

Tony suggests two ways of looking:

Look Up

Look beyond the work you are doing today and see the future milestones for the next few months. Make sure the milestones and the project still align with the mission.

The mission is the reason you're working on the project in the first place.

Critically, there should be a mission—the reason you are building the thing.

If you don't have one or can't think of why you are coding, you should stop everything and talk to your lead.

Everyone on the team must clearly know what is being built and why.

Only in this way can each contributor help to keep the project aligned with the mission and help guide it. Without a mission in place, you're simply building in no direction.

Look Around

Looking around is about getting out of your comfort zone and talking to people and teams who are not engineering.

Talk to your support teams and sales teams. Get their perspectives on the features that are being shipped. Ask what sort of problems they are facing or questions they have.

Their jobs have them caring about vastly different priorities than the widget you're working on and think is cool.

In fact, you might learn that they really don't need what you're building. Priorities like stability, bug fixes, or fixing the UX might be much more important than a new widget.

And when this is the case, you'll need to speak up and help ensure those needs are met. It's your responsibility to ensure the teams are working on important things.

By looking around and up, you can understand the context of what you are doing. In addition, it will help guide your project and give feedback to management to ensure they also see signs of trouble before they become an issue.

This is important because you must engineer your career. To continue to execute and be a great engineer, you need to understand how to guide a project or when it's time to move on.

Your time is precious. A job where the teams are misaligned will spell disaster, and you don't ship catastrophes. If things aren't working out, you need to do what's best for your career and move to a new job where you can ship and show off what you've built.

So stop looking down.