31–40 of 186 posts
As a developer, I'd love to see more managers read and try to follow the advice that makes sense for their company/position from Michael Lopp, aka Rands: http://randsinrepose.com From my perspective, it's a how-to guide for managing information workers, keeping them happy, and keeping yourself sane.
[0] https://www.amazon.com/Managing-Humans-Humorous-Software-Eng...
This is not to say you should down tools and never touch code again, far from it, but you should strictly cap the time you spend coding for at least 12months as it's too easy to fall back into the habit of feeling productive becase you have your IDE open. If you spend too much time coding, you are avoiding your real job. I generally pick up bugs, scut work or the occasional prototype. I also enjoy clearing up some technical debt from time to time. Either choose quick tasks that no one is relying on, or longer term items that wont cause any blocks if you are delayed.
Related to the above - as manager, you are no longer in the best place to decide on a technical solution. It is your job to make sure that the best technical approach is decided on. In fact you can generalise this to management as a whole - its not your job to make decisions, its your job to make sure decisions get made.
You fail if your team fails, you succeed if your team succeeds. Therefore do everything you can to remove impediments, and shield your team from shit that distracts them wherever it comes from. Encourage them to speak out when they think something is wrong. Play the role of facilitator in meetings to make sure every option is heard and discussed. Have regular informal one to ones with your staff with no fixed agenda - just ask them how they are getting on and how they think things are going. If you have a good connection with them, then you can ask them what you personally should be doing better to help them. If there is little to no trust, then expect them to clam up and say all is great and you are awesome even if you are not.
I loved the transition to dev manager because I was able to make a bigger difference to productivity than if I was doing coding myself. Bigger longer term impact, more strategic but less of an instant 'sugar hit' from tech related fun.
One final piece of advice that I was given by a CTO. He asked me who my team was. I replied with the developers and QA who worked for me. He told me I was wrong, they were my 2nd team. My 1st team was my peers. The other dev managers, QA manager, support team manager, product manager, project manager and ops manager were my team. We needed to start working more closely together as a team rather than in our own little 2nd team silos. What a difference that made to my perspective.
edit:some spelling
Know the difference between being a boss and a leader - becoming a manager doesn't mean you know better.
Negativity is like a virus. If you're a cynical engineer, figure out how to not project that cynicism.
Focus on outcomes. Whatever the day to day drama is, move towards your goals.
Team leads have more fun, but that statement is relative :)
If going into management-proper: 2. Make sure you are prepared to give up the hands-on. Absolutely the hardest part for most technical people I've ever met.
3. Make sure you're prepared not to be the SME anymore. You simply won't have the time to be up-to-date on either every detail that's going on with the system or systems you're managing, or industry standards and movements.
4. Learn about people as voraciously as you would have about technical items. Communication is a hard skill to learn and cannot be acquired alone. Aggressively seek mentors and feedback. Run post-mortems: What happened in that meeting and why? Did we reach our goals? Why or why not?
5. Absolutely most importantly: take care of your people. Enable and support and coach them to success. This can be the least externally but most internally satisfying and gratifying part of the job. Depending on your workplace, you may or may not be recognized for developing your team, but this should be your #1 priority, and if you gain personal satisfaction from seeing your team members soar and take flight, you should do OK :)
1- Do you want a team that works really hard and produces a lot? Or has good quality of life? Technically strongest or business focused? Grow new junior people or stick with those who know what you're doing? Usually people just take one day at a time and at the end of year disappointed where they end up. Will you get paid more if you choose which one of those choices? Or maybe you care more about love of your team, or professional accomplishments than money. Think about that.
2- When there is more and more work I tend to come in on weekends and work longer hours. Other teams just say they can't do it without more resources. I wish I was like the other teams.
Otherwise I would focus on three things:
1. Estimating project time. It will now be your problem when things are not on schedule. Nothing happens quite as planned, but knowing when your team can realistically deliver X is priceless. Successful mastery means most projects get completed in line with your internal predictions (which do not have to match whatever your own management expects or claims).
2. Keeping team happy. Knowing each team member strengths and interests, understanding and resolving interpersonal problems. And keeping them shielded from your own management. Successful mastery means your team respects you.
3. Firing (and to a much less extent hiring). Learn when you should let someone go and how to do it. Success means you have to do it rarely and when you do you do not lose team's respect. They may grumble, but deep inside will know that this is the right decision.