I agree. The most important question for me when looking at a position is whether the team has a lead or manager, if they have a lead it is a bad sign. They are too busy coding to manage, they are territorial and are responsible for the all the important, business critical, high profile pieces.
I wish leads did veto more - often I am "delegated" a task, spend a week on it, then they look at it and tell me to it a different way - a way they could have told me to do at the beginning of the week and not have wasted my time. So then I spend another week re-doing it to the way they want.
I should note this dynamic is at play not just for programmers, but for devops and other groups as well.
If you have a task that will take 5 days and someone has the ability to veto the design of the deliverable at the end, you need to talk through the design before you commit to it. Spend a few hours working out what you'd do, then whiteboard it or even verbally run through it.
It's worthwhile doing even if you wouldn't have ended up with wasted effort - other people can have helpful suggestions of things to look out for, or minor refactorings you might do along the way.
I want to add that the title "Tech Lead" doesn't always mean the person is a half-dev/half-manager, nor does the title "Manager" indicate the person has totally stopped coding. Often times, the "Manager" or even "CTO" title will be held by the principal developer. It's also possible to find "Tech Leads" whose duties are 100% management, but they cannot bear the title for reasons dictated by HR.
Comments
I agree. The most important question for me when looking at a position is whether the team has a lead or manager, if they have a lead it is a bad sign. They are too busy coding to manage, they are territorial and are responsible for the all the important, business critical, high profile pieces.
I wish leads did veto more - often I am "delegated" a task, spend a week on it, then they look at it and tell me to it a different way - a way they could have told me to do at the beginning of the week and not have wasted my time. So then I spend another week re-doing it to the way they want.
I should note this dynamic is at play not just for programmers, but for devops and other groups as well.
If you have a task that will take 5 days and someone has the ability to veto the design of the deliverable at the end, you need to talk through the design before you commit to it. Spend a few hours working out what you'd do, then whiteboard it or even verbally run through it.
It's worthwhile doing even if you wouldn't have ended up with wasted effort - other people can have helpful suggestions of things to look out for, or minor refactorings you might do along the way.
I want to add that the title "Tech Lead" doesn't always mean the person is a half-dev/half-manager, nor does the title "Manager" indicate the person has totally stopped coding. Often times, the "Manager" or even "CTO" title will be held by the principal developer. It's also possible to find "Tech Leads" whose duties are 100% management, but they cannot bear the title for reasons dictated by HR.