Been quite busy, herding cats :P I won't be updating Game Programmer/Technical Artist to Team Lead/Game Programmer/Technical Artist, but will be mentioning a few new aspects as a new lead in a few blog posts. My main focus is still art and programming, but have been focusing on trying to run a good team as well. My favorite saying for leading programmers is that leading programmers is like herding cats... "You can get a cat to go anywhere you want, as long as the cat wants to go there too". This can be a lot trickier than it sounds, and in a lot of ways code can be easier than people :) I really enjoy the team I am with and have some really good guys, but dealing with people (especially with the often conflicting priorities across teams) can be tricky. I try and stay as close to the code as possible, and still try and write as much as I can, but find I need to delegate more of the smaller details as I have to be more responsible for more of the overall project and structure of the code base.
In order to help with my new responsibilities I have been reading up on a few management books, and am hoping to try a few of the management techniques to hopefully improve what I can. I finished reading Herding Cats: A Primer for Programmers who Lead Programmers by J. Hank Rainwater, which holds some interesting ideas about the challenges of programmer team management. Rainwater's main focus is "thinking and adapting" and constantly reading to learn new techniques and keep your passion for the craft (both the programming and management side). I really enjoy reading (so that is not a problem) but will extend my focus to management (agile, extreme programming etc.) to try and stay informed of some of these aspects as well.
One of the things that Rainwater mentions is "Don't let your email inbox govern your day" he recommends an email thread that is longer than three emails should be talked about on the phone or in person, and that feature creep should be caught as it can initially appear as email clarifications. He also mentions however, that it is important to only hold meetings that are useful, meetings that do not have any action items could usually be better accomplished through an email or wiki page update.
The book goes on to focus on some hiring practices, working with the different levels of an organization and looking in the mirror and evaluating yourself as a leader. I expect that I will re-read chapters of this book as it is filled with a lot of good ideas and common sense. When I was taking Business Management and Organization courses in university (oh so long ago) I often felt like compared with the technical (programming) books they perhaps did not offer as much new material as they did common sense. I think I was a little unfair in that assessment as I now feel like it is important to put those common sense theories into practice, which are not without their own challenges.
I have started reading more agile books (we are trying to get away from waterfall development as much as I can) and have begun implementing daily quick 10 minute stand up meetings in the morning to try and increase communication and sort out action items for the day (the big three questions, what did you do, what are you going to do today and what (if anything) is blocking you), and find that there are often more blocks than is easily anticipated. I have mentioned to the team a few times not to wait until the morning if they discover blocks, and always have something else for them to work on in the meantime if they have a block that requires other teams to work on first (often server or art). Hopefully the meetings are useful for these guys, I always get something out of it, and feel a few of them do too, but either way try and keep it quick.
Lately I have been working a lot of overtime (leading being my day job and programming being my night job), but after the last few months of leading I am (hopefully) getting a better hang of it and will try and put some more of these ideas (and hopefully some from the new books on my desk) into practice and get more coding/leading done in the day.
Until next time,
Michael
http://michaelhubbard.ca
No comments:
Post a Comment