4 ms·
When I went from freelance developer to managing a team of 20, I went through many of these challenges, especially of feeling like you're handing off a project
by everdev 9y ago
When I went from freelance developer to managing a team of 20, I went through many of these challenges, especially of feeling like you're handing off a project that won't be done as well as if you did it yourself.
But when you find great people and the project is done as good or better than you could have done it it feels amazing as you're accomplishing more than you ever could have by yourself.
- jdoss 9y agoI too have had that uneasy feeling you are talking about. Letting go of total control over how things are being done as I went from just me hacking away, to leading a small team has been interesting. I tell myself (sometimes to my team directly) that we can just redo any choice that we make if it doesn't work out or we will work together to make the choice work. I want them to own problems and decisions. I want to empower them to as best I can. As a result, I have never had to totally redo any technical choice that my team has made. We have had to fix a few things together, and that has only brought us closer.
- drakonka 9y agoI am in the same boat; I'm good at taking responsibility and doing "The Right Thing"(TM) when it comes to my own work. Having to be more directly invested in what other people are or are not doing makes me feel uneasy. I think it's going fine and I don't hate it or anything, it's just that worrying about other people's work isn't really my idea of a dream role.
- Joeri 9y agoI took that approach for a while, but it ended up blowing up in my face one time too many. Now I try to block bad code from landing in the first place by requiring code reviews prior to merging into master. Sometimes a patch is thrown away entirely and usually it takes two or three tries before a patch is ready for merging, but the overall code base quality is higher.
- afarrell 9y agoI think there is a fine but meaninful distinction to be made here: One can (and IMHO should) require code reviews for each change, but not be the person to actually do the code review. If every code review needs to go through you, then you become a bottleneck. This means that you need to trust members of the team to do solid reviews, and you focus on observing the team's processes and debugging problems like: - We don't have clarity on what our conventions look like. - People take too long to review others' code and it blocks the team. - People get interrupted by code reviews too frequently and it keeps them from focusing deeply. - We are missing some piece of build/test infrastructure and it isn't clear to any one person that she should take 3 days to do that longer-term investment work. - We don't have a clear way to onboard newer team members into our frontend toolchain and so it takes them a long time to get productive. - There is a process people are following which is just getting in the way and can be slimmed down or eliminated.
- Joeri 9y agoI agree. I didn’t mean to indicate all code reviews should go through the tech lead. But the tech lead should have a circle of trusted lieutenants who act as gatekeepers. That’s how linus runs the kernel and it seems to work well.
- neltnerb 9y agoAfter practicing a lot, I find one of the greatest satisfactions in life to be the ability to let a project go and know it is good hands.