http://www.perlmonks.org?node_id=823560


in reply to Nobody Expects the Agile Imposition (Part II): The Office

It surprises me that so many managers don't really understand operations, mainly how things get put together. But then again, considering how many managers I have had don't understand programming, maybe I should not be.

If you have someone who has never done the task that they are asking someone else to do, is it any surprise that they don't know how to solve issues that crop up?

Too often I find that managers not only need the problem explained to them but the solution as well. The only role they seemed to be playing is intermediary between their department and another departments manager.

  • Comment on Re: Nobody Expects the Agile Imposition (Part II): The Office

Replies are listed 'Best First'.
Re^2: Nobody Expects the Agile Imposition (Part II): The Office
by TGI (Parson) on Feb 19, 2010 at 00:32 UTC

    A good manager need never have done the job she or he is supervising. Her or his role is that of facilitator.

    A manager does his or her job well by:

    • Clearly defining what work must be done when.
    • Clearly defining priorities. What work takes precendence over other work?
    • Remove impediments that prevent his or her workers from completing their tasks.

    The only way to achieve these three things is to respect and listen to your staff. If you think of them "human resources" or dolts and not people, you can never manage effectively.

    As a programmer, I shouldn't need to think about inter-office power squabbles or pissing-matches between account management and operations. These things don't concern me. To the extent that I am distracted by these issues, and my productivity suffers, my manager is not upholding his or her responsibility. All I need are the specs and a schedule.

    Mutual respect is worth 1000 times any level of 'in field' experience a manager has to offer. This applies whether you are dealing with cannery workers sorting out rotten fruit, car salesmen or engineers.

    eyepops manager should ask for feedback on the new agile approach. S/he should be able to accept negative feedback - "I hate it". S/he should be willing to ask "Why?" and accept an honest answer. Finally, s/he needs to ask "How can we make things better?". Once s/he has this info from eyepops and his coworkers, s/he can determine how best to advocate for her/his staff to maximize productivity.

    None of the above steps are possible without mutual respect.


    TGI says moo

      I completely agree, though I do appreciate a technically competent manager because it makes things go quicker in discussions. The problem is that mutual respect is like a dog that speaks Norwegian. That and it's only the foundation that is needed to support all the competencies involved. I've had... 5, maybe 10, managers out of 30 who were competent at anything in particular, let alone management.

      Something else occurs to me about respect. The employee is much freer to give it properly when it's earned. The manager is constrained by the machinations of the company and its hierarchy and is more often regulated to "chief apologist" than to "team advocate" no matter her skills or intentions.

      This whole thread makes me :(

      Like Your Mother, I appreciate a technically competent manager. While general management skills trump technical competence for high level managers, lower level managers of programmers at the coalface do require technical skills IMHO. At least, that's been my experience.

      Let me give an example to clarify. I remember one particular "delivery focused" programmer with a "strong sense of urgency". Rather than taking the time to properly abstract the design, he crudely cut n pasted thirty new classes from an existing one. Now these thirty classes were identical, except for one line of code!! Of course his code never contained any useful comments because these take time. This fellow consistently left behind huge swathes of unmaintainable code, yet his non-technical manager -- who never looked at the code -- praised him and even gave him bonuses and little plaques for his "strong sense of urgency" and "can do" attitude. You might argue that a better non-technical manager, one who understood technical debt, would not do this (and I agree), yet non-technical managers must rely on others to judge the technical merit of the work produced by their staff. And in a political, non-trusting organisational culture, that results in people playing silly games (e.g. if you tell my non-technical manager that my work is of high quality, I'll return the favour to you).