Thursday, October 13, 2005
Find and Replace...
Wish there was a 'Find and Replace...' command that worked on actual people. Such a command would have a complicated implementation though. Would it be O(N)? Errr... maybe.
Anyway, as you already know, currently I am switching employers. I am going from one great company (www.uvp.com) to another (www.ebay.com). [What makes UVP great? That's the topic of next post...] .
At UVP, I have sort of a jack-of-all-trades role. Depending on who you ask, I'm a different person at UVP:
-some people know me as a rookie pair of hands who helps test our software,
-some people know me as someone who answers questions about our software,
-some people know me as someone who recommends and installs computers for sales people,
-some people know me as someone who tries to introduce new relevant technologies in our software,
-some people know me as someone who writes 200 page manuals,
-some people know me as someone who takes the final build to production,
-some people know me as someone who is a meeting-monger and keeps arguing on what is better and what is not,
-some people know me as someone who worked late-night and weekends doing strange things and
-some other people know me as a "program/product/project manager" who is responsible for overall success of the package.
Whatever it is that they know, now they will have to replace me. That makes me think how different it is to replace a project-management role than replacing a hard-core technical role. It's not any more easy or hard, it is just different.
In a project-management role, you are actually replacing a "personality", as opposed to someone who knows C++,Java. From within the group or even from outside, it's hard to refer to a project-manager as "someone who does project management", the way it is easier to say "the developer or coder".
Maybe it is only my conceited opinion, but I atleast know that is the approach of upper-management. A person who is answerable (project-manager) is associated with a "personality", rather than someone who tools and tinkers (developers). So in this case they would say "we need to replace Soham" - not just the name, but someone who will do what Soham did and more. Had I been a developer, they would say "Let's find someone who knows how to code". This is especially true for smaller setups where there is more visibility than usual. Looking at the other way, they would say "I want someone who can answer questions the way Soham did (or did not)", but would rarely say "I want someone who codes the same way as Soham did (or did not)"
Why? This is because the role of a general project-manager is not as well-defined as the role of a developer/coder. It's hard to see the bounds of that role and responsibility. More you do, the better it is. You then become an interface to Management for overall details. And management is concerned more about their interface with code than the code itself. Hence, they are dealing with a "person" all the time, rather than "code".
So when you interview candidates for positions such as these, it is far more important to figure out how they will gel with the group, instead of how well they can code. A few things I've found are :
-An energetic person with consummate communication skills will fare much better than someone who knows just the technical details.
-Someone who has the guts to cover up for the team and even for the boss sometimes, and take responsibilities is the type of person you need.
-Someone who understands the application space and believes in the power of technology to solve problems is the type of person you want.
-Someone who doesn't shy away from looking into gory details is the type of person that is required.
-Someone who understands that there is no authority he has over anybody or anything, and the only way he can get work done is by the power of facts and presentation of facts, is a best fit for the position.
-Someone who has the patience of repeating the obvious over and over again, is what you are looking for.
I can go on and on and I am sure you can too. It's a constraint satisfaction problem with a twist - different constraints have to be satisfied at different times. So anybody up for desiging an O(N) algorithm for this? :)
--
PS: I'm not undermining the coding/developing positions. I'm just highlighting the difference the way I see it from my limited experience and a hindsight that is 20/20.
Anyway, as you already know, currently I am switching employers. I am going from one great company (www.uvp.com) to another (www.ebay.com). [What makes UVP great? That's the topic of next post...] .
At UVP, I have sort of a jack-of-all-trades role. Depending on who you ask, I'm a different person at UVP:
-some people know me as a rookie pair of hands who helps test our software,
-some people know me as someone who answers questions about our software,
-some people know me as someone who recommends and installs computers for sales people,
-some people know me as someone who tries to introduce new relevant technologies in our software,
-some people know me as someone who writes 200 page manuals,
-some people know me as someone who takes the final build to production,
-some people know me as someone who is a meeting-monger and keeps arguing on what is better and what is not,
-some people know me as someone who worked late-night and weekends doing strange things and
-some other people know me as a "program/product/project manager" who is responsible for overall success of the package.
Whatever it is that they know, now they will have to replace me. That makes me think how different it is to replace a project-management role than replacing a hard-core technical role. It's not any more easy or hard, it is just different.
In a project-management role, you are actually replacing a "personality", as opposed to someone who knows C++,Java. From within the group or even from outside, it's hard to refer to a project-manager as "someone who does project management", the way it is easier to say "the developer or coder".
Maybe it is only my conceited opinion, but I atleast know that is the approach of upper-management. A person who is answerable (project-manager) is associated with a "personality", rather than someone who tools and tinkers (developers). So in this case they would say "we need to replace Soham" - not just the name, but someone who will do what Soham did and more. Had I been a developer, they would say "Let's find someone who knows how to code". This is especially true for smaller setups where there is more visibility than usual. Looking at the other way, they would say "I want someone who can answer questions the way Soham did (or did not)", but would rarely say "I want someone who codes the same way as Soham did (or did not)"
Why? This is because the role of a general project-manager is not as well-defined as the role of a developer/coder. It's hard to see the bounds of that role and responsibility. More you do, the better it is. You then become an interface to Management for overall details. And management is concerned more about their interface with code than the code itself. Hence, they are dealing with a "person" all the time, rather than "code".
So when you interview candidates for positions such as these, it is far more important to figure out how they will gel with the group, instead of how well they can code. A few things I've found are :
-An energetic person with consummate communication skills will fare much better than someone who knows just the technical details.
-Someone who has the guts to cover up for the team and even for the boss sometimes, and take responsibilities is the type of person you need.
-Someone who understands the application space and believes in the power of technology to solve problems is the type of person you want.
-Someone who doesn't shy away from looking into gory details is the type of person that is required.
-Someone who understands that there is no authority he has over anybody or anything, and the only way he can get work done is by the power of facts and presentation of facts, is a best fit for the position.
-Someone who has the patience of repeating the obvious over and over again, is what you are looking for.
I can go on and on and I am sure you can too. It's a constraint satisfaction problem with a twist - different constraints have to be satisfied at different times. So anybody up for desiging an O(N) algorithm for this? :)
--
PS: I'm not undermining the coding/developing positions. I'm just highlighting the difference the way I see it from my limited experience and a hindsight that is 20/20.