In my book, if you want to go for architect/principal/staff, you will have to work on communication, documentation and leadership skills. At work, the group of most senior engineers has a couple of roles:
- 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.
Documentation is a necessary skill at senior levels in large orgs. There will never be a shortage of interested parties eager to vampire away your cycles. Being able to send them docs, diagrams, etc. will save you so much oxygen.
Very much so. We're kind of arriving at a workflow which dictates: If one of the experts or architects has to be asked about some topic, the documentation in that area has to be improved, ideally together with that expert and based on their answer. Similar to how an SLA relevant outage requires a post mortem to fix or mitigate root causes.
Not gonna lie, initially this was somewhat annoying. You had to type up long aeswers, or talk about a topic a lot, and then you had to write the same thing down again. So much repetition and so much markdown! So much time not doing tech stuff.
But doing this for a while.. well initially we ran into the problem of having too much documentation and needing to organize it. We enlisted help from technical writers in the company there a bit. But doing this for a while has resulted in very effective documentation for the teams. Not just architectural decisions written from an ivory tower. Very hands-on design guidelines, explanations and how-tos from practical projects in the company. If the ivory-tower-architect yells at you with a direction, those tell you how to get there.
And this generates a lot of velocity and trust in the teams. You have a problem, you pick up the guide, and for seasoned topics, your problem disappears within that sprint with that guide.
imho, more senior engineers ought to be the trailblazers and support the teams that are building the products.
Yesterday I experienced getting chewed by very senior engineers who instead of trailblazing, seem to just sit and complain, and the actual trailblazing comes from the bottom up.
It was very disappointing and a large degree of trust was lost.
- 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.