managing

entries/managing.rst

@@ -0,0 +1,56 @@
+Managing small teams
+####################
+
+:date: 2015-12-15 11:00
+:tags: python, mozilla
+:category: mozilla
+:author: Tarek Ziade
+
+
+In the past three years, I went from being a developer in a team, to a team lead,
+to a engineer manager. I find my new position is very challenging because of
+the size of my team, and the remote aspects (we're all remotes.)
+
+When you manage 4/5 people, you're in that weird spot where you're not going to
+spend 100% of your time doing manager stuff. So for the remaining time, the obvious
+thing to do is to help out your team by putting back your developer hat.
+
+But switching hats like this has a huge pitfall: you are the person giving
+people some work to do depending on the organization priorities *and* you are
+also helping out developing. That puts you in a position where it's
+easy to fall into micromanagement: you are asking someone or a group of person
+to be accountable for a task and you are placing yourself on both sides.
+
+I don't have any magic bullet to fix this, besides managing a bigger team
+where I'd spent 100% of my time on management. And I don't know if/when this
+will happen because teams sizes depends on the organization priorities and
+on my growth as a manager.
+
+So for now, I am trying to set a few rules for myself:
+
+1. when there's a development task, always delegate it to someone it the team and
+   propose your help as a reviewer. Do not lead any development task,
+   but try to have an impact on how things move forward, so they go into
+   the direction you'd like them to go as a manager.
+
+2. Every technical help you are doing for your team should be done by working
+   under the supervision of a member of your team. You are not a developer
+   among other developers in your own team.
+
+3. If you lead a task, it should be an isolated work that does not direcly
+   impact developers in the team. Like building a prototype etc.
+
+4. Never ever participate in team meetings with a developer hat on. You
+   can give some feedback of course, but as a manager. If there
+   are some technical points where you can help, you should tackle them
+   through 1:1s. See #1
+
+
+There. That's what I am trying to stick with going forward. If you have more tips
+I'll take them :)
+
+I see this challenge as an interesting puzzle to solve, and a key for me to
+maximize my team's impact.
+
+Coding was easier, damned...
+