Building Things Hurts Your Career

There are many things that can hurt your career in tech, but one particular bad habit can derail it completely. It’s an addiction that many software developers struggle with. One might say it’s like smoking for your career if it didn’t give smoking a bad name. Ironically, smoking with the right people actually helps your standing in the company and chances of promotion.

What is this habit I’m talking about? Well, building things of course. Writing code and shipping it. I imagine you are surprised. Aren’t developers supposed to build stuff? Hear me out.

Bob’s big break

Let’s take a fictional example. A young, talented developer Alice works on a team with a hardened senior engineer Bob. They each receive an important project to complete.

Bob sets up stakeholder alignment meetings and starts an architecture draft. He collects comments from peers and updates the architecture plan. Realizes he needs a security review as well. Another meeting scheduled. Then he goes to the leadership offsite to get buy-in for his project an has dinner with the CTO and other architects.

At the same time Alice comes up with a quick plan and codes a prototype. A few days later she is ready with an MVP and deploys it to dev, then to production. Next week, Alice receives change requests and a few bug reports, and dives head first back into coding.

Come performance review season, Bob gets a promotion and a refresher grant. Alice gets a “meets expectations”.

On the surface you might say Alice was productive, she created value by delivering a feature. Bob spent time in meetings and planning, and hasn’t deployed anything to production. Why was he promoted? Ah, but you must remember a few rules.

Rule 1. Never stop planning.

A project in progress is potential. As long as you keep planning for every possible outcome, aligning with all possible stakeholders, producing architecture diagrams, your project cannot fail. It is forever in this blessed state of uncertainty, but the best part is that it also grows in importance. Think of how many people you meet during those architecture reviews, and how many opportunities you have to show off your design skills.

A problem solved in a week, on the other hand, is wasted potential. A simpleton engineer may receive a ticket on Monday and solve it by Wednesday. Yes, the feature is in production, but is anyone paying attention?

Think of what looks better to a promotion committee: a multi-month, complex project architected and designed (although not delivered yet), or a sequence of one-week features that only your team knows about.

Rule 2. Complexity is your friend.

We’ve all heard about over-engineering or bikeshedding. Rest assured, people who avoid those things never get promoted.

A simple solution is dangerous in two ways.

One, it doesn’t give you a chance to prove your knowledge of latest trends in technology. What do you mean you can just put an app on a single EC2 instance and call it a day? Haven’t you heard of Kubernetes and Istio? Does the word microservices even mean anything to you?

Two, see the previous rule. A simple solution doesn’t allow for a multi-month planning effort, and is therefore useless for you.

Rule 3. Make someone else own the work.

As you grow in your career, you will encounter a chance to upgrade from the Planner role to the Advisor role. Make sure you grasp it.

If there is anything better for your career than planning a project forever, it’s letting someone else implement your plan. In this situation you literally cannot lose. If the implementation goes well - congratulations, your architectural wisdom is proven once again. If the project fails, they simply didn’t follow your plan properly. They should do better next time.

Rule 4. Avoid accountability at all cost.

Have you heard of the RACI model? You must study it if you wish to understand how serious companies do software development. The model defines 4 types of roles for any project:

Informed. The people who receive updates on the project progress. That is your final goal. If you reach the top of this pyramid, you’ve made it in your career.
Consulted. Experts or stakeholders whose opinions are sought before or during the work. Also not a bad position to be in.
Resposible. The grunts who are doing the actual work. I hope after reading the above you already know you should never be in this group.
Accountable. Usually the single person who is ultimately blamed for when the project fails. This is the most dangerous trap. You must understand that almost all software projects fail in some way, and someone must pay for this with their reputation. Make sure you’re not that person.

Now hopefully you understand and can see the mistake Alice made. She has fallen into the builder’s trap. And I get it, building things and helping people feels good. However you must always remember that feeling good is not the goal of your career development, and certainly not the right method for it.

So next time you feel tempted to open your IDE and go into the engine room, remember these rules. Go to Confluence instead and start another planning doc. Open your calendar and set up a few more meetings. It’s nice and warm here in the office. The coffee is good. Nobody’s pager is going off.