Sunday 28 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.
Comments