I think you’re right. I’ve been a lead dev/architect for a while. I am not better at coding than my co-workers who are junior to me. In many ways they are better than me in that they come in with a fresh perspective, new ideas, and lots of enthusiasm.
In my mind, the main differences between the roles come down to soft skills, getting comfortable with and staying calm with uncertainty/gray areas, and being good at asking for feedback and listening. These are all things you just end up learning.
Here are some of the things I’ve had to do a lot more of as I got into a more senior position:
Getting a “feeling” for how technical decisions will weather over time given past experience.
Being able to effectively listen to stakeholders and really understand their needs. Asking good follow-up questions and communicating my understanding in non-technical terms they can identify with. This often involves coming up with differing scenarios and seeing if the behavior the system would have is what they really want.
Getting comfortable working in grey areas.
Seeking feedback and ideas from the engineering team and stakeholders. Iterating on a design and incorporating the feedback.
Trying to tease out the best direction for the architecture that will be most likely to meet current and future needs, stand the test of time, and be less likely to accrue too much technical debt.
Staying calm when external circumstances change in unpredictable ways. Planning how to adapt to the changes in the most effective way. Determining whether future changes in a certain area are likely to occur given company direction. Guiding the architecture to more easily be able to accommodate those kind of changes in the future, if they seem likely.
Being a mentor for the engineers. Trying to always make myself available to help. Being willing to dig into the weeds to figure things out. Feeling invested in their success.
Coding. I still code a lot as well. I think this is important. First off, I like coding and making things. Architecture designs are great, but they’re just an idea, not something that can readily be used. Additionally, architectural decisions that don’t take into account the actual experience of coding them are not likely to lead to good outcomes. Sometimes, I can come up with something that sounds great. Then, when I try to scaffold it, it turns out there is a better way that will be much more pleasant for all involved.
Being humble. I don’t know everything. I’m not always right. We are successful as a team when everyone is involved and listened to.
I hope this helps. My career path kind of just happened and I learned along the way.
I think you’re right. I’ve been a lead dev/architect for a while. I am not better at coding than my co-workers who are junior to me. In many ways they are better than me in that they come in with a fresh perspective, new ideas, and lots of enthusiasm.
In my mind, the main differences between the roles come down to soft skills, getting comfortable with and staying calm with uncertainty/gray areas, and being good at asking for feedback and listening. These are all things you just end up learning.
Here are some of the things I’ve had to do a lot more of as I got into a more senior position:
Getting a “feeling” for how technical decisions will weather over time given past experience.
Being able to effectively listen to stakeholders and really understand their needs. Asking good follow-up questions and communicating my understanding in non-technical terms they can identify with. This often involves coming up with differing scenarios and seeing if the behavior the system would have is what they really want.
Getting comfortable working in grey areas.
Seeking feedback and ideas from the engineering team and stakeholders. Iterating on a design and incorporating the feedback.
Trying to tease out the best direction for the architecture that will be most likely to meet current and future needs, stand the test of time, and be less likely to accrue too much technical debt.
Staying calm when external circumstances change in unpredictable ways. Planning how to adapt to the changes in the most effective way. Determining whether future changes in a certain area are likely to occur given company direction. Guiding the architecture to more easily be able to accommodate those kind of changes in the future, if they seem likely.
Being a mentor for the engineers. Trying to always make myself available to help. Being willing to dig into the weeds to figure things out. Feeling invested in their success.
Coding. I still code a lot as well. I think this is important. First off, I like coding and making things. Architecture designs are great, but they’re just an idea, not something that can readily be used. Additionally, architectural decisions that don’t take into account the actual experience of coding them are not likely to lead to good outcomes. Sometimes, I can come up with something that sounds great. Then, when I try to scaffold it, it turns out there is a better way that will be much more pleasant for all involved.
Being humble. I don’t know everything. I’m not always right. We are successful as a team when everyone is involved and listened to.
I hope this helps. My career path kind of just happened and I learned along the way.
Great perspective and approach. If someone like you even has a modicum of emotional intelligence, they’d be one of the best leads I’ve ever seen.