Managing the How

[This an unfinished blog post from years ago being published now as part of housecleaning on the off chance it might be helpful to someone.]

One of the core issues in dealing with the role of the engineering manager in Lean/Agile is the nature of the manager's involvement with the work. At the risk of oversimplifying, the differing perspectives are sometimes characterized as follows:

• Agile: Managers typically cause trouble and should stay out of the way. At most, they should help the team resolve barriers if and only if the team asks for their help.


• Traditional: Managers should continue their traditional Management by Objectives (MBO) role. They should meet with the employee to agree on annual personal performance objectives and evaluate that performance at the end of the year, but they should not micromanage.


• Lean: Managers should be intimately aware of the work process and actively coaching counseling in that regard.

In the context of the above, I've noticed an interesting overloading of the word "how" as in Managers should (not) get involved, let alone dictate, how the work is accomplished. I believe this overloading has resulted in substantial confusion around this topic of the role and has made dialog much more difficult. In addition to having to deal with serious differences in philosophies, people are talking past each other in some key respects.

To understand this overloading, let's consider the case of problem solving, although we could have just as easily chosen product/process development. In the case of problem solving, there are two distinct levels at which problems are addressed. There is first of all the process by which you approach the problem (e.g. ad hoc vs. structured, PDCA vs. DMAIC, iterative vs. waterfall, etc.) But there is also the design that you come up to address/solve/mitigate the problem. And again, this notion of process vs. design applies equally well to product or process development.

Given the above, it's now easy to understand why the phrase how the problem is addressed has multiple meanings as in Managers should (not) get involved in how the problem is addressed. In one case, you're talking about the process of addressing the problem and in another case you're talking about the design used to address the problem.

Looking across the three major management philosophies, the desired level of management influence in each of process and design aspects can be roughly characterized as follows:

Agile: Process (none), Design (none)
Traditional: Process (none), Design (approve after the fact)
Lean: Process (guide throughout), Design (situationally involved)

................