Mandamagement and Division of Labor
Management is not my specialty. If I was asked to be a manger, the outcome would probably be far less than desirable.
I also recognize that I can find your faults, and tell you all about how to fix them, while I strut around doing the same thing I think you should stop doing. In other words, I can fix you, but not myself, so I depend on those around me to keep me in line and on target. What happens when those around me don't know what the target should be, or even worse they assume the responsibility of guiding me off a cliff? In this past blog I asked "Where is my Project Manager?". My more recent experience was quite the opposite.
A while ago I had the pleasure of experiencing a project manager that not only thought they knew how to do architecture and development, but they thought they should tell me how to do architecture and tell me how to provide a technical solution. Their way was not my way, mainly because they had little experience, and the experience they had was bad experience. You can imagine how well that went. They were persistent enough that some days I felt like I had two voices in my head. It was like living in the Gollum and Precious scene. I always knew where they were, because they were always in my space and my head.
I always welcome input from someone until I realize they are not qualified to give input on a certain problem. On my current project I was asked to offer advice on a JAVA architecture and system design. I had to ask not to have to do that. I don't believe in trying to give expert advice on something I am not an expert on. I could have recognized the patterns and the UML diagrams easily enough, but after that, when we got to implementation, I would have been lost. This concept of not being experienced enough in a subject to be able to offer sound advice was beyond the project manager. They were always willing to offer their unsolicited advice without the backing of experience, especially to the customer. That led to a lot of wasted time proving to them why the suggestion would not work.
I have been places where they believe everyone on the team should be capable of doing everything. In my humble opinion that only really works when everyone on the team is actually equally capable.
Usually I find that they aren't equally capable. Some team members are better at one thing, and other team members are better at other things. There is also sometimes when a team member is not capable of meeting the skill sets they sold you on, and must be mentored if the time and resources are available for that, or let go and replaced if the resources are not available, or they are not willing to learn. That does not apply to consultants. If you are a consultant, you better come in hitting the ground running. Consultants are paid to know, not to learn.
This brings me to division of labor. I have yet to find a successful team that did not practice good division of labor. They are usually very productive. On the other hand, if our team is made up of an enmeshment, and you can't define where my responsibility starts and yours stops, and visa versa, we are in trouble.
Management that can be in the weeds, are always welcome in the weeds. I am working with a team right now that I always want in the weeds with me. But in the situation with the project manager that was not qualified to be in the weeds, did not know where their responsibilities stopped, and did not let the people who do architecture and development take over, there was a lot of Mandamagement done. It was to the point where I had to exercise my belief that sometimes the best thing for a project is for me to leave it.
I also recognize that I can find your faults, and tell you all about how to fix them, while I strut around doing the same thing I think you should stop doing. In other words, I can fix you, but not myself, so I depend on those around me to keep me in line and on target. What happens when those around me don't know what the target should be, or even worse they assume the responsibility of guiding me off a cliff? In this past blog I asked "Where is my Project Manager?". My more recent experience was quite the opposite.
A while ago I had the pleasure of experiencing a project manager that not only thought they knew how to do architecture and development, but they thought they should tell me how to do architecture and tell me how to provide a technical solution. Their way was not my way, mainly because they had little experience, and the experience they had was bad experience. You can imagine how well that went. They were persistent enough that some days I felt like I had two voices in my head. It was like living in the Gollum and Precious scene. I always knew where they were, because they were always in my space and my head.
I always welcome input from someone until I realize they are not qualified to give input on a certain problem. On my current project I was asked to offer advice on a JAVA architecture and system design. I had to ask not to have to do that. I don't believe in trying to give expert advice on something I am not an expert on. I could have recognized the patterns and the UML diagrams easily enough, but after that, when we got to implementation, I would have been lost. This concept of not being experienced enough in a subject to be able to offer sound advice was beyond the project manager. They were always willing to offer their unsolicited advice without the backing of experience, especially to the customer. That led to a lot of wasted time proving to them why the suggestion would not work.
I have been places where they believe everyone on the team should be capable of doing everything. In my humble opinion that only really works when everyone on the team is actually equally capable.
Usually I find that they aren't equally capable. Some team members are better at one thing, and other team members are better at other things. There is also sometimes when a team member is not capable of meeting the skill sets they sold you on, and must be mentored if the time and resources are available for that, or let go and replaced if the resources are not available, or they are not willing to learn. That does not apply to consultants. If you are a consultant, you better come in hitting the ground running. Consultants are paid to know, not to learn.
This brings me to division of labor. I have yet to find a successful team that did not practice good division of labor. They are usually very productive. On the other hand, if our team is made up of an enmeshment, and you can't define where my responsibility starts and yours stops, and visa versa, we are in trouble.
Management that can be in the weeds, are always welcome in the weeds. I am working with a team right now that I always want in the weeds with me. But in the situation with the project manager that was not qualified to be in the weeds, did not know where their responsibilities stopped, and did not let the people who do architecture and development take over, there was a lot of Mandamagement done. It was to the point where I had to exercise my belief that sometimes the best thing for a project is for me to leave it.
0 Comments:
Post a Comment
<< Home