What is the best resource for learning to lead a software team?
I work for a 4 person team within a small company of 60 poeple. Recently my team lead has left the company which left me taking the lead of the group. I'd like to modernize the way we work and develop software. What are the best resources for learning good management practises? From leading a group to implementing good coding practises. Relevant books: - Shipping Greatness - Managing Humans - Team Genius Coding practices are hard and team specific. 60 people company is small enough where things change fast so if you make "coding practices" too tight and restrictive then some people will be unhappy and unproductive. Good start: - have linter to check for basic mistakes and perform code formatting - do some testing (integration tests are good because most problems happen between modules and not within modules). Code coverage is a divisive topic but I personally find it useful to understand what parts of software are not well tested. - Build/deployment dashboards for everyone to see. If you break the build your name is shown as a shame factor etc. Many years ago when I was young and dumb and at a startup, you had to take a shot and run a mile if you break the build. Worked wonders to keep things stable. - establish some code review culture. As company grows you'll probably eventually need to pass some compliance requirements. Those usually require you to code review anything that goes to production. So you can't go wrong with: each merge to master needs to be reviewed by someone. It's a bit annoying for a small company but will pay off in the future. If you don't want to go that far then at least identify critical files in the code and require any changes to them to be reviewed. What separates good lead/manager from bad one is caring. By posting this question you already show that you care, which means you are on the path to becoming good lead/manager :) Plus one for Managing Humans. All of the randsinrepose.com posts are worth reading, but here are my favs. https://randsinrepose.com/archives/shields-down/ https://randsinrepose.com/archives/bored-people-quit/ https://randsinrepose.com/links/2015/01/14/ask-them-how-they... >>>Build/deployment dashboards for everyone to see. If you break the build your name is shown as a shame factor etc. Many years ago when I was young and dumb and at a startup, you had to take a shot and run a mile if you break the build. Worked wonders to keep things stable. What? Sorry I am so taken aback with your comment, shaming your team members for breaking build is a big no no in my opinion. Code is meant to be broken because that's when the maximum learnings and opportunities for improvement happen. I don't want "stable" build and "broken" team. I heard numerous stories of sr. software engg breakings stuff and have interesting insights to share afterwards. In fact I'd encourage to experiment more with the code base, go where they feel uncomfortable. If something goes wrong I am behind them. If a build is broken it's on me not the team member I am supporting. PS: In similar situation as OP, leading team of 4 jr software engg. Don't put yourself on the critical path if you can help it. You will be interrupted lots and slow down the rest of the team. A wrote up a few links to resource I found useful at the start of the year
http://zoenolan.org/blog/2021/02/resources-for-new-managers/ * Experience parenting. This teaches you to call bullshit on defiant or obstructive team members with confidence and directness. * Writing. I have worked with many developers that have a phobia of writing anything down. The ability to write down precise guidance in finite simplified ordered steps separates the adults from the children in the room unlike any of factor. I found “The Manager's Path: A Guide for Tech Leaders Navigating Growth and Change” by Camille Fournier to be very useful. 4 Stages of Psychological Safety - when they feel it's safe to communicate, the team trusts each other more and makes unblocking easy. The First 90 Days - good book for planning out any transition to a new role. The Manager's Path - basic primer for leading in tech Accelerate - If you're inclined to measure how well your team does. Gergely Orosz has been writing some great stuff - https://newsletter.pragmaticengineer.com/