People have those things in spectrums, not all or nothing. You have to have at least some of all of them, but I’d argue that mediocre competency with really good communication and accountability is a better combination that really good competency with one of the others being mediocre.
I still kinda disagree. We’re talking here about engineering role after all. I have a colleague who is a code wizard, but has kinda problem with (under)communicating. He’s still widely respected as a very good engineer, people know his communication style and adapt to it.
But if you’re a mediocre problem solver, you can’t really make up for it with communication skills. That kinda moves you into non-engineering role like PO, SM or perhaps support engineer.
But I would say this - once you reach a certain high level of competence, then the communication skills, leadership, ownership can become the real differentiating factors. But you can’t really get there without the high level of competence first.
We’re talking here about engineering role after all.
where? seemed like general advice.
Even then, thee aren’t mutually exclusive. your competence will affect how people see you on a personal level, at least at work. And your competence affects your ability to be given problems to own. You’re not gonna give the nice but still inexperienced employee to own an important problem domain. they might be able to work under the owner and gain experience, though.
Documentation and presentation are highly undervalued, and your ability to understand and spread that knowledge can overcome that lack of experience to actually handle the task yourself.
I think we might be agreeing, it’s just that “mediocre” means different things to each of us. My team supports human spaceflight, and no one we have is crummy. The “mediocre” people have pretty decent technical skills if you’re looking across all software development domains.
Personally, I’ve found the decent technical skills to be easier to come by than the other ones, and having all of them in one package is a real discriminator.
People have those things in spectrums, not all or nothing. You have to have at least some of all of them, but I’d argue that mediocre competency with really good communication and accountability is a better combination that really good competency with one of the others being mediocre.
I still kinda disagree. We’re talking here about engineering role after all. I have a colleague who is a code wizard, but has kinda problem with (under)communicating. He’s still widely respected as a very good engineer, people know his communication style and adapt to it.
But if you’re a mediocre problem solver, you can’t really make up for it with communication skills. That kinda moves you into non-engineering role like PO, SM or perhaps support engineer.
But I would say this - once you reach a certain high level of competence, then the communication skills, leadership, ownership can become the real differentiating factors. But you can’t really get there without the high level of competence first.
where? seemed like general advice.
Even then, thee aren’t mutually exclusive. your competence will affect how people see you on a personal level, at least at work. And your competence affects your ability to be given problems to own. You’re not gonna give the nice but still inexperienced employee to own an important problem domain. they might be able to work under the owner and gain experience, though.
Documentation and presentation are highly undervalued, and your ability to understand and spread that knowledge can overcome that lack of experience to actually handle the task yourself.
I think we might be agreeing, it’s just that “mediocre” means different things to each of us. My team supports human spaceflight, and no one we have is crummy. The “mediocre” people have pretty decent technical skills if you’re looking across all software development domains.
Personally, I’ve found the decent technical skills to be easier to come by than the other ones, and having all of them in one package is a real discriminator.