Manager Controls Process

ManagerControlsProcess is an AntiPattern. See DeveloperControlsProcess.

However, this pattern is not about managers controlling the process, but about managers making technical decisions. Managers defining the process (but not necessarily making the technical decisions) is not an AntiPattern, in my view. -- PaulHudson

Problem:

Who makes sure that software is developed correctly?

Forces:

Software is expensive, and the people paying for it want to get what they paid for.
Developers are experts in software, and know the most about the implications of design choices on the software itself.

Bad solution:

Manager should be in charge of all important decisions, both technical and nontechnical.

Definitions, please! What do we want "Control" to mean in this context? I don't think any process can be "controlled," although it could be "defined" and "enforced."

Processes can be controlled - considering the opposite - an uncontrolled process - makes it clear, I think that both "defined" and "enforced" are elements of control.

If you like, let's use "defined" and "enforced" instead:

ManagerEnforcesProcess? and ManagerDefinesProcess? are both not normally AntiPatterns, in my view. ManagerTakesTechnicalDecisions? can be, however.

Maybe the AntiPattern is that the same individual both defines and enforces the process? As a (bad) analogy, it's like a programmer writing code alone without peer review. At that point, the definition of control tends to the negative implications of "to have power over" -- StevenNewton

Nope. Don't see this as an AntiPattern either. The same individual doing tasks and reviewing his or own work would be. To take another domain, I don't see a problem with a sales manager defining and enforcing the sales process for his sales people. Why is software development different?

I've been poking around over on JimCoplien's Process Patterns site; one of his patterns is DeveloperControlsProcess: http://www1.bell-labs.com/user/cope/Patterns/Process/section12.html

I think he's using "controls" in an unusual way, though: he says it's a good thing for the developer to be the hub of activity: all bug reports, requests for changes, etc. should go directly to the developer. This idea is probably as controversial as developer-defines-and-enforces-process, but I can see agreeing with one and not the other.

A more precise question: Is manager-is-hub-of-process an AntiPattern?

-- GeorgePaci

Some managers do code. They are called Technical managers, technical leaders, SoftwareArchitects, team leaders, etc. If they didn't know how to code, how could they manage? If they don't have a criteria for realizing if the solution is right or wrong, how could they make decisions?

There is a line of thought in which if you do something several times, you will learn by TrialAndError, you just need to practice. I guess management is not one of the areas where you can learn by TrialAndError because:

1. How do you know if the experiment failed not because of the programmers but because of the manager?

2. How do you know if the experiment failed not because of the manager but because of the programmers?

3. If the manager hires InexperiencedProgrammers?, is it the fault on the programmers? Who should be fired then?

4. If an ExperiencedProgrammer? cries that the project is in jeopardy, is it ok to ShootTheMessenger?

5. If an ExperiencedProgrammer? does not cry that the project is in jeopardy as soon as possible, is it ok to ShootTheMessenger because the messenger did not deliver the message?

The process must be agreed among developers, designers, testers and managers. But the manager is in control: He reads the KeyProcessIndicators?. If a defect is found, then TheProcessIsTheProblem, not the people. When a manager thinks the PeopleAreTheProblem, he is willing to fire any employee who makes a mistake. Employees figure that out and a FearCulture is in fact established: they hide their mistakes.

How can the manager manage if he can't tell the difference between a good design and a bad design? Managers must manage statistically (BalancedScoreCard), and have submanagers who are technically savvy and hire top talent to work for them. The process must be simple enough for everyone to understand and get complicated with time, as long as new problems in the process are detected and fixed in the process.

-- GuillermoSchwarz

I agree that this is an antipattern. A manager is supposed to be an expert in proyect management (and that is very hard), not necessarily in technical subjects (this is very hard, too). In my experience, in complex projects the same person has not time to be responsible of both technical decisions and management. I think if the manager have good technical skills he can sometimes make technical suggestions, but that's all. Manager and technical leader or software architect are very different, may be in small or simple projects can be the same person, but in complex projects I think is a very risky idea to have one ssame person doing both.

CategoryAntiPattern