I don't think that's the best advice. There is no hard line between business, product, and technical concerns. There's a lot of gray area.
If you want to be great at your job, then understanding the context of business and product decisions will let you make more nuanced technical decisions that support where the business is heading, not just where it's at today. If your manager, and PM, and business POCs that you work with are all excellent, then maybe you can get this context from them. But chances are that at least some of the people around you are fairly mediocre, and part of being great at your job is making things happen in spite less than ideal circumstances.
Maybe what I would consider being great at the job is what you would consider unhealthy hustle culture, and that's fine. If you want to just get by and not be exceptional in the role, that's much easier. But in that case, why even focus on technical excellence? You can get by with less.
Basically, if you're gonna slack off, then you might as well slack off across the board. If you want to be excellent, then be excellent across the board.
Frankly I have little interest in being great at my job. It's a job. At the end of the day, I have exactly as much loyalty for the company as they do for me. None. [1] Furthermore, the "rewards" for being great at your job kind of suck, which at most companies is just slowly accruing experience until you get noticed and someone has the bright idea to make you a manager. [2]
I want to be great at software engineering. I want to use tech to build things. I see it as coincidence that there's enough overlap between that goal and the company's goal to at least make me good at my job.
[1] That's a lie. I wish I had no loyalty to the company, but my personal pride in a job well done unfortunately means I have a non-zero amount of company loyalty.
[2] Just happened to me, actually. My stress levels are through the roof, and I didn't even get a raise. Clearly I miscalibrated my job performance.
>someone has the bright idea to make you a manager.
maybe present your own manager with a copy of "The Peter Principle" book? This seems like a literal example of it.
The Peter principle is a concept in management developed by Laurence J. Peter, which observes that people in a hierarchy tend to rise to "a level of respective incompetence":
employees are promoted based on their success in previous jobs until they reach a level at which they are no longer competent, as skills in one job do not necessarily translate to another.
A few things. Pride, hubris, challenge-seeking, unwillingness to turn down an "opportunity", and, maybe more than anything else, I thought I'd do a better job than any of the other potential candidates (see: pride).
In life in general I seldom back down from a challenge. I even play video games on the hardest difficulty. [1] It's bitten me more than once, but I still seem to have this almost pathological desire to really go for it rather than leave well enough alone.
It was also an opportunity to see behind the curtain. In my time I've had to deal with a lot of boneheaded decisions handed down from on high, and I wanted to see if I could get a glimpse of where they came from.
My job now consists almost exclusively of being handed boneheaded decisions from higher up the chain, fighting tooth and nail for something realistic, and coming to an unsatisfying compromise only to have upper management go around me and communicate their boneheaded decisions to the team directly.
[1] And yet I don't much care for Souls-likes. I just don't enjoy the core gameplay enough to want to climb the mountain.
For most people this would probably lead to exhaustion.
It is doing 2 full time jobs basically. Because you don’t trust your team.
Lets say 80h weeks are OK there is still the hurdle that most corporate structures will actively fight against this level of JD-breaking initiative!
If the product is Dropbox you can talk to mates to do your primary customer research. But what if it is say defence contracts? Gonna be stepping on toes talking direct to customers.
If you are not doing primary research you are relying on those lackluster colleagues.
If you are doing this kind of stuff the job is just in the way, start a business.
For startupish roles where your job might be half coding half VP growth it might work.
I think Engineers should know something the product is used and why etc. But this can only go so far. Otherwise why have other roles at all?
Fundamentally, I agree. Though you need to draw some boundaries between being aware of customer needs and advocating for them during development (and alloying them with realities in your development environment) and being responsible for all customer satisfaction.
If you want to be great at your job, then understanding the context of business and product decisions will let you make more nuanced technical decisions that support where the business is heading, not just where it's at today. If your manager, and PM, and business POCs that you work with are all excellent, then maybe you can get this context from them. But chances are that at least some of the people around you are fairly mediocre, and part of being great at your job is making things happen in spite less than ideal circumstances.
Maybe what I would consider being great at the job is what you would consider unhealthy hustle culture, and that's fine. If you want to just get by and not be exceptional in the role, that's much easier. But in that case, why even focus on technical excellence? You can get by with less.
Basically, if you're gonna slack off, then you might as well slack off across the board. If you want to be excellent, then be excellent across the board.