In the IT industry (or any for that matter), its typical that an engineer after gaining a bit of experience (say 5y) is expected to take on a bigger role. Usually it starts with becoming a Team Lead, Module Lead, Architect etc. depending on the needs of the team or the org. Notwithstanding the title, it usually signifies the responsibility is not any more of an individual’s productivity, but ensuring that a group of people can stick to the same quality of productivity.
It is somewhat a gradual slope to slip into. All fine for a while. But a few years in the lead, then the industry also expects something drastically different – promote the individual engineer to a People Manager. There is a general tendency to question the capabilities of an individual with a wealth of experience not ending up in the management. Why aren’t you a Manager, Director or VP yet?
Its a cliche that employees leave managers, not jobs. A lot of best sellers have been written around management, lectures delivered, courses created and money made. But the fundamental problem of why employees don’t get along with their managers remains and will remain. Why? Because, humans. Understanding human psychology is a fundamental part of people management. Mere technical proficiency is not a ticket for that skill.
The greatest fear of any manager is that, on any given day his/her best engineer will leave. So the biggest tap dancing any manager has to do is to sustain the balance of “happiness-quotient vs egoistic-importance” of the employee. While every resource is (or must be) replaceable, a manager cannot simply go around and say that to his/her employees. At the same time, the manager should not give too much importance to anyone at the cost of displeasure to others. True, in any company, everyone’s productivity is different and should be rewarded in proportion, but at the same time explicit indulgence isn’t a good management trait.
One of the first things I did after becoming a manager is, I stopped calling any one as “subordinates” and referred to them as “reports”, for a lack of better term. But now, I think even that is wrong. So I reflected a lot on “What should a manager be”?
The biggest asset of any company (project or team) is not the people, but the institutional knowledge. If the higher-ups tell you that the people are most important, its a lie. You are missing the flashing marquee of old style web page that says “you are replaceable”. So if a person leaves, he/she does not just take the knowledge, they take the crucial mental map and gap of that knowledge. That includes the nodes, links, qualities, relations, relevances and most importantly, the irrelevances. Thats almost impossible to reconstruct by someone else to the same degree. How do we protect that institutional knowledge? Documents? LOL. Knowing what won’t work is much more expensive than knowing what works.
For a different perspective, let’s look at the how some of the world’s greatest institutional knowledge were retained. In India, the guru-parampara (loosely translated as teacher-student-lineage) is the basis of its traditional-knowledge-system. Ancient knowledge has been transferred over hundreds of generations, pretty much intact. How was this possible? The Guru was once a student, gained technical proficiency, but at some point of time graduated to a senior, then eventually establishing his own lineage continuing to transfer that knowledge, by becoming a guru himself and taking care of his students. Now, why was this necessary? Because knowledge gained is considered a debt and not a business. That means the only way of getting of rid of the debt of learnt knowledge, is by teaching it to others. This way the guru is not a manager but a server to his students. The guru teaches his students, commands respect, course-corrects the errants, serves for their future, and all this by getting rid of his debt. And that makes the difference.
Most companies have an org chart that goes from top to bottom as CxO, xVP, xMgr etc. and trickles down to other staff employees. This gives a sense of people “managing” other people top down. In the guru-parampara system, the students would be at the top and who they learn from (are being served from) would be at the bottom. (Note that this is not to be confused with Top-Down management or Bottom-up management style of functioning). This is just the perspective of how one employee is seen in relation to another employee. Calling an employee a subordinate or report, pre-supposes a “superiority”, while calling a manager as one who serves his employees is a mark of humility, respect and above all – humanness – which is the original responsibility of “people” managers. It gives an opportunity for such a role to understand the human psychology, perform the role of enabling others in terms of repaying debt, rather than a sense of scaling up the hierarchy.
The roles and responsibilities are still same, but the frame of reference is now quite different. The top becomes the “root” yielding to a tree chart, where the layer below exists for the fruition of the layer above. Who knows, the tree chart could potentially allow to optimize the organization using tree-based algorithms! A binary tree org, anyone?