Showing posts with label Management. Show all posts
Showing posts with label Management. Show all posts

Wednesday, April 30, 2008

Saturday, April 05, 2008

Achievers 08 - A salute to the torch bearers



Today i got a chance to attend a program organised by PUMBA called Achievers 08. The program was to felicitate some of the industry leaders and the achievers in their respective domains. The achievers list included some eminent personalities like -

Mr Dilip Chhabria, CEO and Chief Designer, DC Designs Pvt Ltd
Mr Achyut Godbole, MD, Softexcel Consultancy Services
Mr Ravi Pandit, Founder Chairman, KPIT Cummins Infosystems Ltd and
Mr Subhash Kapre, CEO, Serum Institute of India

Today was one of the most memorable days in my life that i got to listen to all those eminent personalities. To learn from their experiences was a great experience. To know more about the event - Click here for the PUMBA site.

Tuesday, March 25, 2008

3 Corporate Lessons

Found a nice ppt while stumbling through some blogs. Source - Ravi Mevcha. The PPT is prepared by IIM - Kolkata and it explains 3 important lessons that need to be learned in Corporate Life!

Wednesday, January 30, 2008

MBA in a Page...

A comprehensive list of management theories. Its 'MBA in a Page'. Check out guys ! Very Useful !

Sunday, December 30, 2007

Do engineers really do R&D?

Embedded Guru - Jack Ganssle has a column on embedded.com called Breakpoints. A highly recommended read if you are or want to be a embedded systems developer. Recently Jack wrote a nice article on what actually R&D is meant for and what actually it is. I would like to post that small article over here or else you can have a look at it @ Breakpoints

"Research and Development. R&D. It's the lifeblood of tech companies, and it's what we engineers do all day, every day.

Nonsense.

There's no such thing as R&D. There's R, and there's D, and the two are completely separate activities.

Research is all about discovering new things. It's the science that ultimately enables the products we build, the metaphorical man-behind-the-curtain pulling the levers to control the machines we create.

Research might also involve discovering new algorithms, like new ways to smooth signals or compress data. "New" might mean new to us but not to the world. So we research an idea or a need, and then switch to development mode. The result of research is an approach that one can then implement.

Development is taking known ideas and using them to build products. That's the bulk of an engineer's work. We transform an algorithm to something physical, like converting a CRC algorithm to C code, to VHDL inside an FPGA, or to logic components.

One of my top ten reasons for failed projects is "bad science," or the inability to separate R from D. When a company starts building a product before really understanding what is being measured the schedule is doomed. Start coding an algorithm without it being sharply defined and, at best, you'll wander aimlessly till, with luck, settling on an approach that works.

Research simply can't be scheduled. If you don't believe that, please develop a (realistic) schedule for discovering the cure for cancer.

You might be able to guesstimate simple research schedules, like doing a search for a known algorithm, but even that is, in my experience, very difficult to estimate. The first "Eureka" is often followed by disappointment when a little experimenting reveals some fatal flaw, requiring more research to find a better approach.

Yet I constantly see teams conflating R and D, leading inevitably to late or failed projects.

Sure, there are some projects that necessarily pursue R and D in parallel. But those care rarely be scheduled with any accuracy.

What do you think? Have you ever had a project disaster because you were doing R and the same time as D?"
-- Jack Ganssle

Saturday, December 22, 2007

Lead India

Monday, June 11, 2007

IT Strategy that makes Google work...

“Use customized open source where possible, custom build where necessary, and buy if it's not related to something that will give Google a competitive advantage.”

Behind the seeming simplicity is a mash-up of internally developed software, made-to-order hardware, artificial intelligence, obsession with performance, and an unorthodox approach to people management. Do read this article.

http://www.informationweek.com/management/showArticle.jhtml?articleID=192300292&pgno=1&queryText=

Wednesday, May 30, 2007

IT Industry - An entry level perspective

A must read article for all those who are looking to join IT industry or are at entry level. Click here.

Understand relativity to know you better.

An excellent article by Piyush Gupta posted on techtribe. i thought i should share it with you all.

"The observation is as much a statement about the observer as it is about the observed."
I know I'm not pointing out anything unique again but definitely will attempt to refresh something that needs attention. Keep following.

The other day I got to read a saying on internet "A diamond with a flaw is better than a common stone that is perfect".

Wow, what a saying !!! It indeed gazes through our instincts.

It is so natural for any of us to start seeing ourselves as the diamond or the stone for the simple fact that they look like objects here and as a natural tendency we tend to compare objects in sayings with 'ourselves' as individual or 'people' in general.

However the 'common stone that is perfect' refers to a person who is not recognized for any outstanding or clearly well developed or superior characteristics.
Whereas going by the definition of words in 'Flawed Diamond' it seems to refer to people who are rare (as diamond is rare) with a lower level subject matter expertise (as they are flawed) but since diamond enjoys quite a popularity, these people must be the recipient of extraordinary recognition, unlike common stone (that makes it common).

But isn't it true that everyone of us can only be good at certain few things and not all? Since it hold true, therefore, we all are flawed at certain things and extremely well at certain few. What makes us a diamond or a stone is just the "recognition" or "recognition by the observer".

Therefore, each person is a potential diamond but only if the observer is looking for diamonds OR common stone if the observer is looking for common stones. Therefore being a Diamond/common stone goes very much in the view of the observer and not the one under observation. Hence observer is also as good an object in the saying as it is the one being observed.

A person who is not recognized for his/her good deeds will likely have low-self-esteem. I find it very important for every common stone to realize two simple things:

1. It is the observer who made him a common stone, it doesn't necessarily mean that they aren't diamond.
2. Some skills on other front demand little more attention to bring them some recognition, that may probably make them a 'Kohinoor' as they were already perfect.

All the left game is about recognition!

Lets play little Mathematics.

If I see a person X and I make the observation that X is bad, the observation is a statement not only about X but also about myself.

A person Y looking at X might make an altogether different observation. So his statement refers to his understanding about X.

Everything in this world of relative reality is relative to the observer. However, the observer thinks what he/she observes is the absolute. Everything that goes on in my mind is relative to me, however, I have a habit of believing that to be the absolute.

All beliefs are relative to the believer. Different believers will naturally believe different beliefs. Simply because beliefs are relative and not absolute.

What is the need to fight over beliefs then?

A myth called the Indian programmer

Are u a programmer? Are u an indian? Then this is a must read article for you. A Times of India article in which the author explains the indian software industry scenario - true to the core! A must read article - Click Here

Monday, April 23, 2007

10 Tips for Being a Better Office Professional

Found a nice article which lists 10 tips for being a better office professional... I am just listing the main points... For details - Click Here

1. Do not discuss your salary/wage with your coworkers.
2. Perception is reality.
3. Be honest with your coworkers, but not too honest.
4. Choose your battles wisely.
5. Nobody likes a whiner.
6. Don’t get shitfaced at happy hour or the holiday party.
7. Get it in writing.
8. This isn’t high school or college A) debating.
9. This isn’t high school or college B) over the top.
10. Smile, today’s the first day of the rest of your career!