You
Letting Go
before you can even delegate your first task you need to do this. LET GO! I will use a nerdy example to explain this. Say you are playing the role of a tank in a traditional MMO style game (WOW, FF11, etc.). You have chosen the class of warrior because it's stats best suit this role in a group. One night you have plenty of tanks but can not seem to find a healer (we have all been there). So being the team player that you are you switch over to an alternate class/character that is a white mage or equivalent.
When you switch roles in the work place you need to do the same thing. Leads do not have the proper stats to be as good a developer as those they manage. If you do not believe me check out these stats.
Being a Ball Hog
A huge part of letting go is to not be a ball hog. When you are responsible for delegating tasks/issues to your team this can happen if you do not pay attention. If you find you are taking on more tasks then individuals on your team (or the whole team for that matter) then you are turning yourself into a bottleneck. "But Aaron a lot of the tasks I can get done much faster then those available to take it on." This excuse is ridiculous. For one you should have some faith in your team. Even assuming you could get it done faster you need to be challenging your team mates to take on big things so that when you are not available (not just being absent) they can resolve key issues.
When the star player is always shooting all the baskets what happens when he can not make the game? The team's quality shoots way down. If you do not let your team take on the big stuff then your team will not be able to handle big stuff. There is also only so much a single person can achieve.
Be Multi-Threaded
Consider your team is a multi-core processor and you are a programmer running an application on it. If you are not feeding each core tasks and data to process then you are not running your application as fast it could. When you need you application to do cooler effects and push more geometry/objects, it is going to chug. As the lead it is your responsibility to keep the program from chugging.
Now that I have told you what you need to know to get ready to delegate....Delegate!
Methods of Delegation
When you are delegating tasks there is some data you should consider. Again just like in MMOs each player has certain expertise that you need to consider. The data you need to consider to match up a task for delegation can boil down to:
- How much the developer may "like" the task
- How good at the task the developer may be
In a perfect world all the developers you manage would love to get assigned every kind of task and would also be skilled at that task. Unfortunately even in an environment where tedious tasks have been optimized out, there will always be some level of grunt work to complete.
The idea here is to delegate the tasks in a way where they get done as timely as possible. You need to also be thinking long term. Delegation is a tool that can be used to raise the EXP of you developers. That means that you shouldn't always delegate to the guy best suited for the problem. As a rule of thumb I would try to assign a task to someone that isn't best qualified 50% of the time. This way you are getting stuff done as a team at a good velocity, but at the same some having a degree of "grinding" happening (sorry, I am sure you are sick of the MMO references by now).
Once you have figured out who to delegate to you must delegate. The best way to delegate is to simply assign the task. Explain it briefly if its not trivial. If the proper resolution is out of the ordinary, further discussion may be needed. The main idea is to let the developer figure out the details to get the issue resolved. You should not be micromanaging your developers. If you think you need to tell them how to resolve the task then pair them up with an experienced developer (hopefully there are some available).
I know, I know, so now that you are delegating everything, what do you get to do?
Your Responsibilities
You get to sit back and relax. HAHA. Jokes aside, do not worry. You will still get to develop (in most cases you will have to). You will be expected to pull your own weight especially if you are still assigned to wear the developer hat. Honestly though I would try to keep your actual developing to about 25% of your day. Even if you do not do this, the new responsibilities you wikll be juggling will no doubt cause this to happen. So if you are scheduling in a way where you are responsible for doing more then a quarter of those you manage, expect to work more then 8 hours a day.
I am not joking, I have done it. When I became lead I scheduled myself to do 50% of what my guys were expected to do. I was working on average about 12 hours a day (and this is a casual game company). If you are having to work 12 hour days (or more) you are going to be very ineffective for your team. Just like with developing your decision making skills (not to mention your overall quality of work) you have will get worse the longer you work. The difference is the mistakes you make now have a much larger ripple effect.
Okay so you have 25% of your day covered, what do you do with the rest of your day. Well there is too much to explain in depth but here is a quick list.
- Delegating
- Giving constructive feedback to your team
- One on Ones
- Misc. meetings with other departments
- Code reviews
- Design review
- Misc. research
- Checking emails
- Responding to issues that come up
- Fighting fires
Summary
This is simple in concept, but a lot harder in excution. A lot of this will be unnatural. You are just going to have to suck it up and think of the big picture. It is your job to enable your team of developers to get their tasks done as quickly as possible and with the best quality. If they do not have enough to do, they will not get as much done. Let go and give them everything. Build them up so that they can get what you delegate done faster and with higher quality. They should want you to challenge them so do it!
No comments:
Post a Comment