Mixing
How do I become better at Delegating work?
Clash Royale CLAN TAG#URR8PPP
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty margin-bottom:0;
up vote
32
down vote
favorite
I am an introverted programmer who is very good at what I do. I have been suddenly pushed into a position of a team lead, due to my seniors leaving jobs/ moving to different Projects.
I have always been a team player, and I've never had a problem interacting with people or helping them out. My manager pointed out that as one of the main reasons, I was given this responsibility. But I have always avoided responsibility and leadership. It's just not in my nature.
I find it very hard to delegate work and getting work out of people. I also am a perfectionist, and I am never happy with work output, be it mine or someone else's. This makes it even harder accepting the work that other people submit to me. I feel that I am out of my depth in his situation.
How do I become better at delegating work, and getting them to work for me?
leadership learning
asked May 6 '13 at 15:57
leo
16413
add a comment |Â
up vote
32
down vote
favorite
I am an introverted programmer who is very good at what I do. I have been suddenly pushed into a position of a team lead, due to my seniors leaving jobs/ moving to different Projects.
I have always been a team player, and I've never had a problem interacting with people or helping them out. My manager pointed out that as one of the main reasons, I was given this responsibility. But I have always avoided responsibility and leadership. It's just not in my nature.
I find it very hard to delegate work and getting work out of people. I also am a perfectionist, and I am never happy with work output, be it mine or someone else's. This makes it even harder accepting the work that other people submit to me. I feel that I am out of my depth in his situation.
How do I become better at delegating work, and getting them to work for me?
leadership learning
asked May 6 '13 at 15:57
leo
16413
3
The question is: are you applying the most stringent criteria to your own work? While it doesn't solve all the problems, it helps to leverage moral authority... Please remember that people do not work for you - they work for the company.
– Deer Hunter
May 6 '13 at 17:59
add a comment |Â
up vote
32
down vote
favorite
up vote
32
down vote
favorite
I am an introverted programmer who is very good at what I do. I have been suddenly pushed into a position of a team lead, due to my seniors leaving jobs/ moving to different Projects.
I have always been a team player, and I've never had a problem interacting with people or helping them out. My manager pointed out that as one of the main reasons, I was given this responsibility. But I have always avoided responsibility and leadership. It's just not in my nature.
I find it very hard to delegate work and getting work out of people. I also am a perfectionist, and I am never happy with work output, be it mine or someone else's. This makes it even harder accepting the work that other people submit to me. I feel that I am out of my depth in his situation.
How do I become better at delegating work, and getting them to work for me?
leadership learning
asked May 6 '13 at 15:57
leo
16413
I am an introverted programmer who is very good at what I do. I have been suddenly pushed into a position of a team lead, due to my seniors leaving jobs/ moving to different Projects.
I have always been a team player, and I've never had a problem interacting with people or helping them out. My manager pointed out that as one of the main reasons, I was given this responsibility. But I have always avoided responsibility and leadership. It's just not in my nature.
I find it very hard to delegate work and getting work out of people. I also am a perfectionist, and I am never happy with work output, be it mine or someone else's. This makes it even harder accepting the work that other people submit to me. I feel that I am out of my depth in his situation.
How do I become better at delegating work, and getting them to work for me?
leadership learning
asked May 6 '13 at 15:57
leo
16413
asked May 6 '13 at 15:57
leo
16413
asked May 6 '13 at 15:57
leo
16413
asked May 6 '13 at 15:57
leo
16413
16413
3
The question is: are you applying the most stringent criteria to your own work? While it doesn't solve all the problems, it helps to leverage moral authority... Please remember that people do not work for you - they work for the company.
– Deer Hunter
May 6 '13 at 17:59
add a comment |Â
3
The question is: are you applying the most stringent criteria to your own work? While it doesn't solve all the problems, it helps to leverage moral authority... Please remember that people do not work for you - they work for the company.
– Deer Hunter
May 6 '13 at 17:59
3
3
The question is: are you applying the most stringent criteria to your own work? While it doesn't solve all the problems, it helps to leverage moral authority... Please remember that people do not work for you - they work for the company.
– Deer Hunter
May 6 '13 at 17:59
The question is: are you applying the most stringent criteria to your own work? While it doesn't solve all the problems, it helps to leverage moral authority... Please remember that people do not work for you - they work for the company.
– Deer Hunter
May 6 '13 at 17:59
add a comment |Â
4 Answers
4
active
oldest
votes
up vote
36
down vote
First - you're not alone! I see this alot in folks that are only just starting in technical leadership, particularly when they are promoted from within an organization where they were excellent individual contributors.
Some thoughts - I find this to be an oddly assorted collection, even in my own mind, so I never really have a perfect model... but here's some tidbits I've picked up over the years.
The Efficiency Ratio
The efficiency ratio is the time it would take for you to do something vs. the time it will take the person to whom you are delegating. First, realize that your time is now precious for reasons other than your ability to be a great individual contributor - you need to address communication needs that team members simply can't do, you need to see a big picture and get the team moving in the right direction, you need to set out rules that lead to consistency and coalition - in many cases, team members can't do that part, and if you skip these parts, you decrease the efficiency of the whole far more than you increase team efficiency by doing work better than anyone else.
To compensate, I use a ratio for work that can be delegated:
2:1 - IMO, the absolute minimum - if you can do it twice as fast as the person you give the work do, you should still delegate. At 3:1, maybe keep it. Seriously. Two big reasons - people get more efficient through learning by doing, so the first time your team member may take twice as long as you would, but the second time the ratio will be more in their favor. Second - you add at least that much value by coordinating the team's work.
5:1 - a better ratio still for a busy team of 5 or more with a reasonable level of "organizational overhead". "Organizational overhead" is the work that only a manager can do - that includes getting annoying people off the back fo your team, coordinating with other groups so work transitions smoothly, seeing the big risks and preparing for them, etc. The more of it there is, the more your time is at a premium, and you need to let your team take on more work. Even if it will take you 1 hour and your best team member 5 hours - let them do it.
20:1 - the ratio I actually used when I last ran a team that did the same things I could do. I was a subject matter expert in the work, but I wouldn't touch a box until 1 hour of my time would save my folks nearly 3 days of work. It reduced my individual contributor time to mere hours in a week, but when leading a team of 12-20 people, with a high organizational overhead load - it was absolutely critical.
The final point on this element being - it's a sliding scale. A small team, in an informal situation can operate with a way more hands on lead than a big team in a highly structured company. But keep an eye on your own ratio and adjust as needed. You know you have this ratio wrong when you are working 60+ hours and everyone on your team is going home in 40-45 hours.
I go so far as to voice this ratio and vet it with senior management. My management pretty much patted me on the back when I mentioned my insane sounding 20:1 ratio - they knew how much they needed a manager to be managing and they were very happy that the only time I took my eye off the management stuff was to go putout a 5 alarm inferno.
Don't let the best be the enemy of the good
Easy to say, hard to do. Realize that while you are free to make yourself crazy with your own perfectionism - if you nitpick your team member's work to the point of perfection, you will both drive efficiency into the ground and cause a rapid turnover in employment.
My best advice here is to focus on the goal - you want to develop something, it has certain requirements. When they are met, you are done. Dicuss these requirements, get folks that work on the team to re-iterate them so they can be agreed upon, then at the end, look for a demonstration of the requirements. If they can demonstrate success, leave it be.
From time to time, there will be a need to go through and clean up the mess of imperfect decision making. This is going to be true whether you were perfect or not. For the most part, that last 10% of perfection is only perfect to a specific individual. Doing consolidated cleanup is healthy and worth doing with an eye to setting a standard that becomes part of the work requirements. Get group buy in on these standards, and you'll get a status quo that people will enforce without much work from you.
A key test for this is "what will go wrong if we do it not-my-way?" - if the answer is nothing or not much - leave it be.
Stay hands off
If you take a part of the project to work on - fine.
But stay out of the way when you've delegated. If you have issues with the work, and these issues really do matter for the success of the project - give that feedback to your people and let them fix it. Fix it for them, and you break a type of trust - the trust that if you have issues or concerns, you'll come to them and ask for a fix.
Where you can - cross delegate - avoid looking over every part of the code yourself - set a standard and ask the team to help each other. Peer reviews are a great tool here. So is paired programming. Anything that gets multiple eyes (not just yours) on a peice of work.
This is one of the nicer places to stay absolute - if you find your hands twitching on the keyboard to just change this one little thing, don't do it. Give the note instead to the developer and ask them for a fix.
Pet Projects
For those that like leading, but won't be happy with out a peice of the technical fun, get yourself a pet project. A pet project is a peice of work thatL
- Is meaningful and interesting to you, but that might otherwise be done by an individual contributor. There's no management work here, and it satisifies that craving to stay hands on.
- Can be accomplished without harm to the project schedule, even in light of the management work that is also part of your job. It has to be the right size that you can get both done with no harm.
My general guidelines for this are:
- Don't leave a mess. If you can't do it completely, including the boring repetitive work that every other individual contributor would have to do - then you can't do it. Giving yourself special waivers on shirking the work you don't like sets a REALLY bad example.
- Don't hurt the schedule. If you find the schedule slipping because your work isn't getting done, fire yourself and give the work to a regular individual contributor.
- My general heuristic (if I'm really up to speed on the tech) is that I take something that is between medium and medium-low on the priority scale. I leave the glory to my best individual contributors and take something that is meaningul but low enough on the priority scale that I can see the schedule slip well before it becomes an issue.
Be true to yourself
Not everyone loves being a leader. It sounds like you've been very happy not being a leader - so you know at least one career path works for you. Give this opportunity a shot, but be true to yourself. If after 6 months of leading, you find that the only true joy at work comes from having that time by yourself to do individual contributor work, and you know you're doing more than you really have time for because it gives you such joy - then have a frank discussion with your management.
You don't have to like it - management work and being a mentor and a senior individual contributor are very different.
Give it an honest shot, but in the end, a desperately unhappy manager is worse for a team than a new manager, or a manager with weaker technical skills but strong enough people skills.
answered May 6 '13 at 21:14
bethlakshmi
70.4k4136277
One of those answers I wish I could upvote more than once. In a similar boat to the OP, and finding it quite hard to adjust.
– shambulator
May 7 '13 at 8:47
One point missed. Delegation is about growing the skills of your team. So do not delegate work just because you don't like doing it, or if it tedious.
– Simon O'Doherty
Jun 13 '13 at 18:52
I'll add that.. but with a spin... (see edit)
– bethlakshmi
Jun 14 '13 at 19:39
Added Pet Projects as a section - but I disagree about not delegating just because something is tedious - if I have to the same thing 100 times a week, and there's no judgement call involved - it will be tedious. Me doing it 100 times vs. every man on a 10 man team doing it 10 times, is a better division of labor, no matter how boring.
– bethlakshmi
Jun 14 '13 at 19:47
add a comment |Â
up vote
3
down vote
I think that effectively delegating work comes with experience. Don't be afraid about the new responsibilities.
Since you are a good team player, you might know strengths and weaknesses (in terms of work) of your team members. You can divide the projects into tasks and discuss with your team members probably first 1:1 for allocating tasks. During 1:1 discussions, you can convey positively why you would like to allocate a particular task to the team member. Clarify his/her questions. Once all the members agree upon their tasks you can summarize this in a team meeting.
Be positive and brave. Initially you might not be very effective, but gradually you will be good and comfortable with the new responsibilities.
answered May 6 '13 at 17:31
samarasa
1,90621430
add a comment |Â
up vote
2
down vote
Review your work from your previous supervisor's and possibly user's perspectives. You may be a little hard on yourself concerning the "perfectionist" claim. Having high standards is a good thing. It only becomes a problem if it prevents you from getting projects done one time and to the client's satisfaction. If this is a problem, your demanding that the other programmers commit the same mistakes is going to compound the problem.
When you are the manager, try to establish standards for practices and procedures. Consider dividing this up, so different team members can have a voice in this processs. If everyone agrees on the level of test coverage, code review or documentation, it's up to you to hold them to their own levels. You'd be surprise that some of them may come up with something more stringent than you would.
As the team leader, you're also going to have to represent your team to the other management. Of course you'll still have to continue coding, but make sure you take the time and put in the effort to support your team from the outside. They may request different hours because of the nature of their work. Can you make sure everyone knows your team is not slacking off? Will you have the same level of "perfectionism" when your team wants you to ask for faster workstations, extra testing servers or the support department thinks you whould write all the training documents?
Focus on getting things done on time, budget and user satisfaction and everyone will be happier. Your standards should contribute to this and not prevent it.
add a comment |Â
up vote
1
down vote
Firstly, congratulations with the trust your company has put in you. Please take the time to let the compliment sink in.
Next, I think it is important to find someone to mentor you, someone with much more experience. Your current manager would be a prime candidate. You can set up regular meetings with him, say half an hour a week. Alternatively, you could schedule meetings as you go, but this carries the risk that the meetings will be skipped due to deadlines and such. In these meetings you can share the issues you are facing, and talk about how you go about being a team lead. The more experienced person can provide feedback, transferring precious experience form him/her to you. I think this kind of mentoring is definitely worth the time. Avoiding a big pitfall will save time in a project, making up for your 'lost' time talking to your manager. Also, these meetings will increase your confidence, making you more effective at your job.
Learning this new leadership skill is going to take time, just as learning a new programming language would. Good luck!
answered May 6 '13 at 17:32
Paul Hiemstra
3,8451621
add a comment |Â
StackExchange.ready(function ()
$("#show-editor-button input, #show-editor-button button").click(function ()
var showEditor = function()
$("#show-editor-button").hide();
$("#post-form").removeClass("dno");
StackExchange.editor.finallyInit();
;
var useFancy = $(this).data('confirm-use-fancy');
if(useFancy == 'True')
var popupTitle = $(this).data('confirm-fancy-title');
var popupBody = $(this).data('confirm-fancy-body');
var popupAccept = $(this).data('confirm-fancy-accept-button');
$(this).loadPopup(
url: '/post/self-answer-popup',
loaded: function(popup)
var pTitle = $(popup).find('h2');
var pBody = $(popup).find('.popup-body');
var pSubmit = $(popup).find('.popup-submit');
pTitle.text(popupTitle);
pBody.html(popupBody);
pSubmit.val(popupAccept).click(showEditor);
)
else
var confirmText = $(this).data('confirm-text');
if (confirmText ? confirm(confirmText) : true)
showEditor();
);
);
4 Answers
4
active
oldest
votes
4 Answers
4
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
36
down vote
First - you're not alone! I see this alot in folks that are only just starting in technical leadership, particularly when they are promoted from within an organization where they were excellent individual contributors.
Some thoughts - I find this to be an oddly assorted collection, even in my own mind, so I never really have a perfect model... but here's some tidbits I've picked up over the years.
The Efficiency Ratio
The efficiency ratio is the time it would take for you to do something vs. the time it will take the person to whom you are delegating. First, realize that your time is now precious for reasons other than your ability to be a great individual contributor - you need to address communication needs that team members simply can't do, you need to see a big picture and get the team moving in the right direction, you need to set out rules that lead to consistency and coalition - in many cases, team members can't do that part, and if you skip these parts, you decrease the efficiency of the whole far more than you increase team efficiency by doing work better than anyone else.
To compensate, I use a ratio for work that can be delegated:
2:1 - IMO, the absolute minimum - if you can do it twice as fast as the person you give the work do, you should still delegate. At 3:1, maybe keep it. Seriously. Two big reasons - people get more efficient through learning by doing, so the first time your team member may take twice as long as you would, but the second time the ratio will be more in their favor. Second - you add at least that much value by coordinating the team's work.
5:1 - a better ratio still for a busy team of 5 or more with a reasonable level of "organizational overhead". "Organizational overhead" is the work that only a manager can do - that includes getting annoying people off the back fo your team, coordinating with other groups so work transitions smoothly, seeing the big risks and preparing for them, etc. The more of it there is, the more your time is at a premium, and you need to let your team take on more work. Even if it will take you 1 hour and your best team member 5 hours - let them do it.
20:1 - the ratio I actually used when I last ran a team that did the same things I could do. I was a subject matter expert in the work, but I wouldn't touch a box until 1 hour of my time would save my folks nearly 3 days of work. It reduced my individual contributor time to mere hours in a week, but when leading a team of 12-20 people, with a high organizational overhead load - it was absolutely critical.
The final point on this element being - it's a sliding scale. A small team, in an informal situation can operate with a way more hands on lead than a big team in a highly structured company. But keep an eye on your own ratio and adjust as needed. You know you have this ratio wrong when you are working 60+ hours and everyone on your team is going home in 40-45 hours.
I go so far as to voice this ratio and vet it with senior management. My management pretty much patted me on the back when I mentioned my insane sounding 20:1 ratio - they knew how much they needed a manager to be managing and they were very happy that the only time I took my eye off the management stuff was to go putout a 5 alarm inferno.
Don't let the best be the enemy of the good
Easy to say, hard to do. Realize that while you are free to make yourself crazy with your own perfectionism - if you nitpick your team member's work to the point of perfection, you will both drive efficiency into the ground and cause a rapid turnover in employment.
My best advice here is to focus on the goal - you want to develop something, it has certain requirements. When they are met, you are done. Dicuss these requirements, get folks that work on the team to re-iterate them so they can be agreed upon, then at the end, look for a demonstration of the requirements. If they can demonstrate success, leave it be.
From time to time, there will be a need to go through and clean up the mess of imperfect decision making. This is going to be true whether you were perfect or not. For the most part, that last 10% of perfection is only perfect to a specific individual. Doing consolidated cleanup is healthy and worth doing with an eye to setting a standard that becomes part of the work requirements. Get group buy in on these standards, and you'll get a status quo that people will enforce without much work from you.
A key test for this is "what will go wrong if we do it not-my-way?" - if the answer is nothing or not much - leave it be.
Stay hands off
If you take a part of the project to work on - fine.
But stay out of the way when you've delegated. If you have issues with the work, and these issues really do matter for the success of the project - give that feedback to your people and let them fix it. Fix it for them, and you break a type of trust - the trust that if you have issues or concerns, you'll come to them and ask for a fix.
Where you can - cross delegate - avoid looking over every part of the code yourself - set a standard and ask the team to help each other. Peer reviews are a great tool here. So is paired programming. Anything that gets multiple eyes (not just yours) on a peice of work.
This is one of the nicer places to stay absolute - if you find your hands twitching on the keyboard to just change this one little thing, don't do it. Give the note instead to the developer and ask them for a fix.
Pet Projects
For those that like leading, but won't be happy with out a peice of the technical fun, get yourself a pet project. A pet project is a peice of work thatL
- Is meaningful and interesting to you, but that might otherwise be done by an individual contributor. There's no management work here, and it satisifies that craving to stay hands on.
- Can be accomplished without harm to the project schedule, even in light of the management work that is also part of your job. It has to be the right size that you can get both done with no harm.
My general guidelines for this are:
- Don't leave a mess. If you can't do it completely, including the boring repetitive work that every other individual contributor would have to do - then you can't do it. Giving yourself special waivers on shirking the work you don't like sets a REALLY bad example.
- Don't hurt the schedule. If you find the schedule slipping because your work isn't getting done, fire yourself and give the work to a regular individual contributor.
- My general heuristic (if I'm really up to speed on the tech) is that I take something that is between medium and medium-low on the priority scale. I leave the glory to my best individual contributors and take something that is meaningul but low enough on the priority scale that I can see the schedule slip well before it becomes an issue.
Be true to yourself
Not everyone loves being a leader. It sounds like you've been very happy not being a leader - so you know at least one career path works for you. Give this opportunity a shot, but be true to yourself. If after 6 months of leading, you find that the only true joy at work comes from having that time by yourself to do individual contributor work, and you know you're doing more than you really have time for because it gives you such joy - then have a frank discussion with your management.
You don't have to like it - management work and being a mentor and a senior individual contributor are very different.
Give it an honest shot, but in the end, a desperately unhappy manager is worse for a team than a new manager, or a manager with weaker technical skills but strong enough people skills.
answered May 6 '13 at 21:14
bethlakshmi
70.4k4136277
One of those answers I wish I could upvote more than once. In a similar boat to the OP, and finding it quite hard to adjust.
– shambulator
May 7 '13 at 8:47
One point missed. Delegation is about growing the skills of your team. So do not delegate work just because you don't like doing it, or if it tedious.
– Simon O'Doherty
Jun 13 '13 at 18:52
I'll add that.. but with a spin... (see edit)
– bethlakshmi
Jun 14 '13 at 19:39
Added Pet Projects as a section - but I disagree about not delegating just because something is tedious - if I have to the same thing 100 times a week, and there's no judgement call involved - it will be tedious. Me doing it 100 times vs. every man on a 10 man team doing it 10 times, is a better division of labor, no matter how boring.
– bethlakshmi
Jun 14 '13 at 19:47
add a comment |Â
up vote
36
down vote
First - you're not alone! I see this alot in folks that are only just starting in technical leadership, particularly when they are promoted from within an organization where they were excellent individual contributors.
Some thoughts - I find this to be an oddly assorted collection, even in my own mind, so I never really have a perfect model... but here's some tidbits I've picked up over the years.
The Efficiency Ratio
The efficiency ratio is the time it would take for you to do something vs. the time it will take the person to whom you are delegating. First, realize that your time is now precious for reasons other than your ability to be a great individual contributor - you need to address communication needs that team members simply can't do, you need to see a big picture and get the team moving in the right direction, you need to set out rules that lead to consistency and coalition - in many cases, team members can't do that part, and if you skip these parts, you decrease the efficiency of the whole far more than you increase team efficiency by doing work better than anyone else.
To compensate, I use a ratio for work that can be delegated:
2:1 - IMO, the absolute minimum - if you can do it twice as fast as the person you give the work do, you should still delegate. At 3:1, maybe keep it. Seriously. Two big reasons - people get more efficient through learning by doing, so the first time your team member may take twice as long as you would, but the second time the ratio will be more in their favor. Second - you add at least that much value by coordinating the team's work.
5:1 - a better ratio still for a busy team of 5 or more with a reasonable level of "organizational overhead". "Organizational overhead" is the work that only a manager can do - that includes getting annoying people off the back fo your team, coordinating with other groups so work transitions smoothly, seeing the big risks and preparing for them, etc. The more of it there is, the more your time is at a premium, and you need to let your team take on more work. Even if it will take you 1 hour and your best team member 5 hours - let them do it.
20:1 - the ratio I actually used when I last ran a team that did the same things I could do. I was a subject matter expert in the work, but I wouldn't touch a box until 1 hour of my time would save my folks nearly 3 days of work. It reduced my individual contributor time to mere hours in a week, but when leading a team of 12-20 people, with a high organizational overhead load - it was absolutely critical.
The final point on this element being - it's a sliding scale. A small team, in an informal situation can operate with a way more hands on lead than a big team in a highly structured company. But keep an eye on your own ratio and adjust as needed. You know you have this ratio wrong when you are working 60+ hours and everyone on your team is going home in 40-45 hours.
I go so far as to voice this ratio and vet it with senior management. My management pretty much patted me on the back when I mentioned my insane sounding 20:1 ratio - they knew how much they needed a manager to be managing and they were very happy that the only time I took my eye off the management stuff was to go putout a 5 alarm inferno.
Don't let the best be the enemy of the good
Easy to say, hard to do. Realize that while you are free to make yourself crazy with your own perfectionism - if you nitpick your team member's work to the point of perfection, you will both drive efficiency into the ground and cause a rapid turnover in employment.
My best advice here is to focus on the goal - you want to develop something, it has certain requirements. When they are met, you are done. Dicuss these requirements, get folks that work on the team to re-iterate them so they can be agreed upon, then at the end, look for a demonstration of the requirements. If they can demonstrate success, leave it be.
From time to time, there will be a need to go through and clean up the mess of imperfect decision making. This is going to be true whether you were perfect or not. For the most part, that last 10% of perfection is only perfect to a specific individual. Doing consolidated cleanup is healthy and worth doing with an eye to setting a standard that becomes part of the work requirements. Get group buy in on these standards, and you'll get a status quo that people will enforce without much work from you.
A key test for this is "what will go wrong if we do it not-my-way?" - if the answer is nothing or not much - leave it be.
Stay hands off
If you take a part of the project to work on - fine.
But stay out of the way when you've delegated. If you have issues with the work, and these issues really do matter for the success of the project - give that feedback to your people and let them fix it. Fix it for them, and you break a type of trust - the trust that if you have issues or concerns, you'll come to them and ask for a fix.
Where you can - cross delegate - avoid looking over every part of the code yourself - set a standard and ask the team to help each other. Peer reviews are a great tool here. So is paired programming. Anything that gets multiple eyes (not just yours) on a peice of work.
This is one of the nicer places to stay absolute - if you find your hands twitching on the keyboard to just change this one little thing, don't do it. Give the note instead to the developer and ask them for a fix.
Pet Projects
For those that like leading, but won't be happy with out a peice of the technical fun, get yourself a pet project. A pet project is a peice of work thatL
- Is meaningful and interesting to you, but that might otherwise be done by an individual contributor. There's no management work here, and it satisifies that craving to stay hands on.
- Can be accomplished without harm to the project schedule, even in light of the management work that is also part of your job. It has to be the right size that you can get both done with no harm.
My general guidelines for this are:
- Don't leave a mess. If you can't do it completely, including the boring repetitive work that every other individual contributor would have to do - then you can't do it. Giving yourself special waivers on shirking the work you don't like sets a REALLY bad example.
- Don't hurt the schedule. If you find the schedule slipping because your work isn't getting done, fire yourself and give the work to a regular individual contributor.
- My general heuristic (if I'm really up to speed on the tech) is that I take something that is between medium and medium-low on the priority scale. I leave the glory to my best individual contributors and take something that is meaningul but low enough on the priority scale that I can see the schedule slip well before it becomes an issue.
Be true to yourself
Not everyone loves being a leader. It sounds like you've been very happy not being a leader - so you know at least one career path works for you. Give this opportunity a shot, but be true to yourself. If after 6 months of leading, you find that the only true joy at work comes from having that time by yourself to do individual contributor work, and you know you're doing more than you really have time for because it gives you such joy - then have a frank discussion with your management.
You don't have to like it - management work and being a mentor and a senior individual contributor are very different.
Give it an honest shot, but in the end, a desperately unhappy manager is worse for a team than a new manager, or a manager with weaker technical skills but strong enough people skills.
answered May 6 '13 at 21:14
bethlakshmi
70.4k4136277
One of those answers I wish I could upvote more than once. In a similar boat to the OP, and finding it quite hard to adjust.
– shambulator
May 7 '13 at 8:47
One point missed. Delegation is about growing the skills of your team. So do not delegate work just because you don't like doing it, or if it tedious.
– Simon O'Doherty
Jun 13 '13 at 18:52
I'll add that.. but with a spin... (see edit)
– bethlakshmi
Jun 14 '13 at 19:39
Added Pet Projects as a section - but I disagree about not delegating just because something is tedious - if I have to the same thing 100 times a week, and there's no judgement call involved - it will be tedious. Me doing it 100 times vs. every man on a 10 man team doing it 10 times, is a better division of labor, no matter how boring.
– bethlakshmi
Jun 14 '13 at 19:47
add a comment |Â
up vote
36
down vote
up vote
36
down vote
First - you're not alone! I see this alot in folks that are only just starting in technical leadership, particularly when they are promoted from within an organization where they were excellent individual contributors.
Some thoughts - I find this to be an oddly assorted collection, even in my own mind, so I never really have a perfect model... but here's some tidbits I've picked up over the years.
The Efficiency Ratio
The efficiency ratio is the time it would take for you to do something vs. the time it will take the person to whom you are delegating. First, realize that your time is now precious for reasons other than your ability to be a great individual contributor - you need to address communication needs that team members simply can't do, you need to see a big picture and get the team moving in the right direction, you need to set out rules that lead to consistency and coalition - in many cases, team members can't do that part, and if you skip these parts, you decrease the efficiency of the whole far more than you increase team efficiency by doing work better than anyone else.
To compensate, I use a ratio for work that can be delegated:
2:1 - IMO, the absolute minimum - if you can do it twice as fast as the person you give the work do, you should still delegate. At 3:1, maybe keep it. Seriously. Two big reasons - people get more efficient through learning by doing, so the first time your team member may take twice as long as you would, but the second time the ratio will be more in their favor. Second - you add at least that much value by coordinating the team's work.
5:1 - a better ratio still for a busy team of 5 or more with a reasonable level of "organizational overhead". "Organizational overhead" is the work that only a manager can do - that includes getting annoying people off the back fo your team, coordinating with other groups so work transitions smoothly, seeing the big risks and preparing for them, etc. The more of it there is, the more your time is at a premium, and you need to let your team take on more work. Even if it will take you 1 hour and your best team member 5 hours - let them do it.
20:1 - the ratio I actually used when I last ran a team that did the same things I could do. I was a subject matter expert in the work, but I wouldn't touch a box until 1 hour of my time would save my folks nearly 3 days of work. It reduced my individual contributor time to mere hours in a week, but when leading a team of 12-20 people, with a high organizational overhead load - it was absolutely critical.
The final point on this element being - it's a sliding scale. A small team, in an informal situation can operate with a way more hands on lead than a big team in a highly structured company. But keep an eye on your own ratio and adjust as needed. You know you have this ratio wrong when you are working 60+ hours and everyone on your team is going home in 40-45 hours.
I go so far as to voice this ratio and vet it with senior management. My management pretty much patted me on the back when I mentioned my insane sounding 20:1 ratio - they knew how much they needed a manager to be managing and they were very happy that the only time I took my eye off the management stuff was to go putout a 5 alarm inferno.
Don't let the best be the enemy of the good
Easy to say, hard to do. Realize that while you are free to make yourself crazy with your own perfectionism - if you nitpick your team member's work to the point of perfection, you will both drive efficiency into the ground and cause a rapid turnover in employment.
My best advice here is to focus on the goal - you want to develop something, it has certain requirements. When they are met, you are done. Dicuss these requirements, get folks that work on the team to re-iterate them so they can be agreed upon, then at the end, look for a demonstration of the requirements. If they can demonstrate success, leave it be.
From time to time, there will be a need to go through and clean up the mess of imperfect decision making. This is going to be true whether you were perfect or not. For the most part, that last 10% of perfection is only perfect to a specific individual. Doing consolidated cleanup is healthy and worth doing with an eye to setting a standard that becomes part of the work requirements. Get group buy in on these standards, and you'll get a status quo that people will enforce without much work from you.
A key test for this is "what will go wrong if we do it not-my-way?" - if the answer is nothing or not much - leave it be.
Stay hands off
If you take a part of the project to work on - fine.
But stay out of the way when you've delegated. If you have issues with the work, and these issues really do matter for the success of the project - give that feedback to your people and let them fix it. Fix it for them, and you break a type of trust - the trust that if you have issues or concerns, you'll come to them and ask for a fix.
Where you can - cross delegate - avoid looking over every part of the code yourself - set a standard and ask the team to help each other. Peer reviews are a great tool here. So is paired programming. Anything that gets multiple eyes (not just yours) on a peice of work.
This is one of the nicer places to stay absolute - if you find your hands twitching on the keyboard to just change this one little thing, don't do it. Give the note instead to the developer and ask them for a fix.
Pet Projects
For those that like leading, but won't be happy with out a peice of the technical fun, get yourself a pet project. A pet project is a peice of work thatL
- Is meaningful and interesting to you, but that might otherwise be done by an individual contributor. There's no management work here, and it satisifies that craving to stay hands on.
- Can be accomplished without harm to the project schedule, even in light of the management work that is also part of your job. It has to be the right size that you can get both done with no harm.
My general guidelines for this are:
- Don't leave a mess. If you can't do it completely, including the boring repetitive work that every other individual contributor would have to do - then you can't do it. Giving yourself special waivers on shirking the work you don't like sets a REALLY bad example.
- Don't hurt the schedule. If you find the schedule slipping because your work isn't getting done, fire yourself and give the work to a regular individual contributor.
- My general heuristic (if I'm really up to speed on the tech) is that I take something that is between medium and medium-low on the priority scale. I leave the glory to my best individual contributors and take something that is meaningul but low enough on the priority scale that I can see the schedule slip well before it becomes an issue.
Be true to yourself
Not everyone loves being a leader. It sounds like you've been very happy not being a leader - so you know at least one career path works for you. Give this opportunity a shot, but be true to yourself. If after 6 months of leading, you find that the only true joy at work comes from having that time by yourself to do individual contributor work, and you know you're doing more than you really have time for because it gives you such joy - then have a frank discussion with your management.
You don't have to like it - management work and being a mentor and a senior individual contributor are very different.
Give it an honest shot, but in the end, a desperately unhappy manager is worse for a team than a new manager, or a manager with weaker technical skills but strong enough people skills.
answered May 6 '13 at 21:14
bethlakshmi
70.4k4136277
First - you're not alone! I see this alot in folks that are only just starting in technical leadership, particularly when they are promoted from within an organization where they were excellent individual contributors.
Some thoughts - I find this to be an oddly assorted collection, even in my own mind, so I never really have a perfect model... but here's some tidbits I've picked up over the years.
The Efficiency Ratio
The efficiency ratio is the time it would take for you to do something vs. the time it will take the person to whom you are delegating. First, realize that your time is now precious for reasons other than your ability to be a great individual contributor - you need to address communication needs that team members simply can't do, you need to see a big picture and get the team moving in the right direction, you need to set out rules that lead to consistency and coalition - in many cases, team members can't do that part, and if you skip these parts, you decrease the efficiency of the whole far more than you increase team efficiency by doing work better than anyone else.
To compensate, I use a ratio for work that can be delegated:
2:1 - IMO, the absolute minimum - if you can do it twice as fast as the person you give the work do, you should still delegate. At 3:1, maybe keep it. Seriously. Two big reasons - people get more efficient through learning by doing, so the first time your team member may take twice as long as you would, but the second time the ratio will be more in their favor. Second - you add at least that much value by coordinating the team's work.
5:1 - a better ratio still for a busy team of 5 or more with a reasonable level of "organizational overhead". "Organizational overhead" is the work that only a manager can do - that includes getting annoying people off the back fo your team, coordinating with other groups so work transitions smoothly, seeing the big risks and preparing for them, etc. The more of it there is, the more your time is at a premium, and you need to let your team take on more work. Even if it will take you 1 hour and your best team member 5 hours - let them do it.
20:1 - the ratio I actually used when I last ran a team that did the same things I could do. I was a subject matter expert in the work, but I wouldn't touch a box until 1 hour of my time would save my folks nearly 3 days of work. It reduced my individual contributor time to mere hours in a week, but when leading a team of 12-20 people, with a high organizational overhead load - it was absolutely critical.
The final point on this element being - it's a sliding scale. A small team, in an informal situation can operate with a way more hands on lead than a big team in a highly structured company. But keep an eye on your own ratio and adjust as needed. You know you have this ratio wrong when you are working 60+ hours and everyone on your team is going home in 40-45 hours.
I go so far as to voice this ratio and vet it with senior management. My management pretty much patted me on the back when I mentioned my insane sounding 20:1 ratio - they knew how much they needed a manager to be managing and they were very happy that the only time I took my eye off the management stuff was to go putout a 5 alarm inferno.
Don't let the best be the enemy of the good
Easy to say, hard to do. Realize that while you are free to make yourself crazy with your own perfectionism - if you nitpick your team member's work to the point of perfection, you will both drive efficiency into the ground and cause a rapid turnover in employment.
My best advice here is to focus on the goal - you want to develop something, it has certain requirements. When they are met, you are done. Dicuss these requirements, get folks that work on the team to re-iterate them so they can be agreed upon, then at the end, look for a demonstration of the requirements. If they can demonstrate success, leave it be.
From time to time, there will be a need to go through and clean up the mess of imperfect decision making. This is going to be true whether you were perfect or not. For the most part, that last 10% of perfection is only perfect to a specific individual. Doing consolidated cleanup is healthy and worth doing with an eye to setting a standard that becomes part of the work requirements. Get group buy in on these standards, and you'll get a status quo that people will enforce without much work from you.
A key test for this is "what will go wrong if we do it not-my-way?" - if the answer is nothing or not much - leave it be.
Stay hands off
If you take a part of the project to work on - fine.
But stay out of the way when you've delegated. If you have issues with the work, and these issues really do matter for the success of the project - give that feedback to your people and let them fix it. Fix it for them, and you break a type of trust - the trust that if you have issues or concerns, you'll come to them and ask for a fix.
Where you can - cross delegate - avoid looking over every part of the code yourself - set a standard and ask the team to help each other. Peer reviews are a great tool here. So is paired programming. Anything that gets multiple eyes (not just yours) on a peice of work.
This is one of the nicer places to stay absolute - if you find your hands twitching on the keyboard to just change this one little thing, don't do it. Give the note instead to the developer and ask them for a fix.
Pet Projects
For those that like leading, but won't be happy with out a peice of the technical fun, get yourself a pet project. A pet project is a peice of work thatL
- Is meaningful and interesting to you, but that might otherwise be done by an individual contributor. There's no management work here, and it satisifies that craving to stay hands on.
- Can be accomplished without harm to the project schedule, even in light of the management work that is also part of your job. It has to be the right size that you can get both done with no harm.
My general guidelines for this are:
- Don't leave a mess. If you can't do it completely, including the boring repetitive work that every other individual contributor would have to do - then you can't do it. Giving yourself special waivers on shirking the work you don't like sets a REALLY bad example.
- Don't hurt the schedule. If you find the schedule slipping because your work isn't getting done, fire yourself and give the work to a regular individual contributor.
- My general heuristic (if I'm really up to speed on the tech) is that I take something that is between medium and medium-low on the priority scale. I leave the glory to my best individual contributors and take something that is meaningul but low enough on the priority scale that I can see the schedule slip well before it becomes an issue.
Be true to yourself
Not everyone loves being a leader. It sounds like you've been very happy not being a leader - so you know at least one career path works for you. Give this opportunity a shot, but be true to yourself. If after 6 months of leading, you find that the only true joy at work comes from having that time by yourself to do individual contributor work, and you know you're doing more than you really have time for because it gives you such joy - then have a frank discussion with your management.
You don't have to like it - management work and being a mentor and a senior individual contributor are very different.
Give it an honest shot, but in the end, a desperately unhappy manager is worse for a team than a new manager, or a manager with weaker technical skills but strong enough people skills.
answered May 6 '13 at 21:14
bethlakshmi
70.4k4136277
edited Jun 14 '13 at 19:46
answered May 6 '13 at 21:14
bethlakshmi
70.4k4136277
answered May 6 '13 at 21:14
bethlakshmi
70.4k4136277
answered May 6 '13 at 21:14
bethlakshmi
70.4k4136277
70.4k4136277
One of those answers I wish I could upvote more than once. In a similar boat to the OP, and finding it quite hard to adjust.
– shambulator
May 7 '13 at 8:47
One point missed. Delegation is about growing the skills of your team. So do not delegate work just because you don't like doing it, or if it tedious.
– Simon O'Doherty
Jun 13 '13 at 18:52
I'll add that.. but with a spin... (see edit)
– bethlakshmi
Jun 14 '13 at 19:39
Added Pet Projects as a section - but I disagree about not delegating just because something is tedious - if I have to the same thing 100 times a week, and there's no judgement call involved - it will be tedious. Me doing it 100 times vs. every man on a 10 man team doing it 10 times, is a better division of labor, no matter how boring.
– bethlakshmi
Jun 14 '13 at 19:47
add a comment |Â
One of those answers I wish I could upvote more than once. In a similar boat to the OP, and finding it quite hard to adjust.
– shambulator
May 7 '13 at 8:47
One point missed. Delegation is about growing the skills of your team. So do not delegate work just because you don't like doing it, or if it tedious.
– Simon O'Doherty
Jun 13 '13 at 18:52
I'll add that.. but with a spin... (see edit)
– bethlakshmi
Jun 14 '13 at 19:39
Added Pet Projects as a section - but I disagree about not delegating just because something is tedious - if I have to the same thing 100 times a week, and there's no judgement call involved - it will be tedious. Me doing it 100 times vs. every man on a 10 man team doing it 10 times, is a better division of labor, no matter how boring.
– bethlakshmi
Jun 14 '13 at 19:47
One of those answers I wish I could upvote more than once. In a similar boat to the OP, and finding it quite hard to adjust.
– shambulator
May 7 '13 at 8:47
One of those answers I wish I could upvote more than once. In a similar boat to the OP, and finding it quite hard to adjust.
– shambulator
May 7 '13 at 8:47
One point missed. Delegation is about growing the skills of your team. So do not delegate work just because you don't like doing it, or if it tedious.
– Simon O'Doherty
Jun 13 '13 at 18:52
One point missed. Delegation is about growing the skills of your team. So do not delegate work just because you don't like doing it, or if it tedious.
– Simon O'Doherty
Jun 13 '13 at 18:52
I'll add that.. but with a spin... (see edit)
– bethlakshmi
Jun 14 '13 at 19:39
I'll add that.. but with a spin... (see edit)
– bethlakshmi
Jun 14 '13 at 19:39
Added Pet Projects as a section - but I disagree about not delegating just because something is tedious - if I have to the same thing 100 times a week, and there's no judgement call involved - it will be tedious. Me doing it 100 times vs. every man on a 10 man team doing it 10 times, is a better division of labor, no matter how boring.
– bethlakshmi
Jun 14 '13 at 19:47
Added Pet Projects as a section - but I disagree about not delegating just because something is tedious - if I have to the same thing 100 times a week, and there's no judgement call involved - it will be tedious. Me doing it 100 times vs. every man on a 10 man team doing it 10 times, is a better division of labor, no matter how boring.
– bethlakshmi
Jun 14 '13 at 19:47
add a comment |Â
up vote
3
down vote
I think that effectively delegating work comes with experience. Don't be afraid about the new responsibilities.
Since you are a good team player, you might know strengths and weaknesses (in terms of work) of your team members. You can divide the projects into tasks and discuss with your team members probably first 1:1 for allocating tasks. During 1:1 discussions, you can convey positively why you would like to allocate a particular task to the team member. Clarify his/her questions. Once all the members agree upon their tasks you can summarize this in a team meeting.
Be positive and brave. Initially you might not be very effective, but gradually you will be good and comfortable with the new responsibilities.
answered May 6 '13 at 17:31
samarasa
1,90621430
add a comment |Â
up vote
3
down vote
I think that effectively delegating work comes with experience. Don't be afraid about the new responsibilities.
Since you are a good team player, you might know strengths and weaknesses (in terms of work) of your team members. You can divide the projects into tasks and discuss with your team members probably first 1:1 for allocating tasks. During 1:1 discussions, you can convey positively why you would like to allocate a particular task to the team member. Clarify his/her questions. Once all the members agree upon their tasks you can summarize this in a team meeting.
Be positive and brave. Initially you might not be very effective, but gradually you will be good and comfortable with the new responsibilities.
answered May 6 '13 at 17:31
samarasa
1,90621430
add a comment |Â
up vote
3
down vote
up vote
3
down vote
I think that effectively delegating work comes with experience. Don't be afraid about the new responsibilities.
Since you are a good team player, you might know strengths and weaknesses (in terms of work) of your team members. You can divide the projects into tasks and discuss with your team members probably first 1:1 for allocating tasks. During 1:1 discussions, you can convey positively why you would like to allocate a particular task to the team member. Clarify his/her questions. Once all the members agree upon their tasks you can summarize this in a team meeting.
Be positive and brave. Initially you might not be very effective, but gradually you will be good and comfortable with the new responsibilities.
answered May 6 '13 at 17:31
samarasa
1,90621430
I think that effectively delegating work comes with experience. Don't be afraid about the new responsibilities.
Since you are a good team player, you might know strengths and weaknesses (in terms of work) of your team members. You can divide the projects into tasks and discuss with your team members probably first 1:1 for allocating tasks. During 1:1 discussions, you can convey positively why you would like to allocate a particular task to the team member. Clarify his/her questions. Once all the members agree upon their tasks you can summarize this in a team meeting.
Be positive and brave. Initially you might not be very effective, but gradually you will be good and comfortable with the new responsibilities.
answered May 6 '13 at 17:31
samarasa
1,90621430
edited Jun 13 '13 at 3:27
answered May 6 '13 at 17:31
samarasa
1,90621430
answered May 6 '13 at 17:31
samarasa
1,90621430
answered May 6 '13 at 17:31
samarasa
1,90621430
1,90621430
add a comment |Â
add a comment |Â
up vote
2
down vote
Review your work from your previous supervisor's and possibly user's perspectives. You may be a little hard on yourself concerning the "perfectionist" claim. Having high standards is a good thing. It only becomes a problem if it prevents you from getting projects done one time and to the client's satisfaction. If this is a problem, your demanding that the other programmers commit the same mistakes is going to compound the problem.
When you are the manager, try to establish standards for practices and procedures. Consider dividing this up, so different team members can have a voice in this processs. If everyone agrees on the level of test coverage, code review or documentation, it's up to you to hold them to their own levels. You'd be surprise that some of them may come up with something more stringent than you would.
As the team leader, you're also going to have to represent your team to the other management. Of course you'll still have to continue coding, but make sure you take the time and put in the effort to support your team from the outside. They may request different hours because of the nature of their work. Can you make sure everyone knows your team is not slacking off? Will you have the same level of "perfectionism" when your team wants you to ask for faster workstations, extra testing servers or the support department thinks you whould write all the training documents?
Focus on getting things done on time, budget and user satisfaction and everyone will be happier. Your standards should contribute to this and not prevent it.
add a comment |Â
up vote
2
down vote
Review your work from your previous supervisor's and possibly user's perspectives. You may be a little hard on yourself concerning the "perfectionist" claim. Having high standards is a good thing. It only becomes a problem if it prevents you from getting projects done one time and to the client's satisfaction. If this is a problem, your demanding that the other programmers commit the same mistakes is going to compound the problem.
When you are the manager, try to establish standards for practices and procedures. Consider dividing this up, so different team members can have a voice in this processs. If everyone agrees on the level of test coverage, code review or documentation, it's up to you to hold them to their own levels. You'd be surprise that some of them may come up with something more stringent than you would.
As the team leader, you're also going to have to represent your team to the other management. Of course you'll still have to continue coding, but make sure you take the time and put in the effort to support your team from the outside. They may request different hours because of the nature of their work. Can you make sure everyone knows your team is not slacking off? Will you have the same level of "perfectionism" when your team wants you to ask for faster workstations, extra testing servers or the support department thinks you whould write all the training documents?
Focus on getting things done on time, budget and user satisfaction and everyone will be happier. Your standards should contribute to this and not prevent it.
add a comment |Â
up vote
2
down vote
up vote
2
down vote
Review your work from your previous supervisor's and possibly user's perspectives. You may be a little hard on yourself concerning the "perfectionist" claim. Having high standards is a good thing. It only becomes a problem if it prevents you from getting projects done one time and to the client's satisfaction. If this is a problem, your demanding that the other programmers commit the same mistakes is going to compound the problem.
When you are the manager, try to establish standards for practices and procedures. Consider dividing this up, so different team members can have a voice in this processs. If everyone agrees on the level of test coverage, code review or documentation, it's up to you to hold them to their own levels. You'd be surprise that some of them may come up with something more stringent than you would.
As the team leader, you're also going to have to represent your team to the other management. Of course you'll still have to continue coding, but make sure you take the time and put in the effort to support your team from the outside. They may request different hours because of the nature of their work. Can you make sure everyone knows your team is not slacking off? Will you have the same level of "perfectionism" when your team wants you to ask for faster workstations, extra testing servers or the support department thinks you whould write all the training documents?
Focus on getting things done on time, budget and user satisfaction and everyone will be happier. Your standards should contribute to this and not prevent it.
Review your work from your previous supervisor's and possibly user's perspectives. You may be a little hard on yourself concerning the "perfectionist" claim. Having high standards is a good thing. It only becomes a problem if it prevents you from getting projects done one time and to the client's satisfaction. If this is a problem, your demanding that the other programmers commit the same mistakes is going to compound the problem.
When you are the manager, try to establish standards for practices and procedures. Consider dividing this up, so different team members can have a voice in this processs. If everyone agrees on the level of test coverage, code review or documentation, it's up to you to hold them to their own levels. You'd be surprise that some of them may come up with something more stringent than you would.
As the team leader, you're also going to have to represent your team to the other management. Of course you'll still have to continue coding, but make sure you take the time and put in the effort to support your team from the outside. They may request different hours because of the nature of their work. Can you make sure everyone knows your team is not slacking off? Will you have the same level of "perfectionism" when your team wants you to ask for faster workstations, extra testing servers or the support department thinks you whould write all the training documents?
Focus on getting things done on time, budget and user satisfaction and everyone will be happier. Your standards should contribute to this and not prevent it.
answered May 6 '13 at 20:07
user8365
add a comment |Â
add a comment |Â
up vote
1
down vote
Firstly, congratulations with the trust your company has put in you. Please take the time to let the compliment sink in.
Next, I think it is important to find someone to mentor you, someone with much more experience. Your current manager would be a prime candidate. You can set up regular meetings with him, say half an hour a week. Alternatively, you could schedule meetings as you go, but this carries the risk that the meetings will be skipped due to deadlines and such. In these meetings you can share the issues you are facing, and talk about how you go about being a team lead. The more experienced person can provide feedback, transferring precious experience form him/her to you. I think this kind of mentoring is definitely worth the time. Avoiding a big pitfall will save time in a project, making up for your 'lost' time talking to your manager. Also, these meetings will increase your confidence, making you more effective at your job.
Learning this new leadership skill is going to take time, just as learning a new programming language would. Good luck!
answered May 6 '13 at 17:32
Paul Hiemstra
3,8451621
add a comment |Â
up vote
1
down vote
Firstly, congratulations with the trust your company has put in you. Please take the time to let the compliment sink in.
Next, I think it is important to find someone to mentor you, someone with much more experience. Your current manager would be a prime candidate. You can set up regular meetings with him, say half an hour a week. Alternatively, you could schedule meetings as you go, but this carries the risk that the meetings will be skipped due to deadlines and such. In these meetings you can share the issues you are facing, and talk about how you go about being a team lead. The more experienced person can provide feedback, transferring precious experience form him/her to you. I think this kind of mentoring is definitely worth the time. Avoiding a big pitfall will save time in a project, making up for your 'lost' time talking to your manager. Also, these meetings will increase your confidence, making you more effective at your job.
Learning this new leadership skill is going to take time, just as learning a new programming language would. Good luck!
answered May 6 '13 at 17:32
Paul Hiemstra
3,8451621
add a comment |Â
up vote
1
down vote
up vote
1
down vote
Firstly, congratulations with the trust your company has put in you. Please take the time to let the compliment sink in.
Next, I think it is important to find someone to mentor you, someone with much more experience. Your current manager would be a prime candidate. You can set up regular meetings with him, say half an hour a week. Alternatively, you could schedule meetings as you go, but this carries the risk that the meetings will be skipped due to deadlines and such. In these meetings you can share the issues you are facing, and talk about how you go about being a team lead. The more experienced person can provide feedback, transferring precious experience form him/her to you. I think this kind of mentoring is definitely worth the time. Avoiding a big pitfall will save time in a project, making up for your 'lost' time talking to your manager. Also, these meetings will increase your confidence, making you more effective at your job.
Learning this new leadership skill is going to take time, just as learning a new programming language would. Good luck!
answered May 6 '13 at 17:32
Paul Hiemstra
3,8451621
Firstly, congratulations with the trust your company has put in you. Please take the time to let the compliment sink in.
Next, I think it is important to find someone to mentor you, someone with much more experience. Your current manager would be a prime candidate. You can set up regular meetings with him, say half an hour a week. Alternatively, you could schedule meetings as you go, but this carries the risk that the meetings will be skipped due to deadlines and such. In these meetings you can share the issues you are facing, and talk about how you go about being a team lead. The more experienced person can provide feedback, transferring precious experience form him/her to you. I think this kind of mentoring is definitely worth the time. Avoiding a big pitfall will save time in a project, making up for your 'lost' time talking to your manager. Also, these meetings will increase your confidence, making you more effective at your job.
Learning this new leadership skill is going to take time, just as learning a new programming language would. Good luck!
answered May 6 '13 at 17:32
Paul Hiemstra
3,8451621
answered May 6 '13 at 17:32
Paul Hiemstra
3,8451621
answered May 6 '13 at 17:32
Paul Hiemstra
3,8451621
answered May 6 '13 at 17:32
Paul Hiemstra
3,8451621
3,8451621
add a comment |Â
add a comment |Â
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fworkplace.stackexchange.com%2fquestions%2f11595%2fhow-do-i-become-better-at-delegating-work%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
3
The question is: are you applying the most stringent criteria to your own work? While it doesn't solve all the problems, it helps to leverage moral authority... Please remember that people do not work for you - they work for the company.
– Deer Hunter
May 6 '13 at 17:59