Thanks for the feedback. One reason I love sharing ideas here is that thoughtful conversations like this help me refine these ideas more.
What you are saying about asking "why" makes total sense. There is probably a better way to phrase it.
My issue with "leaders vs. followers" is that it implies a hierarchy where I don't think one exists, though on some teams it can. Lead developers can be craftsmen, and lead the team when it comes to not only code quality, but also internal processes and communication.
The agency example could also be stronger. What I was trying to say is that I know other developers who relish in situations where they prefer to do deep work on code and let others focus on the external details, while for others that same work is frustrating.
I have definitely worked on projects where the people responsible for developing the solution were disconnected from the design and definition of said solution. Whether or not those projects ended well is a matter of perspective. If the developers deliver what the client asked for, and the client pays on time, is that a "good" outcome? Did the feature do what it was supposed to do? Does it matter? Sometimes the only metric of success is client happiness.
My issue with "leaders vs. followers" is that it implies a hierarchy where I don't think one exists, though on some teams it can. Lead developers can be craftsmen, and lead the team when it comes to not only code quality, but also internal processes and communication.
This is a good distinction to make. So, I didn't mean that in terms of corporate hierarchy, but in terms of the concept of servant-leadership. Where the workers lead on their projects and management is there to help with blockers and stewarding the team. This is in contrast to the standard command and control style where workers are employed to bring the vision of the management to fruition.
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.
Thanks for the feedback. One reason I love sharing ideas here is that thoughtful conversations like this help me refine these ideas more.
What you are saying about asking "why" makes total sense. There is probably a better way to phrase it.
My issue with "leaders vs. followers" is that it implies a hierarchy where I don't think one exists, though on some teams it can. Lead developers can be craftsmen, and lead the team when it comes to not only code quality, but also internal processes and communication.
The agency example could also be stronger. What I was trying to say is that I know other developers who relish in situations where they prefer to do deep work on code and let others focus on the external details, while for others that same work is frustrating.
I have definitely worked on projects where the people responsible for developing the solution were disconnected from the design and definition of said solution. Whether or not those projects ended well is a matter of perspective. If the developers deliver what the client asked for, and the client pays on time, is that a "good" outcome? Did the feature do what it was supposed to do? Does it matter? Sometimes the only metric of success is client happiness.
This is a good distinction to make. So, I didn't mean that in terms of corporate hierarchy, but in terms of the concept of servant-leadership. Where the workers lead on their projects and management is there to help with blockers and stewarding the team. This is in contrast to the standard command and control style where workers are employed to bring the vision of the management to fruition.