Sigs post on ataxonomy (thanks hugh) got me thinking about one of those little postlets I add from time to time - this one about being sub-amazing.
I was trying to be cute and was thinking about the individual experience - and how there's a weird unwritten law in the workplace that everybody is expected to be incredible at their jobs all the time, (even though we all know that's not really the way the world works).
One of the things that I think is really important in any project development methodology is a resonant sense of reality. The further you get from actual human behaviour (frequently sub-amazing, easily distracted people, who like to waste time laughing and drinking) and the closer you ascribe to crazy robot idealism (where everybody is amazing all the time, and works exactly eight hours a day, and doesn't leave until the job is done), the more likely it is that you are going to be disappointed with the outcome of your project.
The first development methodology I learned was the Microsoft Solutions Framework (MSF ) version 1. The process model itself was a little dull, (and a little idealistic - think RUP or iterative waterfall) but buried within it was this fascinating idea for a project team - one that worked outside of traditional management hierarchies, and was given all the authority it needed to succeed. That really caught my attention. An MSF project team is responsible for everything. It consists of experts in all the important disciplines. All the marketing, the launch, beta programmes, logistics, test, development,deployment - everything. You basically let 'em loose and they do their thing.
Those of you who've worked with me will recognise that team approach as paramount in all my development projects over the last 5 years. Like most Project Managers, I was (still am) desperate for all my projects to succeed. Not all of them did.
But maybe the law of sub-amazing applies here too. Perhaps the reason this approach appears so attractive is because it prepares for failure, just as well as it prepares for success. One of the central tenets of the team model is that "The team succeeds or fails as a whole".
In a big company, maybe the ability to start projects that fail is the thing that sets them apart. Smaller guys can't afford to learn the lessons, without going broke. If you are a big company, and you're not embracing reality - sticking instead to those chain-of-command-my-department-vs-your-department rules, my guess is that you're constraining your brilliance by optimizing for non-failure.
It seems wherever money is concerned, people become obsessed with non-failure. Maybe more so than with success...
More great sub-amazing reading:
Eric Sink - Make more mistakes
I was trying to be cute and was thinking about the individual experience - and how there's a weird unwritten law in the workplace that everybody is expected to be incredible at their jobs all the time, (even though we all know that's not really the way the world works).
One of the things that I think is really important in any project development methodology is a resonant sense of reality. The further you get from actual human behaviour (frequently sub-amazing, easily distracted people, who like to waste time laughing and drinking) and the closer you ascribe to crazy robot idealism (where everybody is amazing all the time, and works exactly eight hours a day, and doesn't leave until the job is done), the more likely it is that you are going to be disappointed with the outcome of your project.
The first development methodology I learned was the Microsoft Solutions Framework (MSF ) version 1. The process model itself was a little dull, (and a little idealistic - think RUP or iterative waterfall) but buried within it was this fascinating idea for a project team - one that worked outside of traditional management hierarchies, and was given all the authority it needed to succeed. That really caught my attention. An MSF project team is responsible for everything. It consists of experts in all the important disciplines. All the marketing, the launch, beta programmes, logistics, test, development,deployment - everything. You basically let 'em loose and they do their thing.
Those of you who've worked with me will recognise that team approach as paramount in all my development projects over the last 5 years. Like most Project Managers, I was (still am) desperate for all my projects to succeed. Not all of them did.
But maybe the law of sub-amazing applies here too. Perhaps the reason this approach appears so attractive is because it prepares for failure, just as well as it prepares for success. One of the central tenets of the team model is that "The team succeeds or fails as a whole".
In a big company, maybe the ability to start projects that fail is the thing that sets them apart. Smaller guys can't afford to learn the lessons, without going broke. If you are a big company, and you're not embracing reality - sticking instead to those chain-of-command-my-department-vs-your-department rules, my guess is that you're constraining your brilliance by optimizing for non-failure.
It seems wherever money is concerned, people become obsessed with non-failure. Maybe more so than with success...
More great sub-amazing reading:
Eric Sink - Make more mistakes
Comments
Post a Comment