Comment by nineteen999
4 days ago
It really only matters on an individual level once you become a manager, and have both juniors and seniors to manage.
4 days ago
It really only matters on an individual level once you become a manager, and have both juniors and seniors to manage.
It matters to me as a senior+.
When I talk to a senior: “hey we got this initiative, I know only little about it. Can you talk to $stake_holder figure out what they need and come back to me and let me know your design ideas, how long you think it will take, etc”.
I can do that with a few seniors and put Epics together and they can take ownership of it.
For a junior I have to do a lot more handholding and make sure the requirements are well spelled out
When I was a junior engineer, I did not need almost any hand-holding, and could take ill-defined initiatives, figure out the desired goals and outcomes, and ship them.
It's just that my code would be shit (hard to understand, hard to test...), but I learned quickly to improve that through code reviews (both getting them, but also doing them) and architecture discussions. I can't thank the team enough that put up with me in my first 6-12 months :)
When I find a junior engineer like that, I give them as little as I can, and remain available to pair, review or discuss when they get stuck. And they... fly... But I also try to develop these qualities in everyone, but it's sometimes really hard to get people to recognize what is really important to get over the finish line.
And I've seen plenty of "senior+" engineers who can't do it and go on to harp about a field in a data model here or a field in a data model there, adding weeks to shipping something. So really, it is only a paygrade.
Any of those "competency matrices" are really just a way to reject anyone from that promotion they are hoping for: it won't be a blocker if that someone has this innate ability to help the team get things done.