Moving to the next level of skill in a foreign language is challenging. Even when you have read, written, listened to and spoken a second language for years, it always seems difficult to be at home. At the least, that's how it is for me when it comes to English. Consider the translation of the following sentence from Urdu into English: "Meray paaon daba do."
I am totally lost here. It's not massage. It's more like kneading. But I am not sure how to say this, really.
There are many situations which somehow are not catered for in academic text and as soon as you come under a peculiar situation, you realize that you are out of vocabulary or you can't freely express what you want to say.
One site that can be of help when you are an intermediate level of English user and want to move forward is ESL Podcasts. Consider this podcast on "Being Generous and Stingy." I like the format and the various situations this guy comes up with.
Showing posts with label soft skills. Show all posts
Showing posts with label soft skills. Show all posts
Monday, August 24, 2009
Sunday, April 12, 2009
Job Titles in Software Development
What's beyond Software Engineer/ Developer and Senior Software Engineer/ Developer in your organization?
While searching for appropriate designations in a software development organization---not your typical outsourcing man-hour based company---I was wondering what could possibly be a "good title" for a person who looks after development of multiple products. While one can always come up with stuff like "VP Engineering," I was more interested in the lowest place in an org-chart where someone can manage development of multiple products. I, myself, could come up with only "Software Development Manager Product Line A" or "Group Development Manager Product Line B."
A quick search on the Internet led me to a slightly out-dated organizational chart of Microsoft. There are a few interesting things to observe:
On a closing note, my search also led me to cogmap.com, which has a sort-of-wiki of org charts of some famous organizations. There is always some fresh, interesting concept out there! Check this org-chart of Google.
While searching for appropriate designations in a software development organization---not your typical outsourcing man-hour based company---I was wondering what could possibly be a "good title" for a person who looks after development of multiple products. While one can always come up with stuff like "VP Engineering," I was more interested in the lowest place in an org-chart where someone can manage development of multiple products. I, myself, could come up with only "Software Development Manager Product Line A" or "Group Development Manager Product Line B."
A quick search on the Internet led me to a slightly out-dated organizational chart of Microsoft. There are a few interesting things to observe:
- The titles for managing development of multiple products in a single product line include CTO, Vice President, Director, General Manager and finally PUM (Product Unit Manager). I guess Product Unit Manager fits nicely to what I had in my mind.
- There are some high profile people who don't fit in the hierarchy and MS calls them "Distinguished Engineer"---interesting! That further strengthens the idea that a strong engineer does not equal a good manager; so you can promote the engineer while somehow not giving him a team.
On a closing note, my search also led me to cogmap.com, which has a sort-of-wiki of org charts of some famous organizations. There is always some fresh, interesting concept out there! Check this org-chart of Google.
Sunday, October 28, 2007
Stereotypes and Customer Facing in IT
James L. Adams in his book "Conceptual Blockbusting: A Guide to Better Ideas" identifies "stereotypical" blocks, and warns us to stay clear of them. I agree that we shouldn't categorize people based on their race, language, etc. However, there do exist stereotypes in human life, albeit in a different, positive manner.
A stand up comedian in a local village in Punjab is not much different from the people in this list, as far as the basic traits of the profession are concerned. Similarly, a soldier is a soldier no matter what his fighting style, and choice of weapons are. A good fighter is fearless, irrespective of whether he uses nunchucks or katana.
Lately, I have come across some stereotypes in customer facing -- customer as in someone who has to see your final work and point out areas that need improvement before he can accept the delivered product. The most notorious are perfectionists. As Joel Spolsky says ,
Remember, you always need to fix the critical issues. Sooner or later, you have to solve them. The more you procrastinate, the harder it will become to provide a remedy. But for non-critical issues, please read on for some great ideas:
Mavericks: The mavericks I have come across are imbalanced perfectionists. They give high priority to one facet of the project (that could be application response time, for example), while ignoring the trade offs (such as time to market, budgeting requirements, etc.) There is an easy way to handle maverick end-users: engage them in a different debate altogether. If they take out issues from your application response time, give them a network sniffer to play with and they will spend a lot of their time on this new toy without bugging you. Most of the time, if they are the end users, their job descriptions do not demand/ provide them with ample time to fulfill their techie desires.
Blabbering Businessmen: These will talk a lot about "their great ideas" with which your software will become the next big thing after Google. They will repeatedly tell you that without their "important" feedback your software was a piece of crap and you should be thankful to them for making it feature-rich. These guys, almost always, have no knowledge of software and provide feedback based on their domain knowledge only. I don't have any solution for except to come up with a very solid signed scope document to confront them with their "ideas" and reminding them that everything costs money and time. In the long run, engage them in some technical discussion --- hand them over an article on database design; discuss simple concepts like primary keys, and gradually they will come to appreciate the complexity of things you as a software developer are dealing with.
No-Clue Users: These don't have any clue of what they asked for during the requirements gathering phase, and they take an about turn on the requirements during UAT. Unfortunately, the phase where you recognize their style, it's already too late. The only precaution is to involve them very early using prototyping, and following at the least some guidelines of the agile methodologies.
A stand up comedian in a local village in Punjab is not much different from the people in this list, as far as the basic traits of the profession are concerned. Similarly, a soldier is a soldier no matter what his fighting style, and choice of weapons are. A good fighter is fearless, irrespective of whether he uses nunchucks or katana.
Lately, I have come across some stereotypes in customer facing -- customer as in someone who has to see your final work and point out areas that need improvement before he can accept the delivered product. The most notorious are perfectionists. As Joel Spolsky says ,
the question is not 'X yes or no?' rather 'Is X worth your time?'I have also come to appreciate the fact that with every piece of software waiting for customer acceptance (usually a phase termed as UAT), there are two types of issues: critical and non-critical. A critical issue is one which you wouldn't debate at all; you as a software developer would also understand the need for that. While for non-critical issues no matter how much the "end-user" would try to convince you of their importance, you would still feel that the end-user is just striving for "ultimate quality"---something which doesn't exist.
Remember, you always need to fix the critical issues. Sooner or later, you have to solve them. The more you procrastinate, the harder it will become to provide a remedy. But for non-critical issues, please read on for some great ideas:
Mavericks: The mavericks I have come across are imbalanced perfectionists. They give high priority to one facet of the project (that could be application response time, for example), while ignoring the trade offs (such as time to market, budgeting requirements, etc.) There is an easy way to handle maverick end-users: engage them in a different debate altogether. If they take out issues from your application response time, give them a network sniffer to play with and they will spend a lot of their time on this new toy without bugging you. Most of the time, if they are the end users, their job descriptions do not demand/ provide them with ample time to fulfill their techie desires.
Blabbering Businessmen: These will talk a lot about "their great ideas" with which your software will become the next big thing after Google. They will repeatedly tell you that without their "important" feedback your software was a piece of crap and you should be thankful to them for making it feature-rich. These guys, almost always, have no knowledge of software and provide feedback based on their domain knowledge only. I don't have any solution for except to come up with a very solid signed scope document to confront them with their "ideas" and reminding them that everything costs money and time. In the long run, engage them in some technical discussion --- hand them over an article on database design; discuss simple concepts like primary keys, and gradually they will come to appreciate the complexity of things you as a software developer are dealing with.
No-Clue Users: These don't have any clue of what they asked for during the requirements gathering phase, and they take an about turn on the requirements during UAT. Unfortunately, the phase where you recognize their style, it's already too late. The only precaution is to involve them very early using prototyping, and following at the least some guidelines of the agile methodologies.
Tuesday, October 16, 2007
Review: Everything is Negotiable
I am including book reviews on this blog. I read a lot but I never find people to share the joy with, and thus I forget almost as fast as I learn. I believe that by including book reviews, I'll attract some comments, which imply discussion and thus, better understanding for me.
Everything is Negotiable by Gavin Kennedy falls under the category of non-IT books that I occasionally pick up (and do not regret). The guy runs a company in UK which helps break deals and negotiate for you, apart from training your people to do better at deals.
The books starts off with a simple question:
Many people will tend to concede. That something is of little value to you, right? and the opponent is somebody overly demanding as well! Gavin Kennedy tends to disagree and he has sound reasons for that:
This remarkable opening is followed by around 24 chapters, which include various negotiating scenarios (not all of them provide insight, though). The book is around 350 pages lengthy, and available as paperback. Below is a content outline, with some of my comments:
Everything is Negotiable by Gavin Kennedy falls under the category of non-IT books that I occasionally pick up (and do not regret). The guy runs a company in UK which helps break deals and negotiate for you, apart from training your people to do better at deals.
The books starts off with a simple question:
Faced with a difficult opponent, it is better to concede something of little value in order to create goodwill. True or False?
Many people will tend to concede. That something is of little value to you, right? and the opponent is somebody overly demanding as well! Gavin Kennedy tends to disagree and he has sound reasons for that:
- Goodwill is a myth! Business is about offering what you have in exchange for what you want. Why is the other person bargaining for that something of little value?
- You are encouraging the behavior of your difficult opponent by conceding in the first deal. He/ she will become more and more unrealistic in future. On the other hand, you will have little ground to behave differently.
This remarkable opening is followed by around 24 chapters, which include various negotiating scenarios (not all of them provide insight, though). The book is around 350 pages lengthy, and available as paperback. Below is a content outline, with some of my comments:
- Of Owls, Foxes, Sheep and Donkeys
- Why you must revive long forgotten negotiating skills (learn from children!)
- The worst thing you can do to a negotiator (accept the first offer!)
- How not to get your room changed (don't just complain, negotiate a remedy!)
- Why seven "no's" are no way to get a "yes" (seven successive proposals!)
- The negotiator's most useful question (what if?)
- The Myth of Goodwill
- How to make them cut their prices (shock'em with your opening offer)
- Why ONO is a NO NO? (ONO = or nearest offer)
- How to handle difficult negotiators (don't let the intended damage to happen)
- Who has the power? (depends on who believes it to be with the other person)
- If you haven't got a principal, invent one! (my brother says you must not accept less than £615)
- There ain't no such thing as a fixed price!
- How to stop conceding?
- Don't change the price, change the package!
- All that glitters is not gold
- On being Russian-Fronted (hijacking countered by buying time -> makes them tired)
- How the hard bargainers make it hard to bargain (creating issues at the last moment --- when the real cost of moving away from the deal is too high for you)
- How addressing other people's interest gets them interested (what we want vs. why we want)
- The long distance negotiator (local hero going global)
Subscribe to:
Posts (Atom)