- They need to collect the needs, challenges and plans of different teams across the company. Based on this, they have to use deep technical knowledge of the stack to distill this into a technical direction for the overall environment to move towards (together with other experts of course). This will usually require implementing some principal cases and some hard edge cases, but then they'll have to document and hand this over to the posse of other development teams to push.
- They must support the trailblazer teams coming after them with hard technical problems. Even if you have a few strong PoCs, if an early adopter of a proposal gets stuck badly and you can't support them, you will lose trust. Call it politics, but losing this trust is very bad in the grander context. The direction they chose with the other principals must be true and trustworthy within a small margin of error.
- They often need to bridge the gap between the business world and the technical world. Technical decisions are technical decisions, but beyond a certain point, they have to be able to translate technical decision into required manpower, required money and tradeoffs to management. Like, we've been asked what the different tradeoffs between manpower investment, money and development velocity a windows-on-prem deployment for a solution would cost us and to compare this to potential revenue from a number of customers.
- They have to be able to say no, and maintain no. As other comments have said: Holding difficult situations. Understand what they need, understand that their need is stupid, and then start guiding them into a discovery process that their idea doesn't fit where we're going.
All of this is skillful communication, understanding and leading. On top of knowing your technical domain very well.