This one is my favourite. I simply love LEANER AND FITTER team structures. So let me start with my abroad work experience.
While working in Singapore the team structure was very simple, I had a manager, who in turn had his manager and then there was the END USER or client who uses what we develop. I was lucky to be involved in meetings with end users several times [I learnt a lot out of it]. So now you can understand what is a leaner and fitter structure.
But over here in India its totally different.
There are so many people involved in the project that at the end of the day
1. we actually forget do we really have a client or are we developing prototypes or side projects.
2. the client gives requirement X and we end up implementing 1/X [inverse of X] courtesy a phenomenon called CHINESE WHISPER .[rather, because of the number of stake holders, you see too many cooks spoil the broth. quote suits aptly].
There are so many people involved in one simple implementation, I would love to sum them all, like
a. program manager.
b. project manager.
c. technical manager.
d. group manager.
e. resource manager.
f. project lead.
g. delivery manager.
I can actually see all these people involved in a small project, and mark my word, NONE AMONGST THESE ACTUALLY WRITE CODE, nor have any idea about TECHNOLOGY.
And by the way, correct me if I am wrong, these guys dont even take responsibility, if something goes wrong blame the developer and sit in a meeting room and spend the entire day doing ROOT CAUSE ANALYSIS [ yeh I guess these guys are SIX SIGMA CERTIFIED, or rather PMP] while the poor developer [scapegoat] has to debug the issue all by himself and find a solution. The RCA done by these guys is of no use because the developer fixes something and something else breaks, so the cycle continues... I mean time to do RCA again.
They just crap crap crap, all the time and spend so much of time in meeting rooms and eat up a major chunk of the project bill or funding that the poor developer will have to COMPLETE the assignment in HALF the time. Believe me when these guys sit for a meeting all by themselves, their time goes unaccounted for, not a single time, I have seen any MINUTES OF MEETING from them.
PHEW..
too much to think about whether to continue in technical line or not or whether to continue in this stream or not.
Cheers,
While working in Singapore the team structure was very simple, I had a manager, who in turn had his manager and then there was the END USER or client who uses what we develop. I was lucky to be involved in meetings with end users several times [I learnt a lot out of it]. So now you can understand what is a leaner and fitter structure.
But over here in India its totally different.
There are so many people involved in the project that at the end of the day
1. we actually forget do we really have a client or are we developing prototypes or side projects.
2. the client gives requirement X and we end up implementing 1/X [inverse of X] courtesy a phenomenon called CHINESE WHISPER .[rather, because of the number of stake holders, you see too many cooks spoil the broth. quote suits aptly].
There are so many people involved in one simple implementation, I would love to sum them all, like
a. program manager.
b. project manager.
c. technical manager.
d. group manager.
e. resource manager.
f. project lead.
g. delivery manager.
I can actually see all these people involved in a small project, and mark my word, NONE AMONGST THESE ACTUALLY WRITE CODE, nor have any idea about TECHNOLOGY.
And by the way, correct me if I am wrong, these guys dont even take responsibility, if something goes wrong blame the developer and sit in a meeting room and spend the entire day doing ROOT CAUSE ANALYSIS [ yeh I guess these guys are SIX SIGMA CERTIFIED, or rather PMP] while the poor developer [scapegoat] has to debug the issue all by himself and find a solution. The RCA done by these guys is of no use because the developer fixes something and something else breaks, so the cycle continues... I mean time to do RCA again.
They just crap crap crap, all the time and spend so much of time in meeting rooms and eat up a major chunk of the project bill or funding that the poor developer will have to COMPLETE the assignment in HALF the time. Believe me when these guys sit for a meeting all by themselves, their time goes unaccounted for, not a single time, I have seen any MINUTES OF MEETING from them.
PHEW..
too much to think about whether to continue in technical line or not or whether to continue in this stream or not.
Cheers,
