- The Command and Control management method
- The Econ 101 management method
- The Identity management method
Despite this fear, I really like mentoring people. I can focus on transferring knowledge (what is the point of being an expert if you do not share your knowledge?) without having to deal with risky personal situations! I act as a mentor in different situations:
- With new employees and interns: to teach them the best practices (efficiency is not that important at the beginning), to have them fully understanding the requirements before thinking about implementation details (to avoid the risk of delivering something that does not match the requirements), etc.
- With experienced developers having a different technical background: to identify their strengths and to make them more productive (better designer, delivering high quality code, documenting their production, more agile).
- And with managers for reasons I am going to developed below.
Usually, implementers (or do-ers, or pigs [4, 5]) are receptive to suggestions. Managers (or chickens [4,5]) are much less willing to listen. In my experience, I met many people that followed the path governed by the Peter Principle [6]. Usually, the only way to get promoted is to become a manager; very few people start their career as managers. Promoted managers often lack of training, and they mostly following the pattern managers have serve to them.
What is the big difference among managers and regular employees? The first ones have been empowered to take decisions and the second ones usually follow orders. Many managers I worked and I work with have a technical expertise reversely proportional to their management experience. And they have most of the time a better salary than their reports.
Managers have many responsibilities, and there is one that is often incompletely assumed: ensure their reports can deliver their best.
- I find dangerous when decisions are taken without having the big picture. Some managers follow Joel Spolsky's advice and delegate the decision instrumentation.
- At the same way, managers should delegate, I think reports should be able to do the same. For example, a developer needing a second hard drive to host big virtual machines should be able to go to his manager, to expose his requirement, and then go back working while the manager fills up the purchase request. How many times have you seen such a situation? Personally too rarely, and just from junior managers who had still fresh in mind some past frustrations. Most of the time, managers think their time is too expensive for such basic tasks and they prefer wasting the time of their smart reports.
- A good manager should delegate to their reports and accept delegation from their reports. Each aspect of the delegation makes the reports more motivated and then producing a better job. I think benefits gained by applying only one delegation aspect are easily compensated by the frustration generated the non application of the other aspect.
This conclusion is another argument why I do not want to be another manager. Hopefully, my current expertise allows me to focus on technical works, to be just a mentor, to give advice and to accept suggestions in return, and to stay on the implementers' side where true collaboration is common.
A+, Dom
--
Sources:
- Joel on Software blog by Joel Spolsky
- Arthur Ryman's profile on eclipse.org
- Eclipse Web Tool Plateform: book co-authored by Arthur Ryman.
- Chickens and pigs in situation by Nick Malik
- Chicken and pig roles in SCRUM context on wikipedia
- Description of the Peter Principle on wikipedia -- read the part on Dilbert Principle ;)
No comments:
Post a Comment