The majority of my time at Director/VP level is already accurately summarised by looking at all the material that's online from a technical aspect.
However, the non-technical aspects that (I believe) some people tend to ignore are:
- When you lead a team, you try to get out of their way and direct them in such a way to extract maximum impact that's sustainable (no burning out).
- When you're Director and above, you're tending to lead teams of teams, so a different skillset applies, you're also coaching your direct reports on point 1 above.
- When you're a Senior/Staff/Lead/Whatever (these titles are somewhat fluid across the industry), you tend to communicate up to your manager who also shares technical attributes, so you can discuss progress with certain details.
At Director or above, there's a greater chance that more of the people you communicate up higher up the chain of command have a different skillset than tech, so you have to talk a different level of abstraction.
As an example, your direct report might tell you that a project is X points, which is meaningful to you, but you gotta translate that when you're communicating upwards to a different abstraction, time. While you also want to make sure your organisation is empowered with good practices, risk management, disaster recovery and taking care of tech debt, those are part of the internal engineering concerns, and all of them don't necessarily need to be discussed in detail with your boss as long as you're not screwing things up.
In another sense, if you're working in a startup, then money as a resource is something that's important to think about, an engineering effort can often be communicated upwards in an approximate dollar sense, both in terms of cost and potential payback if successful.
Lastly, if the organisation is small enough, you might have to concern yourself with working with accountants or CFOs to document your R+D efforts for tax benefits depending on your jurisdiction.