Mastering ambiguity and comm skills. As you move up job levels your role changes from problem solving to problem formulation. You need to be able to tell other engineers what problems need to be solved.
Not valuing technical contributions seems odd. There should always be a base level of strong technical competence that you build atop.
But technical chops alone won’t get you promoted. Also producing a large volume of work won’t get you promoted; that will get you a reputation as a code monkey.
Being irreplaceable. I worked on a team where our full-stack engineer put in nights and weekends consistently and received a $100 gift card for Christmas. Our data architect worked reasonable hours and received a 5 figure Christmas bonus because he was the only person in the company that truly understood how our vital algorithms worked (he wrote them). Our full-stack engineer left soon after that.
We had a guy who knew everything, and was a gate keeper to that knowledge. New VP came in, and said he had to no longer be a silo of knowledge. He kept being a silo. VP fired him and expected the team to play catch up, knowing the company would take a hit short term but be better long term. Buyer beware.
How did that work out in the short term and then in the long run?
We had a guy who knew everything, and was a gate keeper to that knowledge. New VP came in, and said he had to no longer be a silo of knowledge. He kept being a silo. VP fired him and expected the team to play catch up, knowing the company would take a hit short term but be better long term. Buyer beware.
How did that work out in the short term and then in the long run?
Short term was scary, some folks put in more hours, systems too longer to recover if something went sideways (which they did, a lot). Long term, it was great. A whole team of people who were able to keep systems green and diversity of opinions on how to improve systems. It worked out better than I could have expected.