Interesting chapter in the book I'm currently reading (By the way, great book - 1st Break all the rules). You should avoid saying the lines "I think this is a crazy idea, but the corporate insists". What you've just done there is demotivate everyone around you. I've done this plenty of times on my current project. I hear and see something reasonably mad and I report it back to the team and after a while you end up doing two things. One you foster a "Us vs Them" attitude which is never healthy. Secondly you give people excuses to be less than the best they can be and reduces the overall effectiveness of the organization.
So I'm thinking of doing the following:
1. If someone is doing something stupid that doesn't affect my team, just don't report it unless someone asks.
2. If someone asks something stupid of your team, make sure you have all the information and go to the team with it. If the team thinks its stupid, don't make promises of trying to change it.
3. If they insist on it, get the reasoning. It's very rare the reasoning is just plain mad, it is usually a compromise. Find a middle ground and justify the decision to your team as to why you accepted, rather than you didn't have a choice. People are generally mature enough to handle this. By passing the buck, you reduce the trust in the upper organization and you reduce the team's trust in you as a manager.
(This isn't the most well thought out blog post, but I've had a number of people complain I haven't updated in a while, so I figured why not ease myself back into it.)
Wednesday, July 23, 2008
Thursday, July 17, 2008
WYD2008 Super Thursday
Today was 'Super-Thursday' of World Youth Day (week) in Sydney and it was an amazing spectacle. The Sydney CBD was packed with thousands of people attired in the firey orange and yellow WYD 2008 signature outfits. Flags of numerous nations were proudly on display as people marched onto Barangaroo. Unfortunately, since I wasn't a registered pilgrim, I couldn't join them in the main area of Barangaroo. Luckily I did find a great vantage point from where I could observe all of Barangaroo. And boy were there a lot of them. The entire ex-shipping yard was covered with people, with estimates of around 130,000 pilgrims packed into that area.
Even though hordes of people were being herded like cattle, there was lots of singing and dancing in the crowd. The "Free Hugs" girls and guys in my photos really captured the feel of the event in my mind. The entire feeling of giving love for the sake of giving without caring about race, gender or age. The concept is not at all new, but it was lovely to see it at this event.
I was expecting to see some activists complaining about condom use, abortion or other controversial religious decisions. Yet I didn't see even one and I was all over the place from Barangaroo to the Domain. I was originally annoyed that these folk would try to ruin the event (though they do have the right to free speech), but after being there, I would feel sorry for any person who tried to push that kind of ideology against the crowd that was there tonight. They would have been politely ignored at best or ridiculed by the more militant religious ones. You'd have to be quite ballsy to try it.
Of course the Pope did arrive and that was pretty cool. He seems like a nice guy and maybe over time people will grow to respect him the same way we did JP2. The motorcade was funny since they drove past at around 40km/h so it is very quick. Despite one guy going, 'wow, was that it?', in general the crowd was elated and had that 'Wow, I saw the Pope!' excitment in their eyes.
Some come for the celebrity, some come for faith, some come to find meaning and others just to be part of the event. Organized religion may be dying, but its not dead yet.
Even though hordes of people were being herded like cattle, there was lots of singing and dancing in the crowd. The "Free Hugs" girls and guys in my photos really captured the feel of the event in my mind. The entire feeling of giving love for the sake of giving without caring about race, gender or age. The concept is not at all new, but it was lovely to see it at this event.
I was expecting to see some activists complaining about condom use, abortion or other controversial religious decisions. Yet I didn't see even one and I was all over the place from Barangaroo to the Domain. I was originally annoyed that these folk would try to ruin the event (though they do have the right to free speech), but after being there, I would feel sorry for any person who tried to push that kind of ideology against the crowd that was there tonight. They would have been politely ignored at best or ridiculed by the more militant religious ones. You'd have to be quite ballsy to try it.
Of course the Pope did arrive and that was pretty cool. He seems like a nice guy and maybe over time people will grow to respect him the same way we did JP2. The motorcade was funny since they drove past at around 40km/h so it is very quick. Despite one guy going, 'wow, was that it?', in general the crowd was elated and had that 'Wow, I saw the Pope!' excitment in their eyes.
Some come for the celebrity, some come for faith, some come to find meaning and others just to be part of the event. Organized religion may be dying, but its not dead yet.
Monday, July 14, 2008
Slipping task management.
They say someone who is successful is someone who has screwed up a lot and learnt from it. So I'm hoping this project will help me to do that. There was a project manager at my work who was ruthless (in a good way) at tracking tasks that were slipping. Those who worked with her found it annoying in some sense, but everyone acknowledged she also provided perspective and butt protection. At some point, people stepped back and reassessed where they were with the task and re-planned. This is good for the developer, the project and the project manager.
So say you have a task that is slipping by a developer. You need to analyze the task and determine what kind of slippage it is. Is it slipping because its not clear what work it is. Maybe you need to break up the task into more manageable bits.
If it is dangerously slipping you might need to not deliver the entire thing. Understand what is the real dependency or feature that has to be delivered. Can you get away with perhaps releasing the interfaces even if there isn't an implementation. Can you deliver where the configuration is via a configuration file even if there isn't a GUI component requirement. It is a case of being creative and understanding your requirements.
If a person has missed a deadline several times, then you need to keep that in mind when dealing with them again. They could be bad at estimation, or their loading needs to be really low. Note you may have an opportunity for improvement with a person if their productivity is really low*.
When even that fails, you need to start micro-managing. This is where you break the task down with them, ask them daily how they are going with the task, and tracking very carefully. Its funny how quickly a task that is carefully scrutinized ends up being delivered.
Going back to my earlier point on idiosyncrasies of each team, it is really important to understand the motivations of each team member. I've heard people say 'everyone is out to do a good job and spend the right amount of time on it', and this is not always true. As a general rule, it is true, but you need to understand both extremes in the project too. There is the person who will work 12 hour days, rip through tasks, burn out and quit. You also have the 9-5 institutionalized person is waiting for their LSL to kick in and say things will be done 'when its done'. Whilst you can help, often those folk need to sort out their priorities in life outside of the project. You need to realize both are a risk to the project and the tasks and allocate accordingly.
*The funky thing about matrix organizations is that the closest person to the employee in question can't suggest those improvements. They need to tell the coach instead. Unnecessary layer of communication there.
So say you have a task that is slipping by a developer. You need to analyze the task and determine what kind of slippage it is. Is it slipping because its not clear what work it is. Maybe you need to break up the task into more manageable bits.
If it is dangerously slipping you might need to not deliver the entire thing. Understand what is the real dependency or feature that has to be delivered. Can you get away with perhaps releasing the interfaces even if there isn't an implementation. Can you deliver where the configuration is via a configuration file even if there isn't a GUI component requirement. It is a case of being creative and understanding your requirements.
If a person has missed a deadline several times, then you need to keep that in mind when dealing with them again. They could be bad at estimation, or their loading needs to be really low. Note you may have an opportunity for improvement with a person if their productivity is really low*.
When even that fails, you need to start micro-managing. This is where you break the task down with them, ask them daily how they are going with the task, and tracking very carefully. Its funny how quickly a task that is carefully scrutinized ends up being delivered.
Going back to my earlier point on idiosyncrasies of each team, it is really important to understand the motivations of each team member. I've heard people say 'everyone is out to do a good job and spend the right amount of time on it', and this is not always true. As a general rule, it is true, but you need to understand both extremes in the project too. There is the person who will work 12 hour days, rip through tasks, burn out and quit. You also have the 9-5 institutionalized person is waiting for their LSL to kick in and say things will be done 'when its done'. Whilst you can help, often those folk need to sort out their priorities in life outside of the project. You need to realize both are a risk to the project and the tasks and allocate accordingly.
*The funky thing about matrix organizations is that the closest person to the employee in question can't suggest those improvements. They need to tell the coach instead. Unnecessary layer of communication there.
Tuesday, July 08, 2008
Workhorses and Show Ponies
It has been an painful week. There has been lots of dealing with people a lot more senior than I am over screw-ups that I had very little control over. In addition I got my first chewing out by a tech manager for letting the schedule slip, but ironically (or maybe not so ironically, for you learn more from your mistakes then from praises) it was the most beneficial coaching session I've had for a while.
The project has slipped for a number of reasons, but one of the main reasons is due to the way I allocated tasks to people. The difference between a good project manager and a great project manager is that a great PM can work with the idiosyncracies of their team. And within each team are what my tech manager called 'Show Ponies' and 'Workhorses'. And this is how he explained how they work.
Workhorses are easy enough to understand. They are the people who do the hard painful labour. They will sow the fields, write the big modules of your code, put up your walls. They rarely complain, they don't make excuses for being late and they are happy with just doing the work. They are the backbone of your team and losing too many of them will break the project.
Show ponies are the ones that prance from one activity to another. They like to know more stuff and strut their stuff to others. They are excellent for communicating with others, solving puzzles, creating designs but you wouldn't use them for heavy lifting, because its they don't roll like that. They are smart enough to do the work, but they aren't motivated enough by grunt labour to do it. Without them, you won't win any prizes and you probably won't innovate, but you should be able to get the project done regardless.
So when composing a group, you do need a good mix of the two if its possible, though it isn't very often that you get a choice about who you get to pick. Grads make for excellent workhorses, which is why any growing business needs a reasonable number of them. They need to be paired with good senior staff. This is because often senior staff don't believe in the organization, but they do believe in looking after their young proteges. Senior staff are more difficult to split into work horses and show ponies as they seem to eveningly split into both types and often show characteristics of both.
So what I did was allocate work the wrong way around and now I've screwed my schedule and made the other team member very annoyed. Ideally I should have allocated smaller tasks to the pony and made them more free for design/reviews and so on, and given the grunt work to the work horse which would mean it would be closer to being done on time.
It is kind of disconcerting seeing this kind of comparison of your peers to farm animals, being made by a manager, but it doesn't make it wrong, and this kind of simplification helps to guide future decision making.
The project has slipped for a number of reasons, but one of the main reasons is due to the way I allocated tasks to people. The difference between a good project manager and a great project manager is that a great PM can work with the idiosyncracies of their team. And within each team are what my tech manager called 'Show Ponies' and 'Workhorses'. And this is how he explained how they work.
Workhorses are easy enough to understand. They are the people who do the hard painful labour. They will sow the fields, write the big modules of your code, put up your walls. They rarely complain, they don't make excuses for being late and they are happy with just doing the work. They are the backbone of your team and losing too many of them will break the project.
Show ponies are the ones that prance from one activity to another. They like to know more stuff and strut their stuff to others. They are excellent for communicating with others, solving puzzles, creating designs but you wouldn't use them for heavy lifting, because its they don't roll like that. They are smart enough to do the work, but they aren't motivated enough by grunt labour to do it. Without them, you won't win any prizes and you probably won't innovate, but you should be able to get the project done regardless.
So when composing a group, you do need a good mix of the two if its possible, though it isn't very often that you get a choice about who you get to pick. Grads make for excellent workhorses, which is why any growing business needs a reasonable number of them. They need to be paired with good senior staff. This is because often senior staff don't believe in the organization, but they do believe in looking after their young proteges. Senior staff are more difficult to split into work horses and show ponies as they seem to eveningly split into both types and often show characteristics of both.
So what I did was allocate work the wrong way around and now I've screwed my schedule and made the other team member very annoyed. Ideally I should have allocated smaller tasks to the pony and made them more free for design/reviews and so on, and given the grunt work to the work horse which would mean it would be closer to being done on time.
It is kind of disconcerting seeing this kind of comparison of your peers to farm animals, being made by a manager, but it doesn't make it wrong, and this kind of simplification helps to guide future decision making.
Subscribe to:
Posts (Atom)