Monday, 29 August 2011

Thoughts On Management

I've been managing people for a while now. It's not my favourite job --- technology is my passion --- but it has to be done, and it has to be done well, so I'm happy to do it while Mozilla needs me to. We recently did a round of performance reviews and I've been reflecting on what I've learned.

I'm a slack manager. Most people on my team probably don't get more than fifteen minutes a week interacting with me "as a manager". I mostly get away with it for two reasons. Most people on my team are awesome and need very little supervision; they're self-motivated, capable, and function well when left alone to "get on with it". Also, I interact with them a lot in non-manager ways: code reviews, Bugzilla traffic, IRC, and other project-level communication that I'd have even if I wasn't a manager. I admit that the real reason I'm a slack manager is to give me time to work on code.

Another strange thing about this team is that we don't have regular group meetings. In my view, meetings are a tax on productivity and should only be held when necessary, and I think so far the projects executed by my team have not required whole-group coordination. There's some value in having people know what other people are doing, but I'm not convinced it justifies the cost yet.

I haven't been having one-on-one meetings with the people in the Auckland office because we were able to talk about what everyone's working on over lunch every day. However it became clear that actual one-on-one meetings would help bring out issues, so we've started doing that.

One thing I've mostly ignored is "career development". Two options that seem to be common outside Mozilla are training and promoting people into new roles. For most platform developers, though, I don't know what training would be effective. There isn't a manual for browser development, and if there was a lot of it would be written by Mozilla people; we pass that knowledge on through mentoring, code reviews, and shared experience. Once they've mastered basics like knowledge of algorithms, logic and thinking in terms of invariants (which most people have learned before they get to Mozilla), the only ways I know to improve their general development skills are experience and imposing good tools or processes (e.g. testing).

During the last round of performance reviews I tackled the career question by asking people whether there was anything they would like to do at Mozilla that they weren't currently doing. Almost without exception they answered that they love the technical work they do and would be happy to continue doing it indefinitely. I think this would seem strange to a lot of people (I think there's a widely held view that if you're in the same role for too long, there must be stagnation) but I understand it very well, because I feel the same way myself! I enjoy the fresh technical challenges that keep coming along --- new bugs, new features, often whole new technical areas to explore (typography, graphics, video, RTC...). People who keep working on Gecko, who get better and better at it with deeper and deeper knowledge of the Web and our code, keep increasing their value to Mozilla. So I definitely won't ever push people out of their current role for the sake of change.

However, we do need to make sure that we don't miss any opportunities to find roles that might make people even happier or more productive. Just asking them isn't necessarily effective since there may be opportunities they're not aware of or incorrectly assume they won't enjoy. I need to be a bit more proactive in this area.

5 comments:

  1. What you need to realize about management is that it is not that different than anything else you have probably done before as a programming issue people issues can really be handled using the same skills as long as you are comfortable dealing with them. Just treat it the same way and see if that works for you (it has for me).

    ReplyDelete
  2. I think that was not as clear as it could have been. I have found that people issues are not all that different to deal with than programming issues. That was the point I was trying to make.
    If you can do one, you have the skills required to do the other.

    ReplyDelete
  3. Yeah, I've heard that before.

    I'm not sure I believe it though. If you screw up people issues, it's harder to just back out the offending change :-).

    ReplyDelete
  4. I try to keep career development in mind as well. Most of the time, like you, it becomes "what else would you like to do at Mozilla?" Thankfully, Mozilla has so much going on, there is a variety of things for developers to explore.

    I also try to keep any one developer from being too focused on a single area of the code. The experience and ability to squash bugs in that area of code has to be balanced with allowing the developer to grow into new areas.

    ReplyDelete
  5. Found you via Stormy Peters.

    Yeah, I'm 100% with you in that it makes little sense to push good and happy developers into management. Some career development options that might make a little more sense include encouraging people to mentor volunteers, go to conferences, speak at conferences, and write up their work for blogs and magazines. Of course, you know your folks better than I do!

    ReplyDelete

Note: only a member of this blog may post a comment.