I had shared that I was elated to management roles and my struggles with them. As a technical person and and IC my previous roles had been very crips. They completely outlined what was expected from me. But as a manager I had been struggling to define what my role demands. Often I would have the following complains :
- As a manager Why there is no defined KRA metrics ?
- Why are there so many meetings ? As an IC I could well see that these eat away all the time.
- Why can’t I delegate my work easily ?
- How do you work with senior and junior people in your team ?
- Why training of my team must be driven by me ?
- why external training are only theoretical
- What should I look for while hiring ? As The technical check is doe by the engineers
- and a few more.
You can note from the above I had issues in defining what the management is all about. I have read a number of books on management subject. Some of them outlined how do you manage things. They provided solutions how to proceed with one or more items. But none of them outlined what is management about.
During the past few weeks I picked High output Management by Andrew Groove. The book had been a gold mine for me. It provided fundamentals what management is all about.
- The basic definition of a manager. A Technical Architect is manger and not an IC any more. He is responsible of influencing decisions for the team and the customer.
A manager’s output = The output of his organization + The output of the neighboring organizations under his influence
- The role of meetings in capturing information from various sources. The information lays foundation for decisions. Some informal alternatives to meetings.
- Training as one of the defined task for the manager. I haven’t seen many managers owning this up.
- The role of one-2-one sessions. I had been been doing these sessions with no clue of how to make most of them. I usually start them when the KRA for the team is defined. They are periodic in nature but they are skipped after a few initial weeks. I often do a 2 min talk with the subordinate and we mutually agree to skip it, unless there is a pressing on either of our hands.
- Promotions and peter principle, I can only quite the following :
The old saying has it that when we promote our best salesman and make him a manager, we ruin a good salesman and get a bad manager. But if we think about it, we see we have no choice but to promote the good salesman. Should our worst salesman get the job? When we promote our best, we are saying to our subordinates that performance is what counts.
- The concept of Task relevant maturity, which I haven’t seen any of my organisations talk about
we confused the manager’s general competence and maturity with his task-relevant maturity.
As an engineer I often recommend the book Practices of Agile Developer to my new team members. The book is a gold-mine for developers outlining what are the basics which they need to stick to.