Hacking the Development Paradigm: New Models for Management Development Part 2
.jpg)
In Part 1 of this series on New Models for Management Development I offered the following as the background against which much of our corporate management development is currently being conducted…
- Away from the workplace, with a classroom focus
- On a periodic event basis
- With the assumption that development is learning, meaning we focus primarily on providing new information.
- Centers on individual rather than group learning process, most classes made up of unconnected participants
- Assumes all developmental issues to be more or less technical, developing skills is sufficient.
With these elements as background imagine that alongside programs for which this approach truly does make sense, say learning a new software application such as spread sheets or something similar, we began to lay the foundation for another form of development to take place, a “hack” of the current paradigm of development so to speak. Though there are many working definitions of the term “hack” the one we’ll use here is adapted from Gary Hamel’s Management Innovation eXchange, “a disruptive idea or radical fix” offered in the face of a lingering issue.
A “Hack” doesn’t necessarily work well if it threatens the host being hacked so retention of most of the familiar learning paradigm will be a key element of the success of this initiative. Assume we’ll retain what works about the traditional development paradigm with its skills development focus, let’s gently lay out a new parallel path as follows
Parallel Design Features for Organizational Learning
Skill Development Focus Outcome Focus
- Learning In artificial groups (classes) - Learning in real work groups
- Time out” apart from work flow - Infusing learning within work flow
- Time-limited -Time elastic
- Indirect Learner accountability - Direct learner accountability
- Informational/technical -Transformational /Adaptive
- Seeking transfer of learning - Starts at transfer of learning
- Serving team-leaders - Co-Teaching with team leaders
- Tight boundary between learning - Loose boundaries/adjunct faculty
personnel and line personnel - Loose connections to overall -Tight connection to strategy
corporate strategy - In prep for an initiative - In support during an initiative
We’ll call the right hand column above a design for “distributed development”. (Hopefully the meaning of “distributed development” is immediately apparent.)
Establishing and maintaining a distributed developmental environment is based in the belief that there will always be room for all employees to grow. Growth comes about as an outcome of an adaptive change process, a process involving modification of behaviors and even sometimes values. In general it is safe to say that management in many a modern organization is an exercise in coordinating adaptive behaviors. To be sure managers still face many technical challenges but what keeps them up at night are the adaptive challenges and unfortunately they are often facing these challenges alone.
Attempting to teach the skill of managing adaptive change in the vacuum of a classroom full of unrelated strangers is either the height of ignorance or arrogance. I prefer to think that the perpetuation of educational models that treat adaptive issues as technical in nature is a function of misunderstanding the distinct nature of the challenges. No matter, the suggestion to establish a set of practices that acknowledge the need for “distributed development” will initially threaten the prevailing hierarchy and many an entrenched internal development staff. It will test many of the management’s large assumptions upon which past practices have been based. Eventually, with patience, persistence and some undeniable successes it will be possible to expand the world of employee development by moving the developmental horizon right into the place where it can make the biggest difference and offering it when it can make the greatest contribution, a more complete and accurate reflection of the challenges managers really face.
In Part 3 we'll examine what a "distributed development " might look like.
- Where have you been addressing adaptive issues as though they were technical in nature?
