Archive
Pre-mortems in practice
I have recently started to use an exercise from Gary Klein’s very good book The Power of Intuition. This exercise is called a Pre-mortem, if you have lead or participated in a Post-mortem or an AAR then you can easily grasp this idea.
Essentially you and your project participants imagine that many months have passed and that your project has catastrophically failed. You have to make it clear, things have gone badly, very badly. But you say we do not know why. Gary suggests using a mythical crystal ball – I have found that this whimsy helps people relax and works to lighten the mood. However you explain the scenario just be certain to tell them a story which puts the participants in a mind set which allows them to accept that they have failed. This allow their minds to begin searching the present patterns in the project to find the sources of this horrible failure.
You then proceed as if you were performing a post-mortem, except that everyone is using their imaginations and drawing upon their past experiences to tell a story about what could happen. A real key to success here is to force the participants to describe specific scenarios – draw out the details and you can really surface your likely key challenges. However if you allow for vague platitudes like “lack of management support” or “budget cuts” you will not maximize the potential of this exercise.
Instead strive to get colorful, yet plausible scenarios like “server hardware too small due to unforeseen data on Foo server” or “competing project XYZ stole key contributor Bob McCodes aLot”. Being specific forces the participants to focus on things that can really happen which you can probably do something about, whereas vague causes of failure generally can not be fixed.
This has fantastic results and really allows people to accept the possibility of failure without getting stuck in a blame game or analysis paralysis. I have found that this exercise can allow people to prepare for the possibility of failure much more effectively than merely generically reviewing plans for risks and arriving at luke warm mitigation.
Bonus points if you review this list with your project team at least once a month to keep the possibility of failure fresh in their minds and allow those minds to keep looking for early warning signs which will show up if you are on the wrong track.
The Differences between Leadership and Management
First lets start with an old standby…from On Becoming a Leader by Warren Bennis:
- Managers administer, leaders innovate
- Managers ask how and when, leaders ask what and why
- Managers focus on systems, leaders focus on people
- Managers do things right, leaders do the right things
- Managers maintain, leaders develop
- Managers rely on control, leaders inspire trust
- Managers have a short-term perspective, leaders have a longer-term perspective
- Managers accept the status-quo, leaders challenge the status-quo
- Managers have an eye on the bottom line, leaders have an eye on the horizon
- Managers imitate, leaders originate
- Managers emulate the classic good soldier, leaders are their own person
- Managers copy, leaders show originality
- Managers administer, leaders innovate
- Managers ask how and when, leaders ask what and why
- Managers focus on systems, leaders focus on people
- Managers do things right, leaders do the right things
- Managers maintain, leaders develop
- Managers rely on control, leaders inspire trust
- Managers have a short-term perspective, leaders have a longer-term perspective
- Managers accept the status-quo, leaders challenge the status-quo
- Managers have an eye on the bottom line, leaders have an eye on the horizon
- Managers imitate, leaders originate
- Managers emulate the classic good soldier, leaders are their own person
- Managers copy, leaders show originality
In short managers supervise and control resources while making and following plans, whereas leaders transcend resources and plans by influencing and inspiring. Managers are often leaders but the converse of this does not have to be true, many talented leaders are not particularly good at supervision, stewardship or planning, but they can influence and inspire.
One of my favorite measures of a leader is the simplest one of all – leaders have followers – irrespective of title, rank or position – they have and gain followers who are inspired or influenced by what they say and how they act.
To close I will leave you with a quote from one of my favorite thinkers on the management and leadership:
“Management is doing things right; leadership is doing the right things.” – Peter Drucker
Qualities and Practices
I have been thinking a lot about the Qualities and Practices I work to inculcate into my teams. I think I have boiled them down to the following:
- Trust & Cohesion – Concord and trust amongst our team underlie everything.
- Agility – The ability to rapidly and easily re-orient our people, ideas and technology to adapt and shape our environment.
- Initiative – The tendency to start an action, including coming up with a recommendation and giving or helping without first being requested to do so.
- Effectiveness & Efficacy – We can quickly and efficiently realize the correct aim and focus in times of ambiguity, confusion and rapid change.
- Focus & Direction – All other activities of the group must support it and the people conducting these activities must understand what the main effort is know that they must support it.
- Management Intent – A concise, unambiguous statement of an assignments purpose and the desired end state. It may also include an assessment of the acceptable work effort and risk.
- Leadership & Culture – Assignments via task description and management intent in order to enable responsibility, accountability, initiative and trust. We focus on improving our culture, disseminating our ideals and best practices.
- Harmony & Communication – We work together, we ensure that we stay aligned by constantly communicating with each other, we collaborate and constantly seek to improve our means and methods.
- Amazing Projects – We only work on projects which are amazing, therefore we make all assignments amazing.
- Responsibility & Accountability – We empower each person to be both responsible and accountable for the success of their projects and assignments. We hold them accountable by describing unambiguous outcomes via management intent and concise assignments.
The above is a work in progress, however I am generally happy with the compactness and spirit of the language. I generally think any policy worth having has to fit on a 3 by 5 card.
Skills Acquisition
This post is a work in progress for an article about how people develop and acquire skills and what skills are particularly important for software developers…
Before we start with the specifics it is useful to examine the higher order ideas of skill acquisition and then apply those to the skills germane to software developers. A useful framework to describe this process is called the Dreyfus Model.
This model segments up the different stages of skill acquisition into distinct levels: novice, advanced beginner, competent, proficient, and expert. As we progress through the levels of capability with a given skill we move from having our analysis and actions governed by rules, to using nuanced conditional rules, to using varying levels of pattern matching, to finally fully internalizing our experiences into invariant mental representations. Experts then match these patterns against what they observe and then intuit the correct action.
The result is that experts develop an intuitive understanding of a given skill and corresponding domain. One of the interesting consequences for domain experts is that they often have difficulty explaining why they know what will happen and why they should do what they are going to do. This difficulty is caused because experts use their intuition to both understand and solve problems. Experts are often struck by certain knowledge that what they are going to do will work, but not know why. A second notable byproduct of increased skill maturity is an increase in the practitioners sense of inborn responsibility to their craft and the job at hand. True experts can usually be recognized by both their sense of responsibility and their intuitive understanding of their craft.
It is also important to recognize that experts are often the worst teachers of novices. Both novices and experts process information in very different ways: novices need rules, experts need concepts and contexts. Techniques that work when teaching a novice are maddening to an expert, and vice-versa.
The five skills or domains used during the development of correct, quality software are: analysis, specification, design, implementation, and testing. Three additional skills crucial to working in a team are: communication, documentation and planning. Growth in each of these areas is required to mature developers from novices to experts and should be used to measure the progress of developers as they expand their responsibility and influence within their teams and broader organization.
In conclusion we must focus on specifying experiences, capabilities, and responsibilities which will implicitly cross cut against the skills we desire and which we believe will have inculcated the level of maturity needed to perform the job being proffered.
About Me
Misc
Complexity, Agility and Resilience. 