Sunday, January 10, 2010
Lets talk about Diamonds
First things first (though ten days late already) - Wish you a happy new year 2010 and wonderful decade ahead!
I just finished reading "Discover the diamond in you" by Arindam Chaudhuri. It is a fantastic book. Arindam takes the diamond to be a metaphor for us and then explains what things would make us i.e. the diamond in us. He talks about the 4 Cs of a diamond [carrat, cut, color, clarity] and then maps various key attributes for these. I would strongly recommend reading the book.
I just finished reading "Discover the diamond in you" by Arindam Chaudhuri. It is a fantastic book. Arindam takes the diamond to be a metaphor for us and then explains what things would make us i.e. the diamond in us. He talks about the 4 Cs of a diamond [carrat, cut, color, clarity] and then maps various key attributes for these. I would strongly recommend reading the book.
Labels: management, self help
Saturday, February 11, 2006
Software engineering lessons learnt - Microsoft Whidbey release.
Interesting (recorded) session on How Microsoft Does Software Engineering Or, "How We Make the Sausage: Lessons From the Factory Floor." by Russ Ryan. Russ is serving as Product Unit Manager (PUM) at Developer Division Customer Product Life-cycle Experience Team.
Russ talks about experiences and lesson learnt during the Whidbey release. He explains that milestone planning is critical and how milestone cycles should not be too small or long....they need to be just right. At MS milestones are around 8-9 weeks. MQ is the quality milestone where you "get clean and stay clean" by clearing your bug debt accumulated over previous milestones. He mentions that "moving bugs forward is not a good idea - carrying the bug debt is expensive".
Some interesting things covered are:
- Dog food - Ask teams to consume software developed by other team prior to release itself. For example the tools development team will ask other team to use newer tools prior to release.
- Build process - There is a separate build team (24 hours) and concept of a "Build Facilitation Developer" (BFD). A BFD is a team member who is on call to provide HOT fixes for any build breaks.
- Large projects "coast in" as opposed to ending suddenly.
- Concept of "end game" mode. War teams are comprised of team members with prior ship experience.
- "Tell mode" and "Ask mode". In "Tell mode" checkins are communicated to the war teams. In "Ask mode" checkins have to be approved by the war teams.
Finally the most important things I think Russ mentioned:
"Once you checkin the code, you are hostage to the code"
You can find the blog here: DDCPX Team Blog
Russ talks about experiences and lesson learnt during the Whidbey release. He explains that milestone planning is critical and how milestone cycles should not be too small or long....they need to be just right. At MS milestones are around 8-9 weeks. MQ is the quality milestone where you "get clean and stay clean" by clearing your bug debt accumulated over previous milestones. He mentions that "moving bugs forward is not a good idea - carrying the bug debt is expensive".
Some interesting things covered are:
- Dog food - Ask teams to consume software developed by other team prior to release itself. For example the tools development team will ask other team to use newer tools prior to release.
- Build process - There is a separate build team (24 hours) and concept of a "Build Facilitation Developer" (BFD). A BFD is a team member who is on call to provide HOT fixes for any build breaks.
- Large projects "coast in" as opposed to ending suddenly.
- Concept of "end game" mode. War teams are comprised of team members with prior ship experience.
- "Tell mode" and "Ask mode". In "Tell mode" checkins are communicated to the war teams. In "Ask mode" checkins have to be approved by the war teams.
Finally the most important things I think Russ mentioned:
"Once you checkin the code, you are hostage to the code"
You can find the blog here: DDCPX Team Blog
Labels: management, software engineering
Saturday, January 28, 2006
Hiring the right technical people.
Now that's a challenge and that is what I am going to talk about in this post.
Adam Scott in his book "The Dilbert Future" gives us a fair idea about what the future holds in store. He talks about "induh-viduals" i.e. stupid individuals. I think we are seeing more of these guys during our recruitment drive already, looks like the future is not really far away :)
Companies invest a fair amount of money in the hiring process. This involves preparing test papers, visiting places for hiring, identifying folks in the organization to help with the hiring process etc. There is a lot of hard work and pain, that goes in this process. Yet, you endup with the wrong set of people being hired in the organization.
Sometimes I wonder if the educational institutes are contributing towards the "Duhh" factor. The focus these days is on learning programming languages than more fundamental things like deep understanding of data structures or algorithms. There is a basic lack of analytical skills these days. As more educational institutes stress on teaching "cutting edge technology" [believe me there is no such thing], the result is more "induh-viduals".
The other day I asked a candidate to design a set of classes for linked list data structure and I found the candidate struggling with my rather trivial problem. I think folks these days are apprehensive towards these subjects, like "data structures", "algorithm design". To them, these seem as antique as "cobol" or "assembly" language.
I think part of the problem is due to less curiosity that candidates posses these days. They are not interested in knowing "what goes on under the hood". For example, most Java programmers would not know "when" and by "how much" does the vector grow. If I ask this, then the answer I would get these days is that "Java language designers would have done it in an efficient manner" :). Sometimes I wonder if they know the difference between "effective" and "efficient".
If you manage to mis-hire such an induh-vidual on your team, chances are that eventually good people on your team will move on. The simple reason is that the new induh-vidual turns out to be a liability on good people on your team, due to poor independent execution skills.
If in doubt, do not hire.
Please read what Joel thinks on this as well:
http://www.joelonsoftware.com/articles/ThePerilsofJavaSchools.html
More later.....
- Paresh.
Adam Scott in his book "The Dilbert Future" gives us a fair idea about what the future holds in store. He talks about "induh-viduals" i.e. stupid individuals. I think we are seeing more of these guys during our recruitment drive already, looks like the future is not really far away :)
Companies invest a fair amount of money in the hiring process. This involves preparing test papers, visiting places for hiring, identifying folks in the organization to help with the hiring process etc. There is a lot of hard work and pain, that goes in this process. Yet, you endup with the wrong set of people being hired in the organization.
Sometimes I wonder if the educational institutes are contributing towards the "Duhh" factor. The focus these days is on learning programming languages than more fundamental things like deep understanding of data structures or algorithms. There is a basic lack of analytical skills these days. As more educational institutes stress on teaching "cutting edge technology" [believe me there is no such thing], the result is more "induh-viduals".
The other day I asked a candidate to design a set of classes for linked list data structure and I found the candidate struggling with my rather trivial problem. I think folks these days are apprehensive towards these subjects, like "data structures", "algorithm design". To them, these seem as antique as "cobol" or "assembly" language.
I think part of the problem is due to less curiosity that candidates posses these days. They are not interested in knowing "what goes on under the hood". For example, most Java programmers would not know "when" and by "how much" does the vector grow. If I ask this, then the answer I would get these days is that "Java language designers would have done it in an efficient manner" :). Sometimes I wonder if they know the difference between "effective" and "efficient".
If you manage to mis-hire such an induh-vidual on your team, chances are that eventually good people on your team will move on. The simple reason is that the new induh-vidual turns out to be a liability on good people on your team, due to poor independent execution skills.
If in doubt, do not hire.
Please read what Joel thinks on this as well:
http://www.joelonsoftware.com/articles/ThePerilsofJavaSchools.html
More later.....
- Paresh.
Labels: hiring, management
Saturday, August 07, 2004
Leadership!
What does it take to be a leader?
Well, I don't know, but I know a good leader when I see one. Lately I have been reading the book "Leadership and the 1-minute manager". It is quite an interesting book. Now I find it easier to correlate some of the actions my manager took and the interacting style to leadership skills.
Also, now I associate the way I interact with various people with leadership skills. The author mentions that "different people should be treated differently". Now I am sure that we have all been taught to treat people "equally" in the workplace.
But different people are different! For example, consider the new hire (fresh out of college) that started on your project last week. Can you treat the new hire same as a 2+ year experienced person on your project. Of course, not. I am sure all of us will agree that the new hire will need some hand-holding and grooming before s/he becomes a productive team member.
The book talks about following leadership styles:
1. Directing.
2. Coaching.
3. Support.
4. Delegating.
As you progress from style 1 to 4 with a person, the person has been transformed in to a more idependent, responsible, contributing team member.
To measure the performance of a team member one needs to track 2 Cs i.e.:
1. Commitment.
2. Competency.
You could have a person who has lost motivation and is no longer committed but is competent. Then the person needs "support". But the new hire we talked about above would need "coaching" to help build technical skills (be competent).
In our previous meeting in the company about the appraisal process, the speaker talked about competency in two areas:
1. Technical skills.
2. Soft skills (like communication etc.)
Need to read further ...mature to a better leader.
Well, I don't know, but I know a good leader when I see one. Lately I have been reading the book "Leadership and the 1-minute manager". It is quite an interesting book. Now I find it easier to correlate some of the actions my manager took and the interacting style to leadership skills.
Also, now I associate the way I interact with various people with leadership skills. The author mentions that "different people should be treated differently". Now I am sure that we have all been taught to treat people "equally" in the workplace.
But different people are different! For example, consider the new hire (fresh out of college) that started on your project last week. Can you treat the new hire same as a 2+ year experienced person on your project. Of course, not. I am sure all of us will agree that the new hire will need some hand-holding and grooming before s/he becomes a productive team member.
The book talks about following leadership styles:
1. Directing.
2. Coaching.
3. Support.
4. Delegating.
As you progress from style 1 to 4 with a person, the person has been transformed in to a more idependent, responsible, contributing team member.
To measure the performance of a team member one needs to track 2 Cs i.e.:
1. Commitment.
2. Competency.
You could have a person who has lost motivation and is no longer committed but is competent. Then the person needs "support". But the new hire we talked about above would need "coaching" to help build technical skills (be competent).
In our previous meeting in the company about the appraisal process, the speaker talked about competency in two areas:
1. Technical skills.
2. Soft skills (like communication etc.)
Need to read further ...mature to a better leader.
Labels: management
Tuesday, June 08, 2004
Be observant and sensitive in the workplace...
It is really important for a manager to be observant and watchful. S/he should have an eye that captures relevant details from any situation.
I do not mean that the manager should do policing. Well, you might say that in some cases it is necessary/must. Yes, let me put it delicately that you need to "micro-manage". That reminds of a line from the book 'Good to great' from 'Jim Collins', if you need to micro-manage a person, you have made a hiring mistake.
Agreed, we all need to micro-manage at times. Steering back to my original point, it is important for the manager to be observant.
I do not mean that the manager should do policing. Well, you might say that in some cases it is necessary/must. Yes, let me put it delicately that you need to "micro-manage". That reminds of a line from the book 'Good to great' from 'Jim Collins', if you need to micro-manage a person, you have made a hiring mistake.
Agreed, we all need to micro-manage at times. Steering back to my original point, it is important for the manager to be observant.
Labels: management
