|
|
|
|
|
by frozenstorm
3813 days ago
|
|
I'm surprised the feedback here has been primarily negative. It sounds like your heart is in the right place, and that's a good start for being a good manager in my eyes (I've never been a manager personally). One of the best attributes I've found in good managers is facilitating success, rather than participating in it. In one-on-one meetings with your team, listen closely to them. Ask them what they'd like out of you, what their goals are at the company, and how you can help them achieve those goals. You are no longer writing the code, and while you should have final say on high-level technical debates, let your team work out organically what the best architecture / pattern / technologies are for the project at hand. If learning is something you want to encourage (bravo for that, all teams should be actively learning), use whatever power or influence you have to make resources available to them. Paid time to read books, paid time to attend conferences (and budgets to pay for conference entrance / travel), etc. And instead of you dictating the points of learning, ask them what they think they need to focus on learning for their own improvement. Lastly, do everything you can to limit their distractions. Instruct coworkers in non-technical disciplines to direct all questions to you, be the development team's "shield" against pesky interruptions. Managers who have done this for me have won my respect much quicker than those who have not. |
|
Maybe the definition of tech/team lead is different from company to company, but where I work, I still have an engineering manager that takes care of the personnel issues and pesky questions from project managers and other non-technicals for me. The role of a tech/team lead for us is a developer that removes the technical roadblocks, spearheads new ideas/projects and acts as developmental resource for the team. It's sort of a symbiotic relationship--I keep the technical aspects of managing the team off the engineering manager and he keeps the stuff I rather not deal with off of me and the team.
I agree about shielding your team though, but more on a technical aspect. Taking on the tasks no one else wants to do and making the tasks everyone has to do more efficient. Also, being the advocate for your team when the company is making major changes that will affect them. I do write code, but it's not as much as everyone else.