I agree on all your points. As devs move up the ladder, the role becomes more about managing people than building code. I've been in the senior role for a few months now and what I can say for my experience is that I'm about 30% code, 30% people, 40% presales work. My role is essentially helping out my devs so they can focus on delivering the features on time and with as least bugs as possible.
I do want to add an 8th item on your list. For my experience, that has been building processes to help the team function more smoothly. From the git pull request process to sending daily updates, to how to handle change requests. Having a process for these kinds of things help the devs function more smoothly because they know what to do.
Do you not find that the daily updates and processes for everything hurt overall adaptability?
I have once worked at a company that, I kid you not, had a "process for creating processes."
Day to day things, like how to use Git, sure. Have a process, have everyone working the same way. But sometimes there's a guy on the team that hasn't had enough coffee that morning and screws up a commit. You need some people on the team (even if it's only 1 person) that can think outside the box while under pressure.
Same argument stands for all business processes... though those times should definitely be the exception, and not the rule.
Kim Arnett [she/her] leads the mobile team at Deque Systems, bringing expertise in iOS development and a strong focus on accessibility, user experience, and team dynamics.
There's a balance right - I've been on both extremes and I appreciate a good flow lol. It helps everyone, but there's certainly a tipping point where the processes are suffocating, and no longer serving the purpose of the process in the first place.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I agree on all your points. As devs move up the ladder, the role becomes more about managing people than building code. I've been in the senior role for a few months now and what I can say for my experience is that I'm about 30% code, 30% people, 40% presales work. My role is essentially helping out my devs so they can focus on delivering the features on time and with as least bugs as possible.
I do want to add an 8th item on your list. For my experience, that has been building processes to help the team function more smoothly. From the git pull request process to sending daily updates, to how to handle change requests. Having a process for these kinds of things help the devs function more smoothly because they know what to do.
Do you not find that the daily updates and processes for everything hurt overall adaptability?
I have once worked at a company that, I kid you not, had a "process for creating processes."
Day to day things, like how to use Git, sure. Have a process, have everyone working the same way. But sometimes there's a guy on the team that hasn't had enough coffee that morning and screws up a commit. You need some people on the team (even if it's only 1 person) that can think outside the box while under pressure.
Same argument stands for all business processes... though those times should definitely be the exception, and not the rule.
There's a balance right - I've been on both extremes and I appreciate a good flow lol. It helps everyone, but there's certainly a tipping point where the processes are suffocating, and no longer serving the purpose of the process in the first place.