The Curse of Believing in Uniqueness

[This is an unfinished blog post from years back that I'm publishing now as part of a housecleaning on the off chance that someone might find it useful.]

In my dialog with others, particular those in the agile community, I frequently encounter those with a belief system that runs along the following lines:
* As a human, I'm not like a machine or an animal
* As a knowledge worker, I'm not like a physical worker
* As a software professional, I'm not like other professionals
* As someone working today, I'm not like those who have worked in the past
* As a unique individual, I'm not like others

I think these beliefs are in turn linked to the following perspectives:
* I don't do repetitive things, my work is unique
* I don't do physical work, I use my brain
* The problems I deal with in software are different and more complex than problems dealt with by other professionals
* The knowledge and wisdom of today far exceeds that of yesterday
* What others have learned does not apply to me

I think this in turn leads to the following action strategies:
* I shouldn't spend a lot of time really listening to others
* I shouldn't spend a lot of time studying what others do, particularly in other fields
* I shouldn't copy what others do
* I should figure things out for myself

Except that:
* We have much in common with those that are different from us
* So we have much to learn from those that are different from us
* The brain is an organ that is subject to fatigue, change, etc., like other human organs
................

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)

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

Standardization in Large Orgs

I view this issue of organizational learning ands it relationship to standardization as one of the most important and difficult challenges in a large org.

I've had some luck using Jim Luckman's presentation at http://www.lean.org/downloads/Transformational_Leadership_April_2010.pdf which discusses "Blanket Solutions Thinking" and the assumptions that underly it.

Some have suggested that any standardization is bad and that any interdepencies between groups for which standardization would reduce cost should be eliminated by making all groups small and independent (e.g. "two pizza" teams acting as autonomous businesses).

That personally strikes me as somewhat of a "let them eat cake" approach and that we should acknowledge the need/benefit of standardization in some circumstances. The trick is when and how to achieve that standardization and doing it in a way that doesn't kill organization-wide kaizen.

(Written years ago; published as part of a blog draft housecleaning).