> Lots of fresh grads and junior staff focus 99% on being useful, but career advancement beyond the first one or two promotions depends MUCH more on being valued.
Yeah. I've seen a lot of ICs get stuck at the "senior developer" level rather than progressing to team lead, staff/principal eng, etc because they were too focused on being useful, by cranking through Jira tickets and features, rather than thinking strategic and higher level. This is a totally fine career choice, but there's only so far that "coding better and faster" can take you.
The counterintuitive part is increasing your valuableness often reduces your usefulness. As a mundane example, in early stage startups there may be one engineer who handles production deployments, schema migrations, and on-call duties. This is extremely useful! For this engineer to increase their value, however, they'll want to automate production deployments, teach others how to run schema migrations, and set up on-call alerting and schedules. By doing this, they become less useful, since others can now do their work, but more valuable, since they've been able to delegate responsibilities.
As another commenter mentioned, what you are describing is simply strategic vs tactical thinking, and IMO those are much more accurate, standardized, and less judgmental terms for the situation than "useful" vs "valued".
Perception is reality. In my experience, if you're a "useful" employee to your management you are boxed into tactical. If you're "valued" then you are invited into strategic decision making.
It really doesn't matter how much strategic thinking you do if nobody cares.
Yeah the article using "useful" and "valuable" isn't ideal, but I was sticking with those terms for discussion. I agree it's largely about strategic vs tactical thinking.
I think you're twisting the original article's meaning of "useful" and "valuable." Useful means you are able to contribute meaningfully. Valuable means you are perceived as being able to provide value to the company (in this case by being useful), and are treated accordingly.
An engineer who does their job so well that they reduce everyone's workload by automating things and showing others how to do some of their tasks doesn't become less useful; in fact just the opposite, since presumably they will continue to need to do this as the landscape changes and not everybody will have their advanced knowledge of how to efficiently organize things at a high level.
> Being useful means that you are good at getting things done in a specific area, so that people above you can delegate that completely. You are reliable, efficient, maybe even indispensable in the short term. But you are seen primarily as a gap-filler, someone who delivers on tasks that have to be done but are not necessarily a core component of the company strategy.
I take this to mean "usefulness" is: you have a tactical role in the company, where you are able to perform necessary tasks. If you can perform them with little supervision, you are very useful.
However, "value" is eliminating those gaps entirely. Instead of being the on-call person who fixes every issue, which is undeniably useful, you fix the root causes so those issues don't happen. This does make you less useful, by definition, because fewer on-call issues means there's fewer reasons to keep you around. But assuming you also do an ok job of communicating what you've done, and your bosses aren't totally clueless, people will recognize this as valuable. The fact that you were able to identify a systemic issue and address it is what makes you valuable, and it will get you invited into broader technically strategic discussions. In theory, at least.
Again these are just my interpretation of useful vs valuable as far as the article's definition. I don't agree with the terms in a broader sense.
I feel stuck because my industry keeps laying me off. I feel useful, but it's clear that the powers that be don't value any of the studio, let alone a mere 5-10 year nameless fledgling.
Yeah. I've seen a lot of ICs get stuck at the "senior developer" level rather than progressing to team lead, staff/principal eng, etc because they were too focused on being useful, by cranking through Jira tickets and features, rather than thinking strategic and higher level. This is a totally fine career choice, but there's only so far that "coding better and faster" can take you.
The counterintuitive part is increasing your valuableness often reduces your usefulness. As a mundane example, in early stage startups there may be one engineer who handles production deployments, schema migrations, and on-call duties. This is extremely useful! For this engineer to increase their value, however, they'll want to automate production deployments, teach others how to run schema migrations, and set up on-call alerting and schedules. By doing this, they become less useful, since others can now do their work, but more valuable, since they've been able to delegate responsibilities.