alt Hacker News> Talking to sales to get an idea what the customer wanted from the business side (first B2B at a product company and now consulting) -> talking to the customer and hashing out more detailed requirements -> designing the architecture and a proposed technical plan -> presenting it to the stakeholder (sometime internal sometime external) -> doing the work or delegating and leading the work -> presenting the work to the stakeholder and leading the UAT -> getting it to production.
You are not the first person to say things like this.
Tell me, you ever wondered why a person with a programming background was filling that role?
If not the technical person, then who? It’s a lot easier for a technical person to learn how to talk the language of the business than a business person to have a deep understanding of technology.
On the enterprise dev side of the industry where most developers work, I saw a decade ago that if I were just a ticket taker who turned well defined requirements into for loop and if statements, that was an undifferentiated commodity.
You’re seeing now that even on the BigTech side knowing how to reverse a binary tree on the whiteboard is not enough.
Also if you look at the leveling guidelines of any major tech company, their leveling guidelines above mid level are based on scope, impact and dealing with ambiguity - not “I codez real gud”