Sorry, English is not my primary language, so the grammar constructions might get odd from time to time, this might have been the cause.
Point 1. Good engineer should know how to code, and how to cooperate with fellow engineers well. This means healthy balance of "hard" (engineering) and "soft" (communication) skills. When engineer becomes tech lead or engineering manager, being able to communicate, understand other people's behavior, lead them, communicate situation up and down the chain,- soft skills start to matter way more. If there are serious skill gaps in soft skills (and all ex-engineers have ones when they start to grow in this area), addressing them is more important for engineering manager's career than addressing lack of up-to-date-ness in latest technology.
Point 1, Example: when I first got to manage a small team, me not understanding power distribution between younger and more experienced engineers (I came from latter category) led to mass extinction of juniors: the way important decisions were made (with more contribution from senior engineers) was good for the company, but the way it was presented (We The Elders Made Crucial Decision) pissed youngsters off, made them feel incapable of making valuable contributions and they quickly left. After understanding the reason (which took hours of mentoring from CTO, a very experienced manager), I had to really work hard on creating the atmosphere where, even when the decisions were made by seniors, the ownership and responsibility for actual implementation of these decisions was distributed among the teams and everybody could contribute to mutual success.
Point 2, with examples already: It kinda continues point 1, but bridges from personal scale to team scale. Process is as good as it's bottleneck. Team is as fast/writes as quality code, as it's weakest members. If you tolerate them, they constrain the process. Your goal is to spot weaker people / weaker engineering decisions and put reasonable amount of effort to either make them better or make them live. As an engineering manager (e.g. manager that comes from engineering, not from fancy MBA factory), you actually can tell the slacker from person who wasn't properly integrated into the process. As an engineering manager, you can tell that the decision to make blocking tests stop CI on the first failure is a poor decision and having a proper failure log of all tests is crucial for speed of bug fixes, not fixing them faster or with better method. Basically you are responsible for the failure (even if you're formally not), because you're the focal point of knowledge and power that can prevent them, put slower people to speed, put processes to full power.